You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robert Godfrey <ro...@gmail.com> on 2008/09/30 20:12:15 UTC
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java: client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/ client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
I agree with Rafi - this should be separated from the client into a
separate top-level module of the java codebase
-- Rob
2008/9/30 Rafael Schloming <ra...@redhat.com>:
> Why was this stuff added to the client module? Isn't it a stand-alone app?
>
> --Rafael
>
> arnaudsimon@apache.org wrote:
>>
>> Author: arnaudsimon
>> Date: Mon Sep 29 05:02:54 2008
>> New Revision: 700077
>>
>> URL: http://svn.apache.org/viewvc?rev=700077&view=rev
>> Log:
>> qpid-1284: Qman on behalf Andrea
>>
*snip*
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java: client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/ client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by 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.
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java: client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/ client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by Aidan Skinner <ai...@apache.org>.
On Wed, Oct 1, 2008 at 1:34 PM, Carl Trieloff <cc...@redhat.com> wrote:
> 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.
Yeah. I have no desire to do this imminently.
- 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
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java:
client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/
client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Godfrey wrote:
> 2008/10/1 Aidan Skinner <ai...@apache.org>:
>
>> 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.
>>
>
> +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.
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java: client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/ client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by Robert Godfrey <ro...@gmail.com>.
2008/10/1 Aidan Skinner <ai...@apache.org>:
> 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.
+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
>
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java: client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/ client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by Aidan Skinner <ai...@apache.org>.
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
--
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
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java: client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/ client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by Robert Godfrey <ro...@gmail.com>.
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 ;-)
-- rob
2008/9/30 Carl Trieloff <cc...@redhat.com>:
>
> I might not want to say do this but here it comes.....
>
> do we not want to create a qmf directory under qpid, and the repeat the
> java, cpp, python etc dir structure
> under that for all the qmf bridges, tools and consoles etc.
>
> Carl.
>
>
> Robert Godfrey wrote:
>>
>> I agree with Rafi - this should be separated from the client into a
>> separate top-level module of the java codebase
>>
>> -- Rob
>>
>> 2008/9/30 Rafael Schloming <ra...@redhat.com>:
>>
>>>
>>> Why was this stuff added to the client module? Isn't it a stand-alone
>>> app?
>>>
>>> --Rafael
>>>
>>> arnaudsimon@apache.org wrote:
>>>
>>>>
>>>> Author: arnaudsimon
>>>> Date: Mon Sep 29 05:02:54 2008
>>>> New Revision: 700077
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=700077&view=rev
>>>> Log:
>>>> qpid-1284: Qman on behalf Andrea
>>>>
>>>>
>>
>> *snip*
>>
>
>
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java:
client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/
client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by Carl Trieloff <cc...@redhat.com>.
I might not want to say do this but here it comes.....
do we not want to create a qmf directory under qpid, and the repeat the
java, cpp, python etc dir structure
under that for all the qmf bridges, tools and consoles etc.
Carl.
Robert Godfrey wrote:
> I agree with Rafi - this should be separated from the client into a
> separate top-level module of the java codebase
>
> -- Rob
>
> 2008/9/30 Rafael Schloming <ra...@redhat.com>:
>
>> Why was this stuff added to the client module? Isn't it a stand-alone app?
>>
>> --Rafael
>>
>> arnaudsimon@apache.org wrote:
>>
>>> Author: arnaudsimon
>>> Date: Mon Sep 29 05:02:54 2008
>>> New Revision: 700077
>>>
>>> URL: http://svn.apache.org/viewvc?rev=700077&view=rev
>>> Log:
>>> qpid-1284: Qman on behalf Andrea
>>>
>>>
>
> *snip*
>
Re: svn commit: r700077 [1/4] - in /incubator/qpid/trunk/qpid/java:
client/src/main/java/org/apache/qpid/management/ client/src/main/java/org/apache/qpid/management/configuration/
client/src/main/java/org/apache/qpid/management/domain/ client/src/mai
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> I agree with Rafi - this should be separated from the client into a
> separate top-level module of the java codebase
There are top level "tools" and "management" directories which may also
be appropriate places.
--Rafael