I think Martin's suggestion to have a pom for project file generation is a great one !
Regards, Marnie On Mon, Jan 10, 2011 at 2:12 AM, Martin Ritchie <[email protected]> wrote: > On 4 January 2011 18:07, Robert Godfrey <[email protected]> wrote: > > On 4 January 2011 16:59, Andrew Kennedy <[email protected] > >wrote: > > > >> On 4 Jan 2011, at 15:06, Robert Godfrey wrote: > >> > >>> On 4 January 2011 15:36, Rafael Schloming <[email protected]> wrote: > >>> > >>>> Personally I think jumping into major build system changes at this > point > >>>> is > >>>> going to be a waste of time. I think past discussions have made clear > >>>> that > >>>> changing *how* the various components and artifacts are built is > really > >>>> just > >>>> going to introduce more churn, and we have more basic issues to > address > >>>> around *what* components and artifacts are delivered and how the code > is > >>>> structured/divided into modules. > >>>> > >>> > >> However, actually making the change to a modern build system that forces > >> modularity and componentisation would accomplish this, > > > > > > This doesn't follow. The existing "modules" have survived transition > from > > ant to maven and back to ant again... So the use of ant or maven (or > indeed > > make) doesn't guarantee modularity, or indeed help you to define *useful* > > modules. > > > > > >> while also prompting discussion and showing up things that would > otherwise > >> be ignored. Basically, if someone attempted to implement the changes, > that > >> person would discover the cruft and unwanted dependencies and > complexities, > >> hypothetically, and would be in a position to report on or fix them. > >> > >> > >> +1 from me too. I'm not sure what we think the objective of moving to > >>> maven > >>> now would be. I agree with Emmanuel in the other thread that > delivering > >>> official artefacts for Maven repos is a sensible objective, but I don;t > >>> think we need to/should move to Maven simply for that. > >>> > >>> As Rafi says above, I think we need a sensible discussion on what the > >>> components and artefacts are (across the whole project, not just the > Java > >>> part) before jumping into tool selection/change. Related, (at least as > >>> far > >>> as maven is concerned), is the notion of (external) dependency > management > >>> - > >>> however again I think we want to define our desired outcome before > >>> selecting > >>> the tool. > >>> > >>> I think the discussion on modules / components / artefacts is probably > one > >>> of the more important things we have to do in 2011. > >>> > >> > >> -1 Mostly. > >> > >> Discussion is great. We seem to have agreed we need to have one of > those. > >> However, there is always a lot of inertia around changes to 'The Way We > Have > >> Always Done It' which is obvious from the above and other comments in > this > >> threa > >> > > > > But it's *not* the way we've always done it. > > > > We've done maven before. > > > > It didn't help. > > > > In fact there were a lot of issues with maven at the time... however > that's > > not really the point. Even if all the issues with maven have > subsequently > > been solved, that doesn't help *us* structure and manage our project (by > > which I mean the whole of Qpid, not just Java) in a sensible way. > > > > > >> I think the move to Maven is a no-brainer, this is 2011 and it should be > >> done no matter what. We should also be using that work as a springboard > for > >> the discussion we need to have. > >> > >> > > I'm not saying -1 to Maven necessarily, but I'm asking what criteria > we're > > using to make the decision. Given that we have had experience of maven2 > in > > the project before, and it didn't address (in itself) what I consider to > be > > our issues around build, release, modularisation, etc. Changing the > tooling > > when we aren't clear what we want the end result to be seems an odd way > to > > go about things. > > > > I would also add that doing things without thinking and talking about > them > > first (while perhaps something I am notorious for) is not necessarily the > > best way to go about things, so -1'ing discussion seems a little odd ;-) > > > > -- Rob > > This discussion appears to have gone a bit off track from the initial > problem. > > Andrew was interested in checking in Eclipse project files to make it > easier for new developers on the project to get the code loaded in to > an IDE. > > I suggested maven could be useful for this as all the major IDEs have > support for either the pom.xml or maven has a plugin to generate the > required project files. > > If we added a maven pom.xml purely for project setup I think this > would add real benefit to our project as it would reduce one of our > barriers to entry. There would be no impact to the way any work is > currently carried out. I think this is a relatively small change > especially as it would have no impact to any of the existing > developers as I'm sure we all have our IDEs setup. > > I am of course open to other suggestions to solve the initial problem > statement of finding a straightforward way to get the java project > files into an IDE. > > Martin > > >> Cheerz, > >> > >> Andrew. > >> -- > >> -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ; > >> -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ; > >> > >> --------------------------------------------------------------------- > >> Apache Qpid - AMQP Messaging Implementation > >> Project: http://qpid.apache.org > >> Use/Interact: mailto:[email protected] > >> > >> > > > > > > -- > Martin Ritchie > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
