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
