maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billy Newman <>
Subject Re: using maven modules
Date Sat, 05 May 2012 20:53:34 GMT

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

Thanks for any more help.

On Thu, May 3, 2012 at 11:21 PM, Thomas Sundberg <> wrote:

> On Fri, May 4, 2012 at 3:36 AM, Billy Newman <> 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]
> [2]
> >
> > 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:
> Twitter: @thomassundberg
> Better software through faster feedback
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message