qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@apache.org>
Subject Modularizing Qpid
Date Wed, 10 Apr 2013 13:55:22 GMT
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


Mime
View raw message