You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ted Ross <tr...@redhat.com> on 2009/05/07 14:42:55 UTC
Moving QMF to a top-level directory
QMF (the Qpid Management Framework) is a set of libraries and components
layered over Qpid messaging for remote object management. The QMF code
(used to manage the c++ broker) is currently in the same directories as
the broker and clients (i.e. qpid/cpp/src/qpid, python, ruby/lib, etc.).
There is a growing community of users and developers that are interested
in QMF as a tool for management. As such, I propose that we establish a
top level directory (qpid/qmf) to be the home for new development of QMF
to keep it separate from the brokers and clients.
I will proceed with this in a few days if there are no objections from
the Qpid developer community.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Bryan Kearney <bk...@redhat.com>.
Ted Ross wrote:
> Carl Trieloff 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
>>
>> why do we need
>>
>> qpid/qmf/windows - Windows implementations
>>
>> that should be hidden under a sys directory under
I have a pure C# console ready about ready to post. If we could keep
qpid/qmf/dotnet or qpid/qmf/chsharp.
-- bk
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Ted Ross <tr...@redhat.com>.
Carl Trieloff 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
>
> why do we need
>
> qpid/qmf/windows - Windows implementations
>
> that should be hidden under a sys directory under C++ ?
Yes, it's possible that any Windows-specific code should go in
qmf/cpp/bindings as it will consist of bindings for C# and/or WCF. In
this case, the "windows" directory would not be needed.
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Carl Trieloff <cc...@redhat.com>.
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
why do we need
qpid/qmf/windows - Windows implementations
that should be hidden under a sys directory under C++ ?
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Ted Ross <tr...@redhat.com>.
Rafael Schloming wrote:
> 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?
Once we establish a stable API/ABI for the messaging clients, there is
no reason for the qmf build to be integrated with the qpid build. Qmf
would only need headers and libraries for the client API to be built.
Qmf will have its own stable API/ABI in multiple languages. I guess one
question we need to answer is whether we want these interfaces to just
be part of Qpid or to be separately deliverable. See my response to Marnie.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Rafael Schloming <ra...@redhat.com>.
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:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Andrew Stitcher <as...@redhat.com>.
On Thu, 2009-05-07 at 12:21 -0400, Ted Ross wrote:
> ...
> It may be that QMF will someday become its own project or sub-project if
> interest continues to increase. This separation will make an eventual
> spin-off much easier.
I can't see how this makes sense, at least presently: The qpid C++
broker and the putative qmf thing are circularly dependent.
Separating them into different top level projects won't allow any sane
build strategy.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Ted Ross <tr...@redhat.com>.
Hi Marnie,
QMF evolved from what was originally a mechanism to manage the c++
broker. It is now a much more general-purpose facility for managing
just about anything. There is a growing community of users forming
around QMF including some developers who are submitting patches.
I'm not sure if there is a compelling technical reason to put it in its
own directory except for the fact that most of its components are
independent from the broker and interface to Qpid only through the
public client APIs. From an architectural standpoint, I think it's
beneficial to separate it from the deep internals of Qpid.
Please note that the motivation for doing this now is that there will
shortly be a fairly large, multi-directory commit with new QMF
components (a C++ engine with bindings/wrappers for Python, Ruby, C#,
and C++, plus some Java components). Either way this goes, I need to
find a good place to put the new code.
There are also non-technical/marketing aspects. There are developers
coming to Qpid because they wish to use QMF. But it's hard to find
because it is only an embedded aspect of Qpid. I would like to raise
its profile a bit and putting the code into a separate directory is a
step in that direction. I've also requested an email alias for qmf from
PMC for users who are interested in QMF but not Qpid messaging in general.
It may be that QMF will someday become its own project or sub-project if
interest continues to increase. This separation will make an eventual
spin-off much easier.
Regards and thanks for your interest and input,
-Ted
Marnie McCormack wrote:
> 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 <tr...@redhat.com> 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:dev-subscribe@qpid.apache.org
>>
>>
>>
>
>
Re: Moving QMF to a top-level directory
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <tr...@redhat.com> 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:dev-subscribe@qpid.apache.org
>
>
Re: Moving QMF to a top-level directory
Posted by Ted Ross <tr...@redhat.com>.
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:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Ted Ross <tr...@redhat.com>.
Robert Godfrey wrote:
> <snip>
>
>
>>> 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.
>>
>>
>
> Given our current top level split by language and then by function,
> Rafi's proposal seems to make more sense. I've argued before that we
> should consider splitting by function at the top level
> (common/client/broker/management) and then by language... but having
> a mixed model of partly split by function, partly by language at the
> top level makes no sense to me at all...
>
> -- Rob
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Thanks everybody for all the input. There seems to be a consensus (and
I agree) that Rafi's proposed structure is better than mine. I will
proceed using the existing high-level, language-based directories.
-Ted
Re: Moving QMF to a top-level directory
Posted by Robert Godfrey <ro...@gmail.com>.
<snip>
>>
>> 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.
>
Given our current top level split by language and then by function,
Rafi's proposal seems to make more sense. I've argued before that we
should consider splitting by function at the top level
(common/client/broker/management) and then by language... but having
a mixed model of partly split by function, partly by language at the
top level makes no sense to me at all...
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Rafael Schloming <ra...@redhat.com>.
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.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Ted Ross <tr...@redhat.com>.
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.
Regards,
-Ted
Carl Trieloff wrote:
>
>
> It might be good to put the before and after structure into the mail
> thread
>
> Carl.
>
>
> Ted Ross wrote:
>> QMF (the Qpid Management Framework) is a set of libraries and
>> components layered over Qpid messaging for remote object management.
>> The QMF code (used to manage the c++ broker) is currently in the same
>> directories as the broker and clients (i.e. qpid/cpp/src/qpid,
>> python, ruby/lib, etc.).
>>
>> There is a growing community of users and developers that are
>> interested in QMF as a tool for management. As such, I propose that
>> we establish a top level directory (qpid/qmf) to be the home for new
>> development of QMF to keep it separate from the brokers and clients.
>>
>> I will proceed with this in a few days if there are no objections
>> from the Qpid developer community.
>>
>> -Ted
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Moving QMF to a top-level directory
Posted by Carl Trieloff <cc...@redhat.com>.
It might be good to put the before and after structure into the mail thread
Carl.
Ted Ross wrote:
> QMF (the Qpid Management Framework) is a set of libraries and
> components layered over Qpid messaging for remote object management.
> The QMF code (used to manage the c++ broker) is currently in the same
> directories as the broker and clients (i.e. qpid/cpp/src/qpid, python,
> ruby/lib, etc.).
>
> There is a growing community of users and developers that are
> interested in QMF as a tool for management. As such, I propose that
> we establish a top level directory (qpid/qmf) to be the home for new
> development of QMF to keep it separate from the brokers and clients.
>
> I will proceed with this in a few days if there are no objections from
> the Qpid developer community.
>
> -Ted
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org