Rafael Schloming wrote:
Ted Ross wrote:
Good idea Carl,
Here's the current structure:
qpid/cpp/src/qpid/agent - C++ agent library
qpid/cpp/src/qpid/console - C++ console library
qpid/cpp/src/qpid/management - Common files and components for
managing the broker
qpid/python/qmf - Python modules
qpid/ruby/lib/qpid/qmf.rb - Ruby console module
qpid/cpp/managementgen - Code generation tool for C++ agent
qpid/java/management/client/src/main/java/org/apache/qpid/management
- QMF to JMX (QMan)
Here's the proposed structure:
qpid/qmf/cpp - C++ implementation of qmf components
qpid/qmf/cpp/bindings - Wrapped bindings to components (Python,
Ruby, C#, WCF, etc.)
qpid/qmf/python - Pure Python implementations (for portability)
qpid/qmf/java - Pure Java implementations
qpid/qmf/windows - Windows implementations
qpid/qmf/tools - CLI utilities, code generators, etc.
qpid/qmf/docs - Documentation
I do not propose to remove anything from the current structure, only
to do new development in the proposed structure. At such a time when
it is safe and non-disruptive to remove code from the old structure,
we can do so.
How do you intend to build the code? I presume there are dependencies
from code in qpid/qmf/{cpp,python,java} into
qpid/{cpp,python,java}/client. The current build system is organized
around the language division and each language has a self contained
build. This change would seem to disrupt that model somewhat.
QMF will be dependent on the public client APIs in qpid (either
installed or built). Of course, there are already dependencies across
top-level directories (cpp, python, ruby, ... depend on specs).
Is this going to be a problem? Is there an alternative that doesn't
have this problem yet gives us some separation?
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
