Remove com.ibm.icu4j from Orbit

[merks]

I've updated the Platform to version 73.1 and added it to my target:

https://github.com/merks/simrel-maven/blob/17fcd1ac411cd73d9c733093981b265a9b8fe49d/merged-target/updated.target#L240-L245

It's available from here:

• com.ibm.icu
  • icu4j 73.1

And I've done builds to make it available

• https://download.eclipse.org/oomph/simrel-orbit/nightly/latest
• https://download.eclipse.org/oomph/simrel-maven/nightly/latest

This would seem like a good first opportunity to remove something from Orbit...

[ruspl-afed]

And I've done builds to make it available

Perhaps I missed this very important part: what is the process of making maven artifact available?

[merks]

Technically there does not need to be a process to make such a thing available because it's available here:

https://repo1.maven.org/maven2/com/ibm/icu/icu4j/73.1/

And you can use this to fetch it directly yourself:

<target name="MyTarget" sequenceNumber="1">
  <locations>
	  <location includeDependencyDepth="none" includeDependencyScopes="compile" includeSource="true" missingManifest="error" type="Maven">
        <dependency>
          <groupId>com.ibm.icu</groupId>
          <artifactId>icu4j</artifactId>
          <version>73.1</version>
          <type>jar</type>
        </dependency>
    </location>
  </locations>
</target>

The builds Oomph provides are merely a convenience.

Are you asking the process for producing these builds? What specifically do you need to know or understand?

I have described some of it here:

merks/simrel-maven#3
https://github.com/merks/simrel-maven/

Basically I have a workspace with this in it:

https://git.eclipse.org/c/oomph/org.eclipse.oomph.incubator.git/

(There's a project setup for it if you are really interested.)

I run the "maven" generator to update the Maven.target and generate reports. I commit those. I run this build:

https://ci.eclipse.org/oomph/job/simrel/job/simrel-maven/

and then I run this build

https://ci.eclipse.org/oomph/job/simrel/job/simrel-orbit/

When Orbit produces a stable build for M* or RC*, I run those two builds to produce milestone builds, and eventually run each to produce release builds.

Then I often help the projects update their dependencies to the latest, as the generator reports and does automatically for the merged maven target.

[ruspl-afed]

I'm updating Eclipse Mylyn to use new version of Apache Lucene. After learning that "Everyone use the latest version." I'm going to get the 9.5.0 from Maven Central directly

				<dependency>
					<groupId>org.apache.lucene</groupId>
					<artifactId>lucene-analysis-common</artifactId>
					<version>9.5.0</version>
					<type>jar</type>
				</dependency>
				<dependency>
					<groupId>org.apache.lucene</groupId>
					<artifactId>lucene-core</artifactId>
					<version>9.5.0</version>
					<type>jar</type>
				</dependency>
				<dependency>
					<groupId>org.apache.lucene</groupId>
					<artifactId>lucene-queryparser</artifactId>
					<version>9.5.0</version>
					<type>jar</type>
				</dependency>

In the good old days, I would first add these libraries to Orbit, and then pull them from there to Mylyn and possibly to other projects. What is the recommended course of action for today?

[merks]

I don’t think those are in the form of an OSGi bundle are they? I think those need a bnd recipe like discussed here:

#8

I think we will make a super big mess if various projects apply their own recipe variants with zero coordination. Hence the issue above. The grab-it-yourself approach only works okay for Maven libraries that come as ready-to-use bundles.

[merks]

The platform uses these from orbit

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/9ee8fe3c633e2d0488a8c749c76fe1a1d43d6bbd/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target#L32

I’m sure they’d have replaced that if it were feasible.

[ruspl-afed]

Thank you for the answers, Ed. But it looks like I failed to explain my misunderstanding again.

I don’t think those are in the form of an OSGi bundle are they?

They are good enough to be recognized on compile-time/run-time and they have good chances to pass IP review. I'm not aware of other requirements.

The platform uses these from orbit

I know what Platform is using today. But how should it influence other projects that depends on Platform and expected to work smoothly together with Platform? - this is something that I completely lack to understand since Orbit fell into disgrace.

With the modern approach "Everyone use the latest version." every project will take its own version, because "the latest version" could depend on the moment of update and available resources. This potentially can create hardly resolvable dependency collisions for the late stages of the development cycle, such as EPP.

At the same time we now have available 3rd party bundles. And the idea why some projects does contribute its libraries to be available and others are not is also not clear. We have coordination regarding BREE on SimRel level, but the need to coordinate third-party libraries will overtake us soon as well.

Back to the initial subject. A bundle was added to available state and suggested to be removed from Orbit. Good. Should we do the same with the rest of Orbit bundles?

[akurtakov]

It's never a yes/no answer IMHO. If upstream has a good and maintained OSGi metadata removing it from Orbit is best IMHO but there are cases like Ant/Lucene where we would need to keep Orbit for some more time so each case should be considered on its own. But overall Orbit can be reduced significantly already and I'm really grateful to everyone that tries to do so!

[merks]

@ruspl-afed

Looking at a manifest of just one I see this, which does not look to me like it will work as an OSGi bundle at runtime:

Manifest-Version: 1.0
Extension-Name: org.apache.lucene
Implementation-Vendor: The Apache Software Foundation
Implementation-Title: org.apache.lucene
Implementation-Version: 9.5.0 13803aa6ea7fee91f798cfeded4296182ac43a21 -
  2023-01-25 16:44:59
Specification-Vendor: The Apache Software Foundation
Specification-Version: 9.5.0
Specification-Title: Lucene Search Engine: common
X-Compile-Source-JDK: 11
X-Compile-Target-JDK: 11
X-Build-JDK: 11.0.3 (Oracle Corporation 11.0.3+12-LTS)
X-Build-OS: Linux amd64 6.1.5-100.fc36.x86_64

So I'm not the basis of your assertion about these being good enough...

For those Maven artifacts that are well-formed OSGi bundles we do expect to gradually phase those out. Specifically as each new Maven version becomes available, we expect to use/provide only the direct-from-Maven version and not to create an additional Orbit version (perhaps with a different symbolic name and likely a version with a qualifier) which can only help lead to more duplicates rather than eliminate that. We do expect projects will use the latest such version of any dependency as that version becomes available. And I will compose those things into a convenience repository as described.

I'm not sure what else/more/less is possible here or if you have an alternative proposal that you can convince everyone else to follow. I am simply trying to make the best of a challenging situation...

[jonahgraham]

Lets do this removal for 2023-09 M1.