qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ritchie <ritch...@apache.org>
Subject Re: Eclipse project files for Java code
Date Mon, 10 Jan 2011 02:12:36 GMT
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.


>> 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

View raw message