|
Re: OCL validation example violates extension point schema [message #422566 is a reply to message #422557] |
Tue, 09 September 2008 13:33 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Adrian,
The "include" was intended for use by the XML constraint provider that
has since been deprecated, which expected more XML conforming to the
same extension-point schema. I'm not sure that overloading it is the
right solution.
I was thinking about this some time ago, and would incline more to
defining some kind of generic name-value parameter schema that leaves
the interpretation to the constraint provider. What would you think of
that? It is certainly worth raising a bug for this; it's not so nice to
have an example that is ahead of the extension-point schema's capability
of expression.
e.g.
<constraintProvider
class="com.example.validation.internal.ocl.OCLConstraintProvider ">
<package namespaceUri="http://www.example.com/model/>
<configuration>
<param
name="categories"
value="com.example.validation.category.ocl"/>
<param
name="path"
value="constraints/example.ocl"/>
</configuration>
</constraintProvider>
Cheers,
Christian
Adrian Price wrote:
> Sorry, I realised I should have posted this to the EMF newsgroup. Done.
>
> --A
>
> "Adrian Price" <aprice@spamnot.tibco.com> wrote in message
> news:ga5mqs$lp8$1@build.eclipse.org...
>> Good day,
>>
>> The org.eclipse.emf.validation.examples.ocl plug-in violates the
>> org.eclipse.emf.validation.constraintProviders extension point schema, by
>> providing an illegal 'ocl' child element and an illegal 'category'
>> attribute. The following markers show up against the plugin.xml in the
>> Problems View:
>>
>> - Element 'ocl' is not legal as a child of element 'constraintProvider'.
>> plugin.xml org.eclipse.emf.validation.examples.ocl line 85 Plug-in Problem
>> - Illegal attribute 'category' plugin.xml
>> org.eclipse.emf.validation.examples.ocl line 81 Plug-in Problem
>>
>> I was able to achieve the same results without violating the extension
>> point schema by using a minor variation of the OCLConstraintProvider class
>> and the following extension:
>>
>> <constraintProvider
>>
>> class="com.example.validation.internal.ocl.OCLConstraintProvider ">
>> <package namespaceUri="http://www.example.com/model/>
>> <constraints
>> categories="com.example.validation.category.ocl">
>> <include
>> path="constraints/example.ocl">
>> </include>
>> </constraints>
>> </constraintProvider>
>>
>> BTW the ext. pt. schema doc says that
>> constraintProvider/constraints/include@path is for 'Internal use only',
>> but the markup is semantically clearer than the current example and seems
>> to work fine.
>>
>> Anyone have any comments?
>>
>> Thanks,
>>
>> Adrian Price
>> Senior Architect (Presentation Technologies)
>> TIBCO Software, Inc.
>>
>
>
|
|
|
Re: OCL validation example violates extension point schema [message #422574 is a reply to message #422566] |
Tue, 09 September 2008 17:53 |
Adrian Price Messages: 61 Registered: July 2009 |
Member |
|
|
Hi Christian,
Thanks for the quick response. Yes, your point re. overloading deprecated
schema elements taken entirely. In fact, I am just writing code to load any
additional constraints from EAnnotations on the EPackages registered for the
constraintProvider/package@namespaceURI s and am wondering how to assign
them to a category. The generic name-value pair solution you propose would
be ideal. I shall log an enhancement request.
Cheers,
--A
"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message
news:ga5tup$96q$1@build.eclipse.org...
> Hi, Adrian,
>
> The "include" was intended for use by the XML constraint provider that has
> since been deprecated, which expected more XML conforming to the same
> extension-point schema. I'm not sure that overloading it is the right
> solution.
>
> I was thinking about this some time ago, and would incline more to
> defining some kind of generic name-value parameter schema that leaves the
> interpretation to the constraint provider. What would you think of that?
> It is certainly worth raising a bug for this; it's not so nice to have an
> example that is ahead of the extension-point schema's capability of
> expression.
>
> e.g.
>
> <constraintProvider
>
> class="com.example.validation.internal.ocl.OCLConstraintProvider ">
> <package namespaceUri="http://www.example.com/model/>
> <configuration>
> <param
> name="categories"
> value="com.example.validation.category.ocl"/>
> <param
> name="path"
> value="constraints/example.ocl"/>
> </configuration>
> </constraintProvider>
>
> Cheers,
>
> Christian
>
>
> Adrian Price wrote:
>> Sorry, I realised I should have posted this to the EMF newsgroup. Done.
>>
>> --A
>>
>> "Adrian Price" <aprice@spamnot.tibco.com> wrote in message
>> news:ga5mqs$lp8$1@build.eclipse.org...
>>> Good day,
>>>
>>> The org.eclipse.emf.validation.examples.ocl plug-in violates the
>>> org.eclipse.emf.validation.constraintProviders extension point schema,
>>> by providing an illegal 'ocl' child element and an illegal 'category'
>>> attribute. The following markers show up against the plugin.xml in the
>>> Problems View:
>>>
>>> - Element 'ocl' is not legal as a child of element 'constraintProvider'.
>>> plugin.xml org.eclipse.emf.validation.examples.ocl line 85 Plug-in
>>> Problem
>>> - Illegal attribute 'category' plugin.xml
>>> org.eclipse.emf.validation.examples.ocl line 81 Plug-in Problem
>>>
>>> I was able to achieve the same results without violating the extension
>>> point schema by using a minor variation of the OCLConstraintProvider
>>> class and the following extension:
>>>
>>> <constraintProvider
>>>
>>> class="com.example.validation.internal.ocl.OCLConstraintProvider ">
>>> <package namespaceUri="http://www.example.com/model/>
>>> <constraints
>>> categories="com.example.validation.category.ocl">
>>> <include
>>> path="constraints/example.ocl">
>>> </include>
>>> </constraints>
>>> </constraintProvider>
>>>
>>> BTW the ext. pt. schema doc says that
>>> constraintProvider/constraints/include@path is for 'Internal use only',
>>> but the markup is semantically clearer than the current example and
>>> seems to work fine.
>>>
>>> Anyone have any comments?
>>>
>>> Thanks,
>>>
>>> Adrian Price
>>> Senior Architect (Presentation Technologies)
>>> TIBCO Software, Inc.
>>>
>>
|
|
|
Powered by
FUDForum. Page generated in 0.03234 seconds