On 16 November 2011 01:49, Daniel Kulp <[email protected]> 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.
+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 > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com >
