[jbosstools-issues] [JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ] Darryl Miles commented on JBIDE-18862: -------------------------------------- I've never said the problem is easy to solve. :) My own view has always been (since last 7+ years) have a very efficient remotable API. So efficient that is can work in local mode too without any noticeable performance difference. This might mean the AS has code to provide a file/dir manifest of the deployment location, with filenames/fileLength/lastModifiedTimestamp/hashChecksum. The IDE would push delta changes only. The AS would positively acknowledge actions that are going on. The Eclipse IDE would maintain one long running socket connection to the server. You can push file changes down the socket (and have the AS buffer them) even if the AS can not update the files in the deployment area yet because something conflicting is starting/stopping. Since the AS is in control of all file changes to the deployment area itself, it could maintain the current view, transactional updates to that fileset view, and because it was aware of what has changed it can optimize the functions on the AS about what it needs to do to refresh/restart sub-deployments. It also doesn't have to maintain a 1:1 file-system view to logical deployment view, in the case that a file or directory can not be deleted (due to file locking), it could just re-allocate/re-direct the logical deployment view to some temporary location. Even a clean and full publish might still push delta changes, because the AS doesn't have to remove files (it has previously been sent), if it has a hash match for a JAR it has been previous sent it can simply re-use the data. The IDE pushes a complete file-set view to the AS (with filelength/file-content-hashes), the AS comes back with information about which resources it has hits for, providing a unique reference. The IDE can selectively decide which items to push and which items to let the AS resolve from its cache. I've never bought the argument that we must optimize for local, the issue is that remote is too in-efficient to use for local. -- This message was sent by Atlassian JIRA (v6.3.11#6341)