You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2011/03/25 16:32:01 UTC
Project Structure [was Qpid and AMQP 1-0: Plans?]
One clear sub topic that emerged out of the "Qpid and AMQP 1-0: Plans?"
thread was the discussion about the project structure.
It was obvious that everybody dislikes the current structure and rightly so
as it has contributed a lot towards a lot of duplication and
management/maintainability issues.
My motivation for the following proposal is as follows.
1. Have clear sub components (preferably as sub projects),
1. With it's own clearly defined Goals and Vision
2. Independent, self contained components that can evolve independent
of the other components where possible.
i.e any change in these components should not force me to break,
re-test everything else.
3. Preferably it's own release cycle independent of the other
components as much as possible.
2. Facilitate the use of these components in other components as well as 3rd
party projects/applications with minimum dependencies
3. Avoid duplication of code, documentation, testing where possible.
4. Some of these components *may* get their own mailing list in the future.
Proposed structure.
=================
1. I would like to see the following sub projects under Qpid with their own
top level svn directory.
qpid/transport/{trunk/branch}
qpid/client/{trunk/branch}
qpid/broker/{trunk/branch}
qpid/qmf/{trunk/branch}
2. Each sub project should ideally have the following directories .
/doc , /common, /test
For example for "qpid/client" we may have,
/doc, /common, /test, /java, /cpp, /python, /ruby ........
3. Each component should strive to have a common testing strategy and reuse
as many tests as possible.
How that is done is a separate discussion and I believe there have been
several attempts at this with varying degrees of success.
4. I am sure everybody will now have questions about the build system :) -
I believe it's best to discuss that important topic in it's own thread or
atleast in a separate email from this one:).
I will wait for some response on the structure before I get into
discussing the build system.
Regards,
Rajith
Re: Project Structure [was Qpid and AMQP 1-0: Plans?]
Posted by Robert Godfrey <ro...@gmail.com>.
On 25 March 2011 17:13, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 25/03/2011 16:32, Rajith Attapattu a écrit :
>
>
> Proposed structure.
>> =================
>> 1. I would like to see the following sub projects under Qpid with their
>> own
>> top level svn directory.
>>
>> qpid/transport/{trunk/branch}
>> qpid/client/{trunk/branch}
>> qpid/broker/{trunk/branch}
>> qpid/qmf/{trunk/branch}
>>
>> 2. Each sub project should ideally have the following directories .
>> /doc , /common, /test
>>
>> For example for "qpid/client" we may have,
>> /doc, /common, /test, /java, /cpp, /python, /ruby ........
>>
>>
> Shouldn't a project be more language specific? For example I don't think
> the C++ and Java brokers/clients should necessarily be tied by the same
> release schedule. Thus I'd rather suggest a more granular structure like:
>
> qpid/client-java
> qpid/client-python
> qpid/broker-cpp
> qpid/broker-java
> etc...
>
> Would that make sense ?
>
>
I very specifically want to avoid having language specific silos. Clearly a
lot of things are going to be language specific, so a structure of
client/trunk/java
client/trunk/python
...
broker/trunk/cpp
broker/trunk/java
Is going to make sense...
However you should also have
broker/trunk/systests
Since the system test for a broker should be mostly the same (if the brokers
look alike - which they should be made to do).
On the client side what we're really looking at is, for many (most)
languages, wrapping a lower level client... thus they would be mostly the
same under the skin, dependent on a common core (and thus having a single
release schedule most likely).
-- Rob
>
>
> 4. I am sure everybody will now have questions about the build system :)
>> -
>> I believe it's best to discuss that important topic in it's own thread or
>> atleast in a separate email from this one:).
>> I will wait for some response on the structure before I get into
>> discussing the build system.
>>
>
> *cough* Maven anyone ? ;)
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Project Structure [was Qpid and AMQP 1-0: Plans?]
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 25/03/2011 16:32, Rajith Attapattu a écrit :
> Proposed structure.
> =================
> 1. I would like to see the following sub projects under Qpid with their own
> top level svn directory.
>
> qpid/transport/{trunk/branch}
> qpid/client/{trunk/branch}
> qpid/broker/{trunk/branch}
> qpid/qmf/{trunk/branch}
>
> 2. Each sub project should ideally have the following directories .
> /doc , /common, /test
>
> For example for "qpid/client" we may have,
> /doc, /common, /test, /java, /cpp, /python, /ruby ........
>
Shouldn't a project be more language specific? For example I don't think
the C++ and Java brokers/clients should necessarily be tied by the same
release schedule. Thus I'd rather suggest a more granular structure like:
qpid/client-java
qpid/client-python
qpid/broker-cpp
qpid/broker-java
etc...
Would that make sense ?
> 4. I am sure everybody will now have questions about the build system :) -
> I believe it's best to discuss that important topic in it's own thread or
> atleast in a separate email from this one:).
> I will wait for some response on the structure before I get into
> discussing the build system.
*cough* Maven anyone ? ;)
Emmanuel Bourg
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Project Structure [was Qpid and AMQP 1-0: Plans?]
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 25, 2011 at 12:03 PM, Robert Godfrey <ro...@gmail.com>wrote:
>
>
> On 25 March 2011 16:32, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> One clear sub topic that emerged out of the "Qpid and AMQP 1-0: Plans?"
>> thread was the discussion about the project structure.
>> It was obvious that everybody dislikes the current structure and rightly
>> so
>> as it has contributed a lot towards a lot of duplication and
>> management/maintainability issues.
>>
>> My motivation for the following proposal is as follows.
>>
>> 1. Have clear sub components (preferably as sub projects),
>> 1. With it's own clearly defined Goals and Vision
>> 2. Independent, self contained components that can evolve independent
>> of the other components where possible.
>> i.e any change in these components should not force me to break,
>> re-test everything else.
>> 3. Preferably it's own release cycle independent of the other
>> components as much as possible.
>>
>> 2. Facilitate the use of these components in other components as well as
>> 3rd
>> party projects/applications with minimum dependencies
>>
>> 3. Avoid duplication of code, documentation, testing where possible.
>>
>> 4. Some of these components *may* get their own mailing list in the
>> future.
>>
>> Proposed structure.
>> =================
>> 1. I would like to see the following sub projects under Qpid with their
>> own
>> top level svn directory.
>>
>> qpid/transport/{trunk/branch}
>> qpid/client/{trunk/branch}
>> qpid/broker/{trunk/branch}
>> qpid/qmf/{trunk/branch}
>>
>> 2. Each sub project should ideally have the following directories .
>> /doc , /common, /test
>>
>> For example for "qpid/client" we may have,
>> /doc, /common, /test, /java, /cpp, /python, /ruby ........
>>
>> 3. Each component should strive to have a common testing strategy and
>> reuse
>> as many tests as possible.
>> How that is done is a separate discussion and I believe there have
>> been
>> several attempts at this with varying degrees of success.
>>
>> 4. I am sure everybody will now have questions about the build system :)
>> -
>> I believe it's best to discuss that important topic in it's own thread or
>> atleast in a separate email from this one:).
>> I will wait for some response on the structure before I get into
>> discussing the build system.
>>
>> Regards,
>>
>> Rajith
>>
>
> So - I think this is my aspirational directory structure...
>
> the issue for me right now (and sticking only to the codebase I know most
> about) is that because of the current cruft in the Java... there's a whole
> load of stuff in Java that is currently defined as "common" that shared
> between the broker and Client implementations... but I wouldn't want to
> pollute "transport" with. I'm not sure what my solution to that is... maybe
> having an interim java-common-cruft directory as a peer of client and broker
> until such time as it can be made more presentable...
>
> not sure how the above structure would work for the C++ guys who will also
> currently have some shared code between client and broker I imagine...
>
>
I think we are going to through an interim period where there will be some
duplication and/or extra dependencies and directories until we sort out the
current mess.
It will probably take us a few iterations to get the code properly separated
with proper interfaces around them.
-- Rob
>
>
Re: Project Structure [was Qpid and AMQP 1-0: Plans?]
Posted by jr...@redhat.com.
On Fri, 25 Mar 2011, Robert Godfrey wrote:
> On 25 March 2011 16:32, Rajith Attapattu <ra...@gmail.com> wrote:
>> qpid/transport/{trunk/branch}
>> qpid/client/{trunk/branch}
>> qpid/broker/{trunk/branch}
>> qpid/qmf/{trunk/branch}
>
> So - I think this is my aspirational directory structure...
I'm +1 on this, too. It would allow us to make each top-level component
consistent wrt developer and user experience, and even just in the naming
it spells out the dependencies.
> the issue for me right now (and sticking only to the codebase I know most
> about) is that because of the current cruft in the Java... there's a whole
> load of stuff in Java that is currently defined as "common" that shared
> between the broker and Client implementations... but I wouldn't want to
> pollute "transport" with. I'm not sure what my solution to that is... maybe
> having an interim java-common-cruft directory as a peer of client and broker
> until such time as it can be made more presentable...
One alternative you may have considered already:
qpid/transport/{trunk,branches}
qpid/node/{trunk,branches}
qpid/qmf/{trunk,branches}
It would solve the sharing problem by exploiting the client-broker
symmetry of 1-0. Indeed, we're not going to have just clients and
brokers; eventually we'll likely have proxies, concentrators, etc.
> not sure how the above structure would work for the C++ guys who will also
> currently have some shared code between client and broker I imagine...
I think it's the same situation, with more colons.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Project Structure [was Qpid and AMQP 1-0: Plans?]
Posted by Alan Conway <ac...@redhat.com>.
On 03/25/2011 12:03 PM, Robert Godfrey wrote:
> On 25 March 2011 16:32, Rajith Attapattu<ra...@gmail.com> wrote:
>
>> One clear sub topic that emerged out of the "Qpid and AMQP 1-0: Plans?"
>> thread was the discussion about the project structure.
>> It was obvious that everybody dislikes the current structure and rightly so
>> as it has contributed a lot towards a lot of duplication and
>> management/maintainability issues.
>>
>> My motivation for the following proposal is as follows.
>>
>> 1. Have clear sub components (preferably as sub projects),
>> 1. With it's own clearly defined Goals and Vision
>> 2. Independent, self contained components that can evolve independent
>> of the other components where possible.
>> i.e any change in these components should not force me to break,
>> re-test everything else.
>> 3. Preferably it's own release cycle independent of the other
>> components as much as possible.
>>
>> 2. Facilitate the use of these components in other components as well as
>> 3rd
>> party projects/applications with minimum dependencies
>>
>> 3. Avoid duplication of code, documentation, testing where possible.
>>
>> 4. Some of these components *may* get their own mailing list in the future.
>>
>> Proposed structure.
>> =================
>> 1. I would like to see the following sub projects under Qpid with their own
>> top level svn directory.
>>
>> qpid/transport/{trunk/branch}
>> qpid/client/{trunk/branch}
>> qpid/broker/{trunk/branch}
>> qpid/qmf/{trunk/branch}
>>
>> 2. Each sub project should ideally have the following directories .
>> /doc , /common, /test
>>
>> For example for "qpid/client" we may have,
>> /doc, /common, /test, /java, /cpp, /python, /ruby ........
>>
>> 3. Each component should strive to have a common testing strategy and
>> reuse
>> as many tests as possible.
>> How that is done is a separate discussion and I believe there have been
>> several attempts at this with varying degrees of success.
>>
>> 4. I am sure everybody will now have questions about the build system :)
>> -
>> I believe it's best to discuss that important topic in it's own thread or
>> atleast in a separate email from this one:).
>> I will wait for some response on the structure before I get into
>> discussing the build system.
>>
>> Regards,
>>
>> Rajith
>>
>
> So - I think this is my aspirational directory structure...
>
> the issue for me right now (and sticking only to the codebase I know most
> about) is that because of the current cruft in the Java... there's a whole
> load of stuff in Java that is currently defined as "common" that shared
> between the broker and Client implementations... but I wouldn't want to
> pollute "transport" with. I'm not sure what my solution to that is... maybe
> having an interim java-common-cruft directory as a peer of client and broker
> until such time as it can be made more presentable...
>
> not sure how the above structure would work for the C++ guys who will also
> currently have some shared code between client and broker I imagine...
Yes, C++ currently builds common, client and broker libraries so we need some
place to store the "common to a language" stuff in the directory scheme
(/common/cpp /common/java etc.?) Another thing to bear in mind is test
dependencies: projects like c++ broker are going to want to run python and c++
client tests, so the tests (as well as the client libraries) need to be exported
by the client projects - or we need separate test projects which is what we do
currently e.g. for the python test suite.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Project Structure [was Qpid and AMQP 1-0: Plans?]
Posted by Robert Godfrey <ro...@gmail.com>.
On 25 March 2011 16:32, Rajith Attapattu <ra...@gmail.com> wrote:
> One clear sub topic that emerged out of the "Qpid and AMQP 1-0: Plans?"
> thread was the discussion about the project structure.
> It was obvious that everybody dislikes the current structure and rightly so
> as it has contributed a lot towards a lot of duplication and
> management/maintainability issues.
>
> My motivation for the following proposal is as follows.
>
> 1. Have clear sub components (preferably as sub projects),
> 1. With it's own clearly defined Goals and Vision
> 2. Independent, self contained components that can evolve independent
> of the other components where possible.
> i.e any change in these components should not force me to break,
> re-test everything else.
> 3. Preferably it's own release cycle independent of the other
> components as much as possible.
>
> 2. Facilitate the use of these components in other components as well as
> 3rd
> party projects/applications with minimum dependencies
>
> 3. Avoid duplication of code, documentation, testing where possible.
>
> 4. Some of these components *may* get their own mailing list in the future.
>
> Proposed structure.
> =================
> 1. I would like to see the following sub projects under Qpid with their own
> top level svn directory.
>
> qpid/transport/{trunk/branch}
> qpid/client/{trunk/branch}
> qpid/broker/{trunk/branch}
> qpid/qmf/{trunk/branch}
>
> 2. Each sub project should ideally have the following directories .
> /doc , /common, /test
>
> For example for "qpid/client" we may have,
> /doc, /common, /test, /java, /cpp, /python, /ruby ........
>
> 3. Each component should strive to have a common testing strategy and
> reuse
> as many tests as possible.
> How that is done is a separate discussion and I believe there have been
> several attempts at this with varying degrees of success.
>
> 4. I am sure everybody will now have questions about the build system :)
> -
> I believe it's best to discuss that important topic in it's own thread or
> atleast in a separate email from this one:).
> I will wait for some response on the structure before I get into
> discussing the build system.
>
> Regards,
>
> Rajith
>
So - I think this is my aspirational directory structure...
the issue for me right now (and sticking only to the codebase I know most
about) is that because of the current cruft in the Java... there's a whole
load of stuff in Java that is currently defined as "common" that shared
between the broker and Client implementations... but I wouldn't want to
pollute "transport" with. I'm not sure what my solution to that is... maybe
having an interim java-common-cruft directory as a peer of client and broker
until such time as it can be made more presentable...
not sure how the above structure would work for the C++ guys who will also
currently have some shared code between client and broker I imagine...
-- Rob