www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: adding jaxme jars
Date Thu, 11 Mar 2004 19:59:37 GMT

Sander Striker wrote:

>>From: Mark R. Diggory [mailto:mdiggory@latte.harvard.edu]
>>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 general@incubator 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/.

Absolutely Correct.

>>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.
> Sander

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

View raw message