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 <[email protected]> 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 > > [email protected] > > http://dankulp.com/blog > > Talend - http://www.talend.com > > -- Alasdair Nottingham [email protected]
