qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: Eclipse project files for Java code
Date Tue, 04 Jan 2011 18:07:41 GMT
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*

> 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

> 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

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