Problem deleting _library_dependencies dir on cleanup

[scottkurz]

I'm running this via an Eclipse plugin, in Windows.

�[36m2024-11-13T09:31:47.431813100�[0m�[35m	[INFO]	�[0mCleaning up library dependency directory: C:\git\apps\mmmodresorts\_library_dependencies
�[36m2024-11-13T09:31:47.444179100�[0m�[31m	[ERROR]	�[0mError deleting library dependency directory: C:\git\apps\mmmodresorts\_library_dependencies

I'm wondering, instead of trying to fix the permission issue... might it be better to generate this into target (for a Maven project), which is already in .gitignore and will already get cleaned ?

Another idea might be to add these in the output directory, which also, potentially might be outside of the original project/input directory.

[rahlk]

Thanks @scottkurz, we’re working on a possible fix for this issue.

[cherylking]

@rahlk Please keep us updated on the progress. Would like to have a fix within a few days.

[rahlk]

Hi @cherylking, this will be a significantly involved fix from our end. Putting it in the target directory will mean that the dependencies may arbitrarily get removed via clean command (and probably be different for gradle).

We are looking in to better ways of doing like (like using the .m2 folder, or other such alternatives).

We'll keep you posted.

[scottkurz]

I spent a bit of time trying to debug this on Windows....

I suspect this is a case where there's some open "handle" to one or more of the dependency JARs preventing them from each being deleted individually.

I ran this with the 1.0.7-dev branch with the app project: https://github.com/IBM/sample-app-mod in the Eclipse debugger

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8001 -jar "codeanalyzer.jar" -i "C:\sample-app-mod" -f "C:\sample-app-mod" -o "C:\output" -a 2

If I set a breakpoint in BuildProject.cleanLibraryDependencies(), I can see that the two dependency JARs:

• was_public-9.0.0
• javaee-api-7.0

cannot be deleted via Windows Explorer. I get a "File In Use" error dialog and a message that the file is open in the JVM process (screenshot below).

Interestingly, some of the other dependency JARs can be deleted. What do these two have in common? They do happen to both be Maven "provided"-scoped dependencies. Is this significant? Not sure.

The problem seemed to persist when I changed the last parm val from 2 to 1, i.e. ..... -a 2 to .... -a 1.

And ultimately, to complete the picture, the reason the dependency dir cannot be deleted, then, is the fact that its contents are not empty.