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