Reproducer for #33 Maven mojo change ignored

[ppalaga]

No description provided.

[ppalaga]

Strange that it passed on Mac.

[ppalaga]

@gnodet would you mind checking locally what is going on Mac? Is it really passing or the Mac CI is a false positive?

[gnodet]

@gnodet would you mind checking locally what is going on Mac? Is it really passing or the Mac CI is a false positive?

The test succeeds on my Macbook Pro...

[ppalaga]

The test succeeds on my Macbook Pro...

Thanks for checking! That's even stranger.

I have a PoC how to address this, at least on Linux. The idea is to remove all realms from the classworld that contain -SNAPSHOT URLs or which are under the basedir of the currently built project. I am also throwing the plexus container and all its dependents away after each build. Let me polish it a bit and amend this PR.

[ppalaga]

This is the main idea of the fix: we do not re-use the container (an all its dependents) across mvnd executions and we remove -SNAPSHOTS and in-source-tree jars from the class world.

The fact that we do not ditch the whole classworld is intended to keep as many classes as possible loaded and warm. We throw away only those class loaders that are known to be mutable. We still assume that the rest of the jars in the local Maven repo is immutable. #26 is an example of a situation where it does not hold and we should have some checks in place to prevent it.

I was pondering whether we could keep parts of the plexus container across mvnd executions too (to speedup the repeated builds). It seems quite risky. I am not sure we would be able to reliably remove only all the stale beans and their dependents. The beans can be linked in uncontrollable ways. I have not (quickly) found a way how to do that. So to be safe I chose to throw the whole Plexus container.

[gnodet]

Isn't that supposed to be done by the CliPluginRealmCache already ?

[ppalaga]

Actually yes, see #37

BTW, I have not see CliPluginRealmCache to be picked. I had to add an explicit binding https://github.com/mvndaemon/mvnd/pull/37/files#diff-085c748cd75673826a31723d0840b82eR486

[ppalaga]

Oh, I have a theory why the test is passing on Mac: BasicFileAttributes.fileKey() probably works differently on Mac than on Linux and windows. It looks fixing the Plugin Cache implementation would be less intrusive than 51f06c7 https://github.com/mvndaemon/mvnd/blob/master/daemon/src/main/java/org/jboss/fuse/mvnd/plugin/CliPluginRealmCache.java#L166

[ppalaga]

On Mac, BasicFileAttributes.fileKey() seems to change when the content of the file changes https://stackoverflow.com/questions/20676800/inode-value-changed-when-editing-the-file-on-mac-os-x
That's not the case on Linux, where it is constant (device ID and inode).
I see reports that BasicFileAttributes.fileKey() returns null on Windows https://stackoverflow.com/questions/22548076/java-unique-file-id-filekey-path-filekey-ok-filekey-path-possible#comment34317450_22548076

[gnodet]

Oh, I have a theory why the test is passing on Mac: BasicFileAttributes.fileKey() probably works differently on Mac than on Linux and windows. It looks fixing the Plugin Cache implementation would be less intrusive than 51f06c7 https://github.com/mvndaemon/mvnd/blob/master/daemon/src/main/java/org/jboss/fuse/mvnd/plugin/CliPluginRealmCache.java#L166

Ah, that would explain why it works on Mac, it's because that's the OS I developped the CliPluginRealmCache on...

[ppalaga]

Replaced by #37