+1 (BIG PLUS ONE - see my tirade on the svn commit thread) :-) On Wed, Oct 1, 2008 at 3:28 PM, Martin Ritchie <[EMAIL PROTECTED]> wrote:
> 2008/10/1 Rajith Attapattu <[EMAIL PROTECTED]>: > > On Wed, Oct 1, 2008 at 5:02 AM, Aidan Skinner <[EMAIL PROTECTED]> wrote: > > > >> 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. > >> > >> 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 > >> > > > > I like the idea a lot, but not sure how the following is handled. > > > > 1) As Rob pointed out, where is the common code going to live? Both java > and > > C++ have common code thats shared by the broker and client. > > > > 2) I am not sure if I agree with the tools source structure. Shouldn't it > be > > by language as well? > > Bcos currently we have tools in java, python and c++ (all though c++ > is > > more infrastructure than a tool) > > > > 3) The impact on the build system? I am sure ant and make could handle > > this, but as Carl pointed out it will be a bit tricky for the first few > > weeks. > > > > My biggest concern is (1). If we can find a proper solution to that, then > I > > think the rest can be worked out. > > Also it maybe best if we attempt this after M4 (if are to pursue this > path). > > > > Regards, > > > > Rajith. > > Whilst I'm all in favour of streamlining our development and do quite > like the idea of having all the clients in one place.. it might even > make me more tempted to actually work on the other clients. > > The moving of source around is a real PITA, it upsets everyones > development and only exhasperates the merge issue as we introduce a > third structure should we ever wish to merge a change from M4 to M3.x > and M2.x > > Perhaps I just need some more discussion about the benefits of making > the change. > > Martin > > -- > Martin Ritchie >
