Thomas, Thanks! I am still very, very new to this and am a little confused.
I would like to be able to invoke one pom file to build the suite of jars all with the same version. I.E. when the source changes I want to bump the version number in the main parent pom and re-build, test, and deploy all the jars. But when I try a parent project with modules things start to break down for me. I want the module with the java source to build first, then I want all the other modules to use that first guys jar, (unjar it), shove the properties file in, re jar it, then run the tests. Problem is that I cannot have the source module at the same level as the properties modules, can I? I guess I am having trouble even setting up what this project would look like. Thanks for any more help. On Thu, May 3, 2012 at 11:21 PM, Thomas Sundberg <[email protected]> wrote: > On Fri, May 4, 2012 at 3:36 AM, Billy Newman <[email protected]> wrote: > > A while back I had some questions about building some jars that only > differ > > in the properties files stored in the jar. I was going to use > classifiers > > to differentiate the jars but was advised against it. > > > > My company has many, many different deployments and for these jars they > > want to keep the properties file packaged with the jars. > > > > I was think about maybe having a parent project that contains the java > > source (since the code is the same for each jar). Then maybe child > modules > > that have the properties files in the resources directory. Then each > child > > module can build the java code and throw in the properties file ( i dont > > really care that if I build the same byte code many time as the build is > > very fast). This idea came to mind because I have unit tests for the jar > > files that test the code against the different properties files. I.E. > when > > I build the source and throw in the properties the unit test will run). > So > > each module will run the unit tests against its property file. > > > > Unfortunately my idea only really works in my head. My problem is that > the > > parent module cannot contain the java source code as the parent module > > needs to be a pom. > > If I were to build something similar to what you described, I would > keep the production java source in one module that produces a jar. The > modules with the properties would then be dependent on the production > code jar module and produce the jars with the property file and > include the production jar. I would probably keep the test classes > with each property module. I assume the with different properties, > there will be different result for the tests. > > All modules could reside on the same level in a multi module project > or you could have some kind of hierarchy with the property modules > separated. It really doesn't matter from a Maven perspective. > > Explore the maven-assembly-plugin [1] for more inspiration on how to > include a jar within a jar. I wrote an example about how to create an > executable jar from Maven a while ago [2], it is similar in the sense > that packages all it's dependencies in the resulting jar. > > Maybe this can inspire you to a new idea? > Thomas > > > > > > [1] http://maven.apache.org/plugins/maven-assembly-plugin/ > [2] > http://thomassundberg.wordpress.com/2011/03/05/create-an-executable-jar-from-maven/ > > > > Any one have any ideas on how I can setup my maven project hierarchy such > > that the code lives in one place and the resources live in another > (maybe a > > child module). Such that when I build I build from the same source each > > time but insert a different properties file, then test each one. > > > > I think they can all live in one group, but have different artifactids: > > ie. group - com.test.module > > artifacts - module-type1.jar, module-type2.jar, module-type3.jar > > > > Thanks in advance for any ideas. > > > > -- > Thomas Sundberg > M. Sc. in Computer Science > > Mobile: +46 70 767 33 15 > Blog: http://thomassundberg.wordpress.com/ > Twitter: @thomassundberg > > Better software through faster feedback > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
