activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Namespace Reorg
Date Thu, 01 Nov 2007 14:24:44 GMT
Just remembered.. I need to check to see if I can update the VS
project files to refer to dependencies from the local repo...
Otherwise I think I'm gonna have to copy them into the $project/lib
folder as part of the build process.

On 11/1/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
> 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:
> http://people.apache.org/~chirino/nant-repo/
> 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.
>
> Regards,
> Hiram
>
> On 10/31/07, Jim Gomes <e.semog@gmail.com> 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 <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
> > >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message