On 25 March 2011 16:32, Rajith Attapattu <rajit...@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
