[ https://issues.jboss.org/browse/JBDS-2500?page=com.atlassian.jira.plugin.... ] Rob Stryker commented on JBDS-2500: ----------------------------------- We've disabled that because practically it has no effect at all on the server. JBoss doesn't use the working directory at all, as far as I understand. If you look at this link, https://docs.jboss.org/author/display/AS71/General+configuration+concepts you can see that the user's working directory is only used by a variable called user.dir, but that's not used very much internally by jboss at all... it is merely provided for users to use. There's no deployment scanners that care about the working directory that jboss is started from, and changing the working directory will have almost no effect (unless you have modified your standalone.xml yourself to USE that user.dir variable in some way). Assuming you mean a remote server, I don't see any way this could be done. Either the local server would need to pull from the remote, or the remote would need to push to the local. Either way seems too expensive in discovering which files have changed, and would probably require a daemon of some sort checking it and initiating or receiving the push or pull. For a local server, though, I also don't see what benefit it would bring. You clearly won't be modifying .class files or anything by hand, so I must assume you'd be modifying xml, html, etc files. But if this is the case, you should just be modifying them in eclipse and having the tools publish it to the server. I think it COULD be possible, but I would probably need to make a new action with a custom deployment constant. Rather than a 'full' or 'incremental' publish I could make a 'two-way-synch' publish, which would treat the newest file as the correct one. But this would probably require a lot of api changes and might not truly be possible. Can you add some more information about how you see something like this working? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira