I haven't been involved in any history here, so please forgive my naivete.
I think I understand the rationale for developing spec jars here at Apache. Please correct me if I'm wrong. In order to use a spec jar from the JCP, you have to click a license every time you download it. And this can be a real usability problem if every user of a project needs to manually download just to click a license that they don't read anyway (oops, gotta stop that).
It seems like a real waste of energy to have more than one spec jar in Apache per spec. Bygones. Whether this was accidental or intentional, it seems that we mostly need to agree on where the jars live and make sure that everyone knows where that is.
So if I'm interested in using the Servlet 2.3 jar, which project does this live in, and who manages it? I'd think that a well-known directory might be just the thing. Perhaps a TLP responsible to track where the JCP spec jars are being developed? [It might be that Jakarta is the right TLP.] And a pointer to the repository where the spec jars can be downloaded (automatically, maven-style). And some common naming scheme that everyone agrees on.
I doubt that there is enough in common among the spec jar developers to build a community around "spec jars". But certainly there is a community among the developers of Servlet and a different community among the developers of JDO and a different community for MyFaces, etc.
So it sounds straightforward to me to establish a TLP to house a "directory" of the spec jars and which projects they belong to and where the binaries reside.
On Dec 31, 2005, at 4:41 AM, Geir Magnusson Jr wrote:
Niclas Hedhman wrote:
On Saturday 31 December 2005 07:36, Noel J. Bergman wrote:
event, <...> an
uber-umbrella isn't making sense to me, so far.
Don't force things in place. To me, the most logical step forward is that most "uninteresting, boring, stenography" of specs sits in Geronimo, mainly because they were 'fed up' of the re-distro constraints imposed in the licensing. So, if there are duplication between Geronimo and let's say WS, why doesn't G and WS work out on which side of the fence the 'copy' sits. And since so much already sits with Geronimo, it would make sense to grow there.
We did this, actually, with Scout (JAXR), and it actually makes sense to use Scout's IMO because there is running code in the API (a factory) so it makes sense to be maintained by the implementor of the full spec.