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 Sun, 03 Oct 2010 21:26:12 GMT
Thanks; I will take a look at the release and versions plugin to see
if they can help.


On Fri, Oct 1, 2010 at 4:57 PM, David Jencks <> wrote:
> On Oct 1, 2010, at 12:38 PM, Phillip Hellewell wrote:
>> 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.
> I don't think that will work very well.  I think using the release plugin will work
>>>> 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.
> I recommend using the release plugin for releases.  In my experience it's pretty hard
to get everything right for a release without it.  I think you can script the release plugin
so your script will feed in the svn rev as part of the tag name.
>>> 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.
> checking out a tag and providing an environment where a developer might think its ok
to modify it seems pretty dangerous to me.  The release plugin can be configured to produce
a zip or tar.gz of the entire project source which then gets in the maven repo.  Relying
on this for tagged source code might be safer.
>>> 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.
> if you have say 100 components with a dependency graph with maybe 1000 edges you may
want to find out whether a change in one module produces obvious breakage in those that depend
on it, without doing a full build.  If the components are arranged as modules in an aggregator
project, you can do this with
> mvn clean install -pl :X -amd
> where  X is the module you changed.  Maven will figure out all the components that
could be affected, using the dependency graph, and build all of them in order.  I find doing
this by hand implausible.  As I said, I haven't tried this where the components don't have
the aggregator pom as parent, but suspect it will still work.  As long as the components
don't have the aggregator pom as a parent, you can still release them individually.
> You might also want to look at the versions-maven-plugin which is very handy for updating
dependency versions.
>> 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.
> good :-)
> david jencks
>> Phillip
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message