Dain Sundstrom wrote:
I would hope so. These projects have a trivial or non existent set of dependencies. Take a look at a big project using maven and you will see that they use lots of repos, because ibiblio tends not to have everything necessary or was down when someone was working.
Yet, ibiblio is an exact mirror of dist/java-repository without deletion. There is nothing in dist/java-repository that is not also present on ibibilio and the rsync is every four hours so there is actually only a tiny lag concerning differences. Ibiblio is the canonical repository of Maven, you would have to be doing a tremendous about of overriding to change its location on a consistent basis. "Why?" waist such time.
My understanding is that Ibibilio is a system dedicated to mirroring massive amounts of content with raid/fallover and multiple gateways/ISP's, I would expect its up time to be far more consistent than even that of Apache.
In Maven, the repository used to get downloads from is not a project attiribute, it is a user decision/configuaration of the client. So really, a project that ends up with any dependency downloads directly from dist/java-repository is not the best solution, ibiblio is the more persistent and canonical point to be downloading from at this point.
Take a look at geronimo and you will see that it is impractical for a user to hunt down dependencies. The code from a source distribution should just build, which means that all the dependencies *must* always be available.
A simple search of the files in the filesystem for any string matches to "dist/java-repository" would suffice. I checked it out and searched it on my laptop just now using Eclipse, there are no references in any of the files in any of geronimo. I been doing greps on cvs.apache.org and find the following cases as examples of references
jakarta-turbine-2/project.properties,v:maven.repo.remote=http://www.ibiblio.org/maven/,http://www.apache.org/dist/java-repository/
This is a bad usage of java-repository, but not a show stopper, It will go to ibilio first then the ASF Repository, things should work fine as long as ibibilio's up. We should make sure there are no cases of the following for example:
jakarta-turbine-2/project.properties,v:maven.repo.remote=http://www.apache.org/dist/java-repository/
Thats bad, theres really no reason this should be done at this point and time.
Heres a really good example of a reference we promote usage of:
jakarta-commons/chain/project.properties,v:maven.repo.central.directory=/www/www.apache.org/dist/java-repository
maven.repo.central.directory is property which states "where" to publish to, not where to download from.
It might be good to go through the Apache projects that are in java-repository and see if any are packaged to download dependencies from there, I doubt it that here would be any occurances however. As a majority of the files were originally published to/against ibiblio in the first place.
Unfortunately, not all projects that use the apache repos are not hosted at apache.
We've never publicized the the java-repository to be used externally. It 's content was originally migrated from Apache by Jason Van Zyl and Myself with the goal of getting publishing of Apache content back to Apache (with Ibibilio as a mirror). Anyone using it would be using it at their own risk. I believe that any consultation with the ASF Repository project here at Apache would have made this issue clear to them.
Further, my point is that currently there shouldn't be projects dependent on java-repository as its location for resolving jar dependencies, there is an entire discussion on the [EMAIL PROTECTED] list concerning this subject, the repository used is a configuration of the client right now (in Maven) not a characteristic of the project.xml of a maven project. You can suggest a repository to use in properties handed to Maven, but the default is always www.ibiblio.org/maven. Our initial creation of java-repository was never not to have a "Standalone" Maven repository at Apache, but to provide a simple means for Apache developers to publish release jars and distributions to Ibibilio until such a time when distributed repositories become a greater practice.
Its a real bad idea to force build dependencies against it at this time until we get it stabilized. Its entire contents are present at Ibiblio, there currently is no reason a project should be using it directly vs ibibilio.
On top of this I recommend that Apache avoid maintaining interim builds in such a way that external projects can build dependencies against them. External projects should only be using fully 'sanctioned' releases published in dist for this purpose. Until tooling is completed in Ant and Maven to support distributing download requests from the ASF Repository across the mirrors we really cannot recommend that external projects build dependencies against the contents of the ASF Repository directly, please use Ibiblio/maven for this until such capabilities come into existence.
After writing some scripts to search the Apache cvs tree and inspecting the results. It really breaks down to three cases where projects reference java-repository:
1.) In Maven project.properties, Referencing the remote repository
maven.repo.remote=http://www.apache.org/dist/java-repository/
2.) In Maven project.properties, Referencing a central repository
maven.repo.central.directory=/www/www.apache.org/dist/java-repository
3.) In Ant files generated from Maven, Hardcoded references to java-repository.
I believe we should take the following stance on these cases:
1.) ----1 !!!
2.) +1
3.) ----1 !!!
(3) is caused by using (1) and generating an ant build file using Mavens Ant task. Luckily, there are currently (and thankfully) no cases of this occurring in the HEAD of the Apache cvs tree.
As well, most projects that have java-repository as a remote repo, also have have ibibilio in from of it:
maven.repo.remote=http://www.ibiblio.org/maven/,http://www.apache.org/dist/java-repository/
this is safe but not at all recommended (yet) and stops (3) from occurring.
-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
