Question to developers:
How you think is the best way to package and distribute add-ons from the Vaadin Add-ons Directory?
Given:
Add-on shop of the Vaadin.
Status:
No good for maintenance, because each JAR has to be recompiled.
Required result:
An RPM package of a particular add-on has contain a JAR with it, so anyone can install this RPM on his Linux server and get it globally available.
This way we hope should:
Allow us to package most of the Add-on directory (if not everything)
Use them globally for every application, so each WAR will just reference the same library
Update them globally, as patches comes out, so every software will be patched and not vulnerable or buggy
Expecting an answer on the forum within one minute of the original posting is usually a bit unrealistic… it has happened but only very exceptionally.
The directory dictates the binary packaging format of the add-on, but they are built by many different people in many different ways - using Ant, Maven, Eclipse export, by hand… Their sources that may or may not be available in some kind of a public version control system, as separate JARs or in some other form. The builds of some add-ons also depend on the environment in which they are compiled (documentation processing tools, testing environments etc.). Vaadin does not dictate how to build an add-on, and would hurt the add-on ecosystem significantly if requiring e.g. everyone to use - or not use - Maven.
What usually needs to be recompiled by most developers, though, is the widgetset used in the application - not the add-ons themselves. Users might also want to have different widgetsets for different applications to optimize them, to only include the necessary widgets. If an add-on includes client-side code, it has to include the client side source code, and many add-ons do come with all the source code but not necessarily everything else to build the add-on ZIP package, and maybe not even everything needed for the JAR.
Further complicating the issue, add-on dependencies on version numbers of other components (Vaadin, libraries, other add-ons) are not expressed in a formal manner, nor necessarily even checked by add-on authors. Simply updating an add-on may break applications depending on how stable its APIs are etc.
If you are aiming at a system where everything shared in the system is compiled by you from the sources, unfortunately there is no automatic way to do that for all the directory add-ons. Some might be amenable to such processing, and often just building the JAR is simpler than building the add-on ZIP package, but you would need to work a lot on a case-by-case basis for different add-ons.
Don’t make your software turn to a fossil (that’s what happens to a Java stuff in nine fives)
Audit things you’ve providing and make sure there are no garbage
Package them properly in order to provide updates via standard way on various platforms
Keep architecture straightforward for everyone, so everybody will use the same way to make these plugins
And yes, you also want to make sure that nobody is using binary JAR with a wrong license even by mistake (happens really a lot and often — Play Framework for example, that we cannot package and provide in openSUSE any longer). In fact, Vaadin 6 has also fossilized dependencies, where only binary JARs are available and that’s very frustrating. Well, if I were you, I would fix that in Vaadin 7, actually.
For those people who have Mavenized their add-ons, the ability to push the source jar would certainly help.
For third-party dependencies - for example the ICEpush jars that for a long time were not easily found through maven, copy them to an Artifactory. Heroku allows people to add an extra “repository” section to their project for things that are not available through Maven Central.
If I recall correctly, since very recently, Directory also serves Maven source and javadoc JARs via its Maven repository if they are included in the ZIP package of an add-on.
