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 18:02:24 GMT
Ok.. I'll try out setting up the extenal vendor branch system.. I'll
report back in a bit.


On 11/1/07, Jim Gomes <e.semog@gmail.com> wrote:
> Hi Hiram,
>
> I have updated to the latest check-ins and have been thinking about them.  I
> think this new organization is too complicated, and requires developers to
> use nant, which was not a requirement before.  I want to have complete
> development control from within Visual Studio, and I think this is possible.
>
> As I look back at my initial recommendation, it also is too complicated, and
> can be simplified further.  The extra Pre-Build copy step is not really
> necessary.  By setting the correct dependencies inside the solution file,
> Visual Studio will copy the assemblies to the correct locations
> automatically.  Here is what I recommend instead of posting compiled
> assemblies:
>
> The source of the Apache.NMS should be branched into each of the provider
> solutions, just as if it were a vendor snapshot using the paths I outlined
> earlier.  The Apache.NMS.csproj file will be included in the provider .SLN
> file.  the Apache.NMS project will be set as a dependency of the provider
> project.  Instead of Referencing a DLL, it will reference the Project.  This
> will cause the Apache.NMS assembly to be built first, and automatically
> copied into the output directory for link and run-time use.  No Pre-Build
> copy commands are necessary.  No check-in of compiled assembly DLLs is
> necessary.  The provider implementation has complete control over which
> version of Apache.NMS it is compiled against, and Apache.NMS has complete
> independence from any provider implementation.  With this type of
> organization, it is possible to stay within Visual Studio from beginning to
> end, and to have complete step-through debugging of all layers, since all of
> the source code is compiled by the provider solution.
>
> This works very well.  I have done a proof of concept with the
> Apache.NMS.ActiveMQ solution.  The use of nant build scripts is not
> necessary for those of use who work completely within Visual Studio.
>
> I have entered a new issue in the Issue Tracker [AMQNET-72] to track the
> reorganization of the projects.  I attached a patch file to that issue that
> shows the changes necessary to the Apache.NMS.ActiveMQ solution to support
> the vendor branch approach that I have outlined.  If this change suggestion
> is accepted, then the other provider solutions can be easily changed in a
> similar manner.
>
> Thanks,
> Jim Gomes
>
> On 11/1/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
> >
> > 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.csprojas
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.
> > > > >
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message