Hi,
The ibiblio repository mirrors several sites, and the important thing
is to establish with them what gets mirrored. Generally, only
released software distributions are mirrored. Nightly builds, alphas,
betas, release candidates generally don't get mirrored on ibiblio.
But generally available releases including update releases do get
mirrored.
As a specific example, the persistence api spec jar has a groupId of
javax.persistence, an artifactId of persistence-api, and a versionId
of 1.0. This artifact is in the directory
https://maven-
repository.dev.java.net/nonav/repository/javax.persistence/jars. If
you wanted this to be mirrored on ibiblio, you would arrange for the
https://maven-repository.dev.java.net/nonav directory to be mirrored
on ibiblio, for example at
http://mirrors.ibiblio.org/pub/mirrors/
glassfish/java-repository. Anything put into the nonav directory in
glassfish would be mirrored to the java-repository on ibiblio. [What
is the "nonav" terminology"]
Works in progress are another item to discuss. First, you need a
naming strategy that works well with maven. For folks who need the
latest working copy of persistence-api jar and don't want to build
the component themselves, you want the artifact to be named with
SNAPSHOT as part of the versionId. This tells maven to get the latest
jar from the repository. Since you don't want nightly SNAPSHOT
published on ibiblio, you need a different repository for the works
in progress. Perhaps a repository called something like
https://maven-
repository.dev.java.net/nightlies to distinguish from
https://maven-
repository.dev.java.net/nonav.
A naming strategy that I've seen work for other projects is to use
the preview naming convention. That is, you decide what version you
are working towards, and all the versionIds contain the new version
plus a suffix, e.g. 1.0.1-SNAPSHOT for the nightlies, 1.0.1-alpha for
a version that is known to be incomplete, 1.0.1-beta2 for a version
that is close to final, 1.0.1-rc4 for the fourth try at a release.
These works in progress would be published in the "nightlies" area of
the site. Once the community, including Sun, have tested the rc bits
sufficiently, a final call for testing is done against versionId
1.0.1 and if successful, this artifact is pushed to the "nonav" area
of the site.
Each artifact can be independently versioned, and to put together a
maintenance release each artifact would be versioned according to the
above scheme. Some artifacts would not need to be versioned if there
were no changes to that artifact. If a community member wanted to
build e.g. 9.0 UR1, whichever components had changed would be versioned.
Craig
On Jun 14, 2006, at 11:18 PM, Eduardo Pelegri-Llopart wrote:
> I agree there is value in separating spec and implementaiton jars.
>
> I believe that Kohsuke is already working in synchronizing
> Java.Net's repository with ibiblio. But if you have experience
> with Maven and are willing to help that would be very appreciated.
>
> - eduard/o
>
> Craig L Russell wrote:
>> Hi Eduardo,
>> I like that the persistence jars that are on the glassfish maven
>> repo are split into api jar and implementation jar. It is more
>> clear that the api jar is the specification and the toplink jar is
>> the reference implementation. This way, developers can get the
>> official spec jars and use it with any implementation. Good job.
>> I'd also like to see these jars pushed to ibiblio where there are
>> many other open source jars. I can help you identify a place to
>> put them on ibiblio if you don't already know...
>> Craig
>>> We just pushed a few more components to our maven repository (see
>>> http://blogs.sun.com/roller/page/theaquarium?
>>> entry=java_persistence_and_ejb_jars)
>>> and we will continue adding components, and I expect that, as
>>> part of
>>> GlassFish v2, we will normalize and automate the creation of these
>>> components.
>>>
>>> The intention is to make this repository serve the larger Java
>>> Community. This is something that, over the years, Sun has been
>>> asked
>>> to do, and now, with the Open Source focus, we can deliver on.
>>> I have
>>> already seen people starting to use javamail and activation from
>>> there,
>>> and I think it would be useful to spend some energy in making the
>>> repository as useful as possible.
>>>
>>> Probably the first thing to do is to start collecting ideas of what
>>> needs to be done. By my tally we have:
>>>
>>> Components
>>> JavaPersistence API, TopLink Essentials,
>>> JSTL 1.2, JSP 2.0, Servlet 2.4, JSF 1.1, JSF 1.2
>>> FastInfoset, XMLStream
>>> JavaMail
>>> Java Activation Framework
>>> JAXB
>>> JAX-WS, SAAJ
>>>
>>> Relatives
>>> Facelets
>>>
>>> Tools GF uses
>>> Japex
>>> Dalma
>>>
>>> What components are clearly missing? Bill was talking about doing a
>>> javaee.jar just for the APIs. I noticed that JAX-RPC seems
>>> missing and
>>> that should be easy to add, so I just sent a ping to Doug about it.
>>>
>>> What else should we do? Some thoughts...
>>>
>>> * We need a better index than the blogs at TA... :-)
>>> * Regular announcements somewhere (including the Maven USERS
>>> mailing list)
>>> * Synchronization with ibiblio?
>>> * Better integration with NB/Eclipse support?
>>>
>>> What else?
>>>
>>> Who has expertise in this area? Volunteers to help?
>>>
>>> - eduard/o
>>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell_at_sun.com
>> P.S. A good JDO? O, Gasp!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!
- application/pkcs7-signature attachment: smime.p7s