[ https://jira.jboss.org/jira/browse/JBIDE-4320?page=com.atlassian.jira.plu... ] Vincent Girard-Reydet updated JBIDE-4320: ----------------------------------------- Environment: Windows XP, Eclipse Ganymede 3.4.2 (M20090211-1700) (was: Windows XP, Eclipse Ganymede 3.4.2) Affects Version/s: 3.0.1.GA Description: It is not possible to include modules as dependencies of a JBossESB module. The expected behaviour is that ESB modules should behave as EAR modules. For example, if I want to mimick the webservice_consumer quickstart structure using WTP projects, I expect to end-up with 2 projects : - an ESB project - a Dynamic Web Module project, set as dependency of the ESB project I expect to have the .war archive copied at the root of the ESB archive, but: 1. it is not possible to configure dependencies with graphical tools (in the project properties) 2. Manually editing the org.eclipse.wst.common.component file to add the dependency solve nothing to the problem. The same applies for EJB/EJB3 projects (to mimick the helloworld_service quickstart), JPA projects and Utility projects. was: Description of the problem ***************************** It is not possible to include modules as dependencies of a JBossESB module. The expected behaviour is that ESB modules should behave as EAR modules. For example, if I want to mimick the webservice_consumer quickstart structure using WTP projects, I expect to end-up with 2 projects : - an ESB project - a Dynamic Web Module project, set as dependency of the ESB project The expected behaviour is to have the .war archive copied at the root of the ESB archive. The same applies for EJB/EJB3 projects (to mimick the helloworld_service quickstart), JPA projects and Utility projects. -- 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-4320?page=com.atlassian.jira.plu... ] Vincent Girard-Reydet commented on JBIDE-4320: ---------------------------------------------- I am not talking of deploying .esb modules as War's, but of deploying War's as side artifacts of a .esb module. If you look at the "webservice_consumer" quickstart, you will find that the output ESB has the following structure : META-INF/ org/jboss/soa/esb/samples/quickstart/webservice_consumer1 Quickstart_webservice_consumer1.war <----- THIS IS THE FILE OF INTEREST jbmq-queue-service.xml As you can see the War is packaged *inside* the .esb module, which permits to have a single unit of deployment containing the ESB actions and its dependencies. This is what I'm trying to reproduce in Eclipse, but to do so I would need to specify that a Dynamic Web module is a dependency of the ESB module, and also specify where to map the War in the runtime structure of the ESB module. Same idea for EJB modules (package their Jar in the ESB archive). Does this make more sense to you now ? Am I trying to do something you would not recommend ? -- 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-4320?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4320: --------------------------------------- Assignee: Denny Xu Priority: Blocker (was: Major) Denny - I'm not sure what the recommended practices are with respect to .esb deployment with respect to .war inside .esb but supporting deployment dependencies for utility jar is a must have. -- 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-4320?page=com.atlassian.jira.plu... ] Denny Xu commented on JBIDE-4320: --------------------------------- from dependency perspective, I don't think esb module would depend on a War, for the "webservice_consumer" quickstart, the ESB just need a Web Service and Web service can be anywhere, so the War file can be deployed outside the .esb module. for utility jar, it should be doable, I will look into it. -- 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-4320?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4320: --------------------------------------- Fix Version/s: 3.0.2.GA 3.1.0.M2 Any movement on this issue ? -- 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-4320?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4320: --------------------------------------- Fix Version/s: 3.1.0.M3 (was: 3.1.0.M2) (was: 3.0.2.GA) So we won't be able to add jar dependencies into ESB projects in 3.0.x nor 3.1 M2, correct ? Targeting 3.1.M3 then instead. -- 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-4320?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-4320: ------------------------------------ Working on it, trying to make the new page contributable upstream without hindering everything -- 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-4320?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-4320: ------------------------------------ We can get it in. I've committed the super classes and recommitted the properties page which won't make it into WTP just yet so that we can beat on it and have use cases for the upstream version when it comes around. I've got a patch for the ESB project's installation delegate and module factories, but I am *NOT SURE* I like it at all. It's exactly what Max and I discussed, specifically making new ESB projects have a version of 2.0 set as a persistant property on the IProject. However there's a huge problem with this. The user will have no way to make use of new features on his old project. What was discussed earlier was: 1) New ESB projects get a version of 2.0 2) The new ESB Module factory extends from the one in AS Tools 3) The ESB module factory will check this persistant property 4) If the value is 2.0 or greater, it will use the superclass (clean, beautiful) way of returning members and child modules 5) If the value is not set or is under 2.0, the user will use the old way (current way) of collecting resources, by checking for the one or two hard-coded places. What this means is that if a user with an old ESB project finds their way into either the component.xml file or the properties page, they can change everything all they want, but the output of the esb will never change because their project is a pre-2.0 ESB project and so it will always use the legacy method of collecting resources. *I THINK THIS IS BAD* The only way I can think of getting around this is to have the ESB project extend the properties page and, when a < 2.0 project is changing features, automatically convert it to a 2.0 project and make the mappings 100% literal. The issue here is of course the wb-resource mappings. In 2.0 projects if the user maps /src to /, then .java files will appear in the root of the archive. THIS IS INTENTIONAL. However in pre-2.0 projects, this did not happen and the src folder was translated to its output folder and members were found that way. Anyway, perhaps a user of a pre-2.0 ESB project decides they want to add 3 new folders, esbcontent2, esbcontent3, esbcontent4, and assigns them all different output folders. Then they go into the properties page and add these mappings in. None of these mappings will show up in the output file because the project is STILL a pre-2.0 project and so it's not looking for these additional mappings. Which means I don't like this versioned solution at all. I personally believe there should be no 2.0 project and, when a user upgrades his space, he should just go migrate the mapping from it's previous src to / mapping, to the new bin to / mapping. If you lock the previous users up in a pre-2.0 project they will not get to use the new features, and I don't think that's the right way to do things. -- 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-4320?page=com.atlassian.jira.plu... ] Denny Xu commented on JBIDE-4320: --------------------------------- Just looked through the patch, there are some problem in it: 1. we cannot use PersistentProperty of project to persist any property, this would prevent sharing projects between different workspaces. 2. we cannot change the resource mappings to below: <wb-resource deploy-path="/" source-path="/esbcontent"/> <wb-resource deploy-path="/" source-path="/build/classes"/> the folder "/build/classes" is java project output folder and the name and the path are changeable, so if the user change the project default output folder, how do you handle it, just test this case, the patch doesn't work. I don't think the old resource mapping has any problem, it's just like how WTP Web projects use resource mappings, the reason why WTP does so is because of handling the case that the default java project output folder is changed after the project was created. the issue is that the ESB module factory doesn't act like WTP J2EE module, I just refactored the ESB module factory base on a WTP module delegate: J2EEFlexProjDeployable, so currently, the ESB module factory follows the standard way of using Virtual component. anyway, the new ESB module delegate also extends from JBTProjectModuleDelegate and doesn't overwrite any method except the "members()". 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

[ 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

[ https://jira.jboss.org/jira/browse/JBIDE-4320?page=com.atlassian.jira.plu... ] Rob Stryker updated JBIDE-4320: ------------------------------- Attachment: JBIDE-4320b.patch better patch (4320b.patch) that fixes the persistant issue (probably) warning: it's untested. please test it first. -- 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-4320?page=com.atlassian.jira.plu... ] Rob Stryker reassigned JBIDE-4320: ---------------------------------- Assignee: Denny Xu (was: Rob Stryker) Denny: I think we're at the point now where we should apply *this* patch immediately and any new specific issues that are present should be in a new JIRA marking specifically what changes need to be made. I believe the additional code I've added to as.wtp.core has enough functionality to solve most use cases you present. Can we do that? -- 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-4320?page=com.atlassian.jira.plu... ] Denny Xu commented on JBIDE-4320: --------------------------------- Rob, I know you have done some changes on modulefactories, virtualComponent and project structure at least for ESB project and BPEL project, just would like to confirm that if we apply your new changes, if the jira JBIDE-4807 is still a problem for deployment? -- 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-4320?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-4320: ------------------------------------ Discussion on BPEL deployment should get its own JIRA =] Please create one -- 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-4320?page=com.atlassian.jira.plu... ] Denny Xu commented on JBIDE-4320: --------------------------------- this code is a workaround for a wtp issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=257470 and JBIDE-3333 That parts of code should be changed to : VirtualComponent c = ComponentCore.createComponent(project); if(c==null) { c = ComponentCore.createComponent(project, false); } forgot why did not change, I will replace the code. -- 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-4320?page=com.atlassian.jira.plu... ] Max Rydahl Andersen commented on JBIDE-4320: -------------------------------------------- For future reference, the bug description at Eclipse describes this issue and the if statement is there so the code would work on all versions of WTP 3.0.x. Now we (luckily) are on WTP 3.1 it is not needed anymore. -- 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