target platform strategy

[BeckerFrank]

We actual have the targets in two places.

• org.eclipse.mylyn.commons/org.eclipse.mylyn.commons-target
• org.eclipse.mylyn/org.eclipse.mylyn-target (updated 4 days ago)
  I add the targets for 4.23 - 4.25

So maybe we should look that we can

• keep the target in both parts same (actual on use versions and the other 0.0.0)
• reuse one target in the other

What is the way we want to go?

[ruspl-afed]

@BeckerFrank what is the use case of supporting numerous targets? Perhaps, an ability to be installed for older Eclipse Platform without conflicts. Personally, I think this is nice to have. But, it may be much harder than switching a .target file or even hardly possible. Examples:

1. Java 8 -> Java 11 switch for Eclipse Platform
2. javax -> jakarta switch
3. numerous changes in 3rd party (logging was the most painful)
4. potential Java 11 -> Java 17 switch for Eclipse Platform

Let's range our priorities

• work with latest Eclipse Platform
• re-join SimRel
• work with latest Java
• support older releases
• more goals here
  WDYT @BeckerFrank @wimjongman ?

[BeckerFrank]

@BeckerFrank what is the use case of supporting numerous targets? Perhaps, an ability to be installed for older Eclipse Platform without conflicts. Personally, I think this is nice to have. But, it may be much harder than switching a .target file or even hardly possible. Examples:

