Provide a way to get rid of 'No blackbox implementation found for' warnings

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 472482 | | Status | REOPENED | | Importance | P3 normal | | Reported | Jul 13, 2015 05:56 EDT | | Modified | Feb 19, 2021 13:07 EDT | | Depends on | 563721 | | Blocks | 563596, 453909 | | See also | Gerrit change https://git.eclipse.org/r/138084, Gerrit change https://git.eclipse.org/r/162063, Gerrit change https://git.eclipse.org/r/162069, Gerrit change https://git.eclipse.org/r/162548, Gerrit change https://git.eclipse.org/r/163639, Gerrit change https://git.eclipse.org/r/163817, Gerrit change https://git.eclipse.org/r/163875, Gerrit change https://git.eclipse.org/r/164641, Gerrit change https://git.eclipse.org/r/165036, Gerrit change https://git.eclipse.org/r/165165, Gerrit change 166003, Gerrit change 166049, Gerrit change 166050, Gerrit change 166051, Gerrit change 166052, Gerrit change 166053, Gerrit change 166054, Gerrit change 166055, Gerrit change 166063, Gerrit change 166064, Gerrit change 166065, Gerrit change 166066, Gerrit change 166067, Gerrit change 166068, Gerrit change 166069, Gerrit change 166070, Gerrit change 166112, Gerrit change 166113, Gerrit change 166114, Gerrit change 166115, Gerrit change 166116, Gerrit change 166117, Gerrit change 166118, Gerrit change 166119, Gerrit change 166135, Gerrit change 166136, Gerrit change 166137, Gerrit change 166138, Gerrit change 166335, Gerrit change 166336, Gerrit change 166337, Gerrit change 166338, Gerrit change 166339, Gerrit change 166340, Gerrit change 166341, Gerrit change 166342, Gerrit change 166343, 387637, Gerrit change 176315, Gerrit change 176316, Git commit 66e8aab0, Git commit db5b0c81 | | Reporter | Dennis Hendriks |

Description

In some QVTo project, I have a Java class named 'TimestampLibrary', with an @Module annotation:

[code]\ @Module(packageURIs={"http://www.eclipse.org/emf/2002/Ecore"})\ public class TimestampLibrary { ...\ }\ [/code]

It has a method:

[code]\ public long getMicros(Date date, int micros) { ...\ }\ [/code]

The library class is registered in plugin.xml of that same project:

[code]\

\ \ \ \ \ \ \ \ [/code] In that same project, I have a QVTo transformation with the following: [code]\ blackbox helper getMicros(date: EDate, micros: Integer) : ELong;\ [/code] There are no imports in this QVTo file. On the blackbox helper line, I get the following warning: "No blackbox implementation found for 'getMicros'. Make sure that an implementation is available when running the transformation." If I run the QVTo transformation in a runtime Eclipse (child Eclipse), it works as expected. My question is: how do I get rid of this warning. It is my goal to have no warnings in my code, but I can't seem to get rid of this one.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jul 13, 2015 09:28

