Good catch.. let me see if I can resurrect that guy. On 11/1/07, Jim Gomes <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