Yes this can be maybe impossible.
But Mylyn is by example used in OOMPH Mylyn.ecore Model (hard coded with value https://download.eclipse.org/mylyn/releases/latest).
So if you want for some reason install an old Eclipse version the setup can fail.

This is why Mylyn tried to be compatible with very old versions.
I think, that we maybe drop some older Eclipse Version and if possible require Java 11 and only support Eclipse 2020-09 and newer.

1. Java 8 -> Java 11 switch for Eclipse Platform
2. javax -> jakarta switch
3. numerous changes in 3rd party (logging was the most painful)
4. potential Java 11 -> Java 17 switch for Eclipse Platform

Let's range our priorities

• work with latest Eclipse Platform
• re-join SimRel
• work with latest Java
• support older releases
• more goals here
  WDYT @BeckerFrank @wimjongman ?

Yes!
We can contact the OOMPH Project if we found some issues with installing not the latest Eclipse version.

BTW: The Eclipse-Installer points to the new Mylyn.setup (GitHub URL) and can be used for an easy setup of an new Eclipse Instance.

[ruspl-afed]

This is why Mylyn tried to be compatible with very old versions.

Good to know. We also still support Java 8 in Eclipse Passage (engine only) and I understand the challenge. I think if we can enumerate these "kernel" bundles that we want to be extra-compartible - the task will become realisitc. Please help to collect this info.
And then we need to ensure that we test all changes for the set of older platforms.

BTW: The Eclipse-Installer points to the new Mylyn.setup (GitHub URL) and can be used for an easy setup of an new Eclipse Instance

Thanks! I'm a fan of Oomph too. No idea how I managed to overlook the Mylyn.setup

[wimjongman]

<copy/paste>

I agree with Alexander that the repos should be self-sufficient. However, it is also the case that some repos have to be built before others.

common itself is in use by other downstream repositories. This requires a cascading build setup: When commons is built, it must trigger its downstream builds.

We can also look at commons (and other upstream repos) as just another third-party dependency. It means that downstream repositories are built with whatever common is currently in the snapshot/nightly repo. When a release is planned, we can make one build that cascades all builds into proper order and then release that result.

Is there a graph that shows the mylyn internal dependency tree?

[BeckerFrank]

(In reply to comment #4)

<copy/paste>

Is there a graph that shows the mylyn internal dependency tree?

No there is no dependency tree.
But I know that we have a dependency in org.eclipse.mylyn.commons to org.eclipse.mylyn.context (project org.eclipse.mylyn.monitor. ui) and this is the reason why we have extra *.target files in commons with repository https://download.eclipse.org/mylyn/snapshots

The following classes need some parts from org.eclipse.mylyn.context

• ActivityContextManager
• AbstractUserInteractionMonitor

Here the other dependiencies I know

org.eclipse.myln.commons is used by

• org.eclipse.myln.tasks
• org.eclipse.myln.versions

org.eclipse.myln.tasks is used by

• org.eclipse.myln.context
• org.eclipse.myln.reviews

org.eclipse.myln.versions is used by

• org.eclipse.myln.context

[BeckerFrank]

(In reply to comment #4)

<copy/paste>
Is there a graph that shows the mylyn internal dependency tree?

No there is no dependency tree. But I know that we have a dependency in org.eclipse.mylyn.commons to org.eclipse.mylyn.context (project org.eclipse.mylyn.monitor. ui) and this is the reason why we have extra *.target files in commons with repository https://download.eclipse.org/mylyn/snapshots

The following classes need some parts from org.eclipse.mylyn.context

• ActivityContextManager
• AbstractUserInteractionMonitor

Here the other dependiencies I know

org.eclipse.myln.commons is used by

• org.eclipse.myln.tasks
• org.eclipse.myln.versions

org.eclipse.myln.tasks is used by

• org.eclipse.myln.context
• org.eclipse.myln.reviews

org.eclipse.myln.versions is used by

• org.eclipse.myln.context

One more detail.
org.eclipse.mylyn must run twice.

• build the target Platform
• trigger the run of all unit tests

[ruspl-afed]

trigger the run of all unit tests

I'm not sure that I understand this approach @BeckerFrank . If we run unit tests per-repository, what is the value to run the same tests again?

[ruspl-afed]

I've created #19 to let aggregator resolve test bundles from "common".
Also, I removed two excessive .target definitions introduced by @ruspl-afed and @wimjongman:

• org.eclipse.mylyn.commons-target/mylyn-commons-e4.latest.target
• org.eclipse.mylyn.commons-target/org.eclipse.mylyn.commons-target.target

[BeckerFrank]

trigger the run of all unit tests

I'm not sure that I understand this approach @BeckerFrank . If we run unit tests per-repository, what is the value to run the same tests again?

For historical reasons we have one place org.eclipse.mylyn.tests where we have all the Entry Test defined.
We can look if the eclipse project include some additional logic that we can move to another place.

[ruspl-afed]

@wimjongman @BeckerFrank we still have no answer what is the lowest Eclipse version we would like to support.
We need this information to choose better way of resolving circular dependencies.

[BeckerFrank]

@wimjongman @BeckerFrank we still have no answer what is the lowest Eclipse version we would like to support.
We need this information to choose better way of resolving circular dependencies.

I think we have the following options

1. Eclipse 2022-09 (first java 17 version)
   This is maybe the easiest to implement.
2. Eclipse 3.8 / 4.2 (actual supported)
   This get more complicated over the past years.
3. Eclipse 2022-06 (first version mylyn task list not in simrel)
   This is also the last version with java 11
4. one version between 2021-03 and 2022-03
   With one version from this range we allow OOMPH to work in most of the cases assuming that older version are not really used that often.

For all options we should keep in mind that the OOMPH Query Setup Task fetch the version from https://download.eclipse.org/mylyn/releases/latest and this can break all *.setups with "Mylyn Build" and "Mylyn Query" task for Eclipse Versions before the supported Version.

I prefer that we try 4. because "IBM Developer for z/OS" latest version (16.0.0) is based on 2022-03 and my employer use this product and we also have Mylyn.

Thougths?

[ruspl-afed]

From my side it looks like the following:

• Priority 1: support the latest SimRel (2022-12 at the moment) this is the very minimum to re-join SimRel
• Priority 2: support earlier version for subset of bundles/features to let Oomph proceed, we need help from Ed @merks to identify the details.
• Priority 3: support particular version(s) of Eclipse Platform that is needed for commercial offerings. Well, such an extra effort should be funded by interested party.

[merks]

I suspect there are very few features introduced in the last few years of Eclipse that are actually needed by Mylyn so the most likely the concern would be to remove dependencies on things that have been deprecated and subsequently removed.

These are the things used by Oomph: