maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Hellewell <>
Subject Re: Dependencies, modules, and dependency plugin
Date Fri, 01 Oct 2010 19:38:57 GMT
On Fri, Oct 1, 2010 at 1:14 PM, David Jencks <> wrote:
> On Oct 1, 2010, at 11:25 AM, Phillip Hellewell wrote:
>> We are planning to make things consistent so that this automation will
>> be possible, e.g.:
>> 1. Each "component" will live in a specific place in SVN (e.g.,
>> /components/COMPNAME).
> How does this relate to your release process?  i.e. where are the "trunk", "tags", and
"branches"?  Is each component going to be released separately, or all at once?

Each component will have its own source tree with its own trunk, tags,
and branches.  They can be released separately, but a component that
is released to customers will include all its dependencies bundled
with it.

>> 2. Each "component" will have a single pom.xml.  No multi-modules.
>> 3. Before deploying, the SVN tag name will be appended to the artifact
>> version number.
> I think that could be tricky, but I'm not an expert on this.

My idea is to have a script that I run before running mvn that uses
svn info to get the tag name and then puts that into the version in
the pom.xml.  Or even better, I should be able to put a property in
the version number, like "1.0-${svn_tag}" in the pom.xml, and just
pass in the tag name on the command-line with mvn -D.

>> 4. The SVN base url will be defined globally in the user's settings.xml
>> So I'll know exactly what to check out for that component just from
>> its name and version, which I can get from dependency:resolve.
> if you release each component separately, each components pom needs to have an accurate
<scm> tag.

Each component's pom in the Maven repository will have the SVN tag
name as part of its version number.  At the moment I don't think my
plan even requires using the scm plugin at all.

> Unless you have gigabytes of source code I would think you are making extra work for
everyone here.  why not just ask all your developers to check out all of /components from
svn and build the parts they want?  Disk space is usually cheaper and more reliable than
anyones time :-)

It's not about disk space, it's about checking out the exact code that
goes with the version of the dependency that is needed.  By appending
the svn tag name to the version in the pom.xml files, we'll always
know exactly what code that component was built from, and we'll be
able to automate checking out the source code for those components.

> If you want to automatically build dependency chains of modules you can put a parent
pom in components that lists all the individual components as modules and use the really great
maven options described here
> I haven't tried it but I think this might work even if each component does not use the
aggregator pom as its parent.

I can take a look at that, but I'm not really doing multi-modules
here.  I'm doing dependencies.  I want each component to have a single
pom.xml, and depend on other components through <dependencies>, not
through <modules>, and I'm not really sure how mixing up these
concepts could solve anything.

I do appreciate everyone's replies so far.  Based on the answers I've
gotten, I am feeling pretty confident that Maven will work for the
workflow we want to use.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message