Community
Participate
Working Groups
I have redefined our library providers a bit. Here's an example that illustrates the problem. <provider id="jpa-user-library-provider" extends="user-library-provider" abstract="true"> <enablement> <and> <with variable="requestingProjectFacet"> <test property="org.eclipse.wst.common.project.facet.core.projectFacet" value="jpt.jpa" forcePluginActivation="true"/> </with> <with variable="projectFacets"> <iterate> <not> <test property="org.eclipse.jpt.core.group" value="modules" forcePluginActivation="true"/> </not> </iterate> </with> </and> </enablement> </provider> <provider id="jpa-generic1_0-user-library-provider" extends="jpa-user-library-provider"> <param name="validator" value="org.eclipse.jpt.core.internal.utility.KeyClassesValidator"/> <param name="validator.param.0" value="javax.persistence.Entity"/> <enablement> <with variable="jpaPlatform"> <equals value="generic"/> </with> </enablement> </provider> In this case, there are exceptions being thrown when library providers are being tested for other facets (not JPA), because the second (above) library provider is being tested by using its enablement before its parent's enablement. For instance, when library providers are being tested for JSF, the first thing that is tested is the value of the "jpaPlatform" variable, but there is no such variable, and so a CoreException is thrown. It would be my expectation that the parent's more general enablement would be tested first before then proceeding to the child's more specific enablement. Note that this works perfectly well when the "jpaPlatform" variable *is* present.
Of course, the other option is to treat the CoreException as an expected possibility, not log it, and return false from LibraryProvider.isEnabledFor(.....). That seems to be what others have done. I hit many other similar CoreExceptions without the error log being filled up.
Should also stipulate that this exists in 3.3 M1
One can equally well argue that the current ordering is the correct one. In many cases, the more derived provider will have more specific condition, so it makes sense to evaluate that condition first and skip evaluating the base condition. Regardless, the current ordering is API and cannot be changed without risking breakage to existing providers. I recommend adding a jpa facet check in your derived provider to guard your with expression.
Do you have no comment on the CoreException failure? In many other places in eclipse, the CoreException is treated as an expected possibility and false is returned rather than true.
> Do you have no comment on the CoreException failure? In many other places in > eclipse, the CoreException is treated as an expected possibility and false is > returned rather than true. It is generally not appropriate to treat CoreException as expected condition and not report it. I've seen very few cases where that is justified. In most situations, this approach just leads to debugging difficulties. I do not see this as an appropriate solution in this case.
