Delete obsolete p2-repository folder and prepare for 12.0.0.M21

[nikhilnanivadekar]

No description provided.

[nikhilnanivadekar]

@fipro78 can you please review this PR? If this looks ok, I will merge it and run a milestone build. Then update Jenkins such that p2 deploys work from the tag. If everything looks ok, then I can cut 12.0.0 release on Thursday.

[nikhilnanivadekar]

Updated release steps here:

1. https://github.com/eclipse-collections/eclipse-collections/wiki/Release-instructions-(for-committers)#update-p2-versions
2. https://github.com/eclipse-collections/eclipse-collections/wiki/Release-instructions-(for-committers)#start-a-new-release-version-development-aka-snapshot-version

[fipro78]

Looks good to me

[nikhilnanivadekar]

@fipro78 we have an issue and not so much an issue.

Issue

The p2 publish does not work with the release tag. Here are the differences
Error as follows:

04:16:30:818 [ERROR] Cannot resolve dependencies of project org.eclipse.collections:org.eclipse.collections.feature:eclipse-feature:12.0.0-SNAPSHOT
04:16:30:818 [ERROR]  with context {osgi.os=*, osgi.ws=*, org.eclipse.update.install.features=true, osgi.arch=*, org.eclipse.update.install.sources=true}
04:16:30:818 [ERROR]   Software being installed: org.eclipse.collections.feature.feature.group 12.0.0.qualifier
04:16:30:818 [ERROR]   Missing requirement: org.eclipse.collections.feature.feature.group 12.0.0.qualifier requires 'org.eclipse.equinox.p2.iu; org.eclipse.collections.api 0.0.0' but it could not be found: See log for details

Here are the full Jenkins logs:
p2_build_failure.txt

Fix

The p2 publish works directly from the master.

Here are the Jenkins logs:
p2_build_success.txt

Next Steps

Can you please test out if the latest milestone which was published works fine with the eclipse stuff and p2 stuff?

Let us fix these build nuances after I push out the 12.0.0 release (JDK-11) and the 13.0.0 release (JDK-17) this week. I want to push both the releases out before the Sonatype deprecation next week. I will take care of the sequence of changes to ensure p2 works fine and also create a milestone for 13.0.0.

[fipro78]

@nikhilnanivadekar
I suppose it is a time issue. The version from release needs some time to become available via Maven. At least I would expect that. So the p2 build from release tag should work once the version with the release tag is consumable via maven.

I am not able to give you feedback today. I will update you once I am able to access my laptop, probably tomorrow.

[nikhilnanivadekar]

@fipro78

Sounds good, no rush on the verification. Thanks a lot for your help! I am going to start the prep work assuming everything is right. We can always rollback 😄

Re: timing issue: I don’t think it’s a timing issue because I verified that the binaries were pushed to maven central before doing the p2 build. Moreover, the build from master works fine. So, it might be something else, may be the tycho plugin based on the log message. I think we can work around this problem for now.

[fipro78]

@nikhilnanivadekar

I tested with my consumer project and it works as expected. I also tried to consume it via p2 update site, which also works.

Regarding the issue in the release branch, I am actually really confused. There is the following message in the logs of the failing build:

Maven Artifact org.eclipse.collections:eclipse-collections-api:12.0.0.M21 @ /home/jenkins/agent/workspace/publish-p2-repo/.repository/org/eclipse/collections/eclipse-collections-api/12.0.0.M21/eclipse-collections-api-12.0.0.M21.jar is not a bundle and will be ignored, automatic wrapping of such artifacts can be enabled with <pomDependencies>wrapAsBundle</pomDependencies> in target platform configuration.

But the artifact is a bundle. Otherwise the build from master would not work.

The only thing I can still see in the success log is the following:

04:19:37:895 [WARNING] The following referenced plugins have missing sources
	org.eclipse.collections.api_12.0.0.M21
	org.eclipse.collections.impl_12.0.0.M21

But the sources are in Maven. Also happens with the latest 12.0.0 artefacts in Maven.

@laeubi
Does the tycho-source-plugin work with only pom dependencies? Somehow it does not resolve the sources. Even if I add them with the classifier as dependencies. Do the sources need to be bundles as well?

