commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <>
Subject [Fwd: Re: [HiveMind] Forming the community]
Date Mon, 15 Sep 2003 15:55:21 GMT

-------- Original Message --------
Subject: 	Re: [HiveMind] Forming the community
Date: 	Mon, 15 Sep 2003 11:49:13 -0400
From: 	Harish Krishnaswamy <>
To: 	Howard M. Lewis Ship <>
References: 	<006001c37b86$dacf2af0$6401a8c0@ALMIGHTYBEAST>

I think it sounds good.

We certainly have to create multiple sub-projects like you suggested. 
And I think may be an external repository would be appropriate for 
these. The reason I say this is becasue we seem to have more external 
participation and it would be easier to manage in such case. We can 
always bring it back into Jakarta when appropriate. Now I am not sure of 
the pros and cons of these repositories/administrations.

For additional services, I think a DB access service is the next top 
priority as it is the most widely required. And of course we will need 
some sought of service pooling for multi-threaded services that is in 
the core of course.


Howard M. Lewis Ship wrote:

>Based on the feedback I've received from you and from interested parties with Jakarta
and Jakarta
>Commons, I believe this is how it can roll out.
>External developers can contribute patches.  By external, this means people who don't
already have
>Jakarta privileges.
>Those with Jakarta privileges should already have access to the HiveMind CVS repository,
that's the
>nature of the Jakarta Commons Sandbox.
>We'll stay on the mailing list, just put [HiveMind] in
the subject.
>We can worry about promotion out of the sandbox later.  Another possibility is moving
the source
>code under Tapestry (in the Tapestry 3.1 time frame).
>I have HiveMind building locally using Maven 1.0-rc-1 (out of Maven's CVS). I'm going
to look into
>refactoring the code base so that there are multiple sub-projects.  Initially, I envision
>framework subproject (for the framework and the core services ... which is to say, what's
>in CVS). Additionally, we should add a "standard library" module, for useful stuff that
>absolutely have to be in the framework propery and, perhaps, a sandbox module library,
for new code
>under less stringent release mechanisms.
>I this a good vision?  Or should the other modules become new commons sandbox projects
>themselves ... or be elsewhere, such as on SourceForge?
>What kind of services can we create for the additional libraries?
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message