Sander Striker wrote:
From: Mark R. Diggory [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 7:52 PM
Basically, in Maven the difference between "version releases" and "build releases" is designated in the version, not in the artifact id.
It is important to have your artifactId's match across all versions of an artifact, otherwise they aren't the same "artifact", so
does not share the same artifact id as
to have them match it would have to be
Hmm, couldn't the filename and artifact id be decoupled?
I'm not suggesting rightness or wrongness of the approach in the following comments. Simply just what Maven currently does:
This naming structure is important only in terms of the existing Maven Repository Design (probably less likely in future Maven2 designs). The repository structure for Maven is currently rather strict in this regard
One question: How would you then "lookup" that file by only "group", "artifact" and "version"? You'd need to know how to generate its "filename" (ie in this case:<artifactId>-<version>.<ext>).
When ever I think about this, I always come full circle that the only "flexible" solution to this sort of issue is not in the URL "syntax" but in the "resolution" mechanism. What we are essentially doing is trying to establish an "Identifier" for a resource that can be "resolved" to that resource.
I'm really getting more and more of the opinion that what Apache/Maven/Depot etc. needs more than a "Repository" structure is a "resolving service". A service very much similar in structure to that which "Public Id's" in XML/SGML or DOI's/Handles/Purl's in the Library community. Then a Project is simply assigned a Public Id Namespace in which to "identify" its resources, Then resolver/proxy services can be used to map that "id" to an actual URL location of the file. A url location that can be "anywhere" and of "any format". Then the "structure" of these directories become loose and simply just for managing a projects released files again.
Think about it, This gives us a layer of "flexibility" in resolution which is "decoupled" from the layer of storage. As such files can move around and files can be located in multiple locations (mirrors). The resolving mechanism handles the persistence of the id.
This way, if (for instance) a jar file is "demoted" from public distribution (aka www.apache.org/dist) on the mirrors, its id simply is pointed at the archived version instead of the mirrored version.
And, if a file is mirrored, the id can be resolved using a mechanism similar to "/dyn/closer.cgi" to resolve to a distribution mirror for that resource instead of the Apache server.
So, if your going to be distributing a "build release" I recommend the naming strategy where all artifactID's match. If the jaxme project is planning to leave the incubator anytime in the future, I would highly recommend you not use the word "incubator" in the artifact id. My personal opinion added to this is that its the same way we don't use "jakarta" in in projects like the Jakarta Commons, because some aspects Jakarta is a Foundry. Incubator is also a Foundry.
Incubator is a bit of a different beast than Jakarta. Projects in the Incubator are not 'full fledged ASF projects' yet, they will be as soon as they leave in Incubator. The incubation designation has come up on the [EMAIL PROTECTED] list. If this is problematic for any reason I suggest you bring that up there.
Sounds similar to the Jakarta Commons Sandbox, Actually, projects there are not allowed to release jars until they graduate to the Jakarta Commons Proper. Generally speaking, jars produce by such projects are not distributed anywhere but by the author on their local system. Yet, I believe that Jakarta does complete a daily build process for these projects as well, so even though they are not officially released, there are packages which can be gotten at on cvs.apache.org.
My future planned strategy to support "build-releases" is to have build releases (daily, weekly builds etc) not be present on:
but to actually be present on:
Which is where they belong. Snapshots don't ever belong on www.apache.org/dist/.
Then, to actually use this approach with Maven you'd have to add the cvs.apache.org repository to your Maven client, this makes project dependencies hairy in the Current release of Maven because the contents wouldn't be present at ibiblio. We still have much to decide to do and infrastructure to setup to have this build location.
Is there some roadmap I can read and comment on?
Unfortunately, no. Only the discussion on this list to date.
My current strategy in this case is to have the build-releases in the same project directory as the version releases, then they are all rsynced with ibiblio properly. This is simply because build releases already existed in the repository when we moved the apache contents of ibiblio back to Apache.
What is the status of jaxme in the incubator? When do they anticipate an official release?
Given there will be future projects in incubator with releases during
incubation, it would be nice if we could accomodate for that.
I think a repository structure in the cvs.apache.org/builds area should be reserved for this.
Maybe this is a reason enough to push forward the development of the daily/weekly/... build repository. Allowing any more build-releasing in the dist/java-repository is a sensitive issue when it comes to mirroring. It would be wise for us to stop doing this asap. This is probably a good location where I could use assistance from repository folks in working out these details.
Should we setup a Maven repository structure in cvs.apache.org/build to publish snapshot jars to now? This would at least get the ball rolling.
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu