Thanks for the reply Brian, this is much relief.
However in your initial response your wording clearly indicated the new policy
already being enforced, up to:
"[...] your artifacts will end up blocked."
A little less restrictive description could have prevented this
misunderstanding...
I think that, with the goals you have, it would be good to already "announce"
this more prominently, especially within the ASF.
I suspect others will raise questions similar to mine and maybe even more.
Upfront and public awareness of important changes things like these is
important to build up support for it IMO.
Doing it 1-on-1 with individual release managers/projects seems both very time consuming
and "hiding" it from the larger community.
I don't know who "owns" Maven Central (Sonatype?) but as the "default" repository build into Apache Maven I would think at least the ASF
community would have to be informed proper and be allowed to discuss what/how/when concerning such policy changes.
Never mind, we're cool again for now.
I'll ping you again when we are ready for the rsync of our "legacy" bugfix
release.
Kind regards,
Ate
On 03/25/2010 05:49 AM, Brian Fox wrote:
Interesting. That's news to me... You have a pointer to more information?
As it turns out, almost all references to external repositories in
poms are junk or turn out to be junk after a bit of time. See here for
some examples:
http://www.sonatype.com/people/2010/03/why-external-repos-are-being-phased-out-of-central/
* Unclear from the documentation is if this restriction on external
repositories is limited to only the repository definitions in a pom, or if
it is (or will be) extended to dependency resolving as well.
If not all dependencies can be resolved to Central itself, would that be
"flagged" too and also cause blocking the artifact(s) ?
The validations are currently configured to disallow any release
repository declarations in the poms. We may allow some approved
external repos down the road if the contents are vetted and cleaned
and unlikely to disappear. The main issues revolve around fly-by-night
or unreliable repositories. Having these in your poms is a red herring
and end up causing your users more harm than good.
* At what stage is this policy "enforced"? I'm thinking of Apache Repository
when we deploy and release. Would a violation of this policy already be
noticed (and reported) while doing a staging release, or only at the final
release to Maven Central?
This is enforced by the Nexus staging rules in the various forges and
ultimately will be applied to all avenues into Central regardless of
the source. (Rsyncs are being phased out). I have not enabled this
rule on repository.apache.org but it is in place in most other
locations. I wanted to be able to analyze the external repo use of
Apache based projects and work with them before throwing down a new
gauntlet. No panic is necessary, we'll work this out together, but
this is a rule that is going into effect at Central and all projects,
Apache or not will eventually have to pass the same criteria.
The latter clearly would be too little too late IMO.
Note: we're using Apache Repository for snapshot deployments right now, and
I haven't seen any "warning" about us referencing external repositories.
This currently wouldn't trigger on any snapshot builds, but would
prevent the promotion of a staged repo, exactly how you can't promote
artifacts that aren't signed. Again, it's not enabled and I don't
intend to enable it until I can analyze and work with projects to make
this a non issue.
* Does this new policy also affect the processing and handling of the
"legacy" rsync repositories at /www/people.apache.org/repo?
As it will affect all sources into Central, yes this would eventually
affect the legacy repo as well. However...
If it does, or even only partly, please let us know how and to what extend.
Note: we're planning a bugfix release shortly of an older version of
Jetspeed-2, version 2.1.4 (Apache Portals).
That version of Jetspeed-2 doesn't and cannot use the new Apache master pom
nor Apache Repository as it would require too major changes for the whole
project configuration itself. The current Jetspeed-2 version 2.2.0 has been
released through Apache Repository, and we're planning a new release 2.2.1
shortly too. However, for Jetspeed 2.1.4 we'll still have to use the
"legacy" rsync procedure.
When a project is moved over to the new repo, the legacy repo is
disabled for that project. Meaning you won't be able to deploy there
anymore. Central can't rsync the same project from two locations and
expect the metadata to be correct. To deploy into r.a.o, you won't
have to use the entire new master pom, just change the url in your
distributionManagement. Just ping me and I'll be glad to help you out
with this.
* A policy change like this will IMO affect and *restrict* any and all
Apache maven build based projects who want or are supposed to deploy to
Maven Central. *Apache* policy does not in any way restrict (maven)
dependencies on external repositories as long as the ASL license is honored.
For whatever reason, this new Maven Central policy now seems to require all
external dependencies be (at least also) be available from it.
This affects all artifacts in Central not just Apache. We're doing it
to improve the ecosystem, take a look at my blog referenced above and
you'll see why this is a critical issue to be resolved.
What about other, generally respected and IMO also fine repositories like
http://download.java.net/maven/2 ?
Have you actually looked at the contents there? We have and frankly
it's a disaster. The good news is we're working to clean this up and
get all those artifacts into Central as well.
The sky isn't falling here and we aren't going to do anything to harm
the community, this is an effort to move towards a more sustainable
model. My answer was in response to the initial question of should
they use external repositories and I simply wanted to point out that
they should avoid going down a road that will have to be unwound in
the near future.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
