[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-4320) ESB Projects does not respect WTP module dependency rules

[ https://jira.jboss.org/jira/browse/JBIDE-4320?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-4320: ------------------------------------ Yes we can. The user can still share between workspaces. If they take a project which does nto have this property (an old project) and use it in an old workspace, it will work the same as it used to. If they put it in the new workspace, it will *still* work the same as it used to. This is because the project does nto have this property. If you take a NEW project (which ahs the property) and use it in the new workspace, it will work as intended. If you take this new project and put it in the old workspace, that is not an intended use case. Many times in eclipse things created in new workspaces will not work with old workspaces, however all old things must work in new ones. This is not a bug and is intentional. Not everything will work right away. The problem is WTP has many many use cases but they are all very restrictive and coded poorly. We can pretend to be WTP, but since we won't be one of the approved JEE module types we'll never be fully supported by their classes. Basically we will need to identify the missing functionality (refactors that you mention) and either duplicate that functionality in our code *or* get the upstream code to be more liberal and work on more types of projects (like ours). I've asked WTP on conference calls why they did it that way and no one really remembers. You are guessing or assuming. But they all mostly agree with me that everything needs to be simpler and we will move in that direction. Not all functionality will work right away and we will need to either duplicate it or fix it in WTP. But that does not mean the patch is broken. It works as intended. WTP also tends to set up workspace listeners and respond to these changes by then modifying the component.xml properly. If you were to create a dynamic web project, and add a second source folder, you'd see a second mapping was added to the component.xml file. Exactly. This is by design. WTP J2EE modules are cluttered and were programmed when requirements were changing every month. There is a lot of poor design there that needs to be fixed. Separating ourself from the J2EE module will allow us to identify where WTP code is bad, and then fix it either in WTP or in our code. We do not pretend to be a J2EE project because, honestly, we are *not* a j2ee project. You should not do this. To extend this class is to extend a class that is very complicated for no reason. These classes need to be cleaned up and made simpler and you should not extend them for now. They are meant for J2EE and nothing else. They were not designed in a fashion to be extended. They were not meant to be extended, and extending them is inheriting a host of problems that we'd rather avoid. There is no standard way of using virtual component. The way WTP does it is to add on all sorts of unnecessary things and it is very ugly and confusing. Yes this is on purpose. If ESB was a new project and not 8 months old, it would not override ANY of JBTProjectModuleDelegate. The goal here was to make a very very clean implementation of a virtual component class for use by us, and a very very clean implementation of a deployable module delegate, for use by us. The goal was to remove the 100 confusing ways that the J2EE / JEE deployables make things confusing. The goal was to not be confusing like EarVirtualComponent. The goal was for our virtual component to ONLY show what's available in the component.xml file. We also will now expose a UI for the user to modify this appropriately, adding / changing the resource mappings or adding references to other projects. So while these things might not change automatically on a refactor, the user can still go to this property page and fix it himself. Yes, the user will want this done automatically, and we should try to do that for them. But the answer is NOT to pretend to be a J2EEFlexProjDeployable and deal with very confusing logic. The answer is to make new clean classes and then either add the functionality new ourself or make WTP fix their listeners to be open to other module types. so the new ESB module factory can work with old ESB project and also support any resource mappings that you expect. -- 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