Cannot update to SADL 3.4.0

[Ptival]

I'm getting the following error:

Your original request has been modified.
  "SADL Feature" is already installed, so an update will be performed instead.
Cannot complete the install because one or more required items could not be found.
  Software being installed: SADL Feature 3.4.0.202008131540 (com.ge.research.sadl.feature.feature.group 3.4.0.202008131540)
  Missing requirement: com.ge.research.sadl 3.4.0.202008131540 (com.ge.research.sadl 3.4.0.202008131540) requires 'osgi.bundle; org.eclipse.xtext [2.21.0,2.22.0)' but it could not be found
  Cannot satisfy dependency:
    From: SADL Feature 3.4.0.202008131540 (com.ge.research.sadl.feature.feature.group 3.4.0.202008131540)
    To: org.eclipse.equinox.p2.iu; com.ge.research.sadl [3.4.0.202008131540,3.4.0.202008131540]

Is this a new dependency? Do I need Equinox framework?

[tuxji]

Valentin, this is happening because you're trying to install SADL 3.4.0 in an Eclipse that's too old or too new. According to https://github.com/crapo/sadlos2/wiki/Installation-Instructions-for-SADL-IDE,-Version-3.4, you should install SADL 3.4.0 in Eclipse IDE for Java and DSL Developers 2020-03. I don't think older or newer Eclipse versions will work because of how tight SADL's acceptable Xtext range is (only 2.21 will fit the range, not 2.20 or 2.22). SADL probably should be leaving one end of the range open (2.21 or any later version) since almost every new Eclipse release has a higher Xtext version than the previous release.

[Ptival]

Indeed I am on Eclipse 2019-12. Thanks for the information, sorry for the noise!

I'll let one of you close or repurpose as a xtext range issue.

[Ptival]

Can also confirm that with Eclipse 2020-06 and I get the following error:

Cannot complete the install because one or more required items could not be found.
  Software being installed: SADL Feature 3.4.0.202008131540 (com.ge.research.sadl.feature.feature.group 3.4.0.202008131540)
  Missing requirement: com.ge.research.sadl 3.4.0.202008131540 (com.ge.research.sadl 3.4.0.202008131540) requires 'osgi.bundle; org.eclipse.xtext [2.21.0,2.22.0)' but it could not be found
  Cannot satisfy dependency:
    From: SADL Feature 3.4.0.202008131540 (com.ge.research.sadl.feature.feature.group 3.4.0.202008131540)
    To: org.eclipse.equinox.p2.iu; com.ge.research.sadl [3.4.0.202008131540,3.4.0.202008131540]

So indeed SADL 3.4.0 is only compatible with Eclipse 2020-03.

[crapo]

@kittaakos , can you comment on whether the range could be safely opened up?

[kittaakos]

It is safe to remove the Xtext restrictions once this incompatibility issue is fixed.

[crapo]

Ah, I had forgotten where the upper bound limit came from. So fixing "this incompatibility issue" means upgrading to xtext 2.22? And how big of an effort is this @kittaakos ?

[kittaakos]

And how big of an effort is this

Last time, Feb 17, it took three hours to bump up the Xtext version.

[crapo]

@kittaakos , would you be able to fix this in the near future, and is there enough left on the DARPA ARCOS PO? Is this something that will need to be done each time there's a new release of Eclipse with a different Xtext version that people start working with or it is unique to Xtext 2.21 vs Xtext 2.22

[kittaakos]

would you be able to fix this in the near future,

Sure. I can deliver it by next Monday.

and is there enough left on the DARPA ARCOS PO?

I have never received such a PO, but we still have two other ones with sufficient workhours available (2,5 and 16 hours) so it's not a problem.

it is unique to Xtext 2.21 vs Xtext 2.22

I think it was unique. They replaced all the Xtend code with Java.

[kittaakos]

@crapo which Eclipse installations and versions do we target? DSL and Java, 2020-03 and 2020-06?

[kittaakos]

@crapo, do you want me to increase the SADL version numbers?

[crapo]

Targets 2020-03 and 2020-06 sounds right. Version should be 3.4.1. I have been working on a scoping issue for which I will make a PR and ask you to review.

[kittaakos]

it is unique to Xtext 2.21 vs Xtext 2.22

I think it was unique. They replaced all the Xtend code with Java.

@crapo, I started the update yesterday and noticed that the IColoringService service was removed from Xtext 2.22. (Maybe other services are also affected.) It's a non-trivial breaking change but doable. This means I have to reimplement the coloring for WebSadl and add a new theme for the Theia-based application. The overall work could take a few more additional hours. I believe it's time to move to more recent APIs in both Xtext and Theia but wanted to ask if you are OK with this before I start the actual migration. Thank you!

[crapo]

@kittaakos , thanks for informing me. With that magnitude of change I don't think we want to do that for the next point release, which we can just restrict to Eclipse 2020-03. I think the Java version dependency is fixed by @tuxji . I'll need to get approval from the project for the larger changes and will let you know when we can proceed with the more major changes.

[crapo]

@kittaakos , a question that the funding project has for doing this work is one around compatibility. We didn't anticipate that we would need such an upgrade in the API to get to Xtext 2.22 so their question is what is the Xtext commitment to backwards compatibility, i.e., are we going to have to do this again in the foreseeable future? Maybe this is a question for @svenefftinge ?

[kittaakos]

We didn't anticipate that we would need such an upgrade in the API to get to Xtext 2.22

I did not expect such a breaking change either, but semantic coloring is tricky; it's not an LSP standard.

are we going to have to do this again in the foreseeable future

I would expect that bumping up the Xtext versions will most likely not cause such an issue in the future, but I would expect at least one more breaking API change for the coloring in the future.

The very first IColoringService service, which has been removed from Xtext, was introduced way before we opened a request to support semantic highlighting via the LSP just to be able to support coloring for SADL in the browser.

Then we opened the protocol extension request, got some feedback from Microsoft, and reimplemented the IColoringService; it's called SemanticHighlightingRegistry. I am positive that the API of the SemanticHighlightingRegistry will also change in the future.

[crapo]

@kittaakos , finally got approval to resolve this issue. Please let me know in advance if it looks like the money on the open PO is not going to be enough. When will you be able to do this?