aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: relativePath thing..... was Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml
Date Wed, 16 Nov 2011 15:40:22 GMT
On 16 November 2011 01:49, Daniel Kulp <> wrote:
> 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:
> 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.

+1 I totally agree. The recent release caused some instability (not
the only cause, but the one I feel responsible for) and I moved it off
into a branch when I realised that was the only feasible option.

> 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

+1 to that too ... it's becomes a case of people opening JIRAs /
submitting patches etc when they see problems.

> 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.

I'm afraid I can't help here much as I don't have these proxy/firewall
restrictions. What do you suggest when a new feature / bug fix depends
on a bug fix to a dependency outside Aries? A snapshot dependency is
often needed for this until the dependency project is released.

> 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.  :-)

I don't think we've dismissed this. I didn't realise it was a problem
and didn't know this was a solution :-)

> 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.

If you're referring to the oct-2011-release branch, sorry I'm getting
to it. I need to release 0.4.1 of blueprint-core, blueprint-cm,
blueprint-bundle and blueprint-itests. Either I can merge the branch
into trunk then create a new branch for the release, or I can do the
release from the existing branch then merge. In fact I'm minded to do
the former. Thoughts?

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

Thanks for bringing all this up. I certainly wasn't aware of some of this.

> --
> Daniel Kulp
> Talend -

View raw message