Code Layout change

[Martin Ritchie <ri...@apache.org>]

2008/10/1 Rajith Attapattu <ra...@gmail.com>:
> On Wed, Oct 1, 2008 at 5:02 AM, Aidan Skinner <ai...@apache.org> wrote:
>
>> On Tue, Sep 30, 2008 at 10:22 PM, Robert Godfrey <ro...@gmail.com>
>> 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

Re: Code Layout change

[Marnie McCormack <ma...@googlemail.com>]

+1 (BIG PLUS ONE - see my tirade on the svn commit thread) :-)

On Wed, Oct 1, 2008 at 3:28 PM, Martin Ritchie <ri...@apache.org> wrote:

> 2008/10/1 Rajith Attapattu <ra...@gmail.com>:
> > On Wed, Oct 1, 2008 at 5:02 AM, Aidan Skinner <ai...@apache.org> wrote:
> >
> >> On Tue, Sep 30, 2008 at 10:22 PM, Robert Godfrey <
> rob.j.godfrey@gmail.com>
> >> 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
>