On Tue, Nov 9, 2010 at 8:34 AM, jon.mithe <[email protected]> wrote:
> > Interesting. I think I have found some unpacking elements in the assembly > plugin when I write my own descriptor. So it may be possible... needs more > research. > > I think I understand what you are saying about separating the config from > the binaries. But I'm not sold on the idea of creating it in a different > project. The way I'm trying to do it, the code + the config is completely > separate, i.e. its not jar'ed with the classes and I do not have any issues > with duplication. The code and the config is a tightly linked enitity so I > feel uneasy about splitting them into 2 separate projects (albeit linked by > a dependency). > > What concerns me most is I feel that doing it this way would be a work > around for the way maven builds, i.e. I'm starting to think my project does > not seem to fit nicely with maven way of doing things :/ > > Thanks again for all you help, I'm not giving up on maven yet but I think I > need to take a more in depth look at gradle and see if it fits this any > better. > I recently finished solving a very simmilar problem. with trying to package things. Before conversion to maven, the structure looked like this (yes its using ant) Parent Project --Common configs --Module A ---- moduleA.jar ---- moduleA.ear ---- moduleA.war ---- src/config ---- build.xml --Module B ---- moduleB.jar ---- moduleB.ear ---- moduleB.war ---- src/config ---- build.xml /dist/ModuleA/ModuleA.ear /dist/ModuleA/config/ /dist/ModuleB/ModuleB.ear /dist/ModuleB/config/ Once all the dust settled, I ended up with a structure like this: Parent Project --Common Configs ----src/main/other_resource_directory --Module A ----src/main/config ----ModuleA_jar -------src/main/java ----ModuleA_war -------src/main/webapp ----ModuleA_ear -------src/main/META-INF ----ModuleA_Package -------src/main/assembly -------target/ModuleA.zip --Module B ----src/main/config ----ModuleB_jar -------src/main/java ----ModuleB_war -------src/main/webapp ----ModuleB_ear -------src/main/META-INF ----ModuleB_Package -------src/main/assembly -------target/ModuleB.zip Packaging_project ---target/dist/ModuleA/ModuleA.ear ---target/dist/ModuleA/config/ ---target/dist/ModuleB/ModuleB.ear ---target/dist/ModuleB/config/ The key here was first to seperate things out so each project produces exactly one _binary_ artifact. Then to seperate the packaging/assembly from the compiling. In moduleA_package and moduleB_package, the resulting zip file is marked as attached, so it gets stored in the repository. the packaging_project then depends on only whats needed to distribute - which is just the zip file. The zip file is unpacked into its proper directory. the moduleA_package and moduleB_package are assemblies that do filtering and copying of the config files. its not a very elagant solution to the common configs, but it does work.
