On Fri, Mar 25, 2011 at 12:03 PM, Robert Godfrey <[email protected]>wrote:
> > > On 25 March 2011 16:32, Rajith Attapattu <[email protected]> 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 > >
