On 4 Jan 2011, at 18:07, Robert Godfrey 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:
[...] 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.
Half agree here. I do think the Maven dependency management (or Ivy
bor whatever) is a step forward and would help to enforce some rigour
i our Java component structure.
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.
Agree again, this is an excellent objective and should be part of the
list bof things we want to accomplish in 0.10 no matter what build
system is used.
I think the discussion on modules / components / artefacts is
probably one
of the more important things we have to do in 2011.
-1 Mostly.
This is for the disregarding of Maven only. See below.
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
[...]
But it's *not* the way we've always done it.
We've done maven before.
It didn't help.
I looked at the old JIRAs related to Maven before I started thinking
about this, and I felt that many of these issues were now solved or
soluble with newer releases of Maven 2.
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.
True, I'm thinking in a Java-centric way here, and freely admit i
don't have any knowledge of the C++ structure and minimal python
exposure.
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.
Agree. I think we do need to be clear what we want the end result to
be. On initial investigation, I think that Maven makes (some) of the
desired goals simpler.
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 ;-)
Sorry, no, that's not what I meant... I Meant -1 on the no Maven.
Like I said, discussion is *good* and I was hoping that the moving to
Maven would promote said discussion.
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]
