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 Fri, 02 Nov 2007 04:52:02 GMT
Good catch.. let me see if I can resurrect that guy.

On 11/1/07, Jim Gomes <e.semog@gmail.com> wrote:
> Hi Hiram,
>
> It looks like we are missing the vs2005-stomp-tests.csproj in the new
> organization.  This should be included as part of the
> Apache.NMS.ActiveMQproject and added to the
> vs2005-activemq.sln file.
>
> Thanks,
> Jim
>
> On 11/1/07, Hiram Chirino <hiram@hiramchirino.com> wrote:
> >
> > Ok.. I got it setup for the NMS.ActiveMQ module.  Easy enough.
> > Please let me know if that's what you were requesting.. I'll
> > replicated that to the other modules if it's what you were looking
> > for.
> >
> >
> > 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/<http://people.apache.org/%7Echirino/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.NMSsource
> > > > > code.
> > > > > > > >
> > > > > > > > Once these branches have been created, each provider
> > implementation
> > > > > can then
> > > > > > > > control when to take a new drop of the Apache.NMSproject.
 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.NMSassembly
> > > > > 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.NMSproduct
> > > > > 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
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message