activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: Namespace Reorg
Date Thu, 01 Nov 2007 14:20:32 GMT
Hi Jim,

Actually, I was working on the dependency problem last yesterday /
last night.  I went with the solution that has been working for us
very well in the Java space.  And that's using a maven style remote
repository to store deployed artifacts.

I've updated the nant builds so that they auto download the
dependencies from the 'remote' repository to the local repository.
And then the compilers use the files installed to the local
repository.  Right now the 'remote' repository is pointing at:
And the local repository defaults to being $HOME/.nant/repository

All the nant builds now support a install, install-all, deploy, and
deploy-all targets.  The default target is install-all.  This compiles
and the copies the results to the local repository so that they can be
used by other modules that you need to build next.

I wish the deploy target could install the artifacts to the remote
repository but right now it's just copies them to a directory you
specify using the -D:nant.deploy.repo=/path argument on the command
line.  Then you have to rsync that directory up to the remote repo.
Perhaps we can automate this bit too.

Please try it out and let me know what you think.


On 10/31/07, Jim Gomes <> wrote:
> [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 <> wrote:
> >
> > On 10/29/07, Hiram Chirino <> 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:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
> >



View raw message