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:05:43 GMT
And yes nant was a sort of requirement before.. It's the only build
system that works across frameworks and we do want to support mono
too.  It also will detect and compile against all available frameworks
on your machine.  So we will use it at least when we are doing release
builds.

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


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message