Defining a binary distribution is necessary for packaging (debian and other) but also gives other advantages such as a more well-defined deterministic output from the build process.
What I mean with a binary distribution is:
A project structure which makes it possible to create an archive with all compiled bytecode in different jar files etc that then can later be unpacked, configured and the enterprise parts deployed to an application server and then client parts run directly with its configuration read from configuration files.
The binary distribution is created by compiling all sources to different jar/war-files. Configuration such as setting values in properties files, web.xml, ejb-jar.xml and persistence.xml and the decision on which modules to include in the final ear file is posponed to deploy time. This means that the output of the build does not depend on the configuration which should simplify debugging of build related problems.
To support this a lot of changes are needed:
- Change from pre-processing (configuration at compile-time) to post-processing (configuration at deploy time)
- Currently different configuration changes what class-files are included in the resulting application. This must change so the smallest unit of a module is a jar-file. At configuration time a jar-file is either completly included or not and a jar-file always contains the same set of class files.
In addition it is also preferable that:
- Classes with the same (fully qualified) class name should not be packaged in multiple jar files. If different applications wants to reuse some classes, those classes should be packaged in one or more jar files to be put on the classpath of all application wanting to make use of them.
- As far as possible keep all classes from the same package in the same jar. There might be some motivated exceptions to this one.