On 03/25/2011 12:03 PM, Robert Godfrey wrote:
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, RajithSo - 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-subscr...@qpid.apache.org