If I create a target-platform that consumes the artefacts from Maven, the sources are resolved and added. But I also noticed that the filenames of the bundles are always changed to match the bundle symbolic name. Why does that happen? The published artefacts are valid osgi bundles, why does Tycho in any configuration rename those artefacts. Not sure if this is a valid process.

@merks
Do you know how the creation of a p2 repository out of the Maven published artefacts can be done without filename modifications? Or is it ok to change the filenames. Not sure if what I have done is the correct way now.

[laeubi]

The only thing I can still see in the success log is the following

This is likely from the source feature plugin, you should at best avoid that see:

• Remove SourceFeatureMojo eclipse-tycho/tycho#5137

But if you reference it in the pom.xml you won't get full features anyways, so referencing it in target file is usually the best solution but I'm a bit confused who is using what and when and how, should it not be part of the same reactor anyways?

Do you want to build eclipse-collections as a plain maven and only add OSGi metadata?

[fipro78]

No eclipse collections is already built and published on maven central. They want to additionally provide a p2 update site.

In the past it was necessary to re-bundle eclipse collections because of the service loader stuff. With eclipse collections 12 the issue is resolved and the rebundling is not necessary anymore. So I thought of simply providing the artifacts as p2 feature.

[merks]

I’m away from the computer right now. Will look at the details when I’m back.

We could just add it to orbit…

[fipro78]

@nikhilnanivadekar
I suggest to wait with the p2 repo creation until @merks steps up I the discussion. Maybe there is a way to remove the p2 burden from your side.

[laeubi]

@fipro78 I have looked into it now and I think the main source of confusion is that the jars are only made bundles during deployment, otherwise they are plain jars. This is because the required metadata is only added to the jar in the release-artifacts profile.

Also the bnd-maven plugin is only activated with a profile, I have no clue why the build needs all this complications but it makes it rather hard to work on this.

Anyways I have now created the following suggestion to make this less painful and all automatic:

• Build a maven-p2 site from the reactor content #1771

[nikhilnanivadekar]

It would be amazing if it goes to Orbit and I needn’t do anything for p2 on my side! I have pushed the 12.0.0 version to maven central. If we can close out p2 today, then I can also release 13.0.0 with minimum JDK-17 today.

[merks]

Alternatively, I can add these three dependencies to Orbit:

The updater will update the version automatically as they are published to Maven Central.

If there is a 13.0.0 planned I'd rather include that instead of 12.0.0, i.e., I'd rather not include both, although that's also possible if there is a compelling need...

[nikhilnanivadekar]

@merks If possible we should do both 12 and 13. 12 will be the release with JDK11 compatibility and JDK13 onwards we will move to JDK17. So it’ll be helpful for projects on JDK11

[merks]

For many of the jarkata bundles and also for lucene we do include multiple major version numbers so we can do that for eclipse-collections too. This commit adds the 3 bundles:

eclipse-orbit/orbit-simrel@a66411a

Please let me know when 13.0.0 comes out.

Looking at https://download.eclipse.org/tools/orbit/simrel/maven-osgi/table.html the bundle symbolic names are bit inconsistent:

You did want all three of these added, right?

The results will be available here as well in about 10 minutes:

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/table.html

[nikhilnanivadekar]

Thanks @merks ! These are perfect! Does this mean that I dont need to publish the p2 repo anymore? And things just work automatically once I do a v13?

The inconsistent symbolic names is a bug, lets not fix it for v12 or v13. We will fix it from v14 onwards.

[fipro78]

Does the forkjoin also use spi? Because I missed that one to prepare for osgi then.

[merks]

I need to add major versions manually, except for a few libraries that are constantly producing new major versions like icu4j and guava which I specify in the updater as automatically updating to new major versions which replaces the older version. But you don’t want that here. Major version increases are generally disruptive.

So let me know when 13 is available.

[nikhilnanivadekar]

@fipro78 fork join is rarely used by folks unless they really know the use and importance. That is why I am fine without fixing the targets.

@merks ack, will update once 13 is ready.

