Hi Ted,

Why do you need/want separation - what is the goal for moving QMF around ?
It'd be useful to understand the technical drivers for making changes to the
codebase/structure.

Thanks & Regards,
Marnie

On Thu, May 7, 2009 at 3:45 PM, Ted Ross <[email protected]> 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?
>
> -Ted
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>

Reply via email to