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
