incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: Third party Maven Repository Usage
Date Thu, 25 Mar 2010 08:23:39 GMT
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,


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:
>> * 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 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/
> 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
>> ?
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message