[ https://jira.jboss.org/jira/browse/JBIDE-5840?page=com.atlassian.jira.plu... ] Dan Florian commented on JBIDE-5840: ------------------------------------ First a bit more background/clarification about ModeShape and the Eclipse plugin: Each ModeShape server appearing in the Server View represents a ModeShape REST web application running inside a container (like JBoss); the container is hosting the ModeShape repository/server. The ModeShape Eclipse plugin uses the REST application to upload/publish files to, and remove/unpublish files from, the ModeShape repository. The plugin has no control of starting or stopping the REST application, the ModeShape repository, or the container, and there is no expectation that the user would be able to or want to perform such administration. Right now the Server View shows not only which ModeShape instances are available, but also which repositories and workspaces are found for each ModeShape instance. The intention in the future is to show the resources that have been published to each workspace, similar to the browser views provided by CVS/SVN plugins. The ModeShape console gives status on the publishing operations and also creates hyperlinks that allow the user to open files involved in publishing operations in an Eclipse editor. The motivation for creating a ModeShape Console View came from the other dedicated Console Views (i.e., SVN, CVS, Maven, etc.). Now to address your comments: I agree that when integrating the ModeShape plugin into JBT we should not create any redundant or duplicate functionality. Since I'm not familiar with the WTP Server View I cannot say if it is appropriate or not. The ModeShape plugin was developed to have an extremely small footprint and having a dependency to WTP would obviously change that. Right now, the plugin can just as easily run outside of JBT. One consideration in this regard is its use within Teiid Designer, which also can run outside of JBT. The server view provided not only doesn't seem redundant, but also is following the same precedents set by libraries such as SVN/CVS/Git tooling. The same goes for how the console is handled, and even the resource filtering. The point of the filtering is not to filter items from the view, which is the only functionality I know of within Eclipse, but to prevent artifacts from being published to the ModeShape repository, again in a similar manner established by existing Eclipse tools such as SVN/CVS/etc. Regarding the deployment redundancy, please help me understand what facilities already exist that we might leverage. Thanks for looking at the docs and your comments. If you need some help with getting the ModeShape Eclipse plugin working let me know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-5840?page=com.atlassian.jira.plu... ] John Verhaeg commented on JBIDE-5840: ------------------------------------- The association with a ModeShape server is determined on a file-by-file basis, so is once again more similar to the SVN paradigm. In fact, each file can be associated with multiple ModeShape servers. However, publishing to ModeShape is not necessarily a team-related activity either, and is more about dissecting the metadata within models to analyze relationships, report on lineage, etc. Given this understanding, I think the WTP issue is moot. Barry and I are both committers in the ModeShape project, but no one from the ModeShape project (including us) will be at EclipseCon that I'm aware. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira