qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Project Structure [was Qpid and AMQP 1-0: Plans?]
Date Mon, 28 Mar 2011 18:01:00 GMT
On 03/25/2011 12:03 PM, Robert Godfrey wrote:
> On 25 March 2011 16:32, Rajith Attapattu<rajith77@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

View raw message