| Summary: | Push equinox bundles to Maven Central | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Harald Wellmann <hwellmann.de> |
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | amarana.nagaraju, cvgaviao, david_williams, davymeers, pwebster, raymond.auge, remy.suen, sanjeeb.sahoo, t-oberlies, thanh.ha, tjwatson, toni.menzel |
| Version: | 3.7.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Harald Wellmann
This is very much needed. +1 Let us know if we can aid/support in any way. Toni As a start, it would already help if the artifacts were available from repo.eclipse.org. @Paul: Could you help the Equinox team with this? The JDT guys already deploy to repo.eclipse.org - maybe org.eclipse.osgi can be deployed in a similar way? Shouldn't this just be part of our overall eclipse/equinox build process for every milestone? It would seem that we want all bundles published from both the eclipse and equinox projects. We currently (manually) publish milestones versions of org.eclipse.jdt.core to repo.eclipse.org to be used as part of our CBI build process: https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/deployJDTCompiler/ We're just using a job that runs deploy:deploy-file: version=${jdtversion} url=https://repo.eclipse.org/content/repositories/eclipse-staging/ groupId=org.eclipse.jdt file=${jdtlocation}/org.eclipse.jdt.core_${jdtversion}.jar packaging=jar repositoryId=repo.eclipse.org artifactId=org.eclipse.jdt.core Because we're pushing up milestones, we push to staging (so we can delete them later). PW (In reply to Thomas Watson from comment #4) > Shouldn't this just be part of our overall eclipse/equinox build process for > every milestone? It would seem that we want all bundles published from both > the eclipse and equinox projects. Depends on where we put them. Maven is forever :-) We can push up a release to our repo.eclipse.org or maven central, but I thought we had a problem. Maven Central expects a jar (OK), source (mostly OK), proper dependencies in the pom (OK for org.eclipse.osg :-), and javadoc (we don't generate that). So for a release, we could do something like: mvn org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file -Durl=https://repo.eclipse.org/content/repositories/eclipse-releases \ -DrepositoryId=repo.eclipse.org \ -DgroupId=org.eclipse.osgi \ -DartifactId=org.eclipse.osgi \ -Dversion=3.9.1.v20140110-1610 \ -Dfile=eclipse/plugins/org.eclipse.osgi_3.9.1.v20140110-1610.jar \ -Dsources=eclipse/plugins/org.eclipse.osgi.source_3.9.1.v20140110-1610.jar We can't add the javadoc, and it's possible we're supposed to rename the source jar. I'm not sure from there how we would get it into maven central. Thanh? PW (In reply to Paul Webster from comment #6) > I'm not sure from there how we would get it into maven central. Thanh? > Unfortunately if a project wants to push artifacts to Maven Central they will need to use a repo that is supported by Maven Central. Such as: https://maven.apache.org/guides/mini/guide-central-repository-upload.html We have asked in the past and were told that they will not accept our artifacts because we are not using Nexus Pro. (We are running Nexus OSS) See: http://dev.eclipse.org/mhonarc/lists/dash-dev/msg01348.html (In reply to Thanh Ha from comment #7) > We have asked in the past and were told that they will not accept our > artifacts because we are not using Nexus Pro. (We are running Nexus OSS) > > See: http://dev.eclipse.org/mhonarc/lists/dash-dev/msg01348.html So we can't push from repo.eclipse.org (but we haven't been vetting what's in repo.eclipse.org to make sure it's conformant/provides all the information). What about setting up a process that works with Sonatype: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide PW (In reply to comment #7) > We have asked in the past and were told that they will not accept our artifacts > because we are not using Nexus Pro. (We are running Nexus OSS) I don't think that there is actually much benefit in such a setup because Eclipse doesn't do releases in the Maven sense. As long as there are anyway only a few artifacts deployed, you may just as well directly deploy them to oss.sonatype.org. (In reply to comment #8) > What about setting up a process that works with Sonatype: > https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide This is what we do in Tycho, and it works without problems (maybe with the exception of the problems caused by our corporate proxy...) FYI: In the Tycho project, we have just automated our process for deploying org.eclipse.osgi to Maven Central [1] (using our org.eclipse.tycho groupId). It shouldn't be hard for you to do the same. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-releng In trying to shake to cobwebs off this issue, I'd like to throw in my vote to have this issue addressed. Currently, because there is no movement on this, Sonatype OSS's process provides for third parties to request equinox libs to be published to MC outside of equinox's release process, provided the artifacts are the official drops from an equinox release. https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository This means 1) it's not in equinox's control 2) appearance of artifacts in maven central is sporadic and erratic as evidenced by: http://search.maven.org/#browse%7C-552727178 The process to request control of the associated MC groups is https://issues.sonatype.org/secure/CreateIssue.jspa?issuetype=21&pid=10134 Getting control of that group would block third parties from having the ability to request publishing to it. However, it'd be nice if at that point the maintenance effort was upheld. I'm expanding the title of this issue to the entire set of artifacts as I believe any solution won't be partially applied to individual artifacts, but rather as large swaths of them, mostly likely either per repo or per top level project. *** Bug 488826 has been marked as a duplicate of this bug. *** We do now publish our artifacts each release under the group id ID org.eclipse.platform |