This is a common and long-standing bug on windows for wildfly and eap. Windows basically locks some files (usually .jar files) in the deployments folder for use. This makes it difficult (ie impossible) to do a publish that needs to overwrite that file on windows.
On the bright side, users rarely change their bundled libraries... well, at least compared to how often they change their own code.
The best workaround for this issue is to stop the server, right-click on the module, and do a full publish. Since the server is stopped, no process on the machine should have a lock on that file anymore, and it will be overwritten safely. Once the server is started again, odds are you'll only need incremental publishes for most changes in your workspace. These should be able to be published without error, since none of the files being changed are likely to be locked by the server.
I can't seem to locate the WFCore jira issue representing this long-standing bug, but I'll be sure to ask around and see if I can at least point you to proof that the bug is known to exist and it's not just your machine that hates you
Well no, it is not long standing bug, but rather expected behavior.
jar/class files are locked by classloader on any platform, but only Windows's NTFS file system honors them by not allowing modifications to them.
But when it comes to exploded deployments in most cases replacing jar file with newer version (rename/move) usually works as long as you properly invoke that operation, I say usually as it depends in what kind of state deployment is.
Yeah, as I understand it we simply do a temporaryNewFile.renameTo(existingFile), but that call is returning as unsuccessful due to the file lock. I guess I'll have to try to replicate and use File Leak Detector - to debug it, but it's not something I replicate often because I so rarely use the windows environment.
I have a case where the publish job can't rename a MANIFEST.MF file to it's final destination. What I am observing is that that the directory that is being deployed (<install>\standalone\deployments\Test.war in my case) has no owner and thus can't be changed. This is on Windows 10/Wildfly 10