Just to double check, I need not run the p2-deploy build for 12.0.0 correct? The p2-deploy build is pushed and makes artifacts available in the update site. Jenkins build is here: https://ci.eclipse.org/collections/view/all/job/publish-p2-repo/

[merks]

Those three bundles are available at this p2 update site

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/nightly/latest

Eventually it will be in a release repository like this one

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/release/4.36.0

for the 4.37 release.

So if that’s sufficient for you and your consumers you don’t need anything else. In fact anyone can directly specify your maven artifacts in their target platform exactly as I did for orbit so no one strictly needs a p2 repository…

[nikhilnanivadekar]

Great! Thanks a ton! This simplifies the process a ton. I will make sure to update it in the release notes for visibility. Starting on the work for 13.0.0 release now.

[nikhilnanivadekar]

@fipro78 I have published the 13.0.0.M1 to maven central.

Maven central link: https://central.sonatype.com/artifact/org.eclipse.collections/p2-site

Per the instructions from @laeubi the usage is mvn:org.eclipse.collections:p2-site:<version> in the target-files.

Would you mind testing the milestone to see if it works as expected for p2/OSGi and other Eclipse dependencies? Please note that the minimum JDK version will be Java-17 for 13.0.0 release.

I am waiting for few of my tests to pass with the milestone version.
Once @donraab and you test in your repos and give the go ahead, I will publish the 13.0.0 final version to maven central. Thanks a million for your help!

[fipro78]

I will try. But what should be that p2-site artefact in maven central? That doesn't make sense to me.

I mean, if I followed the discussion correctly @merks suggested to include the EC artefacts to orbit. So all the p2 related work that I did and @laeubi suggested should be obsolete then. You only need to consider the publishing the EC artefacts with proper osgi metadata to maven.

[laeubi]

I will try. But what should be that p2-site artefact in maven central? That doesn't make sense to me.

And for me it doesn't make sense to mirror content already available elsewhere ;-)

Tycho/P2/PDE since a while can perfectly consumer artifacts and even sites (like here) directly from the source (usually maven central) so there is (except for some rare cases) not much need to have orbit at all.

So all the p2 related work that I did and @laeubi suggested should be obsolete then.

It is more complementary and people can choose if they want to want until orbit update, a new release is published and they finally can use it just for the sake of having https versus mvn in their URL in the target platform instead of getting everything whenever a release is made by the project. Given the major infra outage recently I can only see benefits in a more diverse and alternative deployments than relying on single points of failure.

So of course I can't speak for the project, but can only recommend to native maven projects to use maven deployed p2 sites (as these even share download cache with regular maven).

[merks]

Out of curiosity, what do you see as the advantage of p2 repository published to maven versus specifying maven dependencies. I imagine one advantage is to be able to install from it, if you also have m2e installed to support to protocol. I don't expect Eclipse Collections has this use case though. I imagine it's primarily consumed via a consumer project's target platform where maven dependencies seem also like a good way. I'm just curious, and I'm not pushing anyone is any particular direction.

[laeubi]

Out of curiosity, what do you see as the advantage of p2 repository published to maven versus specifying maven dependencies

The main problem with maven is that we miss the P2 metadata information (e.g. exported packages) for that reason you either have to know what you need (possible) or download everything to get known about it. Also you can easily explore things e.g. using Repository Explorer (what is not possible with plain maven unless you have an index).

Tycho is even smart enough to know what you need (like Oomph) so if you add this as a repository in maven it will only ever download what is needed. You can even use it as a referenced site to have something similar in PDE, e.g your project needs eclipse-collections you do not need to ship it, just add it as a reference and it will download automatically whats needed from central maven.

Compared to that, one only has a few extra bytes (12.3 kB) to store this information for others to consume and with the Tycho mojo is is not a big deal to generate it. Actually it just do the steps onces that are performed over and over again for a traditional maven dependency (because the P2 data must be generated on each run).

So in general its like a BOM for P2 ;-)

[nikhilnanivadekar]

I can say for all the project maintainers, we are not experts in p2. We didn’t start with p2 repo until about 2018 when some eclipse projects wanted p2 artifacts. We have had requests for having an “uber” p2 site published to maven as well as having p2 artifacts. FWIW with the new build changes, the p2-site is published to maven central without my handholding. I presume it’s something similar to publish to orbit once @merks adds the maven coordinates.

