Re: relativePath thing..... was Re: svn commit: r1202350 - in /aries/trunk: application/application-modeller/pom.xml quiesce/pom.xml

[Alasdair Nottingham <no...@apache.org>]

I agree, I think trunk should be the latest, although I wasn't following
the release closely enough to know why this wasn't the case.

On 16 November 2011 01:54, David Jencks <da...@yahoo.com> wrote:

> I think this reflects what we discussed.   Many thanks to Dan for putting
> up with my argumentative nature, working hard to fix the problem,
> explaining it to me :-) and documenting everything here :-D
>
> thanks
> david jencks
>
> On Nov 15, 2011, at 5:49 PM, 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:
> >
> >
> http://irclogs.dankulp.com/logs/irclogger_log/apache-aries?date=2011-11-16,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
> > thoughts!
> >
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
>
>


-- 
Alasdair Nottingham
not@apache.org