aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject relativePath thing..... was Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Date Wed, 16 Nov 2011 01:49:24 GMT

On Tuesday, November 15, 2011 2:36:01 PM David Jencks wrote:
> On Nov 15, 2011, at 10:59 AM, Daniel Kulp wrote:
> > On Tuesday, November 15, 2011 10:50:31 AM David Jencks wrote:
> >> -1 to the <relative-path>s
> >> 

> > I feel pretty strong that they SHOULD be there.    IMO,  we need to be
> > able to just checkout trunk and run "mvn install"  and have it build
> > and test and such.  That's how maven projects work.     Having it work
> > properly "out of the box" for new users, IMO, trumps aesthetics of a
> > release tag where the relativePath would be ignore anyway.   Without
> > them, you get all kinds of warnings (if they work at all).
> Since you are proposing the change, can you explain exactly what the problem
> you are trying to solve is and how to reproduce it?  I haven't encountered
> _any_ problems that this change would solve so it seems like a bad idea
> with no redeeming features.  Also, what are the warnings you are referring
> to?

David and I had a chat on IRC.  Log at:,Wed

to discuss this and clear the air a bit.  Here is my summary:  (actually,I 
think this summary is longer than the original IRC log)   David, please 
correct anything I got wrong or missed.

Basically, IMO, any potential developer should be able to checkout Aries trunk 
(or ANY other Maven based project) and run "mvn install" and have it just 
work.  They should not need to go to some web site or README or anything to 
figure out how to build the project.   That's the whole point of Maven.  
Conventions.  If it doesn't work, you are doing something wrong.     *THAT* is 
important to me and is the basic problem I'm trying to solve.   I also believe 
that the resulting build should be SUCCESSFUL and should also be error and 
warning free as much as is possible.   That is secondary though.    Still 
tackling the first part.  :-)    I also *prefer* that it work behind a 
reasonably setup proxy/firewall (read: no snapshot deps not part of the 
build), but that is definitely tertiary. 

In our specific case, we failed miserably.   Due to the snapshot parents, 
maven could not resolve the parents without first going to the web site to 
find out we need to build parents first, which is wrong.   David and I 
discussed 4 possible options:

1) Add relativePath entries to all the poms.   This was simple for me to do 
which is what I did.  It's also consistent with what other projects I'm 
involved in have done (CXF, Camel, Maven, etc...) which I why I didn't think 
it would be a big deal.   Heck, if the Maven folks themselves recommend using 
it and are using it for their plugins and such, I would think it would be OK.   
Apparently not.  :-)

2) Do NOT use SNAPSHOT parents - if the parents are in Central, not a problem.   
I didn't realize the 0.5 versions were released, otherwise I think I would 
have gone this route.   Even easier.  

3) Combination of 1 and 2 - don't use SNAPSHOT parents unless you REALLY have 
to, in which case use a relativePath until the parent is released.  

4) For poms that have a snapshot parent, add a <repositories> entry to add the 
apache.snapshot repo in it so it can resolve the parent.   Again, when parent 
is released, the repositories entry can be removed.

Since 0.5 is released, I'll go back tomorrow and flip to #2.   However, this 
does mean that if we need a 0.6 version, when we create the SNAPSHOTS, we'll 
need to remember to do either #3 or #4 until released.  

On a side note: it *really* bothers me that there is work that has been done 
on a branch that is not reflected on trunk.   IMO, trunk should always reflect 
the most up-to-date status of the code.   

Anyway, if anyone else has any input into this, feel free to add their 

Daniel Kulp
Talend -

View raw message