On Fri, 2005-05-13 at 00:59, Scott M Stark wrote: > The jbossas module I have been talking about is a testcase for > validating the breakout of the current jboss-head to validate use of the > repository. I thought that is what this module was for and had no other > uses. So let's clarify its current purpose. Is jbossas being used for > anything? >
jbossas was a module I introduced to support the new build during the transition. It replaces the build module as the top level build information in the cvs repository. > In terms of monolithic vs modular, I think were in agreement as the only > source I am envisioning is the integration and management code. I am > suggesting the legacy code that will never be standalone just be in > jbossas as least initially. If your arguing that everything should be > seperated from the start, ok, let's discuss it. The only thing that has > been done as far as I know if removal of remoting from jboss-head to > introduce the binary. I'm only working on reproducing the legacy > thirdparty binary structure for use with the 4.0 build. > Source trees have been added to the top level build and I thought you suggested that everything should be in one cvs module. I agree that that CVSROOT/modules is not the place to define the project struture. Equally, a directory structure inside a cvs module is not the place either. The correct place to define the project structure is in the versioned ant files for the top level builds and the referenced components. > We need to clarify who is working on what. I don't think there is any > real work to setup the next generation build right now. Maybe there is > confusion over what jbossas currently is being used for. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Adrian Brock > > Sent: Thursday, May 12, 2005 5:19 PM > > To: [email protected] > > Subject: MORE RANTS. was RE: [JBoss-dev] creating jboss > > thirdparty directory > > > > Ok, so I missed this post. > > > > Why are we changing the build structure before we have the > > new build in place and for untested/unvalidated/undiscussed > > requirements? > > > > My concerns (basically trying to run before we can walk): > > 1) We still don't have a new build that reproduces the old build > > 2) Some of the changes we have discussed or articulated are > > being done almost without people getting chance to respond or review > > 3) None of these changes has any experiments or use case > > descriptions showing how it will work. > > > > I'm confused, god knows about the other developers who are > > less involved in the project or paying less attention to the > > discussions? > > > > e.g. a use case I described for the new build, and I thought > > Scott articulated in his original response to this thread was > > the following: > > > > I want to test a patch to jboss-4.0.5 with the new build > > without going through all the tedium of a full > > rebuild/recompile on every small change. > > With the new build, the way I envisioned it was it would work > > as follows: > > > > 1) Download the main structure from the relevent branch cvs > > co -r JBoss_4_0_5 jbossas cd jbossas > > 2) Tell the build system I'm only interested in binaries by > > editing my local properties and retrieve the binaries ant synchronize > > 4) Build the release from the binaries > > ant release > > 5) Checkout the module I want to patch as source make my > > changes and recompile ant release > > 6) Run all the tests in all the projects (the tests are > > binary artifacts/jars in the repository) ant test > > > > How is this going to be possible if everything is in one > > module under cvs? > > > > Equally, how does this work with other integrations like > > jbossas + portal jbossas + seam etc. > > that have their own notion of the build totality. > > e.g. I would doubt portal wants to build jbossas from source! > > > > Also, I've been arguing for a while now that putting > > everything in one big "ball of mud" (as Andy calls it) just > > leads to everybody referencing everybody else and an > > integration/dependency nightmare. > > I see this only getting worse if everything is under one source tree. > > > > What I'd like to see before we make more changes are: > > 1) A working new build > > 2) Definition of build uses cases/procedures/requirements > > 3) Experiments that show these are supported and work > > 4) A dry run through the whole release cycle to show the > > process is working > > > > By a dry run, I mean smaller test project(s) where we can > > experiment/test the procedures and use cases before > > implementing them with our real projects. > > Rather than hoping that the new build will eventually support > > what you are trying to do. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_ids93&alloc_id281&op=click > _______________________________________________ > JBoss-Development mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
