Community
Participate
Working Groups
There are several issues related to resource location mapping that indicate a different approach is needed. (see: bug 149451 bug 209820 bug 234383 bug 251323 bug 309030) We propose an extension point to provide three things needed with regards to resource location: - Determine where in a project a resource can exist - Determine a default location for generated resources - Resolve a resource location from a deployment path Dali would provide extensions for the following cases: - module faceted project (in which case, we would use the existing flexible project structure provided by wtp) - web module faceted project (a subset of the above) - plugin project - plugin web project? - standard java project - others may be necessary Extensions for other project types (maven, for one) would have to be provided by external sources. Please see: http://wiki.eclipse.org/Dali_Project/FeatureDocs/RemovingModuleFacetDependence#ResourceLocator_interface for more information. Please provide feedback here.
This sounds like something other plugins in WTP could use too - but I guess we need to start somewhere ;)
I had briefly considered that, but I couldn't think of any other functionality that has the sort of ... "interconnectedness" of files that JPA has, and yet doesn't depend on Java EE file structure. Do you know of any?
spring, seam, jboss bpel, jboss esb, CDI, ...basically any framework - but yes JPA is "harder" :)
(In reply to comment #2) > I had briefly considered that, but I couldn't think of any other functionality > that has the sort of ... "interconnectedness" of files that JPA has, and yet > doesn't depend on Java EE file structure. Do you know of any? btw. do you think it is enough to just have resource paths, wouldn't the location and name actually be dependent on what resource you are actually looking for ? i.e. is persistence.xml might be named something different in src than in the target destination, i.e. persistence-dev.xml, persistence-test.xml or persistence.xml is in a resource directory where as orm.xml files are actually on the normal java source path ? (since its not dependent on deployment environment)
(In reply to comment #4) I'm not sure I'm following what you're saying here. I imagine that a resource location implementation *could* resolve a deployment path of "META-INF/orm.xml" to a resource path of "resources/orm-dev.xml" if that's what was appropriate.
I have added the resourceLocators extension point and the ResourceLocator interface to head for M1 and have added implementations for: - simple java projects - module projects (EJB, utility, etc.) - web module projects (a special case of the above) - plug-in projects This framework has been connected to all existing functionality of this nature. For all further issues, please open new bugs/enhancement requests.
Could it be possible to backport this fix to Dali 2.3.x (which corresponds to WTP 3.2.5)? An adopter product is seeing this problem in WTP 3.2.5. I'm willing to work on backporting this change (I actually started to work on a patch for this), but before continuing, I'd like to know if this change is acceptable in Dali 2.3.x.
(In reply to comment #7) > Could it be possible to backport this fix to Dali 2.3.x (which corresponds > to WTP 3.2.5)? > > An adopter product is seeing this problem in WTP 3.2.5. > > I'm willing to work on backporting this change (I actually started to work > on a patch for this), but before continuing, I'd like to know if this change > is acceptable in Dali 2.3.x. There are a lot of inherent problems associated with backporting this fix into a maintenance stream, including API changes, behavioral changes, and general risk associated with a change of this magnitude. All of that said, if this change was going to go into a non-publicly available patch build that would only be used by adopters specifically interested in this change, and those adopters accepted the risk associated with this change, then I suppose the Dali project could commit such a change to the patch stream. We would not be able to provide an in depth review for any patch, since this would be very time consuming, so would have to provide with a "use at your own risk" caveat. If you do wish to proceed, please open a new bug targeted to the 2.3.5P for the backport.
