Ted Ross wrote:
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?
I think it may be a source of some difficulty. It sort of depends on
what you want to achieve. Do you want qmf to be an integrated part of
the qpid build, or do you want qmf to be an entirely independent build?
One alternative to consider would be doing something along the lines of:
qpid/{cpp,python,java}/qmf
This would put qmf alongside client and broker, and it would make it
(for Java at least) quite trivial to leverage the current build system.
My fear is with your current choice you may be forced into either
developing a new build system or spending a fair bit of time modifying
the current one to be able to handle the different structure you've
chosen. I'm not necessarily opposed to this, but if it does in fact
involve modifying the build system(s) or adding a new one then that
needs to be considered in a larger context.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