Is there any harm/extra effort to publish both and give consumers the options? I am not an expert so will rely on your advice on what’s the right thing to do.

[laeubi]

Is there any harm/extra effort to publish both and give consumers the options?

There is no harm, both are valid ways. The effort is mostly on the Orbit Team side to keep it up-to-date with new releases so nothing to actively do on your side.

[nikhilnanivadekar]

Is there a way to automate the work from orbit? I don’t want to create unnecessary additional work for the orbit team.

Secondly, what’s the best way to test that the maven site is correct? @fipro78 had a question about that above.

[laeubi]

Open Eclipse, and create a new target file (you need m2e+pde for this, this is included for example in the Eclipse for RCP/RAP developers) and create a new Software Site location.

Then add mvn:org.eclipse.collections:p2-site:13.0.0.M1:zip as the URI and you should see your bundles:

[merks]

For Orbit the updates are automatically generated by looking at what's available at maven central. Generally that updater does not do automatic updates for major version increments because those typically (and for sure when using proper semantic versioning) suggests some type of API breakage.

But even for this case, we generate a report with exactly that information about available major new versions.

https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/merged-target/REPORT.md#major-updates

So if someone asked for any of those, I would just add them. I don't generally proactively add new major versions, again, because no one has asked. And doing so would take just a couple of minutes.

[nikhilnanivadekar]

This is awesome! Thanks a ton! Does this also mean that we can remove the semver contributions as it’ll be streamlined via orbit? Or that’s a different point?

[merks]

When do you mean by a semver contribution?

[nikhilnanivadekar]

Sorry I meant sim rel contribution : https://projects.eclipse.org/releases/2025-06

[fipro78]

@laeubi
Thanks for the explanation. Actually I wasn't aware of the p2 repository published in Maven. I think I read about it, but seem to have forgotten.

I can't judge what would be best for the project. Only that the least maintenance burden for the p2 stuff would be perfect, as there is not really p2 knowledge here. Looks like the modifications from @laeubi are much better than the stuff I did and reduces the effort to publish the p2 update site a lot. But it also requires a quite current version of PDE and Tycho. That could be the only argument against it, as the update site location in Maven is not supported in older versions. Is that a reason against it, probably not. Is it a reason to additionally publish to a traditional p2 repository with Orbit, probably yes.

Anyhow, I have updated my example to use the p2 repo in Maven and 13 M1 for the plain Java and OSGi with bndtools applications, and they all work as expected.

[laeubi]

@fipro78 it depends a bit how you define "current" version of PDE/Tycho/M2E, support for this was added here eclipse-m2e/m2e-core@fabc65c in Nov 25, 2020 (and Tycho here eclipse-tycho/tycho@162c177 since Tycho 2.x) so about five years ago, I think it should be quite common ground now :-)

[merks]

Sorry I meant sim rel contribution : https://projects.eclipse.org/releases/2025-06

The SimRel participation is already kind of broken and it's problematic to simply add the Orbit update site as a replacemend. One problem is that nattable's feature which is pulled in my papyrus (for no good reason) locks in a very specific older version via a bundle include in its feature.xml:

You can see that that bundle is available via two contributed p2 repositories:

So even if we were to update the collections contribution to 12.0.0 (which sounds like API breakage) we'd end up with two versions instead of just one latest (until papyrus and/or nattable) address the issues that lead to this situation.

Also problematic is if we contribute the Orbit repo as the source, all the other content is likely to "leak" into the aggregation. That's not actually a totally bad thing at least on first glance, but Orbit's content update often and automatically, so other contributions might easily end up relying on Orbit's repository contributing their transitive dependencies, and then, if they have strict version ranges, when Orbit updates, aggregation might fail because each project is supposed to provide its third party dependencies via their own site or via a site contributed by that third party project (with which they must remain coordinated).

So the whole think looks like a bit of a mess currently and why the Planning Council specified a new rule against this problem

