On Jan 7, 2005, at 6:56 AM, Mark R. Diggory wrote:
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.
Regardless of what people should and shouldn't do, they do this all the 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.
:) I would expect that also, but it simply isn't true. Ibiblio has blackouts and brownouts all the time. The latter are much worse as it doesn't immediately return an error code; instead, it spends like 5 minutes downloading a 20k jar.
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.
This is exactly my point. If someone pulled down that source, it potentially won't build. Once you start messing with repos, it can eliminate the possibility of recreating *historical* builds.
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.
I agree with what you are writing, but people do it. IMHO if you are going to create a public repo, they you have a responsibility to keep the artifacts around forever.
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.
That is simply not possible. Geronimo has three external sister projects OpenEJB, ActiveMQ and TranQL. These projects import Geronimo and Geronimo aggregates their jars into the final distribution. If this were policy, then either the Geronimo project would stop, or more likely the Geronimo project would publish fully "sanctioned' releases every checkin.
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 !!!
Agree - I personally wouldn't do 2, but I see no reason to discourage it.
I personally don't mind eliminating files from this repo, but I think you should be aware that you are making a decision that most like will break a few historical builds. I personally feel this is an acceptable level of breakage, but I don't think we should down play the fact it may break some builds.
-dain
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
