maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Dependencies, modules, and dependency plugin
Date Fri, 01 Oct 2010 22:57:45 GMT

On Oct 1, 2010, at 12:38 PM, Phillip Hellewell wrote:

> On Fri, Oct 1, 2010 at 1:14 PM, David Jencks <david_jencks@yahoo.com> 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 better.

> 
>>> 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
>> 
>> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
>> 
>> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message