https://eclipse.dev/eclipse/markdown/?file=eclipse-simrel/.github/main/wiki/SimRel/Simultaneous_Release_Requirements.md#do-not-include-non-project-content-in-features

My sense is that it would be better for Eclipse Collections not to directly participate in SimRel but rather rely on a consuming project to contribute the version actually being used as is the case for other non-eclipse-project 3rd party dependencies consumed from Orbit.

Do you folks have a problem with disabling the SimRel contribution for Eclipse Collections?

The activity has been minimal:

[laeubi]

Do you folks have a problem with disabling the SimRel contribution for Eclipse Collections?

This sound reasonable and is similar to how jetty is part of the simrel. I think a SimRel contribution for a library is most likely useless and only beneficial if it contributes something to the UI somehow, adding some editor capabilities and alike. Its quite unlikely a user would ever want to "install" Eclipse Collections into their IDE and all others can consume this in their target file much better than through Simrel (in whatever fashion).

[merks]

Indeed Jetty is a good analog. I still need to find time (in July) to chase down the nattable inclusion problem, and figure out what viatra is up with its dependencies...

[fipro78]

@merks
Regarding NatTable, I am planning a new release soon. Should I simply remove the included Eclipse Collections to a requirement in the feature? Or maybe two features, one with dependencies and one without?

I remember discussions in the past about how to configure features to be best consumeable, and there were good reasons for both variants. If Eclipse Collections are part of Orbit and/or available as p2 update site in Maven, I think removing the dependencies from the feature and making them a requirement should be the right way now. What do you think?

[laeubi]

@fipro78 as long as you have an import package/ require bundle somewhere you do not need to mention any bundles in the feature, just the nat-table ones and the rest will be pulled by P2 anyways. If you want it in the update site you can either include (and filter) all dependencies or you can have an own category adding dedicated bundles.

[merks]

Yes, @laeubi's advice is sound. For ECF with the same problem I took this approach:

eclipse-ecf/ecf#191

I.e., I defined a 3rd party dependencies feature, but directly including the bundles in the category.xml is also fine and good.

If you make changes for nattable, just @ mention me and I'll have a look and give advice. 😀

[merks]

I'll repeat the question so that I'm sure folks didn't miss it:

Do you folks have a problem with me disabling the SimRel contribution for Eclipse Collections?

[nikhilnanivadekar]

I am fine removing Eclipse Collections from SimRel and simplifying the process. @merks let me know if I need to raise a PR/issue or you’ll be taking care of it.

@fipro78 and @ujhelyiz are our only two users from the SimRel. Tagging both of them here for visibility. Presumably they’ll have to test their projects after EC is removed from SimRel.

Seems like the next steps mentioned by @fipro78 here are the same ones that will be applicable to Viatra as well.

[ujhelyiz]

I am fine removing Eclipse Collections from SimRel and simplifying the process. @merks let me know if I need to raise a PR/issue or you’ll be taking care of it.

@fipro78 and @ujhelyiz are our only two users from the SimRel. Tagging both of them here for visibility. Presumably they’ll have to test their projects after EC is removed from SimRel.

Seems like the next steps mentioned by @fipro78 here are the same ones that will be applicable to Viatra as well.

Thanks for the feedback, to proposed options are fine for VIATRA. Furthermore, we are also planning to remove VIATRA from SimRel this September, so it will not cause us any issues if Eclipse Collections gets removed as well.

[merks]

No problem. I'll take care of it before M1. 👍

[fipro78]

I never was a user of SimRel. I always used the p2 site and will change that as already mentioned. ;)

[nikhilnanivadekar]

@merks Eclipse Collections 13.0.0 is released to maven central. Can you please add it to orbit? Thanks a ton!

[merks]

The builds are in progress, the one that's finished now shows both and shows the BREE:

After the 4.37 release I will remove the 12.x version. It's really not needed for SimRel, which is shipping with Java 21, and consumers can always get the 12.x version from the 4.37 permanent update site if need be. (And Java 11 is reaching end of life.)

[nikhilnanivadekar]

Perfect! Thank you very much! I will update the release notes and the Readme with this info.

Thanks a lot everybody for helping me through the nuances of p2.