qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: Eclipse project files for Java code
Date Wed, 12 Jan 2011 11:23:39 GMT
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 <ritchiem@apache.org> wrote:

>  On 4 January 2011 18:07, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> > On 4 January 2011 16:59, Andrew Kennedy <andrewinternational@gmail.com
> >wrote:
> >
> >> On 4 Jan 2011, at 15:06, Robert Godfrey wrote:
> >>
> >>> On 4 January 2011 15:36, Rafael Schloming <rafaels@redhat.com> 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:dev-subscribe@qpid.apache.org
> >>
> >>
> >
>
>
>
> --
> Martin Ritchie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message