Just to continue this to its full logical end. The ultimate goal, for all artifacts, is a sync to maven central. Without that last step, nothing in eclipse can use maven central, and noone using eclipse artifacts for their OSS projects can get into maven central. It is a requirement that the artifact you are wanting to be placed into maven central to have all of its downstream dependencies also in maven central. No pom defined alternate repositories allowed if you want your OSS project to reach maven central.
Now, to be clear, this requirement is for release (non-SNAPSHOT) artifacts. If, for example, gwt started to use eclipse jetty, then in order for their gwt artifacts to be put into central the eclipse jetty artifacts must also be in central. The iron fist declaration that all artifacts must be at maven.eclipse.orgis only answering 1/4th of the requirements eclipse and its community has. Here's my suggestions: * maven.eclipse.org is where all artifacts, produced by eclipse projects, both snapshot and release, are to be deployed to. * maven.eclipse.org will have a release repository * maven.eclipse.org will support release artifact staging and promotion to the release repository (this is a feature of nexus) * maven.eclipse.org will prevent direct deployment to the release repository (this is a security configuration for nexus) * maven.eclipse.org will reject overwriting or deleting of release artifacts (this is a rule that should be setup in nexus) * maven.eclipse.org will reject artifacts not within the org.eclipse.* groupId space (we shouldn't be using any other groupIds anyway) * maven.eclipse.org will have a snapshot repository * maven.eclipse.org will coordinate with the maven central maintainers at oss.sonatype.org how to have a (1 way) sync of maven.eclipse.org release repository to maven central. (How this is usually accomplished by oss.sonatype.org by a sync from maven.eclipse.org to an eclipse repository on oss.sonatype.org, then that repository is added to the maven central sync from oss.sonatype.org to maven central). - this is how google, apache, sun/oracle, and github (for example) now perform their syncs to maven central. - there is extra metadata produced by oss.sonatype.org to help out ivy/groovy build systems as well. - oss.sonatype.org mines the contents of the poms and jars to help with the search.maven.org search system as well (a system that is integrated into m2e's dependency search UI btw) * all release artifacts on maven.eclipse.org are permanent and never deleted (a behavior of p2 repositories that is extremely problematic) * snapshot artifact purging rules on maven.eclipse.org are up to the individual project leads. - pick from one of the following techniques: a) purge version specific snapshots on version release. b) purge snapshots based on age [1 year] c) manual purge of snapshots * snapshot deployment and release staging can be done by any member of the project to their own groupId space. * orbit dependencies are placed into org.eclipse.orbit groupId and managed by the orbit-dev teams using the orbit-maven-plugin * build systems at build.eclipse.org can deploy snapshots automatically to maven.eclipse.org's snapshot repositories using a common snapshot repository user id. * build systems at build.eclipse.org can never deploy release artifacts to the maven.eclipse.org release repositories, that must be performed by a committor of the project using their maven.eclipse.org credentials and build-time gpg signatures (used by maven and the repository system for artifact signing, not jar signing). * all deployments to maven.eclipse.org should follow the same rules as content eventually destined for maven central. a) if packaging is jar then -javadoc.jar is required b) if packaging is a java type (jar, war, sar, etc.) then -sources.jar is required c) no internal <repository> or <pluginRepository> sections are allowed in release quality poms (ok for snapshots) d) along with the default required list, the following (typically optional) pom sections are required for a release artifact <scm>, <url>, <licenses>, <organization> (fortunately most of these are already done for you in the eclipse parent pom) - Joakim Eclipse Jetty commiter
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
