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
