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

eclipse-qvt-oml-bot commented 5 days ago

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 commented 5 days ago

Jul 10, 2020 05:40

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166115

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 05:40

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166116

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 05:40

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166117

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 05:40

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166118

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 05:40

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166119

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 10, 2020 05:45

Might be a problem with EGit? For me "Push to origin" does not bypass Gerrit (remote repository configured as ssh://cgerking@git.eclipse.org:29418/mmt/org.eclipse.qvto.git).

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 07:20

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166135

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 07:20

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166136

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 07:20

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166137

eclipse-qvt-oml-bot commented 5 days ago

Jul 10, 2020 07:20

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166138

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 10, 2020 07:37

Finally managed to rebase. Unfortunately EGit was not very helpful. Instead of showing the errors that happen behind the scenes, it does nothing.

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 10, 2020 15:20

(In reply to Christopher Gerking from comment #111)

Finally managed to rebase. Unfortunately EGit was not very helpful. Instead of showing the errors that happen behind the scenes, it does nothing.

Perhaps, but your activities have given me 50 email notifications today which seems well over the top.

Rebase is easy. To rebase your current committed branch, select what you want to base on on and invoke Rebase HEAD On. If you have many conflicts you may have to work with the GIT merge tool. Sometimes it can be eaier to Cherry PIck one at a time. If the development is a mess, it can be good to create a saved branch to go back to iff eberything goes wrong, then do a Reset MIxed to the start of the development, and then commit the changes. This gives you a single flattened commit of everything that has actually changed. These chnages may be REbased as part of a single Merge Conflict fight, or you can review the changes and redevelop theme by them to avoid confusion from multiple improvements.

When using Push branch xxx or Remote->Push | xxx, you may find that the dialog ia auto-populated by a Gerrit push to refs/for/xxx. I delete it and configure a regular push to refs/head/xxx .

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 14, 2020 02:35

(In reply to Ed Willink from comment #112)\ Your rebasing is clearly wrong.

I see two cgerking branches, each of which duplicates

"[releng] Bump build/features by +0.0.1 for 3.10.3"

It looks as if you rebased master on your code, rather than your code on master.

Your branches should descend from (and re-use) the master copy of

"[releng] Bump build/features by +0.0.1 for 3.10.3"

rather than duplicate it.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 15, 2020 04:11

(In reply to Ed Willink from comment #112)

Perhaps, but your activities have given me 50 email notifications today which seems well over the top.

That was because it took me multiple attempts to do it right (i.e. resolve all the conflicts).

(In reply to Ed Willink from comment #113)

I see two cgerking branches, each of which duplicates

"[releng] Bump build/features by +0.0.1 for 3.10.3"

Which branch are you looking at? For cgerking/472482, I see that commit only once: https://git.eclipse.org/c/mmt/org.eclipse.qvto.git/log/?h=cgerking/472482

It looks as if you rebased master on your code, rather than your code on master.

That was probably one of my initial mistakes, I had hoped I got it right in the end. I have no clue why my branch does not descend from the latest master commit.

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 15, 2020 05:40

It may be better in your workspace; I can only comment on what I see on the server.

IMHO a good GIT history comprises a single chain of commits for master with occasional side branches, for maintenance, development. Some development branches, e.g. ewillink/533565, remain work in progress and clutter the history for ever. Others should be rebased on master, so that the good commits of the development enhance the existing commits of master. It should very rarely be appropriate to use a master commit in a branch.

I suggest you read a GIT tutorial to explain rebase because you clearly have a misunderstanding.

NB. When making non-forward changes to your development, you can check the Force Update to replace your stale commits with your better ones.

NB. When you have finished with a development branch, you can Remote Push... and then select a delete.

You might try checking out origin/ewillink/533565 as a new local branch, then rebasing it on master to demonstrate that ewillink/533565 moves to be a single commit enhancement to master, not a duplicate of two year's commits on origin/ewillink/533565. You can just commit the bad unresolved merges to demonstrate the commit.

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:30

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166335

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:30

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166336

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:30

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166337

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:30

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166338

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:31

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166339

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:31

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166340

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:31

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166341

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:31

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166342

eclipse-qvt-oml-bot commented 5 days ago

Jul 15, 2020 09:31

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/166343

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 15, 2020 09:44

Sorry for spamming. The branch should now correctly descend from master: https://git.eclipse.org/c/mmt/org.eclipse.qvto.git/log/?h=cgerking/472482

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 15, 2020 11:44

The build seems to pass.

Diffing the total change, I see additional tests data, but the test result shows the same number of tests. It would appear that new tests are not running.

Glancing at the code I see at least one public static method has vanished. Ok, it's in an internal package, but QVTo is one of those projects that cannot really justify its "internal". Because the API is unsound and mandates non-API, users are forced to access internal and so cannot distinguish between gratuitously internal and genuinely internal. Therefore it is best to preserve the API wherever possible, keep/deprecate the garbage, add new sensible functionality.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 16, 2020 03:35

(In reply to Ed Willink from comment #126)

It would appear that new tests are not running.

There are 2093 tests running, master has only 2092.

Glancing at the code I see at least one public static method has vanished.

I assume you are referring to JdtBlackboxProvider.clearDescriptors(IProject), which has been given the more general name reset(...) because it now does additional clean-up operations. I will preserve the signature and let the new method delegate to the old one.

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 16, 2020 04:37

(In reply to Christopher Gerking from comment #127)

(In reply to Ed Willink from comment #126)

It would appear that new tests are not running. There are 2093 tests running, master has only 2092.

https://ci.eclipse.org/qvt-oml/job/qvto-master/lastCompletedBuild/testReport/ shows 2294

https://ci.eclipse.org/qvt-oml/job/qvto-master-gerrit/lastCompletedBuild/testReport/ also shows 2294

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 16, 2020 09:55

(In reply to Christopher Gerking from comment #127)

I will preserve the signature and let the new method delegate to the old one.

Done in commit 0a6f8e2593181f8ff069320bfe6811dc871f25e6, but without delegation to avoid a dependency on the newly deprecated method.

(In reply to Ed Willink from comment #128)

https://ci.eclipse.org/qvt-oml/job/qvto-master/lastCompletedBuild/testReport/ shows 2294

https://ci.eclipse.org/qvt-oml/job/qvto-master-gerrit/lastCompletedBuild/ testReport/ also shows 2294

I have no idea what went wrong, clearly there is one additional test case in TestQvtParser called "bug472482".

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 16, 2020 11:51

(In reply to Christopher Gerking from comment #129)

(In reply to Ed Willink from comment #128)

https://ci.eclipse.org/qvt-oml/job/qvto-master/lastCompletedBuild/testReport/ shows 2294

https://ci.eclipse.org/qvt-oml/job/qvto-master-gerrit/lastCompletedBuild/ testReport/ also shows 2294 I have no idea what went wrong, clearly there is one additional test case in TestQvtParser called "bug472482".

Perhaps but

https://ci.eclipse.org/qvt-oml/job/qvto-master-gerrit/lastCompletedBuild/testReport/org.eclipse.m2m.tests.qvt.oml/TestQvtParser/

does not show it, so either that build is not what you have developed or your new test is not being used.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 16, 2020 12:39

(In reply to Ed Willink from comment #130)

... so either that build is not what you have developed or your new test is not being used.

Just triggered https://ci.eclipse.org/qvt-oml/job/qvto-branch-tests/85 manually, with "bug472482" failing. Probably the new blackbox class is not properly built, although I configured the .classpath of org.eclipse.m2m.tests.qvt.oml accordingly. I assume that I have to register the additional source folder somewhere else?

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 16, 2020 15:09

(In reply to Christopher Gerking from comment #131)

although I configured the .classpath of org.eclipse.m2m.tests.qvt.oml accordingly

When using plugins you should never configure the classpath manually. It is auto-updated from the MANIFEST.MF, and manually updated if necessary by "Update the classpath setting" on the Overview tab.

My understanding was that your blackbox class is now very boring build-wise, so you should only need boring strategies to use it.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 17, 2020 07:33

(In reply to Ed Willink from comment #132)

My understanding was that your blackbox class is now very boring build-wise, so you should only need boring strategies to use it.

Yes but the blackbox has its own source folder, simply because it requires a separate output folder other than "bin". This is specified in the .classpath file, is there a way to make the CI aware of that?

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 17, 2020 08:26

Have a look at org.eclipse.m2m.qvt.oml.cst.parser which has multiple source folders.

Yes, the .classpath needs updating, but I always control the paths via the Java Build Path Property Page. Maybe it's the build.properties entry you miss.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 17, 2020 13:23

(In reply to Ed Willink from comment #134)

Maybe it's the build.properties entry you miss.

You are right, https://ci.eclipse.org/qvt-oml/job/qvto-branch-tests/86 succeeded.

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 18, 2020 05:18

Great. I leave it to your conscience to review the changes for user impact; it's not an area that I understand adequately.

Then we are good to fast merge to master, after the additional releng commit to bump

org.eclipse.m2m.internal.qvt.oml MANIFEST.MF\ org.eclipse.m2m.qvt.oml.runtime.jdt MANIFEST.MF\ org.eclipse.m2m.tests.qvt.oml MANIFEST.MF\ org.eclipse.m2m.tests.qvt.oml pom.xml

to 3.10.3 (plugins but not tests have auto-generated pom.xml).

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 18, 2020 05:23

(In reply to Christopher Gerking from comment #135)

(In reply to Ed Willink from comment #134)

Maybe it's the build.properties entry you miss. You are right

If we had tackled Bug 387637 you might have noticed the warning from the Manifest editor.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 20, 2020 02:06

(In reply to Ed Willink from comment #137)

If we had tackled Bug 387637 you might have noticed the warning from the Manifest editor.

Which one are you referring to? I only get one warning inside the plugin.xml file.

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Jul 20, 2020 04:40

In the past I have seen a missing source path warning wrt build.properties; although not always appropriate for auto-generated paths. I would expect that some similar warning was present for you.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Jul 23, 2020 05:20

(In reply to Ed Willink from comment #136)

... after the additional releng commit to bump

org.eclipse.m2m.internal.qvt.oml MANIFEST.MF org.eclipse.m2m.qvt.oml.runtime.jdt MANIFEST.MF org.eclipse.m2m.tests.qvt.oml MANIFEST.MF org.eclipse.m2m.tests.qvt.oml pom.xml

to 3.10.3 (plugins but not tests have auto-generated pom.xml).

Done in commit b26441deff96a7f9ca565737a8d6f240a93d0e75.

eclipse-qvt-oml-bot commented 5 days ago

Feb 16, 2021 04:30

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176315

eclipse-qvt-oml-bot commented 5 days ago

Feb 16, 2021 04:30

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176316

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Feb 16, 2021 04:44

(In reply to Ed Willink from comment #136)

Then we are good to fast merge to master, after the additional releng commit

This one was already reviewed.

Due to authentication problem with my new e-mail address, I had to recreate branch cgerking/472482 which is now based on master: https://git.eclipse.org/c/mmt/org.eclipse.qvto.git/log/?h=cgerking/472482

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Feb 17, 2021 05:50

(In reply to Christopher Gerking from comment #143)

(In reply to Ed Willink from comment #136)

Then we are good to fast merge to master, after the additional releng commit This one was already reviewed.

I'm confused. The rebased origin/cgerking/472482 seems to involve completely different classes to those that I previously looked at in origin/ewillink/472482 and for which I provided an extra commit.

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Feb 17, 2021 13:10

(In reply to Ed Willink from comment #144)

I'm confused. The rebased origin/cgerking/472482 seems to involve completely different classes to those that I previously looked at in origin/ewillink/472482 and for which I provided an extra commit.

The classes are certainly not completely different, but I condensed all changes into two commits (one fix, one test). So perhaps some premature changes are no longer visible because they were reverted in the end.

Which extra commit are you referring to, the classpath entries that you added in commit c0bf7ae2ffed4fff56e97e0e78836bef6e1716e1? They are part of the test commit, see https://git.eclipse.org/c/mmt/org.eclipse.qvto.git/commit/?h=cgerking/472482&id=66e8aab03cb7ebf10ed4a80a32935f2fccd288e8

eclipse-qvt-oml-bot commented 5 days ago

Feb 18, 2021 00:57

Gerrit change https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176316 was merged to [master].\ Commit: http://git.eclipse.org/c/mmt/org.eclipse.qvto.git/commit/?id=66e8aab03cb7ebf10ed4a80a32935f2fccd288e8

eclipse-qvt-oml-bot commented 5 days ago

Feb 18, 2021 00:57

Gerrit change https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176315 was merged to [master].\ Commit: http://git.eclipse.org/c/mmt/org.eclipse.qvto.git/commit/?id=db5b0c810fd438096945ee3726e92913461541d9

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Feb 18, 2021 01:04

(In reply to Christopher Gerking from comment #145)

(In reply to Ed Willink from comment #144)

I'm confused. The rebased origin/cgerking/472482 seems to involve completely

It was my stale branch with the no-class-file-commit that confused me.

Build passes. Pushed to master for M3.

(The other four branches now need rebasing on master again without auto-merging.). For simple progress it's trivial. For overlapping changes such as add bugNNNNNN versus add bugYYYYYY a manual merge may be necessary, but at least it will be right. I don't find the Merge Tool uniformly helpful; sometimes it's confusing. Just agree to maege then from the staging view open each conflicting file in turn. The JDT editor gives you nice error areas where you can see the two variants that you need to reconcile.)

eclipse-qvt-oml-bot commented 5 days ago

By Ed Willink on Feb 18, 2021 13:39

Pushed to master for 3.10.3M3

eclipse-qvt-oml-bot commented 5 days ago

By Christopher Gerking on Feb 19, 2021 08:16

Are you sure that all the new branches test are actually executed?\ I'm facing local problems because the test case for this bug is not correctly teared down, impeding some of the subsequent parser tests.

Pushed a fix to cgerking/472482 which does both: it tears down the test and also prevents the problem by adding an additional check for null.

eclipse-qvto / org.eclipse.qvto

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

Description