Say goodbye to Xpand

[cdietrich]

Now that Xpect is finally Xpand free, we will start the removal of the Xpand dependency in Xtext

• Postprocessor
• Old generator
• targets

see also

• remove xtext.generator and xpand based IXtext2EcorePostProcessor api #2788
• Find solution for orbit icu4j removal  #2729
• Problems with Xpand in TP and Oomph #2676
• Xpand and EPL 2.0 #1669

[cdietrich]

@ewillink

looks like ocl still depends on the old org.eclipse.xtext.generator

16:14:23  Build failed! Exception was org.eclipse.core.runtime.CoreException: Cannot complete the install because one or more required items could not be found. Software being installed: validationSet_main 1.0.0 Missing requirement: org.eclipse.ocl.examples.xtext.build 1.18.0.v20221201-0557 requires 'osgi.bundle; org.eclipse.xtext.generator [2.9.0,3.0.0)' but it could not be found Cannot satisfy dependency: mappedRepo_download.eclipse.org_modeling_mdt_ocl_updates_releases_6.18.0 1.0.0 depends on: org.eclipse.equinox.p2.iu; org.eclipse.ocl.build.feature.group [6.18.0,6.19.0) Cannot satisfy dependency: org.eclipse.ocl.build.feature.group 6.18.0.v20221201-0557 depends on: org.eclipse.equinox.p2.iu; org.eclipse.ocl.examples.xtext.build [1.18.0.v20221201-0557,1.18.0.v20221201-0557] Cannot satisfy dependency: validationSet_main 1.0.0 depends on: org.eclipse.equinox.p2.iu; mappedRepo_download.eclipse.org_modeling_mdt_ocl_updates_releases_6.18.0 [1.0.0,1.0.0]
16:14:23  Cannot complete the install because one or more required items could not be found. Software being installed: validationSet_main 1.0.0 Missing requirement: org.eclipse.ocl.examples.xtext.build 1.18.0.v20221201-0557 requires 'osgi.bundle; org.eclipse.xtext.generator [2.9.0,3.0.0)' but it could not be found Cannot satisfy dependency: mappedRepo_download.eclipse.org_modeling_mdt_ocl_updates_releases_6.18.0 1.0.0 depends on: org.eclipse.equinox.p2.iu; org.eclipse.ocl.build.feature.group [6.18.0,6.19.0) Cannot satisfy dependency: org.eclipse.ocl.build.feature.group 6.18.0.v20221201-0557 depends on: org.eclipse.equinox.p2.iu; org.eclipse.ocl.examples.xtext.build [1.18.0.v20221201-0557,1.18.0.v20221201-0557] Cannot satisfy dependency: validationSet_main 1.0.0 depends on: org.eclipse.equinox.p2.iu; mappedRepo_download.eclipse.org_modeling_mdt_ocl_updates_releases_6.18.0 [1.0.0,1.0.0]
16:14:23  [0]Missing requirement: OCL build support for the Xtext Declarative Serializer 1.18.0.v20221201-0557 (org.eclipse.ocl.examples.xtext.build 1.18.0.v20221201-0557) requires 'osgi.bundle; org.eclipse.xtext.generator [2.9.0,3.0.0)' but it could not be found
16:14:23  
16:14:23  Bundle(org.eclipse.xtext.generator [2.9.0,3.0.0)) is required by:
16:14:23    ValidationSet(main)
16:14:23      Contribution(OCL for 2023-09)
16:14:23        MappedRepository(https://download.eclipse.org/modeling/mdt/ocl/updates/releases/6.18.0)
16:14:23          Feature(org.eclipse.ocl.build.feature.group [6.18.0,6.19.0))
16:14:23            InstallableUnit(org.eclipse.ocl.examples.xtext.build 1.18.0.v20221201-0557)

[ewillink]

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=563046

I sort of got the migration going but found the 'new' formatter absolutely dreadful particularly once de-Xtend-ed.

This prompted me to develop the Declarative Formatter. Ouch! a year later it sort of worked but assumed a lossless mapping between node model and EMF model, which sadly Xtext in particular does not satisfy. So after pretty much wasting a year, I moved on to the next distressingly time consuming problem.

[cdietrich]

you still can use the old formatter.
you can (for now) even stay with the old generator. but you should not ship it as runtime dependency

[cdietrich]

i dont even know how to clone from old git.eclipse.org anymore :( so i cannot see what you are actually doing

[ewillink]

The problem dependency is from the Releng aspect of OCL which most users should not install. This could be dropped from SimRel and users redirected to the project install, provided a similar redirect to the Xtext project install finds the old generator.

But in the same way that EMF ships its JET support, I feel OCL should ship its Xtext support.

[cdietrich]

i have doubts old generator would work with new xtext.

[cdietrich]

disabling indeed seems to work

[ewillink]

I'm just about to do OCL 2023-12 M1, but see no disable in ocl.aggrcon. Are you waiting for me, or waiting for M2 or ...

I'll try to phase out the old generator (again) for M2.

[cdietrich]

@ewillink I have disabled it here eclipse-simrel/simrel.build@c7ddc34 (simrel is on GitHub now)

[ewillink]

oops. I'm still set up for the old 'Gerrit' approach. Amazing how long the Gerrit approach didn't last.

[ewillink]

2023-12M3: OCL and QVTd editors have moved to the new generator framework, albeit using the idiom-based DeclarativeFormatter/Serializer. (generator usage re-enabled on SimRel.)

[ewillink]

This prompted me to develop the Declarative Formatter. Ouch! a year later it sort of worked but assumed a lossless mapping between node model and EMF model, which sadly Xtext in particular does not satisfy. So after pretty much wasting a year, I moved on to the next distressingly time consuming problem.

I think the real reason I reverted was that it was M3 and a depressing number of bugs were still appearing, so I had to put the migration on hold. This time. restarting after M1 there was enough time to finish development.