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:55:45 GMT
Yay.. your able to use environment variables in the VS project files.
I've now updated them to also refer to the nant repo to look for
dependencies.

On 11/1/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
> 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
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message