Community
Participate
Working Groups
We are currently using OSSRH as the main Maven repository for EE4J projects. This solution is not ideal comparing to maven.java.net which we used in Oracle. This ‘bug’ is created to describe advantages of using maven.java.net or similar solutions and track the decision making process. Maven.java.net was provided to Oracle for free. It’s the same software used by OSSRH. We need to make sure that Nexus software provided to Eclipse Foundation has the same functionality and allow releasing artifacts to Maven Central which the absolutely required. Advantantages: 1. Control over retention policy It was a pain point for GlassFish 5.1 release. Removing (or loosing) the retention policy would save us a lot of time and efforts. 2. Administration access It’s the main reason we need our own Sonatype instance. It will allow making requested changes faster without interacting with OSSRH support. We will be able to set it up the way we need. For example: a. Setup and manage users accounts, access rights or even integrate it with Eclipse SSO. b. Create automation allowing releasing to Maven Central from top to bottom automatically. Instead of a manual bottom-top approach, an automated top-bottom approach could be implemented. This would mean that projects like GlassFish would trigger the release of missing dependencies automatically. c. Create custom workflows for releasing to Maven Central 3. Promoted repositories Instead of consuming from the staging group, we'd have another level of repositories used as intermediate release. This would mean, consumption from staging group is replaced by consumption from promoted group. Access to promoted groups could be restricted to limit the re-release madness. E.g. one could still create/drop/promoted a staging repository, however promoted would only be doable by people with proper access. Promotion would be required in order to be consumed by other projects, thus once consumed re-releasing something requires a special approval and a special action by someone with special access. 4. Other possible features such as metrics, additional checks (e.g. deep license check), artifact tracking (keep track of all Maven artifacts being deployed under eclipse), etc.
I understand your reason, but it sounds as if you want to have one big single GlassFish project with all pieces contained in it rather than having independent objects. Speaking for myself only but as the maintainer of all JAX-RS releases under EF control I need to say that I dislike your proposal. I was happy with OSSRH and vote to stay with it, and all JAX-RS committers already have all what they need including access to the OSSRH account (if not, they can get it). OSSRH is the world's de-facto way to push open source to Maven Central and the EF should not start our own way just because some GlassFish people want that.
(In reply to Markus Karg from comment #1) > I understand your reason, but it sounds as if you want to have one big > single GlassFish project with all pieces contained in it rather than having > independent objects. For bigger projects like GlassFish it makes more sense. For smaller projects you will have the same as OSSRH offers plus some potential integration with Eclipse build infra, Eclipse SSO, etc. > Speaking for myself only but as the maintainer of all JAX-RS releases under > EF control I need to say that I dislike your proposal. I was happy with > OSSRH and vote to stay with it, and all JAX-RS committers already have all > what they need including access to the OSSRH account (if not, they can get > it). Partially it's because you were releasing JAX-RS not the recommended way. If you use Eclipse build infra to make releases (which is the recommended way) you would possibly change your opinion. :) > OSSRH is the world's de-facto way to push open source to Maven Central > and the EF should not start our own way just because some GlassFish people > want that. This is the way we used in Oracle and I must say that it's much better. My reasons are described above. I think we should not give up this idea only because some JAX-RS people don't want it.
(In reply to Dmitry Kornilov from comment #2) > (In reply to Markus Karg from comment #1) > > Speaking for myself only but as the maintainer of all JAX-RS releases under > > EF control I need to say that I dislike your proposal. I was happy with > > OSSRH and vote to stay with it, and all JAX-RS committers already have all > > what they need including access to the OSSRH account (if not, they can get > > it). > Partially it's because you were releasing JAX-RS not the recommended way. If > you use Eclipse build infra to make releases (which is the recommended way) > you would possibly change your opinion. :) Don't know what you're talking about. Actually we *did* use the Eclipse build infra to make releases, and we used it in the way it *was* (and still is) recommended by the EF admins. But yes, we did not do it the way some Oracle employees, the PMC, or the GF team recommended / used it. ;-) > > OSSRH is the world's de-facto way to push open source to Maven Central > > and the EF should not start our own way just because some GlassFish people > > want that. > This is the way we used in Oracle and I must say that it's much better. My > reasons are described above. I think we should not give up this idea only > because some JAX-RS people don't want it. Did not demand that, but clearly wrote it is my personal opinion. Whether a project chooses to use OSSRH or something else is every subproject's decision - at least unless there is a majority in the PMC to either merge subprojects or override the subproject's sovereignty. ;-)
Just to set expectations -- even if we can demonstrate that there is a true need/requirement for Nexus Pro, we don't have any plans of moving forward in the foreseeable future. We currently have much work to do on improving other areas of build and streamlining the committer and contributor experience.