(In reply to Dennis Hendriks from comment #0)

My question is: how do I get rid of this warning. It is my goal to have no warnings in my code, but I can't seem to get rid of this one.

There is currently no way to get rid of this, because there is currently no way for QVTo to resolve a blackbox that resides in the workspace. Therefore the blackbox does currently not exist from the viewpoint of the QVTo compiler. The alternative would be to show a compile error instead of the warning (which was the pre-Mars behavior), which is muss less what you want.

It is my goal to enable resolving of blackboxes from the workspace for Neon.

[eclipse-qvt-oml-bot]

By Dennis Hendriks on Jul 13, 2015 09:32

(In reply to Christopher Gerking from comment #1)

[...] The alternative would be to show a compile error instead of the warning (which was the pre-Mars behavior), which is muss less what you want.

Indeed, that would be much worse.

It is my goal to enable resolving of blackboxes from the workspace for Neon.

That is good to here, and would indeed be a real solution.

A good alternative, at least for now, would be to support project configurable warning setting, allowing them to be set to 'ignore' for these specific warnings. Java/JDT, PDE, etc also support customizing warnings settings in this manner.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Sep 16, 2015 07:31

(In reply to Christopher Gerking from comment #1)

It is my goal to enable resolving of blackboxes from the workspace for Neon.

Externalized to bug 474603.

[eclipse-qvt-oml-bot]

By Ed Willink on Nov 27, 2018 13:25

(In reply to Christopher Gerking from comment #3)

(In reply to Christopher Gerking from comment #1)

It is my goal to enable resolving of blackboxes from the workspace for Neon.

Externalized to bug 474603.

However we still have the warning.

So long as the warning is just informative, shouldn't it be an INFO?

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 28, 2018 04:10

(In reply to Ed Willink from comment #4)

However we still have the warning.

Yes but only under justified circumstances. The warning shows up if executing the transformation as is (i.e. inside the workspace where it is compiled) would produce a "No blackbox implementation found" exception at runtime.

Thus, the warning should be perfectly consistent with the engine's capability of resolving blackboxes at runtime. Is there a situation where an inconsistency shows up?

One known exception is when a transformation is intended to be executed exclusively using a QVTO Application Launch Delegate. In this case, a false positive warning will actually occur because the delegate makes additional blackboxes resolvable at runtime (namely those that have been registered via extensions). I consider this a corner case.\

So long as the warning is just informative, shouldn't it be an INFO?

In my opinion it is not just informative.

[eclipse-qvt-oml-bot]

By Ed Willink on Nov 28, 2018 04:28

(In reply to Christopher Gerking from comment #5)

I consider this a corner case.

No doubt my use case. In

https://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/examples/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/qvto/BlackBoxLibrary.java

provides a single helper utility.

Now that I've reduced OCL to about 20 warnings, the remaining ones get more irritating.

The equivalent syntax for the OCL standard library model is:

operation toString() : String[1] => 'org.eclipse.ocl.pivot.library.oclany.OclAnyToStringOperation';

Perhaps QVTo should have an "=>" / "implementedBy" syntax too.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 29, 2018 09:31

(In reply to Ed Willink from comment #6)

No doubt my use case.

Why? Can't you make the blackbox accessible on the classpath? In that case it could be resolvable through its Java FQN, so

import org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary;

might work. And then you could try executing with the default "QVT Operational Interpreter".

(In reply to Ed Willink from comment #4)

So long as the warning is just informative, shouldn't it be an INFO?

No basic objection to an INFO. However I think that the QVTo editor is ill-prepared for severities other than ERROR or WARNING. Might be more effort than expected.

[eclipse-qvt-oml-bot]

By Ed Willink on Nov 29, 2018 10:42

(In reply to Christopher Gerking from comment #7)

Why?

Because this is the only time I have ever used blackboxes and blackbox documentation is dreadful. I raised Bug 453909

Can't you make the blackbox accessible on the classpath?

It is on the classpath.

In that case it could be resolvable through its Java FQN, so

import org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary;

might work.

No it gives me an error in regard to

Cyclic dependency from 'platform:/resource/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/qvto/BlackBoxLibrary.qvto' to 'platform:/resource/org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/qvto/BlackBoxLibrary.qvto'

that is when I change my *.qvto to:

import org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary;

modeltype Ecore "strict" uses ecore('http://www.eclipse.org/emf/2002/Ecore');

library BlackBoxLibrary;

blackbox helper getURI(eObject : EObject) : String;

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 29, 2018 11:34

(In reply to Ed Willink from comment #8)

import org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary;

modeltype Ecore "strict" uses ecore('http://www.eclipse.org/emf/2002/Ecore');

library BlackBoxLibrary;

blackbox helper getURI(eObject : EObject) : String;

This should work, I will have a look. I recall a discussion with Sergey that ended up with the decision that only explicitly imported Java classes should be searched for implementations of blackbox operations. But this is exactly what your snippet does.

However you don't need to declare a QVTo library for your blackbox. Just use

import org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary;

inside the transformation that uses the blackbox helper. This should allow you to just invoke getURI(...) without any warning. No dedicated "blackbox helper" declaration required.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 05, 2019 07:57

(In reply to Christopher Gerking from comment #9)

This should work, I will have a look.

Pushed a trivial fix for your case to cgerking/472482. As long as the blackbox resides in the same project as the QVTo transformation, this should enable the import exactly as attempted below:

(In reply to Ed Willink from comment #8)

import org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary;

modeltype Ecore "strict" uses ecore('http://www.eclipse.org/emf/2002/Ecore');

library BlackBoxLibrary;

blackbox helper getURI(eObject : EObject) : String;

Now the import and the blackbox declaration are both optional, you only need one of them to get rid of the warning.

Please note that due to bug 545063, the interplay between QVTo and Java is still somewhat problematic. A clean might help.

[eclipse-qvt-oml-bot]

Mar 05, 2019 11:21

New Gerrit change created: https://git.eclipse.org/r/138084

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 05, 2019 11:22

Looks trivial enough.

The Gerrit build should give me something to install and see if the warning goes away.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 05, 2019 12:01

(In reply to Ed Willink from comment #12)

The Gerrit build should give me something to install and see if the warning goes away.

Successfully eliminates the warning in the Problems View / Package Explorer.

Warning remains in the QVTo editor.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 05, 2019 13:16

(In reply to Ed Willink from comment #13)

Warning remains in the QVTo editor.

Tried to reproduce with the original project. The first (minor) problem is that the BlackBoxLibrary has identical FQNs for QVTo and Java, that's probably where the cyclic dependency comes from. Rename helps.

The major problem is that there a no class files built, at least the bin folder is always empty. QVTo needs these files to load them into an URLClassLoader. I can't figure out why they are missing.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 05, 2019 16:10

I have a BlackBoxLibrary.class in my bin tree.

Renaming BlackBoxLibrary.qvto to BlackBoxLibrary2.qvto makes it worse; warning in Package Explorer too.

Renaming import BlackBoxLibrary to import BlackBoxLibrary2 makes clear that I do not understand what a library is;doesn't help anyway.

For a trivial usage the same name stem throughout seems the obvious thing to do.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 06, 2019 08:57

(In reply to Ed Willink from comment #15)

I have a BlackBoxLibrary.class in my bin tree.

Local problem on my side, forget about it.

Renaming BlackBoxLibrary.qvto to BlackBoxLibrary2.qvto makes it worse; warning in Package Explorer too.

Clearly a bug, imported workspace blackboxes were never loaded. Fixed on cgerking/472482. Commit ID: 90405904805b13aaa4fb67b74a8db0bd2934d6eb

False positive warnings in the Package Explorer seem to be a separate issue, it often takes some time to refresh.

In addition, I fell over some local Java compile errors inside the org.eclipse.ocl.examples.build project, which were not properly handled by QVTo and therefore interrupted the search for blackboxes. Commit ID: 639e92012a9341daed73b9c20aa39537f8aee28f

Renaming import BlackBoxLibrary to import BlackBoxLibrary2 makes clear that I do not understand what a library is

The thing is that two different "blackbox" mechanisms are co-existing.

The old one was implemented by Borland, and it simply converts a Java class into a QVTo Library that can be imported like any other QVTo module. Strictly speaking, this approach has nothing to do with a blackbox, at least there are no 'blackbox' keywords involved.

The new mechanism was established as per bug 289982. It enables the use of 'blackbox' keywords at the concrete syntax level, whereas the respective Java methods will be dynamically resolved.

Sergey came up with an idea for a well-defined interplay between both mechanisms in bug 289982, comment 8. According to his proposal, if blackbox libraries are explixitly imported using the old mechanism, then only these libraries are consulted during the dynamic resolution of the new mechanism. Makes sense, but nothing like this is OMG-specified.

For a trivial usage the same name stem throughout seems the obvious thing to do.

Instead if reporting a circular dependency, the compiler could maybe fall back to a blackbox library of the same name. However the point is that you don't need two libraries at all. In case of the old mechanism, just import the Java class directly from where it is needed. In case of the new mechanism, just declare a blackbox operation wherever you like. No need for colliding names.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 06, 2019 12:14

(In reply to Christopher Gerking from comment #16)

Renaming BlackBoxLibrary.qvto to BlackBoxLibrary2.qvto makes it worse; warning in Package Explorer too. Clearly a bug, imported workspace blackboxes were never loaded. Fixed on cgerking/472482. Commit ID: 90405904805b13aaa4fb67b74a8db0bd2934d6eb

False positive warnings in the Package Explorer seem to be a separate issue, it often takes some time to refresh.

In addition, I fell over some local Java compile errors inside the org.eclipse.ocl.examples.build project, which were not properly handled by QVTo and therefore interrupted the search for blackboxes. Commit ID: 639e92012a9341daed73b9c20aa39537f8aee28f

The latest build is disastrous for me; possibly aggravated by my rename.

I was inundated with hundreds of log entries such as

!ENTRY org.eclipse.m2m.qvt.oml.blackbox.java 4 0 2019-03-06 17:02:49.175\ !MESSAGE Failed to load Java black-box unit 'org.eclipse.qvtd.codegen.qvticgmodel.impl.CGConnectionAssignmentImpl'\ !SUBENTRY 1 org.eclipse.m2m.qvt.oml.blackbox.java 4 0 2019-03-06 17:02:49.175\ !MESSAGE Loading Java module diagnostics 'org.eclipse.qvtd.codegen.qvticgmodel.impl.CGConnectionAssignmentImpl, javaClass: org.eclipse.qvtd.codegen.qvticgmodel.impl.CGConnectionAssignmentImpl'\ !SUBENTRY 2 org.eclipse.m2m.qvt.oml.blackbox.java 4 0 2019-03-06 17:02:49.175\ !MESSAGE Invalid Java class 'class org.eclipse.qvtd.codegen.qvticgmodel.impl.CGConnectionAssignmentImpl' for black-box module 'org.eclipse.qvtd.codegen.qvticgmodel.impl.CGConnectionAssignmentImpl, javaClass: org.eclipse.qvtd.codegen.qvticgmodel.impl.CGConnectionAssignmentImpl'

seemingly one per class anywhere. I was left with no alternative but to kill Eclipse.

After reverting the rename external to Eclipse and restarting, everything seems good; no warning. Too soon. My error log is filling up again.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 07, 2019 04:28

(In reply to Ed Willink from comment #17)

I was inundated with hundreds of log entries

I see. I assume there is no Java class being imported now? In this case, all the class files inside the project are tried to be loaded as a blackbox, which most often fails. You could work around the resulting errors by re-enabling the explicit import.

Of course reporting errors about all classes is pointless. Therefore it seems that different BlackboxProviders require different ways to handle load exceptions. In particular, the JdtBlackboxProvider should never report errors because it loads just everything. Pushed to cgerking/472482.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 08, 2019 06:53

(In reply to Christopher Gerking from comment #18)

Therefore it seems that different BlackboxProviders require different ways to handle load exceptions.

This work in progress seems too risky to push to master for RC2. Currently we have a defective warning; much less harmful than a log full of errors.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 08, 2019 07:10

(In reply to Ed Willink from comment #19)

This work in progress seems too risky to push to master for RC2.

Agreed.

Currently we have a defective warning; much less harmful than a log full of errors.

These errors should be gone with the latest changes. However these changes are only justified by my personal view that blackboxes provided by JDT should not report load errors (due to their immaturity and because they are not explicitly registered). This might require some more in-depth discussions.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 08, 2019 07:21

I've just installed a build of

commit 82a830df2308df577c1bbe99755b21917fde53fc\ [472482] Suppress load errors for blackboxes obtained through JDT

and now get a different failure. It seems that we have a significant lack of test coverage for balck boxes.

java.lang.TypeNotPresentException: Type org.eclipse.emf.codegen.ecore.genmodel.GenPackage not present\ at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:117)\ at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)\ at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)\ at sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68)\ at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138)\ at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)\ at sun.reflect.generics.repository.ConstructorRepository.getParameterTypes(ConstructorRepository.java:94)\ at java.lang.reflect.Executable.getGenericParameterTypes(Executable.java:283)\ at java.lang.reflect.Method.getGenericParameterTypes(Method.java:283)\ at org.eclipse.m2m.internal.qvt.oml.blackbox.java.OperationBuilder.createOperation(OperationBuilder.java:60)\ at org.eclipse.m2m.internal.qvt.oml.blackbox.java.OperationBuilder.buildOperation(OperationBuilder.java:49)\ at org.eclipse.m2m.internal.qvt.oml.blackbox.java.JavaModuleLoader.loadModule(JavaModuleLoader.java:101)\ at org.eclipse.m2m.internal.qvt.oml.blackbox.java.JavaBlackboxProvider$JavaUnitDescriptor.load(JavaBlackboxProvider.java:201)\ at org.eclipse.m2m.internal.qvt.oml.blackbox.BlackboxProvider.getBlackboxCallHandler(BlackboxProvider.java:129)\ at org.eclipse.m2m.internal.qvt.oml.blackbox.BlackboxRegistry.getBlackboxCallHandler(BlackboxRegistry.java:80)\ at org.eclipse.m2m.internal.qvt.oml.ast.parser.QvtOperationalVisitorCS.visitMappingMethodCS(QvtOperationalVisitorCS.java:3750)\ at org.eclipse.m2m.internal.qvt.oml.ast.parser.QvtOperationalVisitorCS.visitMethodBodies(QvtOperationalVisitorCS.java:2412)\ at org.eclipse.m2m.internal.qvt.oml.ast.parser.QvtOperationalVisitorCS.visitUnitCS(QvtOperationalVisitorCS.java:2109)\ at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.analyze(QVTOCompiler.java:279)\ at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.doCompile(QVTOCompiler.java:444)\ at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.compileSingleFile(QVTOCompiler.java:325)\ at org.eclipse.m2m.internal.qvt.oml.compiler.QVTOCompiler.compile(QVTOCompiler.java:183)\ at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.rebuildAll(QVTOBuilder.java:216)\ at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.fullBuild(QVTOBuilder.java:94)\ at org.eclipse.m2m.internal.qvt.oml.project.builder.QVTOBuilder.build(QVTOBuilder.java:81)\ at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:833)\ at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)\ at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:220)\ at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:263)\ at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:316)\ at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)\ at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:319)\ at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:371)\ at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:392)\ at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:154)\ at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:244)\ at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)\ Caused by: java.lang.ClassNotFoundException: org.eclipse.emf.codegen.ecore.genmodel.GenPackage\ at java.net.URLClassLoader.findClass(URLClassLoader.java:382)\ at java.lang.ClassLoader.loadClass(ClassLoader.java:424)\ at java.lang.ClassLoader.loadClass(ClassLoader.java:357)\ at java.lang.Class.forName0(Native Method)\ at java.lang.Class.forName(Class.java:348)\ at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114) ... 36 more

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 08, 2019 07:50

(In reply to Ed Willink from comment #21)

It seems that we have a significant lack of test coverage for balck boxes.

Yes, at least with respect to "bad" blackboxes. Can you image why yours is considered bad, is there a compile error in your project or something? Unchecked exceptions like TypeNotPresentException are really hard to anticipate. I wonder why I don't get the same exception.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 08, 2019 08:05

My suspicion is that you are looking at thousands of Java classes and have not considered all the possible things that can happen in arbitrary classes.

I would hope that you would only analyze a few which might well be simple. You might then get away with neglecting to support generics or ... lambdas or ...

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 08, 2019 08:13

(In reply to Ed Willink from comment #23)

My suspicion is that you are looking at thousands of Java classes and have not considered all the possible things that can happen in arbitrary classes.

Right, that's what currently happens.

I would hope that you would only analyze a few which might well be simple.

This is what you can achieve by importing only those Java classes to QVTo that should be analyzed. In your case,

import org.eclipse.ocl.examples.build.qvto.MyUnambigousBlackBoxLibrary;

should do the trick.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 08, 2019 08:21

I obviously don't understand some aspect of this problem.

Given:

library BlackBoxLibrary;

blackbox helper getURI(eObject : EObject) : String;

In the QVTo world there is a BlackBoxLibrary Library=Class(+Package), which is mapped to a Java org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary class by

\ \ \ \ \ \

Additionally in the QVTo world there is a BlackBoxLibrary::getURI(EObject) declaration, which is mapped to org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary.getURI(EObject).

So every time BlackBoxLibrary::getURI() is analyzed, you check the org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary.getURI() declaration for consistency. Every time BlackBoxLibrary::getURI() is invoked, you redirect to new org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary().getURI().

No need to analyze any class that uses GenPackage.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 14, 2019 04:26

(In reply to Ed Willink from comment #25)

In the QVTo world there is a BlackBoxLibrary Library=Class(+Package), which is mapped to a Java org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary class by

Yes but how can we be aware of such registrations inside our workspace projects? Is there an easy way to parse/analyze plugin.xml files from the workspace? Does PDE provide such a thing? Of course we could implement this manually, but that sounds like a great effort.

Additionally in the QVTo world there is a BlackBoxLibrary::getURI(EObject) declaration, which is mapped to org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary.getURI(EObject).

How is it mapped? By means of an import?

Using an import, you should be able to achieve the desired behavior already now (only blackboxes imported through their Java FQN will be taken into account).

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 14, 2019 07:15

Accessing extension points is almost Eclipse Plugin Development 101.

See org.eclipse.emf.ecore.plugin.RegistryReader.readRegistry() and friends.

From a workspace its easy. From standalone it's harder but org.eclipse.emf.ecore.plugin.EcorePlugin.ExtensionProcessor does it.

The extension point is an Eclipse QVTo 'language extension' to provide the implementation specific binding between QVTo and implementation worlds.

---

While being 100% OMG standard compatible is admirable, I have to wonder whether users wouldn't prefer a syntax compatible

library BlackBoxLibrary; --class="org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary"

or even a sensible extension to

library BlackBoxLibrary implementedBy "java:org.eclipse.ocl.examples.build.qvto.BlackBoxLibrary";

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 14, 2019 13:06

(In reply to Ed Willink from comment #27)

Accessing extension points is almost Eclipse Plugin Development 101.

See org.eclipse.emf.ecore.plugin.RegistryReader.readRegistry() and friends.

I see. We should use this in JdtBlackboxProvider to filter the registered blackbox classes, and thereby mimic the behavior of BundleBlackboxProvider. However in case of a default (non-plugin) project, we should retain the current mechanism.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 14, 2019 13:35

(In reply to Ed Willink from comment #27)

From a workspace its easy.

... however the proposed approach seems to be limited to extensions contributed by deployed plugins. I still don't understand how we can use this approach to analyze the registrations inside the plugin.xml files from the workspace.

From standalone it's harder but org.eclipse.emf.ecore.plugin.EcorePlugin.ExtensionProcessor does it.

Which is not really helpful as well because in case of IS_ECLIPSE_RUNNING it just does nothing.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 14, 2019 17:18

PluginReader in https://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.pivot/src/org/eclipse/ocl/pivot/internal/resource/StandaloneProjectMap.java reads a plugin.xml to extract a particular extension point.

Which is not really helpful as well because in case of IS_ECLIPSE_RUNNING it just does nothing.

Have another look.

I evolved StandaloneProjectMap from MWE2 before EcorePlugin.ExtensionProcessor existed. In its first incarnation EcorePlugin.ExtensionProcessor did just OSGI, but now it does standalone too and makes StandaloneProjectMap redundant for many location purposes (but not matamodel schizophrenia suppression).

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 15, 2019 04:56

(In reply to Ed Willink from comment #30)

EcorePlugin.ExtensionProcessor did just OSGI, but now it does standalone too and makes StandaloneProjectMap redundant for many location purposes (but not matamodel schizophrenia suppression).

I'm afraid that I still don't get it, at least not how to use the ExtensionProcessor as is. According to its Javadoc, invoking process(...) "does nothing if invoked in the context of an Eclipse application". The problem is that the QVTo compiler is normally running in the context of an Eclipse application. There is no nested standalone application or something like that.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 15, 2019 08:15

The QVTo compiler is supported in a standalone invocation, so you have to support both. (A binding within the *.qvto file would avoid all the complexity.)

The ExtensionProcessor works for EMF extensions.

For novel extensions you have to write your own registry reader. See the 4 readers in org.eclipse.ocl.pivot.internal.plugin.

In the past, before ExtensionProcessor, standalone initialization was a magic caller's responsibility. Particularly hard for UML leading to my development of UMLResourcesUtil.init(). Xtext has now 'standardized' on XXXStandaloneSetup.doSetup(), which the Pivot OCL, QVTd extends to non-Xtext. A QVToStandaloneSetup.doSetup() would be nice.

The above is fine for tooling declarations, but the QVTo URImap is a user declaration (that belongs in the *.qvto file). You could mandate that a standalone caller do something like

MetamodelURIMappingHelper.Registry.INSTANCE.put(URI.createURI("http://www.eclipse.org/ocl/2012/UML2EcoreControl", URI.createURI("platform:/resource/org.eclipse.ocl.examples.build/model/UML2EcoreControl.ecore"));

to get things to work. Actually we should support that anyway. A reader routine could avoid the need to duplicate the declarations.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Apr 16, 2020 08:37

This bug has still not been fixed entirely. I have now committed a trivial fix that at least enables "good" blackboxes to be resolved without a warning. Good means that the blackbox compiles and includes only such Java methods that are directly convertible into QVTo operations (no additional auxiliary methods for which the conversion fails).

Commit ID: 50dc647d668ff00eed6c34a7fabcaeaa251d2cc6. Since the fix is so trivial, I'm inclined to believe that there was a failure to commit or merge parts of this issue in the past.

Handling of more sophisticated blackboxes (including compile errors or auxiliary methods) still to come.

[eclipse-qvt-oml-bot]

By Ed Willink on Apr 29, 2020 09:22

The fix certainly looks pretty trivial, but beyond my understanding.

I can only make a structural suggestion. The change of the static

QvtOperationalVisitorCS.getSourceURI(QvtOperationalModuleEnv env)

from private to public suggests that you have identified a useful pubic API that is nothing to do with QvtOperationalVisitorCS.

As public API, it deserves a Javadoc comment, particularly in regard to the null return.

As nothing to do with QvtOperationalVisitorCS, perhaps there is a better place to put it, perhaps a CSUtils class or perhaps in the QvtOperationalModuleEnv argument type.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Apr 29, 2020 09:29

(In reply to Ed Willink from comment #34)

As nothing to do with QvtOperationalVisitorCS, perhaps there is a better place to put it, perhaps a CSUtils class or perhaps in the QvtOperationalModuleEnv argument type.

Yes I'm right there with you.

I'm about to prepare a test case for this issue, which is non-trivial because it involves the JDT builder to produce a class file for the blackbox.

[eclipse-qvt-oml-bot]

By Ed Willink on May 05, 2020 10:51

Fix Pushed to master for M2.

Please adjust API in time for M3 so we don;t have to worry about bad released public API legacy.

[eclipse-qvt-oml-bot]

May 05, 2020 11:48

New Gerrit change created: https://git.eclipse.org/r/162063

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 05, 2020 12:19

(In reply to Eclipse Genie from comment #37)

New Gerrit change created: https://git.eclipse.org/r/162063

Added a test case for the QVTo parser on cgerking/472482. Commit ID: 907abc2931e7426a7c218724bdf22fd92ff433d9.

Since the parser tests do not invoke a Java build, the test case also includes the class file that represents the blackbox.

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 05, 2020 12:24

(In reply to Ed Willink from comment #34)

As nothing to do with QvtOperationalVisitorCS, perhaps there is a better place to put it, perhaps a CSUtils class or perhaps in the QvtOperationalModuleEnv argument type.

Since getSourceURI(...) does not directly relate to CS at all, I think that QvtOperationalUtil would be the right place.

(In reply to Ed Willink from comment #36)

Please adjust API in time for M3 so we don;t have to worry about bad released public API legacy.

Will provide a Javadoc comment.

[eclipse-qvt-oml-bot]

May 05, 2020 13:00

New Gerrit change created: https://git.eclipse.org/r/162069

[eclipse-qvt-oml-bot]

By Ed Willink on May 05, 2020 13:23

(In reply to Christopher Gerking from comment #38)

Since the parser tests do not invoke a Java build, the test case also includes the class file that represents the blackbox.

That doesn't seem right. GenModel and other auto-generatprs do not run, but .java => .class should happen.

Which file is not built; maybe it's just missing from its folder pom.xml.

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 05, 2020 13:35

(In reply to Ed Willink from comment #41)

That doesn't seem right. GenModel and other auto-generatprs do not run, but .java => .class should happen.

The problem is that TestQvtParser.compile(...) is programmatically restricted to a pure QVTo build. But yes, maybe there is a way to make the infrastructure produce the class file before the tests are running.

Which file is not built; maybe it's just missing from its folder pom.xml.

It's the new org.eclipse.m2m.tests.qvt.oml.Blackbox, but it is not even located in a source folder so currently it cannot be built.

[eclipse-qvt-oml-bot]

By Ed Willink on May 05, 2020 14:36

(In reply to Christopher Gerking from comment #42)

Which file is not built; maybe it's just missing from its folder pom.xml. It's the new org.eclipse.m2m.tests.qvt.oml.Blackbox, but it is not even located in a source folder so currently it cannot be built.

You forget that I have no knowledge of how this works. I cannot find the new Blackbox. Perhaps because it isn't in a source folder. Not being in a source folder seems like potentially the root of the problem.

[eclipse-qvt-oml-bot]

May 06, 2020 05:44

New Gerrit change created: https://git.eclipse.org/r/162548

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 06, 2020 06:52

(In reply to Ed Willink from comment #43)

Not being in a source folder seems like potentially the root of the problem.

The question is whether it is a problem or not. What QVTo actually does is analyzing class files dynamically. In practice, these class files are produced during a Java build invoked by JDT. But for a unit test, isn't it valid to provide such a class file as is?

Moving to a source folder is not easily possible because the project under test is created on-the-fly during the parser tests. Of course we could programmatically add any pre-built class files to this project's class path. But then we would need a mechanism to indicate explicitly which class files are needed for a particular test case. That's not impossible but it requires a change to the parser tests.

[eclipse-qvt-oml-bot]

By Ed Willink on May 06, 2020 07:16

(In reply to Christopher Gerking from comment #45)

What QVTo actually does is analyzing class files dynamically.

I don't understand. Why does an analysis produce a class file, surely it produces an analysis report?

In practice, these class files are produced during a Java build invoked by JDT. But for a unit test, isn't it valid to provide such a class file as is?

Your comments strongly imply that QVTo has a Java CG whose outputs need building. I am not aware of such functionality in QVTo.

QVTd does since it synthesizes a .ecore trace model that needs genmodeling, and a .java tx implementation that needs compiling, all before the resulting code is executed and tested. To make this work on Tycho requires synthesis of a project.

If you really need this, the org.eclipse.ocl.examples.codegen.dynamic package has some classes that help with compilation. ExplicitClassLoader is particularly magic. org.eclipse.ocl.examples.xtext.tests has classes that help manage a file system that works with JUnit, JUnit plugin, tycho-surefire, maven-surefire.,

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 06, 2020 12:33

(In reply to Ed Willink from comment #46)

I don't understand. Why does an analysis produce a class file, surely it produces an analysis report?

It analyzes class files with the aim to use them as dynamic Java blackboxes. More precisely, it just uses an URLClassLoader to load class files from the workspace, before using QVTo's traditional mechanism for deriving blackboxes from the loaded classes.

Your comments strongly imply that QVTo has a Java CG whose outputs need building. I am not aware of such functionality in QVTo.

Fortunately not. Nevertheless, blackboxes can be derived from class files after they were built. To that end, QVTo integrates with JDT to reload classes after each build.

[eclipse-qvt-oml-bot]

By Ed Willink on May 06, 2020 15:16

Ok. So if you're just analyzing class files and not creating Java files, presumably the Java files could be in GIT and so could be built normally.

[eclipse-qvt-oml-bot]

By Ed Willink on May 06, 2020 15:34

Quite probably the class file is there, but not in the way you expect.

With Tycho, you are testing the packaged project, so distributed class files are within their plugin JARs. You will need to use a ZipFile to access them.

If however you are testing a test project class file, it's probably down below the target folder so any magic ".../bin/..." path construction is probably wrong.

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 07, 2020 03:32

(In reply to Ed Willink from comment #48)

Ok. So if you're just analyzing class files and not creating Java files, presumably the Java files could be in GIT and so could be built normally.

Yes, no problem if we move them to a source folder (which we must then put on the classpath of the test project dynamically).

However to actually test the functionality of loading classes dynamically, these classes should not be on the classpath of the running Eclipse. Otherwise, QVTo's URLClassLoader will not take effect because it just delegates to the EquinoxClassLoader through which QVTo has been loaded. Is there a way to build a class but then exclude it from the classpath?