activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes" <e.se...@gmail.com>
Subject Re: Namespace Reorg
Date Thu, 01 Nov 2007 23:28:45 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message