Thanks again for all your help, although I've come up with a slightly different solution. Was not comfortable splitting the config + jars up, especially as I am going to have a minimum of 20 odd modules in this project (its fairly large / diverse).
So if anyone is interested / has this problem this is what I did: I used the src/main/resources folder of each module. In there I have created 3 folders mpApp-root, myApp-config, myApp-otherConfig (well, not those exact names). Each module / artifact is a jar. with that inside, e.g: Parent --ModuleA ----src/main/java ----src/main/resources ------src/main/resources/myApp-config ------src/main/resources/myApp-otherConfig ------src/main/resources/myApp-root --ModuleB ----src/main/java ----src/main/resources ------src/main/resources/myApp-config ------src/main/resources/myApp-otherConfig ------src/main/resources/myApp-root I created another module (myApp-dist) and made it depend on all other modules I want to distribute in my test build (eventually this will probably be a separate project). Its the pom in this module I define my overall build. The build defines 3 custom assemblies: 1. uses dependencySet with exclude "myApp-*/**" to jar up all dependencies into a monster jar. i.e. I get just a jar of all classes without special resource folders. 2. uses dependencySet with include "myApp-*/**" to just includes the myApp-* special folders, this assemble outputs to format "dir". 3. Defines filesets to include in a tar.gz. So the main dist jar created by the 1st assembler and then all the special folders. The cool thing is you can define the output directory so myApp-root contents goes to ./, myApp-config goes ./config etc. The result is along the lines of a tar.gz with contents: ./myApp-version/config ./myApp-version/otherConfig ./myApp-version/artifact-version-dist.jar ./some.properties ./readme.txt Sucks a little creating special folders that do magic things in the build but its not too bad. One odd little side effect is putting a - in the resource folder name means it cant be used as a java package... handy to ensure some random java package does not clash with a special folder and accidentally get its .class excluded from the dist jar. Also to get this building and packaging locally, mvn install is quite a useful command :P Tried gradle, think it had the potential to suit my build better but ultimately using it with eclipse, defining new modules etc, it was clunky. Cheers, Jon Jon Paynter wrote: > > On Tue, Nov 9, 2010 at 8:34 AM, jon.mithe <jon.mi...@gmail.com> 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. > > -- View this message in context: http://maven.40175.n5.nabble.com/Custom-assembly-of-multi-module-project-tp3256773p3262443.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
