Re: [orbit-dev] Orbit contribute directly to simrel

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

There is an interesting side-effect of adding orbit directly to simrel. Because I put orbit first in the list, all the dependencies are pulled from orbit if they are in orbit. This means that for the bundles that were resigned, we are publishing the resigned ones to simrel regardless of whether the project is up to date or not in their contribution.

That is a positive for me. I am slightly unsure if we should take on this change now, or wait until early in the 2020-03. I also don't know if the new tycho based simrel will have this same behaviour?

If I place Orbit at the end, then it only supplies bundles not available from any other repo. I have done that experiment locally and have been filing bugs or sending email to projects who have that kind of dependency. There are a couple of them tied to removing BIRT from simrel.

Finally, by having Orbit first, it makes it easy to see all the bundles (at least by name) that are not org.eclipse.* that are not currently resolvable from Orbit. Here is a quick report I made:

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/rt/ecf/3.14.18/site.p2
com.mycorp.examples.timeservice,1.1.200.v20200611-1508
org.apache.commons.codec,1.13.0.v20200108-0001
ch.ethz.iks.slp,1.4.0.v20201027-0408
org.apache.hadoop.zookeeper,3.3.3.v201105210832
com.mycorp.examples.timeservice.async,2.1.100.v20200611-1508
com.mycorp.examples.timeservice.consumer.ds,1.0.300.v20200611-1508
com.mycorp.examples.timeservice.consumer.filediscovery,1.2.101.v20191012-1926
com.mycorp.examples.timeservice.host,1.1.300.v20200611-1508
com.mycorp.examples.timeservice.consumer.filediscovery.rest,1.2.101.v20191012-1926
com.mycorp.examples.timeservice.consumer,1.1.200.v20200611-1508
org.jivesoftware.smack,3.3.300.v20180303-0057
com.mycorp.examples.timeservice.consumer.ds.async,1.0.200.v20200611-1508
org.apache.hadoop.zookeeper.source,3.3.3.v201105210832
ch.ethz.iks.r_osgi.remote.source,1.2.203.v20201026-0028
ch.ethz.iks.r_osgi.remote,1.2.203.v20201026-0028
ch.ethz.iks.slp.source,1.4.0.v20201027-0408

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/tools/gef/updates/milestones/5.3.2M3_gef-master_6199
com.google.guava,21.0.0.v20170206-1425

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/webtools/downloads/drops/R3.20.0/S-3.20.0.M3-20201124175450/repository
javax.persistence,2.2.1.v201807122140

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/mylyn/drops/3.25.2/v20200831-1956
org.apache.lucene.core,6.1.0.v20170814-1820
com.google.gwt.servlet,2.0.4.v20100709-0658
org.apache.lucene.queryparser,6.1.0.v20161115-1612
javax.servlet,3.0.0.v201112011016
org.apache.commons.codec,1.9.0.v20170208-1614
org.apache.lucene.analyzers-common,6.1.0.v20161115-1612

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/birt/update-site/oxygen-interim <-- this report is from before BIRT being removed, that build is still running
org.apache.batik.parser,1.7.0.v201011041433
org.apache.batik.dom,1.7.1.v201505191845
org.apache.batik.dom.svg,1.7.0.v201011041433
org.apache.batik.svggen,1.7.0.v201011041433
org.apache.batik.util,1.7.0.v201011041433
org.apache.batik.ext.awt,1.7.0.v201011041433
org.apache.batik.transcoder,1.7.0.v201011041433
org.apache.batik.util.gui,1.7.0.v200903091627
org.apache.batik.util,1.8.0.v20170214-1941
org.apache.batik.xml,1.7.0.v201011041433
org.apache.batik.util.gui,1.8.0.v20170214-1941
org.apache.batik.bridge,1.7.0.v201011041433
org.apache.batik.css,1.7.0.v201011041433
org.apache.batik.css,1.8.0.v20170214-1941

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/modeling/gmp/gmf-runtime/updates/releases/R202004160913
org.apache.batik.bridge,1.6.0.v201011041432
org.apache.batik.util.gui,1.6.0.v201011041432
org.apache.batik.dom,1.6.1.v201505192100
org.apache.batik.util,1.6.0.v201011041432
org.apache.batik.ext.awt.source,1.6.0.v201011041432
org.apache.batik.pdf,1.6.0.v201105071520
org.apache.batik.css.source,1.6.0.v201011041432
org.apache.batik.dom.source,1.6.1.v201505192100
org.apache.batik.xml.source,1.6.0.v201011041432
org.apache.batik.util.gui.source,1.6.0.v201011041432
org.apache.batik.parser.source,1.6.0.v201011041432
org.apache.batik.transcoder.source,1.6.0.v201011041432
org.apache.batik.bridge.source,1.6.0.v201011041432
org.apache.batik.svggen.source,1.6.0.v201011041432
org.apache.batik.parser,1.6.0.v201011041432
org.apache.batik.dom.svg,1.6.0.v201011041432
org.apache.batik.ext.awt,1.6.0.v201011041432
org.apache.batik.transcoder,1.6.0.v201011041432
org.apache.batik.css,1.6.0.v201011041432
org.apache.batik.dom.svg.source,1.6.0.v201011041432
org.apache.batik.svggen,1.6.0.v201011041432
org.apache.batik.xml,1.6.0.v201011041432
org.apache.batik.util.source,1.6.0.v201011041432

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/m2e-wtp/milestones/1.4/1.4.4.20200220-1005
org.sonatype.m2e.mavenarchiver.feature,0.17.5.202002191804
org.sonatype.m2e.mavenarchiver,0.17.5.202002191804

Non org.eclipse bundles that aren't in current orbit from:  download.eclipse.org/buildship/updates/e415/releases/3.x/3.1.4.v20200326-1743
org.gradle.toolingapi,6.3.0.v20200326-1743

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

On Wed, 25 Nov 2020 at 11:36, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

On Wed, 25 Nov 2020 at 11:30, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:

I like the idea. Only question is how would it enforce that only the latest bundle from Orbit is used?

Two parts to this.

1. For bundles with functional change we currently change the qualifier, so that case is easy as the dependency needs to specify that qualifier to as I did in https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/172825/1/orbit.aggrcon

2. For bundles with just signature changes we need to adopt compare and replace so that we keep reusing the previously signed bundle, so that orbit does not publish new versions of bundles with only signature changes. And when we do need to do things like resign all the bundles, then do a forced qualifier update.

So, the first part is doable now. The second part requires more work which won't happen in 2020-12 timeframe, but once https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936 is done this should be achievable.

However, we could do part 2 for all the current git bundles for 2020-12 RC2. Not sure it is necessary though as the more problematic bundles are the older CVS defined one.