Assembling products off projects (was Re: Back to Avalon...)

[Arieh Markel <Ar...@central.sun.com>]

Although being lurking in the shadows lately, my $0.02 follow.

> Mailing-List: contact general-help@jakarta.apache.org; run by ezmlm
> list-help: <ma...@jakarta.apache.org>
> list-unsubscribe: <ma...@jakarta.apache.org>
> list-post: <ma...@jakarta.apache.org>
> Delivered-To: mailing list general@jakarta.apache.org
> X-Sender: gdonald@alphalink.com.au
> To: general@jakarta.apache.org
> From: Peter Donald <do...@apache.org>
> Subject: Re: Back to Avalon...
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
> 
> hi,
> 
> At 02:06  2/2/01 -0800, Jon Stevens wrote:
> >Then you should be suggesting another top level project be created instead
> >of creating a pseudo project that is half within Avalon and half within the
> >top level namespace.
> >
> >Just like there is for Jetspeed.
> 
> No one else commented on this from PMC so I guess this is general consensus?
> 
> ie. 1 Project == 1 Product.

I don't think that this is the case.

I have run into a similar scenario here at work in the context of how
to come up with methodologies, infrastructure, process to be able to deliver
products that are composed of project-components.

That is:

	A product is composed of a set of deliverables that originate in
	discrete projects

	Projects contribute their deliverables as components that are
	assembled into products.
	
	Deliverables of one project may be assembled into multiple
	products
	
Therefore,

	if there are projects like:
	
		. Jakarta Base Network Utilities
		. Jakarta Base JSP Utilities
		. Jakarta XML Utilities
		. Jakarta SMTP Utilities
		. Jakarta Tools
		  .
		  .
		etc
		
	one could go about assembling products by picking up the appropriate
	'project deliverables' off the virtual shelf.
	
	So for example, Jakarta/Tomcat would result in the assembly into
	a product of:
	
		. Jakarta Base Network Utilities
		. Jakarta Base JSP Utilities
		. Jakarta XML Utilities
		. Jakarta Tools
		  .
		  .
		. rest of what is needed
		
	Other projects will pick and choose off the 'virtual shelf' what
	they deem appropriate.

What I am proposing is certainly one way of fostering re-use of code
and 'assembly-line' type of creation of products, and allowing our
efforts to scale.

Arieh

> 
> When any project grows such that there is multiple products they should be
> split off into multiple projects. Personally I don't see the advantage of
> splitting a community like that - especially when the split off project may
> not have enough momentum to survive. 
> 
> While I don't really like the idea of splitting Avalon at the moment if
> it's the only option to move forward then so be it ;) To propose the split
> do I just go back to Avalon and try to get consensus via vote and then
> reapproach here with a proposal? If so does the proposal have to be formal
> or can it be informal?
> 
> Cheers,
> 
> Pete
> 
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

--
 Arieh Markel		                Sun Microsystems Inc.
 Network Storage                        500 Eldorado Blvd. MS UBRM11-194
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)