MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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.

On Wed, 2005-05-11 at 00:51, Scott M Stark wrote:
> Yes, go ahead. After I finish the 4.0 thirdparty setup I'll migrate it
> to the jbossas build on head as well. The code that will continue to
> live in jbossas like the legacy ejb container, jbossmq, etc. should be
> copied into the jbossas module with its cvs history to get rid of the
> modules file usage as well to complete this.
> 
> > -----Original Message-----
> > From: jbo...@li... 
> > [mailto:jbo...@li...] On 
> > Behalf Of Tom Elrod
> > Sent: Tuesday, May 10, 2005 8:58 PM
> > To: jbo...@li...
> > Subject: Re: [JBoss-dev] creating jboss thirdparty directory
> ...
> > 
> > I think we are there.  There is already a jbossas module 
> > defined with nothing but the new build in it.  Remoting is 
> > ready to make this move (no better time actually).  If you 
> > give the green light, I will execute what I have described 
> > below and we will be on our way to this new path.
> > 
> > As other projects break off, they can do the same.  I think 
> > with the new build process, it would also be a big help to 
> > network as will have modular, versioned components that will 
> > be easier to do patch updates for.
> > 
> 
> 
> -------------------------------------------------------
> 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
> JBo...@li...
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-- 
xxxxxxxxxxxxxxxxxxxxxxxx 
Adrian Brock
Chief Scientist
JBoss Inc.
xxxxxxxxxxxxxxxxxxxxxxxx 