eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

http://www.eclipse.org/qvt/2015/QVTbase not consistently visible #2203

Open eclipse-ocl-bot opened 1 week ago

eclipse-ocl-bot commented 1 week ago

| --- | --- | | Bugzilla Link | 576546 | | Status | REOPENED | | Importance | P3 normal | | Reported | Oct 10, 2021 03:36 EDT | | Modified | Oct 22, 2021 05:10 EDT | | See also | 564180, 576593 | | Reporter | Ed Willink |

Description

While trying to get qvtd's OOMPG working, a config comprising QVTd projects but no QVTd plugins is used. THis appears to have some problems with resolving http://www.eclipse.org/qvt/2015/QVTbase

QVTimperative.ecore fails with

The 'ResolveableURI' constraint is violated on 'http://www.eclipse.org/qvt/2015/QVTbase'

QVTimperative.ocl is much worse

Presumably the Ecore Annotation validations have noy used an adequate ProjectMap.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Oct 18, 2021 15:25

Cannot reproduce with no QVTd and with/without OCL in Running Platform.

Perhaps it was a side effect of some other bug in the under-development qvtd.setup.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Oct 19, 2021 03:14

The OCL OOMPH with no UML2 in tha P2 Director demonstrates this when /org.eclipse.ocl.examples.build/model/UML2EcoreControl.ecore is validated.

Secondary issue; it seems quite hard to edit the .project parameterization to exclude *.ecore from the OCL validation.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Oct 19, 2021 07:04

(In reply to Ed Willink from comment #2)

The OCL OOMPH with no UML2 in tha P2 Director demonstrates this when

This might be a different problem, UML2 should have been visible from the Target Platform, whereas the original report should not have been visible and so should have used a project resource.

The running/target platform distinction is supported by EcorePlugin.computePlatformURIMap and switches between statics and PDEHelper. StandaloneProjectMap is probably using only statics. Nearly all calls to computePlatformURIMap use the recommended true argument, calls wirth false are suspect.

1 in QVTo - Bug 576728 raised.\ 2 in Xtext - at least one is legacy guarded\ 1 in StandaloneCommand.getURIConverter\ 1 in testValidate_Validate_completeocl_Bug422583\ 1 in GenericTestSuite.initializeTestResourceSet

Transitively called from EcorePlugin.getEPackageNsURIToGenModelLocationMap

1 in ExtensionProcessor.internalProcessExtensions\ 2 in Xtext Generator\ 1 in EMF EcoreEditor\ 1 in GenModelHelper.getGenPackage

The implementation of computePlatformURIMap uses PDEHelper or computePlatformPluginToPlatformResourceMap(), computePlatformResourceToPlatformPluginMap();

The latter are directly called (ignoring PDEHelper algorithms by)

VMDebugCore.getPlatformPluginMap()

The above OCL calls can be changed to use a target platform without impact on JUnit yests of Generate OCL All.

The functionality of computePlatformPluginToPlatformResourceMap() is a scan of Workspace.getRoot().getProjects(). ProjectMap.scanProjects does this too. It needs a PDEHelper variant.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Oct 21, 2021 01:32

(In reply to Ed Willink from comment #3)

(In reply to Ed Willink from comment #2)

The OCL OOMPH with no UML2 in tha P2 Director demonstrates this when

This might be a different problem, UML2 should have been visible from the

Moved to Bug 576593

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Oct 22, 2021 04:52

(In reply to Ed Willink from comment #0)

problems with resolving http://www.eclipse.org/qvt/2015/QVTbase

Bug 576593 identifies that http://www.eclipse.org/uml2/5.0.0/UML is resolved by the Java package in the global EPackage Registry that is always populated from the loaded Java in the running platform rather than the could-be-loaded Java in the target platform.

Similarly any reference to http://www.eclipse.org/qvt/2015/QVTbase requires QVTd models to be installed in the running platform.

A QVTd developer should be able to develop QVTd without using installed models (or at present tooling). Therefore any reference to http://www.eclipse.org/qvt/2015/QVTbase is a bug just waiting for a thin running platform to be used.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Oct 22, 2021 05:10

(In reply to Ed Willink from comment #0)

QVTimperative.ecore fails with

The 'ResolveableURI' constraint is violated on 'http://www.eclipse.org/qvt/2015/QVTbase'

There is no reference to http://www.eclipse.org/qvt/2015/QVTbase in QVTimperative.ecore.

There is a single

...\
and many eType="ecore:EClass ../../org.eclipse.qvtd.pivot.qvtbase/model/QVTbase.ecore#T-qvtbase-TypedModel" so it looks like the single problem is a confusing diagnostic from the OCL_Import_AnnotationValidator.