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

[Rob Stryker (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBIDE-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12482092#action_12482092 ] 

Rob Stryker 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.

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. 


>> 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,

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 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.

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. 

>> the issue is that the ESB module factory doesn't act like WTP J2EE module, 

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. 

>> I just refactored the ESB module factory base on a WTP module delegate: J2EEFlexProjDeployable, 

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. 

>> so currently, the ESB module factory follows the standard way of using Virtual component.
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. 

>> anyway, the new ESB module delegate also extends from JBTProjectModuleDelegate and doesn't overwrite any method except the "members()".

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. 

> ESB Projects does not respect WTP module dependency rules
> ---------------------------------------------------------
>
>                 Key: JBIDE-4320
>                 URL: https://jira.jboss.org/jira/browse/JBIDE-4320
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: esb
>    Affects Versions: 3.0.0.GA, 3.0.1.GA
>         Environment: Windows XP, Eclipse Ganymede 3.4.2 (M20090211-1700)
>            Reporter: Vincent Girard-Reydet
>            Assignee: Rob Stryker
>            Priority: Blocker
>             Fix For: 3.1.0.M3
>
>         Attachments: JBIDE-4320a.patch
>
>
> 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.

-- 
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