[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] deploying snapshot builds from hudson.e.o to oss.sonatype.org
|
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.org is 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 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)
- 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 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
