My guess is something is holding a lock on your HelloWorld.class.
Any chance you got some app running that would lock you class files ?
yes, but I do not know which service holds that lock.
I am using maven and jboss tools and when running jboss-maven-plugin with jboss:deploy (deploy to jmx instead of hard-deploy),
then the behaviour should be the same as if jboss tools hot-deploys the war. Am I right?
But when I change the source-code then the "Error renaming"-problem occurs. IfI do a manual maven jboss:deploy, it will work.
we do not deploy via JMX - we simply use JMX to notify jboss about the deployment (much faster, but only of course when it works
Can you manually delete the offending .class file ? Just to check if there actually is a lock or there is some other error.
Okay I deleted that file and make a new restart. Now, I can hot-deploy (and it is really fast:):
I can edit a source code and see that the *.class of the exploded war in deploy-directory is changed properly. So my java-classes are synchronized by RF-Tools.
However, when I explore the exploded war archive,
I find out that it does NOT copied all files of my origin project-folder: xhtml-files, web.xml. libs are not deployed. What is wrong?
I have not compiled, packaged and distributed the war with maven,
I only go under "Add and Remove.." and added my project which should be monitored by RF-Tools.
But RF-Tools does not hot-deploy all files (xhtml, lib, web.xml is missing in my hot-deploy-directory) - it only hot-deploys java-sources.
What version of jboss tools are you using ?
If latest please open jira on this with details and we'll investigate.
It seems as if you're using a mix of maven commands and wtp publishing. When you click the 'publish' icon inside the servers view, this will do what is called an "Incremental Publish". This means it will only publish whatever files have changed in the workspace since the last publish event. If you right-click on your module in the servers view, however, you can click "FULL PUBLISH" to republish the entire module.
So, if you do a full publish, you wil note all resources should now be synchronized and all files should have been deployed. All files should have a timestamp of t at that point. If you then wait 1 minute, modify a java file, save it, and use the publish icon or incremental publish buttons, you will note in the deploy folder that *ONLY* your .class file has changed its timestamp, and all other resources have the previous timestamp.
If you then go to the deploy folder and delete all files for this deployment, return to your eclipse workspace, modify a file or two, and click publish again (incremental), you will see that *only* the two changed files have been published. This is in fact a user-error. If the user manually deletes a publish folder and its contents outside of eclipse, there is no way for the tooling to know or expect this. This includes if the user uses some other tool such as maven which may have deleted the module's deploy folder as well. In these cases, the tooling will again try to simply do an incremental publish of only the changed files.
I'll need to look into your first problem, with the error renaming, but it seems like either there was a file lock (which would be a jboss-as problem) or the destination folder did not exist. I really don't think the folder not existing is a problem, however, because for our local copy handler, we have the following code:
if (!safeRename(tempFile, file, 10))
with safeRename doing the following:
File dir = to.getParentFile();
if (dir != null && !dir.exists())
So if this *is* the problem, that hte folder does not exist, it is a problem with your filesystems permissions, such that jbosstools cannot create these directories without the OS complaining. If that's the case, there doesn't seem to be much I can do. The javadoc for java.io.File.mkdirs() is the following:
* Creates the directory named by this abstract pathname, including any
* necessary but nonexistent parent directories. Note that if this
* operation fails it may have succeeded in creating some of the necessary
* parent directories.
* @return <code>true</code> if and only if the directory was created,
* along with all necessary parent directories; <code>false</code>
The best I can do here is capture the return value and try to return a slightly more relevant error message, but really the java.io.File api does not tell me WHY the mkdirs failed, or why the renameTo failed... so really there's nothing I can change the error message to to make it more clear than it already is. All *I* can know is that the rename / mkdirs failed... but the API does not allow me to know why.
Hopefully the first half of this post gives you some hint as to what is going on in your current situation, but for the mkdirs / renameto error, there's not much more I can do aside from ask you to look into permissions in the folders.
Another possible suggestion as to why the initial renameTo failed is if the maven tooling was creating archive deployments (instead of unzipped deployments) then C:\jboss-188.8.131.5201110-CR1\server\default\deploy\mysite.war is actually a zip file, and I clearly cannot copy a .class file into what the tooling is expecting is an exploded folder, but which actually has a zip file somewhere in the path.
Rob, thank you for your help.
Now it works:
I have done it that way:
1. I removed the maven-dependency-management of the project.
2. I removed the JSF-Capabilities of the project.
3. Then, I added maven-dependency-management of the project again.
4. And after all, I added the JSF-Capabilities of the project again.
And now all files are hot-deployed (automatically).
Besides, sporadically the jsf-capabilites are removed from the project without my will. I do not know why. Maybe Maven overwrites some project-settings which are needed by jsf-tools.
1) Where is "maven-dependency-management" coming from ?! are you using m2eclipse, mvn eclipse:eclipse or something else ?
2) if jsf capabilities are being removed without you doing anything then we are back to #1 ...what are you actually using to do this maven stuff ?
removing jsf capabilities is like removing all metadata about the project and jboss tools nor Eclipse WTP will be able to do anything with your project.
1) yes, I am using m2eclipse: "maven-dependency-management" is then integrated within the menu.
2) jsf capabilities was being removed after closing eclipse - but I do not know, why it is removed (I do not removed it manually).
When I started eclipse again, then the "add jsf capabilies?"-dialog occurs. I say yes, then all works.
2) Please install the m2eclipse WTP extras and jboss tools maven integration which will make sure it doesn't remove these things behind your back.
Nature org.jboss.tools.jsf.jsfnature may be removed automatically, with an error message to the log, if the model fails to load necessary data from project settings and there is no way to correct it. That usually means that something is wrong with settings of the project. If there is no message in the log like "Project * has corrupted nature: org.jboss.tools.jsf.jsfnature", but the nature was removed; that must have been done by a third party.
I installed the m2eclipse WTP extras and jboss tools maven integration plugin.