incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: Starting a java specs project
Date Fri, 30 Dec 2005 16:31:42 GMT

this is just for sources of javax.* NOT implementations. One location
for a servlet-api.jar, jaxrpc.jar, saaj.jar, xml-apis.jar.

-- dims

On 12/30/05, Noel J. Bergman <> wrote:
> Alan D. Cabrera wrote:
> > There has been some discussion on creating a Java specs project
> > which would hold all the specs jars from the various JSRs as well
> > as other standards, e.g. CORBA.  Often, there are many duplicate
> > "copies" of the source code for the same JSR floating around in
> > different Apache projects.  It would be a great idea to move them
> > all into one project.  This idea, so far, has been met with much
> > enthusiasm.
> What exactly does this mean?  That the source for Tomcat, JackRabbit,
> Geronimo, WS, Directory and all of the others will be moved to one place?
> Geir says:
>  "The point of this was that this is shared code as well as code that
>  causes collisions.  Apache Geronimo had to implement this stuff for
>  J2EE, but it's a dupe of what we find elsewhere, like in tomcat and
>  in web-services land.
> I agree that this is a problem, but turning Geronimo into something worse
> than Jakarta ever was, or turning Jakarta back into its old self is not a
> solution.  Getting projects to stop rolling their own, and to collaborate
> with the other projects is one solution.  For example, if those Geronimo
> built artifacts are dupes, then why were they built instead of re-used?  And
> we have similar situations all over the ASF.
> Geronimo was never intended to build everything.  It was intended to build
> the infrastructure for pulling together all of the parts from around the ASF
> and elswhere as necessary that were required to build a J2EE server.
> If you want to have an ontological map of where each JSR is implemented
> around the ASF, for that I would be +1.  We've discussed that idea before.
> If we want to make sure that these jars can be separately accessed, rather
> than just in a big release package, +1 of course.  If we want a common
> distribution repository for the binaries, OK.
> But to have a single uber-umbrella for every JSR implementation?
>         --- Noel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Davanum Srinivas :

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message