Robert Godfrey wrote:
2008/10/1 Aidan Skinner <[EMAIL PROTECTED]>:
On Tue, Sep 30, 2008 at 10:22 PM, Robert Godfrey <[EMAIL PROTECTED]>
wrote:

Well - we've had a discussion previously where my opinion was that
having things cut primarily by language was silly, and that
broker/client was a bigger distinction... however since we primarily
cut by language first, and presuming this work depends on the Java
common stuff then i would suggest that to fit with the existing
structure it should go in Java...  however I am very open to
discussing a different structure for the project a a whole ;-)
I hate our source layout with a passion. The top level trunk containing just
qpid/ is remarkably irritating and makes merging between the branches a
PITA. I'd rather see a split along functional terms. The build system would
need to be complicated slightly to allow this, but a couple of simple
Makefiles should be sufficent. I'd think something like:

trunk/
  broker/
     java/
     cpp/
  client/
     java/
     cpp/
     ruby/
     python/
  tools/
     management/
        jmx-gui/ <-- eclipse plugin
        jmx-cli/ <-- JMX console
        qman/

etc.

+1 From me... The only caveat being that there is an awful lot of
codec and infrastructure type stuff that it makes sense to share
between a client and a broker written in the same language (i.e. most
of the stuff that is currently in java/common for Java (and I'm sure
C++ has similar).  IMHO the Java client should have more in common
functionality and release schedule wise with the C++ client than it
does with the Java Broker... otherwise what we will get are two
divergent products: a Java Broker/Client and a C++ Broker/Client (with
Ruby/Python et al being left somewhat in the shade...

however we've had this discussion before and I remember being in the
minority :-)

-- Rob

This might be a bit yak shavey though. I'd really like to have a clearer
idea of where we are with the management tooling and where we're going with
it. It seems very ad-hoc atm. A plan would be good.

- Aidan

--
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt


This is pretty major shuffle, not sure such a move around is a good idea for M4. It is going to be build
hell for a few weeks to make such a big change.

- few things the structure above does not handle, if the agents etc on each lang on top of the tools. - where do the common generators live? (qmf-gen) which broker and agents have a dependency on
- do we introduce a high level 'common' directory'?
- do we create an agent dir under client and then repeat the language structure under that?

Carl.

Reply via email to