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?
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. 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
