You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Justin Ross <jr...@apache.org> on 2013/04/10 15:55:22 UTC
Modularizing Qpid
Hi, everyone. We've recently been discussing the components of our
project in a couple different contexts. This is a proposal to take
the outcomes of those discussion and apply them to how Qpid is
organized.
Thanks for taking a look,
Justin
## Related discussions
- http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
- http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
## The problem
For a long time, Qpid was in many respects treated as one thing, with
one release cycle. Its parts were divided at the top level by
language, not function.
The division by language provides little incentive to factor out
dependencies into clean interfaces, and it has tended to mean that
developers often work in just one language silo.
It has also meant that our source modules have only a weak
correspondence to the user-focused release artifacts that we produce.
With Proton, we've broken the mold, and the overall picture of Qpid is
inconsistent and confusing, to the Qpid developers and users.
## The proposed approach
- Qpid the project embraces a functional division of components
- Each source component is self-contained and independent, with a
focused purpose; among components, there are well defined
dependencies
- The source components should correspond closely to the pieces our
users want to use independently; nonetheless, there would in some
cases be multiple release artifacts from a component
- Each component has its own set of branches, supporting independent
releases
- Each component should be neither too large nor too small; large
enough to ease development and release management; small enough to
represent a focused functional unit and to clarify dependencies
- API components would in some cases also contain code shared by APIs
and servers; the server would in that case depend on the API code
base
## Proposed source components
- Proton (this one already exists)
- /qpid/proton/trunk/
- JMS
- /qpid/jms/trunk/
- Depends on Proton
- Java broker
- /qpid/java-broker/trunk/
- Depends on JMS (?)
- Messaging API
- /qpid/messaging-api/trunk/
- Both the C++ (and bindings) and python implementations would
move here
- Depends on Proton
- C++ broker
- /qpid/cpp-broker/trunk/
- Depends on Messaging-API
Note that this matches the download page of the new website pretty
nicely.
- http://people.apache.org/~jross/transom/head/download.html
There's some debate about the right names for these things. Don't
take my suggestions seriously. I just had to put something down to
illustrate. If I had my druthers, we'd give the two brokers names
that didn't include a programming language.
## First steps
This change can't happen all at once. We propose to start with these:
- Isolate JMS from the existing qpid/trunk/qpid tree
- Isolate the Messaging API from the existing qpid/trunk/qpid tree
If this is agreed, the idea is to bite off this much during the 0.24
cycle.
## Developer infrastructure
This change calls for some work to support developers using multiple
components in one development environment. This needs more
investigation.
## JIRA instances
We propose *not* to create new jira instances for each component. We
can do that later on if necessary. For now we can overload the
version field in the qpid jira instance to include a component name.
## A Qpid "distribution" of source component releases
While this scheme supports independent releases of each source
component, it doesn't rule out a Qpid-wide release. There may be
reason for Qpid as a whole to share a release cadence and
produce a new "distribution" of components each cycle. It would all
be more flexible, however. A component might want to produce three
revisions in the space of a standard Qpid-wide four-month cycle, or a
component might produce no new revisions.
To me the advantage of producing a periodic distribution is (a)
coordinated testing and (b) a known distribution set for users to
deploy together.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Modularizing Qpid
Posted by Alan Conway <ac...@redhat.com>.
On 04/11/2013 03:37 PM, Ted Ross wrote:
> +1
>
> As you point out, Justin, we've already taken this step with Proton without too
> many difficulties. This looks like a major improvement to me.
>
> It will be desirable for each library component to have a well-defined,
> constrained, and stable API. This will be difficult if we separate the C++
> client from the C++ broker. Should we consider making the C++ client
> AMQP-1.0-only, thus greatly reducing the coupling between client and broker?
>
We could allow components to have a stable user API and a "private API" for use
by other components. That's what we do in Qpid C++ for the windows store and the
legacy message store. The public API is alone in its own include/ directory,
components that don't mind getting dirty use private include files under the
src/ directory.
To really clean things up we would have a user API and one or more "plug-in"
APIs where the plug-in APIs rather than just randomly using private headers from
other projects. We've often talked about that but the motivation isn't very
strong since it's challenging to come up with the right API and the current
"Just let them at the src/ directory" approach is working fairly well.
> On 04/10/2013 09:55 AM, Justin Ross wrote:
>> Hi, everyone. We've recently been discussing the components of our
>> project in a couple different contexts. This is a proposal to take
>> the outcomes of those discussion and apply them to how Qpid is
>> organized.
>>
>> Thanks for taking a look,
>> Justin
>>
>> ## Related discussions
>>
>> -
>> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
>>
>> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>>
>> ## The problem
>>
>> For a long time, Qpid was in many respects treated as one thing, with
>> one release cycle. Its parts were divided at the top level by
>> language, not function.
>>
>> The division by language provides little incentive to factor out
>> dependencies into clean interfaces, and it has tended to mean that
>> developers often work in just one language silo.
>>
>> It has also meant that our source modules have only a weak
>> correspondence to the user-focused release artifacts that we produce.
>>
>> With Proton, we've broken the mold, and the overall picture of Qpid is
>> inconsistent and confusing, to the Qpid developers and users.
>>
>> ## The proposed approach
>>
>> - Qpid the project embraces a functional division of components
>>
>> - Each source component is self-contained and independent, with a
>> focused purpose; among components, there are well defined
>> dependencies
>>
>> - The source components should correspond closely to the pieces our
>> users want to use independently; nonetheless, there would in some
>> cases be multiple release artifacts from a component
>>
>> - Each component has its own set of branches, supporting independent
>> releases
>>
>> - Each component should be neither too large nor too small; large
>> enough to ease development and release management; small enough to
>> represent a focused functional unit and to clarify dependencies
>>
>> - API components would in some cases also contain code shared by APIs
>> and servers; the server would in that case depend on the API code
>> base
>>
>> ## Proposed source components
>>
>> - Proton (this one already exists)
>> - /qpid/proton/trunk/
>>
>> - JMS
>> - /qpid/jms/trunk/
>> - Depends on Proton
>>
>> - Java broker
>> - /qpid/java-broker/trunk/
>> - Depends on JMS (?)
>>
>> - Messaging API
>> - /qpid/messaging-api/trunk/
>> - Both the C++ (and bindings) and python implementations would
>> move here
>> - Depends on Proton
>>
>> - C++ broker
>> - /qpid/cpp-broker/trunk/
>> - Depends on Messaging-API
>>
>> Note that this matches the download page of the new website pretty
>> nicely.
>>
>> - http://people.apache.org/~jross/transom/head/download.html
>>
>> There's some debate about the right names for these things. Don't
>> take my suggestions seriously. I just had to put something down to
>> illustrate. If I had my druthers, we'd give the two brokers names
>> that didn't include a programming language.
>>
>> ## First steps
>>
>> This change can't happen all at once. We propose to start with these:
>>
>> - Isolate JMS from the existing qpid/trunk/qpid tree
>> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>>
>> If this is agreed, the idea is to bite off this much during the 0.24
>> cycle.
>>
>> ## Developer infrastructure
>>
>> This change calls for some work to support developers using multiple
>> components in one development environment. This needs more
>> investigation.
>>
>> ## JIRA instances
>>
>> We propose *not* to create new jira instances for each component. We
>> can do that later on if necessary. For now we can overload the
>> version field in the qpid jira instance to include a component name.
>>
>> ## A Qpid "distribution" of source component releases
>>
>> While this scheme supports independent releases of each source
>> component, it doesn't rule out a Qpid-wide release. There may be
>> reason for Qpid as a whole to share a release cadence and
>> produce a new "distribution" of components each cycle. It would all
>> be more flexible, however. A component might want to produce three
>> revisions in the space of a standard Qpid-wide four-month cycle, or a
>> component might produce no new revisions.
>>
>> To me the advantage of producing a periodic distribution is (a)
>> coordinated testing and (b) a known distribution set for users to
>> deploy together.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Modularizing Qpid
Posted by Rafael Schloming <rh...@alum.mit.edu>.
+1 from me as well
I'm also skeptical that separate releases will prove workable without
separate JIRAs, however I think we can cross that bridge when we come to it.
There may also be a bit of a middle ground here. One of the reasons a
separate JIRA instance for Proton was an easy decision is that Proton
didn't have a history of existing JIRAs that would need to be migrated to
the new instance. We could similarly create new JIRA instances for new
streams of work (e.g. JMS over Proton) where there is no such history.
--Rafael
On Thu, Apr 11, 2013 at 3:37 PM, Ted Ross <tr...@redhat.com> wrote:
> +1
>
> As you point out, Justin, we've already taken this step with Proton
> without too many difficulties. This looks like a major improvement to me.
>
> It will be desirable for each library component to have a well-defined,
> constrained, and stable API. This will be difficult if we separate the C++
> client from the C++ broker. Should we consider making the C++ client
> AMQP-1.0-only, thus greatly reducing the coupling between client and broker?
>
> -Ted
>
>
>
> On 04/10/2013 09:55 AM, Justin Ross wrote:
>
>> Hi, everyone. We've recently been discussing the components of our
>> project in a couple different contexts. This is a proposal to take
>> the outcomes of those discussion and apply them to how Qpid is
>> organized.
>>
>> Thanks for taking a look,
>> Justin
>>
>> ## Related discussions
>>
>> - http://qpid.2158936.n2.nabble.**com/Proposal-to-adjust-our-**
>> source-tree-layout-td7587237.**html<http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html>
>> - http://qpid.2158936.n2.nabble.**com/Website-update-td7590445.**html<http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html>
>>
>> ## The problem
>>
>> For a long time, Qpid was in many respects treated as one thing, with
>> one release cycle. Its parts were divided at the top level by
>> language, not function.
>>
>> The division by language provides little incentive to factor out
>> dependencies into clean interfaces, and it has tended to mean that
>> developers often work in just one language silo.
>>
>> It has also meant that our source modules have only a weak
>> correspondence to the user-focused release artifacts that we produce.
>>
>> With Proton, we've broken the mold, and the overall picture of Qpid is
>> inconsistent and confusing, to the Qpid developers and users.
>>
>> ## The proposed approach
>>
>> - Qpid the project embraces a functional division of components
>>
>> - Each source component is self-contained and independent, with a
>> focused purpose; among components, there are well defined
>> dependencies
>>
>> - The source components should correspond closely to the pieces our
>> users want to use independently; nonetheless, there would in some
>> cases be multiple release artifacts from a component
>>
>> - Each component has its own set of branches, supporting independent
>> releases
>>
>> - Each component should be neither too large nor too small; large
>> enough to ease development and release management; small enough to
>> represent a focused functional unit and to clarify dependencies
>>
>> - API components would in some cases also contain code shared by APIs
>> and servers; the server would in that case depend on the API code
>> base
>>
>> ## Proposed source components
>>
>> - Proton (this one already exists)
>> - /qpid/proton/trunk/
>>
>> - JMS
>> - /qpid/jms/trunk/
>> - Depends on Proton
>>
>> - Java broker
>> - /qpid/java-broker/trunk/
>> - Depends on JMS (?)
>>
>> - Messaging API
>> - /qpid/messaging-api/trunk/
>> - Both the C++ (and bindings) and python implementations would
>> move here
>> - Depends on Proton
>>
>> - C++ broker
>> - /qpid/cpp-broker/trunk/
>> - Depends on Messaging-API
>>
>> Note that this matches the download page of the new website pretty
>> nicely.
>>
>> - http://people.apache.org/~**jross/transom/head/download.**html<http://people.apache.org/~jross/transom/head/download.html>
>>
>> There's some debate about the right names for these things. Don't
>> take my suggestions seriously. I just had to put something down to
>> illustrate. If I had my druthers, we'd give the two brokers names
>> that didn't include a programming language.
>>
>> ## First steps
>>
>> This change can't happen all at once. We propose to start with these:
>>
>> - Isolate JMS from the existing qpid/trunk/qpid tree
>> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>>
>> If this is agreed, the idea is to bite off this much during the 0.24
>> cycle.
>>
>> ## Developer infrastructure
>>
>> This change calls for some work to support developers using multiple
>> components in one development environment. This needs more
>> investigation.
>>
>> ## JIRA instances
>>
>> We propose *not* to create new jira instances for each component. We
>> can do that later on if necessary. For now we can overload the
>> version field in the qpid jira instance to include a component name.
>>
>> ## A Qpid "distribution" of source component releases
>>
>> While this scheme supports independent releases of each source
>> component, it doesn't rule out a Qpid-wide release. There may be
>> reason for Qpid as a whole to share a release cadence and
>> produce a new "distribution" of components each cycle. It would all
>> be more flexible, however. A component might want to produce three
>> revisions in the space of a standard Qpid-wide four-month cycle, or a
>> component might produce no new revisions.
>>
>> To me the advantage of producing a periodic distribution is (a)
>> coordinated testing and (b) a known distribution set for users to
>> deploy together.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Modularizing Qpid
Posted by Alan Conway <ac...@redhat.com>.
On 04/11/2013 03:37 PM, Ted Ross wrote:
> +1
>
> As you point out, Justin, we've already taken this step with Proton without too
> many difficulties. This looks like a major improvement to me.
>
> It will be desirable for each library component to have a well-defined,
> constrained, and stable API. This will be difficult if we separate the C++
> client from the C++ broker. Should we consider making the C++ client
> AMQP-1.0-only, thus greatly reducing the coupling between client and broker?
>
We could allow components to have a stable user API and a "private API" for use
by other components. That's what we do in Qpid C++ for the windows store and the
legacy message store. The public API is alone in its own include/ directory,
components that don't mind getting dirty use private include files under the
src/ directory.
To really clean things up we would have a user API and one or more "plug-in"
APIs where the plug-in APIs rather than just randomly using private headers from
other projects. We've often talked about that but the motivation isn't very
strong since it's challenging to come up with the right API and the current
"Just let them at the src/ directory" approach is working fairly well.
> On 04/10/2013 09:55 AM, Justin Ross wrote:
>> Hi, everyone. We've recently been discussing the components of our
>> project in a couple different contexts. This is a proposal to take
>> the outcomes of those discussion and apply them to how Qpid is
>> organized.
>>
>> Thanks for taking a look,
>> Justin
>>
>> ## Related discussions
>>
>> -
>> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
>>
>> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>>
>> ## The problem
>>
>> For a long time, Qpid was in many respects treated as one thing, with
>> one release cycle. Its parts were divided at the top level by
>> language, not function.
>>
>> The division by language provides little incentive to factor out
>> dependencies into clean interfaces, and it has tended to mean that
>> developers often work in just one language silo.
>>
>> It has also meant that our source modules have only a weak
>> correspondence to the user-focused release artifacts that we produce.
>>
>> With Proton, we've broken the mold, and the overall picture of Qpid is
>> inconsistent and confusing, to the Qpid developers and users.
>>
>> ## The proposed approach
>>
>> - Qpid the project embraces a functional division of components
>>
>> - Each source component is self-contained and independent, with a
>> focused purpose; among components, there are well defined
>> dependencies
>>
>> - The source components should correspond closely to the pieces our
>> users want to use independently; nonetheless, there would in some
>> cases be multiple release artifacts from a component
>>
>> - Each component has its own set of branches, supporting independent
>> releases
>>
>> - Each component should be neither too large nor too small; large
>> enough to ease development and release management; small enough to
>> represent a focused functional unit and to clarify dependencies
>>
>> - API components would in some cases also contain code shared by APIs
>> and servers; the server would in that case depend on the API code
>> base
>>
>> ## Proposed source components
>>
>> - Proton (this one already exists)
>> - /qpid/proton/trunk/
>>
>> - JMS
>> - /qpid/jms/trunk/
>> - Depends on Proton
>>
>> - Java broker
>> - /qpid/java-broker/trunk/
>> - Depends on JMS (?)
>>
>> - Messaging API
>> - /qpid/messaging-api/trunk/
>> - Both the C++ (and bindings) and python implementations would
>> move here
>> - Depends on Proton
>>
>> - C++ broker
>> - /qpid/cpp-broker/trunk/
>> - Depends on Messaging-API
>>
>> Note that this matches the download page of the new website pretty
>> nicely.
>>
>> - http://people.apache.org/~jross/transom/head/download.html
>>
>> There's some debate about the right names for these things. Don't
>> take my suggestions seriously. I just had to put something down to
>> illustrate. If I had my druthers, we'd give the two brokers names
>> that didn't include a programming language.
>>
>> ## First steps
>>
>> This change can't happen all at once. We propose to start with these:
>>
>> - Isolate JMS from the existing qpid/trunk/qpid tree
>> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>>
>> If this is agreed, the idea is to bite off this much during the 0.24
>> cycle.
>>
>> ## Developer infrastructure
>>
>> This change calls for some work to support developers using multiple
>> components in one development environment. This needs more
>> investigation.
>>
>> ## JIRA instances
>>
>> We propose *not* to create new jira instances for each component. We
>> can do that later on if necessary. For now we can overload the
>> version field in the qpid jira instance to include a component name.
>>
>> ## A Qpid "distribution" of source component releases
>>
>> While this scheme supports independent releases of each source
>> component, it doesn't rule out a Qpid-wide release. There may be
>> reason for Qpid as a whole to share a release cadence and
>> produce a new "distribution" of components each cycle. It would all
>> be more flexible, however. A component might want to produce three
>> revisions in the space of a standard Qpid-wide four-month cycle, or a
>> component might produce no new revisions.
>>
>> To me the advantage of producing a periodic distribution is (a)
>> coordinated testing and (b) a known distribution set for users to
>> deploy together.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Modularizing Qpid
Posted by Ted Ross <tr...@redhat.com>.
+1
As you point out, Justin, we've already taken this step with Proton
without too many difficulties. This looks like a major improvement to me.
It will be desirable for each library component to have a well-defined,
constrained, and stable API. This will be difficult if we separate the
C++ client from the C++ broker. Should we consider making the C++
client AMQP-1.0-only, thus greatly reducing the coupling between client
and broker?
-Ted
On 04/10/2013 09:55 AM, Justin Ross wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
>
> Thanks for taking a look,
> Justin
>
> ## Related discussions
>
> - http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>
> ## The problem
>
> For a long time, Qpid was in many respects treated as one thing, with
> one release cycle. Its parts were divided at the top level by
> language, not function.
>
> The division by language provides little incentive to factor out
> dependencies into clean interfaces, and it has tended to mean that
> developers often work in just one language silo.
>
> It has also meant that our source modules have only a weak
> correspondence to the user-focused release artifacts that we produce.
>
> With Proton, we've broken the mold, and the overall picture of Qpid is
> inconsistent and confusing, to the Qpid developers and users.
>
> ## The proposed approach
>
> - Qpid the project embraces a functional division of components
>
> - Each source component is self-contained and independent, with a
> focused purpose; among components, there are well defined
> dependencies
>
> - The source components should correspond closely to the pieces our
> users want to use independently; nonetheless, there would in some
> cases be multiple release artifacts from a component
>
> - Each component has its own set of branches, supporting independent
> releases
>
> - Each component should be neither too large nor too small; large
> enough to ease development and release management; small enough to
> represent a focused functional unit and to clarify dependencies
>
> - API components would in some cases also contain code shared by APIs
> and servers; the server would in that case depend on the API code
> base
>
> ## Proposed source components
>
> - Proton (this one already exists)
> - /qpid/proton/trunk/
>
> - JMS
> - /qpid/jms/trunk/
> - Depends on Proton
>
> - Java broker
> - /qpid/java-broker/trunk/
> - Depends on JMS (?)
>
> - Messaging API
> - /qpid/messaging-api/trunk/
> - Both the C++ (and bindings) and python implementations would
> move here
> - Depends on Proton
>
> - C++ broker
> - /qpid/cpp-broker/trunk/
> - Depends on Messaging-API
>
> Note that this matches the download page of the new website pretty
> nicely.
>
> - http://people.apache.org/~jross/transom/head/download.html
>
> There's some debate about the right names for these things. Don't
> take my suggestions seriously. I just had to put something down to
> illustrate. If I had my druthers, we'd give the two brokers names
> that didn't include a programming language.
>
> ## First steps
>
> This change can't happen all at once. We propose to start with these:
>
> - Isolate JMS from the existing qpid/trunk/qpid tree
> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>
> If this is agreed, the idea is to bite off this much during the 0.24
> cycle.
>
> ## Developer infrastructure
>
> This change calls for some work to support developers using multiple
> components in one development environment. This needs more
> investigation.
>
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
>
> ## A Qpid "distribution" of source component releases
>
> While this scheme supports independent releases of each source
> component, it doesn't rule out a Qpid-wide release. There may be
> reason for Qpid as a whole to share a release cadence and
> produce a new "distribution" of components each cycle. It would all
> be more flexible, however. A component might want to produce three
> revisions in the space of a standard Qpid-wide four-month cycle, or a
> component might produce no new revisions.
>
> To me the advantage of producing a periodic distribution is (a)
> coordinated testing and (b) a known distribution set for users to
> deploy together.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Modularizing Qpid
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Wed, Apr 10, 2013 at 09:55:22AM -0400, Justin Ross wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
+1
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Modularizing Qpid
Posted by Jakub Scholz <ja...@scholz.cz>.
>From a user point of view ... if the client libraries have independent
releases, it might be more clear to many people that they do not need to
use exactly the same version of the client library as is the broker
version. That seems to be quite popular believe among the people connecting
to our brokers. I hope the new website will help a bit with this as well.
Similarly, it might also clear a few misunderstandings that the Java broker
and the C++ broker are fully identical in terms of features /
functionality, just written in different language.
Regards
Jakub
On Wed, Apr 10, 2013 at 3:55 PM, Justin Ross <jr...@apache.org> wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
>
> Thanks for taking a look,
> Justin
>
> ## Related discussions
>
> -
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>
> ## The problem
>
> For a long time, Qpid was in many respects treated as one thing, with
> one release cycle. Its parts were divided at the top level by
> language, not function.
>
> The division by language provides little incentive to factor out
> dependencies into clean interfaces, and it has tended to mean that
> developers often work in just one language silo.
>
> It has also meant that our source modules have only a weak
> correspondence to the user-focused release artifacts that we produce.
>
> With Proton, we've broken the mold, and the overall picture of Qpid is
> inconsistent and confusing, to the Qpid developers and users.
>
> ## The proposed approach
>
> - Qpid the project embraces a functional division of components
>
> - Each source component is self-contained and independent, with a
> focused purpose; among components, there are well defined
> dependencies
>
> - The source components should correspond closely to the pieces our
> users want to use independently; nonetheless, there would in some
> cases be multiple release artifacts from a component
>
> - Each component has its own set of branches, supporting independent
> releases
>
> - Each component should be neither too large nor too small; large
> enough to ease development and release management; small enough to
> represent a focused functional unit and to clarify dependencies
>
> - API components would in some cases also contain code shared by APIs
> and servers; the server would in that case depend on the API code
> base
>
> ## Proposed source components
>
> - Proton (this one already exists)
> - /qpid/proton/trunk/
>
> - JMS
> - /qpid/jms/trunk/
> - Depends on Proton
>
> - Java broker
> - /qpid/java-broker/trunk/
> - Depends on JMS (?)
>
> - Messaging API
> - /qpid/messaging-api/trunk/
> - Both the C++ (and bindings) and python implementations would
> move here
> - Depends on Proton
>
> - C++ broker
> - /qpid/cpp-broker/trunk/
> - Depends on Messaging-API
>
> Note that this matches the download page of the new website pretty
> nicely.
>
> - http://people.apache.org/~jross/transom/head/download.html
>
> There's some debate about the right names for these things. Don't
> take my suggestions seriously. I just had to put something down to
> illustrate. If I had my druthers, we'd give the two brokers names
> that didn't include a programming language.
>
> ## First steps
>
> This change can't happen all at once. We propose to start with these:
>
> - Isolate JMS from the existing qpid/trunk/qpid tree
> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>
> If this is agreed, the idea is to bite off this much during the 0.24
> cycle.
>
> ## Developer infrastructure
>
> This change calls for some work to support developers using multiple
> components in one development environment. This needs more
> investigation.
>
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
>
> ## A Qpid "distribution" of source component releases
>
> While this scheme supports independent releases of each source
> component, it doesn't rule out a Qpid-wide release. There may be
> reason for Qpid as a whole to share a release cadence and
> produce a new "distribution" of components each cycle. It would all
> be more flexible, however. A component might want to produce three
> revisions in the space of a standard Qpid-wide four-month cycle, or a
> component might produce no new revisions.
>
> To me the advantage of producing a periodic distribution is (a)
> coordinated testing and (b) a known distribution set for users to
> deploy together.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Modularizing Qpid
Posted by Robbie Gemmell <ro...@gmail.com>.
+1 from me as well. I think this would be a good improvement on the
existing structure and benefit everyone by allowing for schedules more
tailored to the specific components, and in turn enable us to better meet
the needs of their users.
We would need to investigate how some of the changes might best be
achieved, and thus better understand how much effort is likely to be
involved as Rob mentioned. I think it is at least somewhat likely it would
be easier to do the JMS clients and the Java broker at the same time rather
than separately for example, but we would need to examine the options to be
sure.
Robbie
On 10 April 2013 15:46, Rob Godfrey <ro...@gmail.com> wrote:
> I'm +1 this... Obviously we need to understand better the amount of work to
> achieve the separation of the components... but if this were in place then
> we wouldn't be facing the sort of issues we are currently experiencing with
> the 0.22 release which would strongly benefit from not having the release
> cycles of all components tied together.
>
> -- Rob
>
>
> On 10 April 2013 15:55, Justin Ross <jr...@apache.org> wrote:
>
> > Hi, everyone. We've recently been discussing the components of our
> > project in a couple different contexts. This is a proposal to take
> > the outcomes of those discussion and apply them to how Qpid is
> > organized.
> >
> > Thanks for taking a look,
> > Justin
> >
> > ## Related discussions
> >
> > -
> >
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> > - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
> >
> > ## The problem
> >
> > For a long time, Qpid was in many respects treated as one thing, with
> > one release cycle. Its parts were divided at the top level by
> > language, not function.
> >
> > The division by language provides little incentive to factor out
> > dependencies into clean interfaces, and it has tended to mean that
> > developers often work in just one language silo.
> >
> > It has also meant that our source modules have only a weak
> > correspondence to the user-focused release artifacts that we produce.
> >
> > With Proton, we've broken the mold, and the overall picture of Qpid is
> > inconsistent and confusing, to the Qpid developers and users.
> >
> > ## The proposed approach
> >
> > - Qpid the project embraces a functional division of components
> >
> > - Each source component is self-contained and independent, with a
> > focused purpose; among components, there are well defined
> > dependencies
> >
> > - The source components should correspond closely to the pieces our
> > users want to use independently; nonetheless, there would in some
> > cases be multiple release artifacts from a component
> >
> > - Each component has its own set of branches, supporting independent
> > releases
> >
> > - Each component should be neither too large nor too small; large
> > enough to ease development and release management; small enough to
> > represent a focused functional unit and to clarify dependencies
> >
> > - API components would in some cases also contain code shared by APIs
> > and servers; the server would in that case depend on the API code
> > base
> >
> > ## Proposed source components
> >
> > - Proton (this one already exists)
> > - /qpid/proton/trunk/
> >
> > - JMS
> > - /qpid/jms/trunk/
> > - Depends on Proton
> >
> > - Java broker
> > - /qpid/java-broker/trunk/
> > - Depends on JMS (?)
> >
> > - Messaging API
> > - /qpid/messaging-api/trunk/
> > - Both the C++ (and bindings) and python implementations would
> > move here
> > - Depends on Proton
> >
> > - C++ broker
> > - /qpid/cpp-broker/trunk/
> > - Depends on Messaging-API
> >
> > Note that this matches the download page of the new website pretty
> > nicely.
> >
> > - http://people.apache.org/~jross/transom/head/download.html
> >
> > There's some debate about the right names for these things. Don't
> > take my suggestions seriously. I just had to put something down to
> > illustrate. If I had my druthers, we'd give the two brokers names
> > that didn't include a programming language.
> >
> > ## First steps
> >
> > This change can't happen all at once. We propose to start with these:
> >
> > - Isolate JMS from the existing qpid/trunk/qpid tree
> > - Isolate the Messaging API from the existing qpid/trunk/qpid tree
> >
> > If this is agreed, the idea is to bite off this much during the 0.24
> > cycle.
> >
> > ## Developer infrastructure
> >
> > This change calls for some work to support developers using multiple
> > components in one development environment. This needs more
> > investigation.
> >
> > ## JIRA instances
> >
> > We propose *not* to create new jira instances for each component. We
> > can do that later on if necessary. For now we can overload the
> > version field in the qpid jira instance to include a component name.
> >
> > ## A Qpid "distribution" of source component releases
> >
> > While this scheme supports independent releases of each source
> > component, it doesn't rule out a Qpid-wide release. There may be
> > reason for Qpid as a whole to share a release cadence and
> > produce a new "distribution" of components each cycle. It would all
> > be more flexible, however. A component might want to produce three
> > revisions in the space of a standard Qpid-wide four-month cycle, or a
> > component might produce no new revisions.
> >
> > To me the advantage of producing a periodic distribution is (a)
> > coordinated testing and (b) a known distribution set for users to
> > deploy together.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Modularizing Qpid
Posted by Rajith Attapattu <ra...@gmail.com>.
+1 on this.
Having the flexibility to have individual release cycles for each component
will be huge advantage for us.
However as Justin mentioned, we shouldn't rule out a Qpid wide release
perhaps once a year or so.
>From a users perspective this is a great thing to have, bcos all the
components bundled under that release will be guaranteed to work well
together.
Rajith
On Wed, Apr 10, 2013 at 10:46 AM, Rob Godfrey <ro...@gmail.com>wrote:
> I'm +1 this... Obviously we need to understand better the amount of work to
> achieve the separation of the components... but if this were in place then
> we wouldn't be facing the sort of issues we are currently experiencing with
> the 0.22 release which would strongly benefit from not having the release
> cycles of all components tied together.
>
> -- Rob
>
>
> On 10 April 2013 15:55, Justin Ross <jr...@apache.org> wrote:
>
> > Hi, everyone. We've recently been discussing the components of our
> > project in a couple different contexts. This is a proposal to take
> > the outcomes of those discussion and apply them to how Qpid is
> > organized.
> >
> > Thanks for taking a look,
> > Justin
> >
> > ## Related discussions
> >
> > -
> >
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> > - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
> >
> > ## The problem
> >
> > For a long time, Qpid was in many respects treated as one thing, with
> > one release cycle. Its parts were divided at the top level by
> > language, not function.
> >
> > The division by language provides little incentive to factor out
> > dependencies into clean interfaces, and it has tended to mean that
> > developers often work in just one language silo.
> >
> > It has also meant that our source modules have only a weak
> > correspondence to the user-focused release artifacts that we produce.
> >
> > With Proton, we've broken the mold, and the overall picture of Qpid is
> > inconsistent and confusing, to the Qpid developers and users.
> >
> > ## The proposed approach
> >
> > - Qpid the project embraces a functional division of components
> >
> > - Each source component is self-contained and independent, with a
> > focused purpose; among components, there are well defined
> > dependencies
> >
> > - The source components should correspond closely to the pieces our
> > users want to use independently; nonetheless, there would in some
> > cases be multiple release artifacts from a component
> >
> > - Each component has its own set of branches, supporting independent
> > releases
> >
> > - Each component should be neither too large nor too small; large
> > enough to ease development and release management; small enough to
> > represent a focused functional unit and to clarify dependencies
> >
> > - API components would in some cases also contain code shared by APIs
> > and servers; the server would in that case depend on the API code
> > base
> >
> > ## Proposed source components
> >
> > - Proton (this one already exists)
> > - /qpid/proton/trunk/
> >
> > - JMS
> > - /qpid/jms/trunk/
> > - Depends on Proton
> >
> > - Java broker
> > - /qpid/java-broker/trunk/
> > - Depends on JMS (?)
> >
> > - Messaging API
> > - /qpid/messaging-api/trunk/
> > - Both the C++ (and bindings) and python implementations would
> > move here
> > - Depends on Proton
> >
> > - C++ broker
> > - /qpid/cpp-broker/trunk/
> > - Depends on Messaging-API
> >
> > Note that this matches the download page of the new website pretty
> > nicely.
> >
> > - http://people.apache.org/~jross/transom/head/download.html
> >
> > There's some debate about the right names for these things. Don't
> > take my suggestions seriously. I just had to put something down to
> > illustrate. If I had my druthers, we'd give the two brokers names
> > that didn't include a programming language.
> >
> > ## First steps
> >
> > This change can't happen all at once. We propose to start with these:
> >
> > - Isolate JMS from the existing qpid/trunk/qpid tree
> > - Isolate the Messaging API from the existing qpid/trunk/qpid tree
> >
> > If this is agreed, the idea is to bite off this much during the 0.24
> > cycle.
> >
> > ## Developer infrastructure
> >
> > This change calls for some work to support developers using multiple
> > components in one development environment. This needs more
> > investigation.
> >
> > ## JIRA instances
> >
> > We propose *not* to create new jira instances for each component. We
> > can do that later on if necessary. For now we can overload the
> > version field in the qpid jira instance to include a component name.
> >
> > ## A Qpid "distribution" of source component releases
> >
> > While this scheme supports independent releases of each source
> > component, it doesn't rule out a Qpid-wide release. There may be
> > reason for Qpid as a whole to share a release cadence and
> > produce a new "distribution" of components each cycle. It would all
> > be more flexible, however. A component might want to produce three
> > revisions in the space of a standard Qpid-wide four-month cycle, or a
> > component might produce no new revisions.
> >
> > To me the advantage of producing a periodic distribution is (a)
> > coordinated testing and (b) a known distribution set for users to
> > deploy together.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Modularizing Qpid
Posted by Rajith Attapattu <ra...@gmail.com>.
+1 on this.
Having the flexibility to have individual release cycles for each component
will be huge advantage for us.
However as Justin mentioned, we shouldn't rule out a Qpid wide release
perhaps once a year or so.
>From a users perspective this is a great thing to have, bcos all the
components bundled under that release will be guaranteed to work well
together.
Rajith
On Wed, Apr 10, 2013 at 10:46 AM, Rob Godfrey <ro...@gmail.com>wrote:
> I'm +1 this... Obviously we need to understand better the amount of work to
> achieve the separation of the components... but if this were in place then
> we wouldn't be facing the sort of issues we are currently experiencing with
> the 0.22 release which would strongly benefit from not having the release
> cycles of all components tied together.
>
> -- Rob
>
>
> On 10 April 2013 15:55, Justin Ross <jr...@apache.org> wrote:
>
> > Hi, everyone. We've recently been discussing the components of our
> > project in a couple different contexts. This is a proposal to take
> > the outcomes of those discussion and apply them to how Qpid is
> > organized.
> >
> > Thanks for taking a look,
> > Justin
> >
> > ## Related discussions
> >
> > -
> >
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> > - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
> >
> > ## The problem
> >
> > For a long time, Qpid was in many respects treated as one thing, with
> > one release cycle. Its parts were divided at the top level by
> > language, not function.
> >
> > The division by language provides little incentive to factor out
> > dependencies into clean interfaces, and it has tended to mean that
> > developers often work in just one language silo.
> >
> > It has also meant that our source modules have only a weak
> > correspondence to the user-focused release artifacts that we produce.
> >
> > With Proton, we've broken the mold, and the overall picture of Qpid is
> > inconsistent and confusing, to the Qpid developers and users.
> >
> > ## The proposed approach
> >
> > - Qpid the project embraces a functional division of components
> >
> > - Each source component is self-contained and independent, with a
> > focused purpose; among components, there are well defined
> > dependencies
> >
> > - The source components should correspond closely to the pieces our
> > users want to use independently; nonetheless, there would in some
> > cases be multiple release artifacts from a component
> >
> > - Each component has its own set of branches, supporting independent
> > releases
> >
> > - Each component should be neither too large nor too small; large
> > enough to ease development and release management; small enough to
> > represent a focused functional unit and to clarify dependencies
> >
> > - API components would in some cases also contain code shared by APIs
> > and servers; the server would in that case depend on the API code
> > base
> >
> > ## Proposed source components
> >
> > - Proton (this one already exists)
> > - /qpid/proton/trunk/
> >
> > - JMS
> > - /qpid/jms/trunk/
> > - Depends on Proton
> >
> > - Java broker
> > - /qpid/java-broker/trunk/
> > - Depends on JMS (?)
> >
> > - Messaging API
> > - /qpid/messaging-api/trunk/
> > - Both the C++ (and bindings) and python implementations would
> > move here
> > - Depends on Proton
> >
> > - C++ broker
> > - /qpid/cpp-broker/trunk/
> > - Depends on Messaging-API
> >
> > Note that this matches the download page of the new website pretty
> > nicely.
> >
> > - http://people.apache.org/~jross/transom/head/download.html
> >
> > There's some debate about the right names for these things. Don't
> > take my suggestions seriously. I just had to put something down to
> > illustrate. If I had my druthers, we'd give the two brokers names
> > that didn't include a programming language.
> >
> > ## First steps
> >
> > This change can't happen all at once. We propose to start with these:
> >
> > - Isolate JMS from the existing qpid/trunk/qpid tree
> > - Isolate the Messaging API from the existing qpid/trunk/qpid tree
> >
> > If this is agreed, the idea is to bite off this much during the 0.24
> > cycle.
> >
> > ## Developer infrastructure
> >
> > This change calls for some work to support developers using multiple
> > components in one development environment. This needs more
> > investigation.
> >
> > ## JIRA instances
> >
> > We propose *not* to create new jira instances for each component. We
> > can do that later on if necessary. For now we can overload the
> > version field in the qpid jira instance to include a component name.
> >
> > ## A Qpid "distribution" of source component releases
> >
> > While this scheme supports independent releases of each source
> > component, it doesn't rule out a Qpid-wide release. There may be
> > reason for Qpid as a whole to share a release cadence and
> > produce a new "distribution" of components each cycle. It would all
> > be more flexible, however. A component might want to produce three
> > revisions in the space of a standard Qpid-wide four-month cycle, or a
> > component might produce no new revisions.
> >
> > To me the advantage of producing a periodic distribution is (a)
> > coordinated testing and (b) a known distribution set for users to
> > deploy together.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Modularizing Qpid
Posted by Robbie Gemmell <ro...@gmail.com>.
+1 from me as well. I think this would be a good improvement on the
existing structure and benefit everyone by allowing for schedules more
tailored to the specific components, and in turn enable us to better meet
the needs of their users.
We would need to investigate how some of the changes might best be
achieved, and thus better understand how much effort is likely to be
involved as Rob mentioned. I think it is at least somewhat likely it would
be easier to do the JMS clients and the Java broker at the same time rather
than separately for example, but we would need to examine the options to be
sure.
Robbie
On 10 April 2013 15:46, Rob Godfrey <ro...@gmail.com> wrote:
> I'm +1 this... Obviously we need to understand better the amount of work to
> achieve the separation of the components... but if this were in place then
> we wouldn't be facing the sort of issues we are currently experiencing with
> the 0.22 release which would strongly benefit from not having the release
> cycles of all components tied together.
>
> -- Rob
>
>
> On 10 April 2013 15:55, Justin Ross <jr...@apache.org> wrote:
>
> > Hi, everyone. We've recently been discussing the components of our
> > project in a couple different contexts. This is a proposal to take
> > the outcomes of those discussion and apply them to how Qpid is
> > organized.
> >
> > Thanks for taking a look,
> > Justin
> >
> > ## Related discussions
> >
> > -
> >
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> > - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
> >
> > ## The problem
> >
> > For a long time, Qpid was in many respects treated as one thing, with
> > one release cycle. Its parts were divided at the top level by
> > language, not function.
> >
> > The division by language provides little incentive to factor out
> > dependencies into clean interfaces, and it has tended to mean that
> > developers often work in just one language silo.
> >
> > It has also meant that our source modules have only a weak
> > correspondence to the user-focused release artifacts that we produce.
> >
> > With Proton, we've broken the mold, and the overall picture of Qpid is
> > inconsistent and confusing, to the Qpid developers and users.
> >
> > ## The proposed approach
> >
> > - Qpid the project embraces a functional division of components
> >
> > - Each source component is self-contained and independent, with a
> > focused purpose; among components, there are well defined
> > dependencies
> >
> > - The source components should correspond closely to the pieces our
> > users want to use independently; nonetheless, there would in some
> > cases be multiple release artifacts from a component
> >
> > - Each component has its own set of branches, supporting independent
> > releases
> >
> > - Each component should be neither too large nor too small; large
> > enough to ease development and release management; small enough to
> > represent a focused functional unit and to clarify dependencies
> >
> > - API components would in some cases also contain code shared by APIs
> > and servers; the server would in that case depend on the API code
> > base
> >
> > ## Proposed source components
> >
> > - Proton (this one already exists)
> > - /qpid/proton/trunk/
> >
> > - JMS
> > - /qpid/jms/trunk/
> > - Depends on Proton
> >
> > - Java broker
> > - /qpid/java-broker/trunk/
> > - Depends on JMS (?)
> >
> > - Messaging API
> > - /qpid/messaging-api/trunk/
> > - Both the C++ (and bindings) and python implementations would
> > move here
> > - Depends on Proton
> >
> > - C++ broker
> > - /qpid/cpp-broker/trunk/
> > - Depends on Messaging-API
> >
> > Note that this matches the download page of the new website pretty
> > nicely.
> >
> > - http://people.apache.org/~jross/transom/head/download.html
> >
> > There's some debate about the right names for these things. Don't
> > take my suggestions seriously. I just had to put something down to
> > illustrate. If I had my druthers, we'd give the two brokers names
> > that didn't include a programming language.
> >
> > ## First steps
> >
> > This change can't happen all at once. We propose to start with these:
> >
> > - Isolate JMS from the existing qpid/trunk/qpid tree
> > - Isolate the Messaging API from the existing qpid/trunk/qpid tree
> >
> > If this is agreed, the idea is to bite off this much during the 0.24
> > cycle.
> >
> > ## Developer infrastructure
> >
> > This change calls for some work to support developers using multiple
> > components in one development environment. This needs more
> > investigation.
> >
> > ## JIRA instances
> >
> > We propose *not* to create new jira instances for each component. We
> > can do that later on if necessary. For now we can overload the
> > version field in the qpid jira instance to include a component name.
> >
> > ## A Qpid "distribution" of source component releases
> >
> > While this scheme supports independent releases of each source
> > component, it doesn't rule out a Qpid-wide release. There may be
> > reason for Qpid as a whole to share a release cadence and
> > produce a new "distribution" of components each cycle. It would all
> > be more flexible, however. A component might want to produce three
> > revisions in the space of a standard Qpid-wide four-month cycle, or a
> > component might produce no new revisions.
> >
> > To me the advantage of producing a periodic distribution is (a)
> > coordinated testing and (b) a known distribution set for users to
> > deploy together.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Modularizing Qpid
Posted by Rob Godfrey <ro...@gmail.com>.
I'm +1 this... Obviously we need to understand better the amount of work to
achieve the separation of the components... but if this were in place then
we wouldn't be facing the sort of issues we are currently experiencing with
the 0.22 release which would strongly benefit from not having the release
cycles of all components tied together.
-- Rob
On 10 April 2013 15:55, Justin Ross <jr...@apache.org> wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
>
> Thanks for taking a look,
> Justin
>
> ## Related discussions
>
> -
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>
> ## The problem
>
> For a long time, Qpid was in many respects treated as one thing, with
> one release cycle. Its parts were divided at the top level by
> language, not function.
>
> The division by language provides little incentive to factor out
> dependencies into clean interfaces, and it has tended to mean that
> developers often work in just one language silo.
>
> It has also meant that our source modules have only a weak
> correspondence to the user-focused release artifacts that we produce.
>
> With Proton, we've broken the mold, and the overall picture of Qpid is
> inconsistent and confusing, to the Qpid developers and users.
>
> ## The proposed approach
>
> - Qpid the project embraces a functional division of components
>
> - Each source component is self-contained and independent, with a
> focused purpose; among components, there are well defined
> dependencies
>
> - The source components should correspond closely to the pieces our
> users want to use independently; nonetheless, there would in some
> cases be multiple release artifacts from a component
>
> - Each component has its own set of branches, supporting independent
> releases
>
> - Each component should be neither too large nor too small; large
> enough to ease development and release management; small enough to
> represent a focused functional unit and to clarify dependencies
>
> - API components would in some cases also contain code shared by APIs
> and servers; the server would in that case depend on the API code
> base
>
> ## Proposed source components
>
> - Proton (this one already exists)
> - /qpid/proton/trunk/
>
> - JMS
> - /qpid/jms/trunk/
> - Depends on Proton
>
> - Java broker
> - /qpid/java-broker/trunk/
> - Depends on JMS (?)
>
> - Messaging API
> - /qpid/messaging-api/trunk/
> - Both the C++ (and bindings) and python implementations would
> move here
> - Depends on Proton
>
> - C++ broker
> - /qpid/cpp-broker/trunk/
> - Depends on Messaging-API
>
> Note that this matches the download page of the new website pretty
> nicely.
>
> - http://people.apache.org/~jross/transom/head/download.html
>
> There's some debate about the right names for these things. Don't
> take my suggestions seriously. I just had to put something down to
> illustrate. If I had my druthers, we'd give the two brokers names
> that didn't include a programming language.
>
> ## First steps
>
> This change can't happen all at once. We propose to start with these:
>
> - Isolate JMS from the existing qpid/trunk/qpid tree
> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>
> If this is agreed, the idea is to bite off this much during the 0.24
> cycle.
>
> ## Developer infrastructure
>
> This change calls for some work to support developers using multiple
> components in one development environment. This needs more
> investigation.
>
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
>
> ## A Qpid "distribution" of source component releases
>
> While this scheme supports independent releases of each source
> component, it doesn't rule out a Qpid-wide release. There may be
> reason for Qpid as a whole to share a release cadence and
> produce a new "distribution" of components each cycle. It would all
> be more flexible, however. A component might want to produce three
> revisions in the space of a standard Qpid-wide four-month cycle, or a
> component might produce no new revisions.
>
> To me the advantage of producing a periodic distribution is (a)
> coordinated testing and (b) a known distribution set for users to
> deploy together.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Modularizing Qpid
Posted by Alan Conway <ac...@redhat.com>.
+1 on the general concept, details to be figured out...
On 04/10/2013 09:55 AM, Justin Ross wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
[snip]
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
"Overload the version field" sounds like a Bad Idea to me. That's not what the
version field is for. Anyone know of projects that have successfully done this?
I would say that if a component is big enough to have its own SVN repo, then
it's big enough to have its own JIRA. Note that the only successful component to
date (Proton) /does/ have it's own JIRA. Anyone think it's a good idea to merge
the Proton JIRA into the QPID JIRA?
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Modularizing Qpid
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Wed, Apr 10, 2013 at 09:55:22AM -0400, Justin Ross wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
+1
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Modularizing Qpid
Posted by Alan Conway <ac...@redhat.com>.
+1 on the general concept, details to be figured out...
On 04/10/2013 09:55 AM, Justin Ross wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
[snip]
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
"Overload the version field" sounds like a Bad Idea to me. That's not what the
version field is for. Anyone know of projects that have successfully done this?
I would say that if a component is big enough to have its own SVN repo, then
it's big enough to have its own JIRA. Note that the only successful component to
date (Proton) /does/ have it's own JIRA. Anyone think it's a good idea to merge
the Proton JIRA into the QPID JIRA?
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Modularizing Qpid
Posted by Jakub Scholz <ja...@scholz.cz>.
>From a user point of view ... if the client libraries have independent
releases, it might be more clear to many people that they do not need to
use exactly the same version of the client library as is the broker
version. That seems to be quite popular believe among the people connecting
to our brokers. I hope the new website will help a bit with this as well.
Similarly, it might also clear a few misunderstandings that the Java broker
and the C++ broker are fully identical in terms of features /
functionality, just written in different language.
Regards
Jakub
On Wed, Apr 10, 2013 at 3:55 PM, Justin Ross <jr...@apache.org> wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
>
> Thanks for taking a look,
> Justin
>
> ## Related discussions
>
> -
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>
> ## The problem
>
> For a long time, Qpid was in many respects treated as one thing, with
> one release cycle. Its parts were divided at the top level by
> language, not function.
>
> The division by language provides little incentive to factor out
> dependencies into clean interfaces, and it has tended to mean that
> developers often work in just one language silo.
>
> It has also meant that our source modules have only a weak
> correspondence to the user-focused release artifacts that we produce.
>
> With Proton, we've broken the mold, and the overall picture of Qpid is
> inconsistent and confusing, to the Qpid developers and users.
>
> ## The proposed approach
>
> - Qpid the project embraces a functional division of components
>
> - Each source component is self-contained and independent, with a
> focused purpose; among components, there are well defined
> dependencies
>
> - The source components should correspond closely to the pieces our
> users want to use independently; nonetheless, there would in some
> cases be multiple release artifacts from a component
>
> - Each component has its own set of branches, supporting independent
> releases
>
> - Each component should be neither too large nor too small; large
> enough to ease development and release management; small enough to
> represent a focused functional unit and to clarify dependencies
>
> - API components would in some cases also contain code shared by APIs
> and servers; the server would in that case depend on the API code
> base
>
> ## Proposed source components
>
> - Proton (this one already exists)
> - /qpid/proton/trunk/
>
> - JMS
> - /qpid/jms/trunk/
> - Depends on Proton
>
> - Java broker
> - /qpid/java-broker/trunk/
> - Depends on JMS (?)
>
> - Messaging API
> - /qpid/messaging-api/trunk/
> - Both the C++ (and bindings) and python implementations would
> move here
> - Depends on Proton
>
> - C++ broker
> - /qpid/cpp-broker/trunk/
> - Depends on Messaging-API
>
> Note that this matches the download page of the new website pretty
> nicely.
>
> - http://people.apache.org/~jross/transom/head/download.html
>
> There's some debate about the right names for these things. Don't
> take my suggestions seriously. I just had to put something down to
> illustrate. If I had my druthers, we'd give the two brokers names
> that didn't include a programming language.
>
> ## First steps
>
> This change can't happen all at once. We propose to start with these:
>
> - Isolate JMS from the existing qpid/trunk/qpid tree
> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>
> If this is agreed, the idea is to bite off this much during the 0.24
> cycle.
>
> ## Developer infrastructure
>
> This change calls for some work to support developers using multiple
> components in one development environment. This needs more
> investigation.
>
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
>
> ## A Qpid "distribution" of source component releases
>
> While this scheme supports independent releases of each source
> component, it doesn't rule out a Qpid-wide release. There may be
> reason for Qpid as a whole to share a release cadence and
> produce a new "distribution" of components each cycle. It would all
> be more flexible, however. A component might want to produce three
> revisions in the space of a standard Qpid-wide four-month cycle, or a
> component might produce no new revisions.
>
> To me the advantage of producing a periodic distribution is (a)
> coordinated testing and (b) a known distribution set for users to
> deploy together.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Modularizing Qpid
Posted by Rob Godfrey <ro...@gmail.com>.
I'm +1 this... Obviously we need to understand better the amount of work to
achieve the separation of the components... but if this were in place then
we wouldn't be facing the sort of issues we are currently experiencing with
the 0.22 release which would strongly benefit from not having the release
cycles of all components tied together.
-- Rob
On 10 April 2013 15:55, Justin Ross <jr...@apache.org> wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
>
> Thanks for taking a look,
> Justin
>
> ## Related discussions
>
> -
> http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>
> ## The problem
>
> For a long time, Qpid was in many respects treated as one thing, with
> one release cycle. Its parts were divided at the top level by
> language, not function.
>
> The division by language provides little incentive to factor out
> dependencies into clean interfaces, and it has tended to mean that
> developers often work in just one language silo.
>
> It has also meant that our source modules have only a weak
> correspondence to the user-focused release artifacts that we produce.
>
> With Proton, we've broken the mold, and the overall picture of Qpid is
> inconsistent and confusing, to the Qpid developers and users.
>
> ## The proposed approach
>
> - Qpid the project embraces a functional division of components
>
> - Each source component is self-contained and independent, with a
> focused purpose; among components, there are well defined
> dependencies
>
> - The source components should correspond closely to the pieces our
> users want to use independently; nonetheless, there would in some
> cases be multiple release artifacts from a component
>
> - Each component has its own set of branches, supporting independent
> releases
>
> - Each component should be neither too large nor too small; large
> enough to ease development and release management; small enough to
> represent a focused functional unit and to clarify dependencies
>
> - API components would in some cases also contain code shared by APIs
> and servers; the server would in that case depend on the API code
> base
>
> ## Proposed source components
>
> - Proton (this one already exists)
> - /qpid/proton/trunk/
>
> - JMS
> - /qpid/jms/trunk/
> - Depends on Proton
>
> - Java broker
> - /qpid/java-broker/trunk/
> - Depends on JMS (?)
>
> - Messaging API
> - /qpid/messaging-api/trunk/
> - Both the C++ (and bindings) and python implementations would
> move here
> - Depends on Proton
>
> - C++ broker
> - /qpid/cpp-broker/trunk/
> - Depends on Messaging-API
>
> Note that this matches the download page of the new website pretty
> nicely.
>
> - http://people.apache.org/~jross/transom/head/download.html
>
> There's some debate about the right names for these things. Don't
> take my suggestions seriously. I just had to put something down to
> illustrate. If I had my druthers, we'd give the two brokers names
> that didn't include a programming language.
>
> ## First steps
>
> This change can't happen all at once. We propose to start with these:
>
> - Isolate JMS from the existing qpid/trunk/qpid tree
> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>
> If this is agreed, the idea is to bite off this much during the 0.24
> cycle.
>
> ## Developer infrastructure
>
> This change calls for some work to support developers using multiple
> components in one development environment. This needs more
> investigation.
>
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
>
> ## A Qpid "distribution" of source component releases
>
> While this scheme supports independent releases of each source
> component, it doesn't rule out a Qpid-wide release. There may be
> reason for Qpid as a whole to share a release cadence and
> produce a new "distribution" of components each cycle. It would all
> be more flexible, however. A component might want to produce three
> revisions in the space of a standard Qpid-wide four-month cycle, or a
> component might produce no new revisions.
>
> To me the advantage of producing a periodic distribution is (a)
> coordinated testing and (b) a known distribution set for users to
> deploy together.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Modularizing Qpid
Posted by Ted Ross <tr...@redhat.com>.
+1
As you point out, Justin, we've already taken this step with Proton
without too many difficulties. This looks like a major improvement to me.
It will be desirable for each library component to have a well-defined,
constrained, and stable API. This will be difficult if we separate the
C++ client from the C++ broker. Should we consider making the C++
client AMQP-1.0-only, thus greatly reducing the coupling between client
and broker?
-Ted
On 04/10/2013 09:55 AM, Justin Ross wrote:
> Hi, everyone. We've recently been discussing the components of our
> project in a couple different contexts. This is a proposal to take
> the outcomes of those discussion and apply them to how Qpid is
> organized.
>
> Thanks for taking a look,
> Justin
>
> ## Related discussions
>
> - http://qpid.2158936.n2.nabble.com/Proposal-to-adjust-our-source-tree-layout-td7587237.html
> - http://qpid.2158936.n2.nabble.com/Website-update-td7590445.html
>
> ## The problem
>
> For a long time, Qpid was in many respects treated as one thing, with
> one release cycle. Its parts were divided at the top level by
> language, not function.
>
> The division by language provides little incentive to factor out
> dependencies into clean interfaces, and it has tended to mean that
> developers often work in just one language silo.
>
> It has also meant that our source modules have only a weak
> correspondence to the user-focused release artifacts that we produce.
>
> With Proton, we've broken the mold, and the overall picture of Qpid is
> inconsistent and confusing, to the Qpid developers and users.
>
> ## The proposed approach
>
> - Qpid the project embraces a functional division of components
>
> - Each source component is self-contained and independent, with a
> focused purpose; among components, there are well defined
> dependencies
>
> - The source components should correspond closely to the pieces our
> users want to use independently; nonetheless, there would in some
> cases be multiple release artifacts from a component
>
> - Each component has its own set of branches, supporting independent
> releases
>
> - Each component should be neither too large nor too small; large
> enough to ease development and release management; small enough to
> represent a focused functional unit and to clarify dependencies
>
> - API components would in some cases also contain code shared by APIs
> and servers; the server would in that case depend on the API code
> base
>
> ## Proposed source components
>
> - Proton (this one already exists)
> - /qpid/proton/trunk/
>
> - JMS
> - /qpid/jms/trunk/
> - Depends on Proton
>
> - Java broker
> - /qpid/java-broker/trunk/
> - Depends on JMS (?)
>
> - Messaging API
> - /qpid/messaging-api/trunk/
> - Both the C++ (and bindings) and python implementations would
> move here
> - Depends on Proton
>
> - C++ broker
> - /qpid/cpp-broker/trunk/
> - Depends on Messaging-API
>
> Note that this matches the download page of the new website pretty
> nicely.
>
> - http://people.apache.org/~jross/transom/head/download.html
>
> There's some debate about the right names for these things. Don't
> take my suggestions seriously. I just had to put something down to
> illustrate. If I had my druthers, we'd give the two brokers names
> that didn't include a programming language.
>
> ## First steps
>
> This change can't happen all at once. We propose to start with these:
>
> - Isolate JMS from the existing qpid/trunk/qpid tree
> - Isolate the Messaging API from the existing qpid/trunk/qpid tree
>
> If this is agreed, the idea is to bite off this much during the 0.24
> cycle.
>
> ## Developer infrastructure
>
> This change calls for some work to support developers using multiple
> components in one development environment. This needs more
> investigation.
>
> ## JIRA instances
>
> We propose *not* to create new jira instances for each component. We
> can do that later on if necessary. For now we can overload the
> version field in the qpid jira instance to include a component name.
>
> ## A Qpid "distribution" of source component releases
>
> While this scheme supports independent releases of each source
> component, it doesn't rule out a Qpid-wide release. There may be
> reason for Qpid as a whole to share a release cadence and
> produce a new "distribution" of components each cycle. It would all
> be more flexible, however. A component might want to produce three
> revisions in the space of a standard Qpid-wide four-month cycle, or a
> component might produce no new revisions.
>
> To me the advantage of producing a periodic distribution is (a)
> coordinated testing and (b) a known distribution set for users to
> deploy together.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org