Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Re: OCL validation example violates extension point schema
Re: OCL validation example violates extension point schema [message #422557] Tue, 09 September 2008 12:00 Go to next message
Adrian Price is currently offline Adrian PriceFriend
Messages: 61
Registered: July 2009
Member
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 #422566 is a reply to message #422557] Tue, 09 September 2008 13:33 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous message
Adrian Price is currently offline Adrian PriceFriend
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.
>>>
>>
Previous Topic:[CDO] and EFS
Next Topic:Avoiding "Cannot modify resource set without a write transaction" in lazy initialization
Goto Forum:
  


Current Time: Sat Jan 25 19:26:43 GMT 2020

Powered by FUDForum. Page generated in 0.01728 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top