Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of chirino@gmail.com designates
 209.85.146.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=AY0XUIK1QzwCOa4/3XqlU30hUsDeZlpxpvLLEpH+UwW7JFzI4tw3EfSPePrwTq4k5ssZsuR+kTJAhbk/ix9pZzpRqZQc9tVZWiSR2aAOq2ioK3zTxUNFykHrToVtDwpXxn3IvZNsihlLXv+gXmepXIJPb/IuxDW34UXYn4nGtns=
Message-ID: <af2843cd0711010724j1ccc303bkde451bd6b9e2e807@mail.gmail.com>
Date: Thu, 1 Nov 2007 10:24:44 -0400
From: "Hiram Chirino" <hiram@hiramchirino.com>
Sender: chirino@gmail.com
To: dev@activemq.apache.org
Subject: Re: Namespace Reorg
In-Reply-To: <af2843cd0711010720w76bf4aa9wf98379a67f02393c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <5a56ce1b0710311629kbdf4a6fo738ef82c9c49d08f@mail.gmail.com>
	 <af2843cd0711010720w76bf4aa9wf98379a67f02393c@mail.gmail.com>

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