| Restricting certain JPA facet versions for particular runtimes [message #618692] |
Mon, 18 January 2010 13:34  |
Eclipse User |
|
|
|
Hi, given that org.eclipse.jpt.core (dali 3.0) defines the following runtime extension below, it appears that all jpa facet versions will be available for choice when a user targets any runtime:
<extension point="org.eclipse.wst.common.project.facet.core.runtimes">
<supported>
<runtime-component any="true"/>
<facet id="jpt.jpa"/>
</supported>
Given that adopter extension point definitions listing specific jpa facet versions for particular runtimes will be overridden by the above definition, can this be removed? i.e. if a particular runtime version only supported JPA 1.0, the user will still be able to choose JPA 2.0
Is there a reason why org.eclipse.jpt.core needs to define this as opposed to particular runtime implementation plugins?
|
|
|
|
| Re: Restricting certain JPA facet versions for particular runtimes [message #618698 is a reply to message #618697] |
Tue, 19 January 2010 15:47  |
| Eclipse User |
|
|
|
Hi Paul, ok so let me outline the issues we are seeing:
1) When launching the JPA project creation wizard, for certain runtimes we want to restrict the choices of JPA facet versions (i.e. JPA 1.0 only as opposed to both JPA 1.0 and 2.0 since version X of a particular runtime Y might only support up to JPA 1.0, or no JPA at all, etc)
2) Similarly, once a project is created and the user goes to configure more facets via the project properties, given the runtime chosen, we want to control what JPA facet version choices are shown.
All of this filtering of facet version choices is taken care of by the facet framework in all the wizards and facet config UIs, and each server vendor implementation uses the org.eclipse.wst.common.project.facet.core.runtimes ext point to define what facet versions are supported in their impl plugins. i.e:
<supported>
<runtime-component
id="com.xxx.yyy.runtime"
version="2.0"/>
<facet
id="jpt.jpa"
version="1.0"/>
</supported>
This is similar to what is done for other facets like EJB's jst.ejb, etc.
But since the dali core plugin implements this ext point and allows *any* runtime to add *any* JPA facet version, the more restrictive declarations defined by the runtime vendors are overridden by the <runtime-component any="true"/> part.. and therefore the user can choose for example a JPA 2.0 facet level on a runtime that doesn't support JPA 2.0.
Perhaps there's a problem in the facet framework here in that for a particular runtime component it's configuration of facet choices/versions should override everything else.
I understand your point about a SEE5 capable server being able to support JPA w/o explicitly providing a JPA impl, but I'm trying to figure out how to restrict JPA facet version levels for certain runtimes if we choose to do so.
|
|
|
|
|
| Re: Restricting certain JPA facet versions for particular runtimes [message #618704 is a reply to message #618702] |
Wed, 20 January 2010 11:16 |
| Eclipse User |
|
|
|
So do you want to completely eliminate the possibility of users running, for instance, a web app with a third party JPA implementation, such as Hibernate or EclipseLink?
a) I'm not sure that's something you *should* be doing. But I guess that's up to you.
b) That's completely outside the scope of Dali. We *have* to have this, or else runtimes that don't provide JPA implementations will also have to say that they support JPA, just so users who *are* providing their own implementation can enable a JPA application on that runtime.
What this sounds like is a facets problem. There is a no difference in the facets world between "enablement" (*has* it) and "compatibility" (can *work* with it). An EJB 2.0 enabled runtime is also an EJB 2.0 compatible runtime. A Java 5 compatible runtime is also a Java 5 enabled runtime. But a JPA compatible runtime is not the same thing as a JPA enabled runtime. The way that facets work now, in order for us to support use cases, we have to treat all runtimes as JPA compatible (and if they're Java 5 compatible, they're JPA compatible) because the interpretation of the runtime spec is that facets define enablement. A web server would never specify that it supports the JPA facet, since it has no libraries for the JPA facet. But it is (potentially) compatible with the JPA facet.
If a runtime had two sets of facets: those that it provides, and those that it is compatible with, then both our problems would be solveable, but that is currently not the case.
Or alternatively, if a runtime could specify *overrides*, those facets (versions) that it specifically does not support, then that would also solve our problem. That is currently also unavailable.
As it stands, I do not see how we can make this change to our facet definition to support your use case without also unsupporting some of our core use cases.
I'd support change requests to the facets framework to address this problem.
|
|
|
| Re: Restricting certain JPA facet versions for particular runtimes [message #618705 is a reply to message #618692] |
Wed, 20 January 2010 14:18 |
| Eclipse User |
|
|
|
Hi Paul thanks for your input. Yes this is looking more like an issue best fixed in the facet framework (at the very least specific runtime vendors should be able to override behaviour if they choose to do so, and perhaps a larger scale change of allowing multiple types of runtime targetting, etc)
Will pursue with that team and keep you in the loop on any enhancement requests/bugzillas I open. Let me know if any were already opened by Dali against the facet framework in this area.
|
|
|
Powered by
FUDForum. Page generated in 0.06468 seconds
Home