activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes" <e.se...@gmail.com>
Subject Namespace Reorg
Date Wed, 31 Oct 2007 23:29:52 GMT
[Subject was: NMS Tibco Code Drop is In!]

I have downloaded the latest code (Revision 590826) and have begun playing
with it.  There are some definite advantages and disadvantages to this new
structure.  The new structure breaks out the provider implementations into
independent projects.  The only dependency that each of these projects have
is on the main Apache.NMS project for the standard interfaces.

To support this dependency, I suggest the use of the Vendor Branch pattern.
the Apache.NMS project must be viewed and treated as a 3rd Party vendor
product by the provider implementation projects.  Each provider
implementation needs to control its own release cycle.  Therefore, the
Apache.NMS project tree should be branched as follows:

>From /Apache.NMS/trunk    ->    /Apache.NMS.ActiveMQ/trunk/Apache.NMS
>From /Apache.NMS/trunk    ->    /Apache.NMS.EMS/trunk/Apache.NMS
>From /Apache.NMS/trunk    ->    /Apache.NMS.MSMQ/trunk/Apache.NMS

The Subversion book recommends using an intermediate branch of /vendor, but
this is only to support custom modifications to the vendor source code.  I
don't think this level of support is necessary, as the individual provider
implementations should not be customizing the Apache.NMS source code.

Once these branches have been created, each provider implementation can then
control when to take a new drop of the Apache.NMS project.  The solution
file within the provider project will include the Apache.NMS.csproj as well
as it's own project file.  It will build the Apache.NMS assembly first, and
then copy the output of the Apache.NMS.csproj build into its lib folder
where it can be referenced for its build.  The copying of the
Apache.NMSassembly should be done in the Pre-Build custom build step
of the provider's
project file.  This will leave the Apache.NMS.csproj file untouched.  The
Pre-Build custom build step should take into account the current build
configuration (i.e., Debug or Release) to copy the correct version of the
Apache.NMS.dll file.

I think there is a similar solution for the unit tests as well.  It should
be possible to write a common set of tests in the Apache.NMS product that
can be shared out to each provider implementation.  This allows each
provider to have a baseline reference of functionality that they must
support.  Each provider project should be free to augment the unit tests
with their own unit tests.

Comments and discussion are welcome and appreciated.

On 10/29/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
>
> On 10/29/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
> > Ok.. The code has been moved and it seems to build fine using the
> > VS2005 project files.  The build methods still need to get updated.
> > But while we are re-orging this stuff..I think it might be a good time
> > to bing the module naming conventions to match up.
> >
> > Right Now:
> >  * NMS module uses the namespace Apache.NMS and produces a NMS.dll.
> >  * NMS.ActiveMQ module uses the namespace Apache.ActiveMQ and produces
> > a NMS.ActiveMQ.dll.
> >  * NMS.MSMQ module uses the namespace Apache.MSMQ and produces a
> NMS.MSMQ.dll.
> >  * NMS.EMS module uses the namespace Apache.TibcoEMS and produces a
> NMS.EMS.dll.
> >
> > I propose that we make the module name, namespace, and dll names
> > match.  Those being:
> > Apache.NMS, Apache.NMS.ActiveMQ, Apache.NMS.MSMQ, and Apache.NMS.EMS
> >
>
> Ok.. the above changes have been committed.
>
> Please get fresh checkouts from:
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS/trunk/
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.EMS/trunk/
>
> https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.MSMQ/trunk/
>
> I'm going to work on the nant builds next.  But the VS builds work
> fine as long as you manually copy the inter-project dlls into the lib
> directory.  For example, the NMS.ActiveMQ project depends and you
> building NMS then copying the produced dll files to the ActiveMQ
> project's lib directory.
>
> Anybody have suggestions on how we could automate some of this inter
> project dependency copying??
>
> Regards,
> Hiram
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message