Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CANVjZ_SqXFxcdR=DaknErN2S0TFc7zW5GXeZw8nZzi3FX4iPpQ@mail.gmail.com>
References: 
 <CANVjZ_SqXFxcdR=DaknErN2S0TFc7zW5GXeZw8nZzi3FX4iPpQ@mail.gmail.com>
Date: Thu, 11 Apr 2013 00:24:53 +0200
Message-ID: 
 <CAOhBXQ5CgZ69ipkzZ2mewD8xkDs7B-HAA-n-p-_yyenXyAV4EQ@mail.gmail.com>
Subject: Re: Modularizing Qpid
From: Jakub Scholz <jakub@scholz.cz>
To: dev@qpid.apache.org, users@qpid.apache.org
Content-Type: multipart/alternative; boundary=e89a8f6464e796851304da0923d3

--e89a8f6464e796851304da0923d3
Content-Type: text/plain; charset=ISO-8859-1

>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 <jross@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
>
>

--e89a8f6464e796851304da0923d3--