search

bndtools / bnd

Bnd/Bndtools. Tooling to build OSGi bundles including Eclipse, Maven, and Gradle plugins.
https://bndtools.org
Other
532 stars 305 forks source link

[m2e] Workspace artifacts not refreshed on build #4117

Closed kriegfrj closed 4 years ago

kriegfrj commented 4 years ago

For some reason, when I run the tests in the junit5 project in osgi-test, even with the "reload bundles" option set, it appears that changes to bundles are not getting detected. Fortunately the junit5 test project is quite quick to start up so it's not too much of an issue to re-run the whole test suite from scratch, but in a bigger project with a longer startup time this would become an issue.

bjhargrave commented 4 years ago

@kriegfrj Can you tell the rest of us how you set this up for continuous testing? :-)

kriegfrj commented 4 years ago

This will start the OSGi framework with the tester running. Like the standard Eclipse launcher it will listen for changes to bundles and the bndrun, and redeploy them if they've changed. Because the tester listens for test bundles becoming active, a redeploy will usually trigger a rerun of the tests.

This didn't work for me the last time i tried it in osgi-test. It does work in bndtools.core.test (though Eclipse doesn't like it when bndtools.core is restarted in a running workbench).

kriegfrj commented 4 years ago

Ok, I figured out precisely what the problem is here.

The Bndtools launch delegate base class (used by both the standard launcher and the JUnit launcher) sets up a ResourceListener to listen for changes to the relevant files in the Eclipse workspace:

https://github.com/bndtools/bnd/blob/e45586638070a8d7833e4bb73cfd13e06652c7cd/bndtools.core/src/bndtools/launch/AbstractOSGiLaunchDelegate.java#L426-L488

The set of files it listens for changes to are all the bundles in -runbundles, plus the bnd(run) file itself that was used to launch the framework.

The problem is that when Bndtools m2e rebuilds the bundles, it must do so direct on the filesystem and outside of the normal Eclipse workspace resource handling API. The result is that Eclipse is not aware of the changes, which means that it doesn't issue a and the workspace doesn't actually notice the resource change, and so doesn't fire off the resource change listeners.

I figured this out because I went to delete one of the output artifacts as a test to see if it would get noticed, and Eclipsed warned me that it was out of sync with the filesystem. When I press F5 to refresh the Eclipse workspace's view of the artifact, the resource change listener got executed and the bundle got redeployed into the running system as per normal.

Note that this problem would not affect only continuous testing, but also live coding without the test launcher.

I think ideally what needs to happen is that m2e refreshes the Eclipse workspace when the artifacts are generated. I think that this is probably not really the responsibility of Bndtools m2e, but of the m2e connectors that are generating the actual output files (specifically in this case, the maven-jar-plugin I think). But maybe there is something that we can do (perhaps in conjunction with #4174).

kriegfrj commented 4 years ago

An alternative solution would be is if the launch delegate polled the filesystem directly instead of relying on Eclipse' resources API to notify of it of changes to runbundles.

gamerson commented 4 years ago

I believe the BndConfigurator does sometimes try to "refresh" the built files after the jar goal runs here: https://github.com/bndtools/bnd/blob/master/bndtools.m2e/src/bndtools/m2e/BndConfigurator.java#L192

Maybe you could set a breakpoint and see why this "refresh" isn't working for you.

On Mon, Jul 13, 2020 at 9:39 PM Fr Jeremy Krieg notifications@github.com wrote:

Ok, I figured out precisely what the problem is here.

The Bndtools launch delegate base class (used by both the standard launcher and the JUnit launcher) sets up a ResourceListener to listen for changes to the relevant files in the Eclipse workspace:

https://github.com/bndtools/bnd/blob/e45586638070a8d7833e4bb73cfd13e06652c7cd/bndtools.core/src/bndtools/launch/AbstractOSGiLaunchDelegate.java#L426-L488

The set of files it listens for changes to are all the bundles in -runbundles, plus the bnd(run) file itself that was used to launch the framework.

The problem is that when Bndtools m2e rebuilds the bundles, it must do so direct on the filesystem and outside of the normal Eclipse workspace resource handling API. The result is that Eclipse is not aware of the changes, which means that it doesn't issue a and the workspace doesn't actually notice the resource change, and so doesn't fire off the resource change listeners.

I figured this out because I went to delete one of the output artifacts as a test to see if it would get noticed, and Eclipsed warned me that it was out of sync with the filesystem. When I press F5 to refresh the Eclipse workspace's view of the artifact, the resource change listener got executed and the bundle got redeployed into the running system as per normal.

Note that this problem would not affect only continuous testing, but also live coding without the test launcher.

I think ideally what needs to happen is that m2e refreshes the Eclipse workspace when the artifacts are generated. I think that this is probably not really the responsibility of Bndtools m2e, but of the m2e connectors that are generating the actual output files (specifically in this case, the maven-jar-plugin I think).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bndtools/bnd/issues/4117#issuecomment-657931772, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAERKFK7L5IIXN6XVIKNAYLR3PAMNANCNFSM4NNVMMSQ .

-- Greg Amerson Liferay Developer Tools Liferay, Inc. www.liferay.com

gamerson commented 4 years ago

Hmm, i just looked at this, and the refresh isn't happening to the osgi-test jar because we are not refreshing the "target" folder, but rather we are refreshing only the "target/classes" folder. See here: https://github.com/bndtools/bnd/commit/be08830ab5552fe3736e7158ffcd64c6c438a1da Maybe @rotty3000 can shed some more light.