Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » export model to xsd with referenced generator model
| | |
Re: export model to xsd with referenced generator model [message #1734577 is a reply to message #1734548] |
Thu, 09 June 2016 13:43 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Martin,
Comments below.
On 09.06.2016 11:49, Martin Jacob wrote:
> Thanks Ed,
>
> well, the namespace is correct but the schemaLocation is not.
>
> Yes, both xsd files are included in the distribution and I also unpack
> the plugin. But still no success using the WST XML editor.
> The only working solution is to use platform:/plugin/ instead of ../../.
I think whether it works or not depends on what URI is used to open the
schema that contains this reference. Or at least it should. If the
schema itself is referenced with platform:/plugin/<plugin-id>/<path>
then the relative path itself should resolve to platform:/plugin/....
The platform:/plugin scheme should not require a version number.
I know all this works for *.ecore and *.genmodel resources, so it should
work in general. That's how relative paths should work in general.
>
> I believe when using ../../, the correct path could not be resolved,
> e.g. the plugin version.
>
> So instead of ../../com.xyz.a/model/schemaA.xsd
> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not tested.
>
> When starting the product from the IDE it works as it takes the source
> code/xsd directly without a version at the "plugin" folder.
Yes it should just work.
>
> May be it is an issue in WST XML editor catalogue to be unable to find
> the imported schema?
It would certainly depend on how the schema that contains this relative
reference itself is referenced. platform:/plugin/<plugin-id> should work
and then the relative reference should be resolved to platform:/plugin
as well.
>
> Shall I create two small sample plugins to reproduce the issue on your
> side?
I implemented the XSD model, so I know how relative reference should
work. I can't comment on why it might not work with WST. That's a Web
Tools issue. You can see in *.ecore and *.genmodel files that these
cross resource references also look like this, and they definitely work.
>
> Martin
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: export model to xsd with referenced generator model [message #1734649 is a reply to message #1734577] |
Fri, 10 June 2016 07:48 |
Martin Jacob Messages: 191 Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
As the emf eco system is able to handle the relative path it might be an
issue of the WST XML editor.
So I posted a question in eclipse.webtools forum, but no response for now.
some more comments below
Am 09.06.2016 um 15:43 schrieb Ed Merks:
> Martin,
>
> Comments below.
>
>
> On 09.06.2016 11:49, Martin Jacob wrote:
>> Thanks Ed,
>>
>> well, the namespace is correct but the schemaLocation is not.
>>
>> Yes, both xsd files are included in the distribution and I also unpack
>> the plugin. But still no success using the WST XML editor.
>> The only working solution is to use platform:/plugin/ instead of ../../.
> I think whether it works or not depends on what URI is used to open the
> schema that contains this reference. Or at least it should. If the
> schema itself is referenced with platform:/plugin/<plugin-id>/<path>
> then the relative path itself should resolve to platform:/plugin/....
> The platform:/plugin scheme should not require a version number.
When I look into the catalogue entry (preferences > XML > XML Catalog)
it says for the referencing schema:
Entry element: URI
Location: model\schemaB.xsd in jar file
C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
URI:
jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
Key type: Namespace name
Key: http://xyz.com/schemaB.xsd
Is there any thing suspicious?
>
> I know all this works for *.ecore and *.genmodel resources, so it should
> work in general. That's how relative paths should work in general.
>>
>> I believe when using ../../, the correct path could not be resolved,
>> e.g. the plugin version.
>>
>> So instead of ../../com.xyz.a/model/schemaA.xsd
>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not tested.
>>
>> When starting the product from the IDE it works as it takes the source
>> code/xsd directly without a version at the "plugin" folder.
> Yes it should just work.
Yes it does.
>>
>> May be it is an issue in WST XML editor catalogue to be unable to find
>> the imported schema?
> It would certainly depend on how the schema that contains this relative
> reference itself is referenced. platform:/plugin/<plugin-id> should work
> and then the relative reference should be resolved to platform:/plugin
> as well.
Both schema are inside different plugins. The structure is like this:
RCP
+ plugins
+ com.xyz.a_1.0.0/model/schemaA.xsd
+ com.xyz.b_1.0.0/model/schemaB.xsd
Where schemaB.xsd is referencing schemaA.xsd
>>
>> Shall I create two small sample plugins to reproduce the issue on your
>> side?
> I implemented the XSD model, so I know how relative reference should
> work. I can't comment on why it might not work with WST. That's a Web
> Tools issue. You can see in *.ecore and *.genmodel files that these
> cross resource references also look like this, and they definitely work.
Yes all works well within the IDE respectively RCP started as run
configuration. But unfortunately not with the exported RCP and the WST
XML editor.
Do you know the xsd model you implemented is also used by the WST XML
editor?
>>
>> Martin
>
|
|
|
Re: export model to xsd with referenced generator model [message #1734659 is a reply to message #1734649] |
Fri, 10 June 2016 08:26 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Martin,
I wonder which URIs you used the register the schemas... I'm not
familiar with the details of the catalog, but I imagine it's a logical
namespace URI to physical location mapping. A correct/proper
interpretation of a relative path in schema import/includes should
resolve the relative URI of the location against the absolute URI of the
containing schema, and that should produce another absolute path (just
as it does for an href="..." in an HMTL document).
On 10.06.2016 09:48, Martin Jacob wrote:
> Hi Ed,
>
> As the emf eco system is able to handle the relative path it might be
> an issue of the WST XML editor.
> So I posted a question in eclipse.webtools forum, but no response for
> now.
>
> some more comments below
>
>
> Am 09.06.2016 um 15:43 schrieb Ed Merks:
>> Martin,
>>
>> Comments below.
>>
>>
>> On 09.06.2016 11:49, Martin Jacob wrote:
>>> Thanks Ed,
>>>
>>> well, the namespace is correct but the schemaLocation is not.
>>>
>>> Yes, both xsd files are included in the distribution and I also unpack
>>> the plugin. But still no success using the WST XML editor.
>>> The only working solution is to use platform:/plugin/ instead of
>>> ../../.
>> I think whether it works or not depends on what URI is used to open the
>> schema that contains this reference. Or at least it should. If the
>> schema itself is referenced with platform:/plugin/<plugin-id>/<path>
>> then the relative path itself should resolve to platform:/plugin/....
>> The platform:/plugin scheme should not require a version number.
> When I look into the catalogue entry (preferences > XML > XML Catalog)
> it says for the referencing schema:
>
> Entry element: URI
> Location: model\schemaB.xsd in jar file
> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
> URI:
> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
> Key type: Namespace name
> Key: http://xyz.com/schemaB.xsd
>
> Is there any thing suspicious?
>
>>
>> I know all this works for *.ecore and *.genmodel resources, so it should
>> work in general. That's how relative paths should work in general.
>>>
>>> I believe when using ../../, the correct path could not be resolved,
>>> e.g. the plugin version.
>>>
>>> So instead of ../../com.xyz.a/model/schemaA.xsd
>>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not
>>> tested.
>>>
>>> When starting the product from the IDE it works as it takes the source
>>> code/xsd directly without a version at the "plugin" folder.
>> Yes it should just work.
> Yes it does.
>>>
>>> May be it is an issue in WST XML editor catalogue to be unable to find
>>> the imported schema?
>> It would certainly depend on how the schema that contains this relative
>> reference itself is referenced. platform:/plugin/<plugin-id> should work
>> and then the relative reference should be resolved to platform:/plugin
>> as well.
> Both schema are inside different plugins. The structure is like this:
> RCP
> + plugins
> + com.xyz.a_1.0.0/model/schemaA.xsd
> + com.xyz.b_1.0.0/model/schemaB.xsd
>
> Where schemaB.xsd is referencing schemaA.xsd
>
>>>
>>> Shall I create two small sample plugins to reproduce the issue on your
>>> side?
>> I implemented the XSD model, so I know how relative reference should
>> work. I can't comment on why it might not work with WST. That's a Web
>> Tools issue. You can see in *.ecore and *.genmodel files that these
>> cross resource references also look like this, and they definitely work.
> Yes all works well within the IDE respectively RCP started as run
> configuration. But unfortunately not with the exported RCP and the WST
> XML editor.
>
> Do you know the xsd model you implemented is also used by the WST XML
> editor?
>
>>>
>>> Martin
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: export model to xsd with referenced generator model [message #1734681 is a reply to message #1734659] |
Fri, 10 June 2016 09:30 |
Martin Jacob Messages: 191 Registered: July 2009 |
Senior Member |
|
|
Ed,
oh yes, the URI looks strange. I used the extension point definition of
the catalogue is:
<extension point="org.eclipse.wst.xml.core.catalogContributions">
<catalogContribution id="opn">
<uri name="http://xyz.com/schemaB.xsd" uri="model/schemaB.xsd"></uri>
</catalogContribution>
</extension>
Which is then displayed/translated at the catalogue preferences as
described.
Entry element: URI
Location: model\schemaB.xsd in jar file
C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
URI:
jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
Key type: Namespace name
Key: http://xyz.com/schemaB.xsd
Am 10.06.2016 um 10:26 schrieb Ed Merks:
> Martin,
>
> I wonder which URIs you used the register the schemas... I'm not
> familiar with the details of the catalog, but I imagine it's a logical
> namespace URI to physical location mapping. A correct/proper
> interpretation of a relative path in schema import/includes should
> resolve the relative URI of the location against the absolute URI of the
> containing schema, and that should produce another absolute path (just
> as it does for an href="..." in an HMTL document).
>
>
> On 10.06.2016 09:48, Martin Jacob wrote:
>> Hi Ed,
>>
>> As the emf eco system is able to handle the relative path it might be
>> an issue of the WST XML editor.
>> So I posted a question in eclipse.webtools forum, but no response for
>> now.
>>
>> some more comments below
>>
>>
>> Am 09.06.2016 um 15:43 schrieb Ed Merks:
>>> Martin,
>>>
>>> Comments below.
>>>
>>>
>>> On 09.06.2016 11:49, Martin Jacob wrote:
>>>> Thanks Ed,
>>>>
>>>> well, the namespace is correct but the schemaLocation is not.
>>>>
>>>> Yes, both xsd files are included in the distribution and I also unpack
>>>> the plugin. But still no success using the WST XML editor.
>>>> The only working solution is to use platform:/plugin/ instead of
>>>> ../../.
>>> I think whether it works or not depends on what URI is used to open the
>>> schema that contains this reference. Or at least it should. If the
>>> schema itself is referenced with platform:/plugin/<plugin-id>/<path>
>>> then the relative path itself should resolve to platform:/plugin/....
>>> The platform:/plugin scheme should not require a version number.
>> When I look into the catalogue entry (preferences > XML > XML Catalog)
>> it says for the referencing schema:
>>
>> Entry element: URI
>> Location: model\schemaB.xsd in jar file
>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>> URI:
>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>
>> Key type: Namespace name
>> Key: http://xyz.com/schemaB.xsd
>>
>> Is there any thing suspicious?
>>
>>>
>>> I know all this works for *.ecore and *.genmodel resources, so it should
>>> work in general. That's how relative paths should work in general.
>>>>
>>>> I believe when using ../../, the correct path could not be resolved,
>>>> e.g. the plugin version.
>>>>
>>>> So instead of ../../com.xyz.a/model/schemaA.xsd
>>>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not
>>>> tested.
>>>>
>>>> When starting the product from the IDE it works as it takes the source
>>>> code/xsd directly without a version at the "plugin" folder.
>>> Yes it should just work.
>> Yes it does.
>>>>
>>>> May be it is an issue in WST XML editor catalogue to be unable to find
>>>> the imported schema?
>>> It would certainly depend on how the schema that contains this relative
>>> reference itself is referenced. platform:/plugin/<plugin-id> should work
>>> and then the relative reference should be resolved to platform:/plugin
>>> as well.
>> Both schema are inside different plugins. The structure is like this:
>> RCP
>> + plugins
>> + com.xyz.a_1.0.0/model/schemaA.xsd
>> + com.xyz.b_1.0.0/model/schemaB.xsd
>>
>> Where schemaB.xsd is referencing schemaA.xsd
>>
>>>>
>>>> Shall I create two small sample plugins to reproduce the issue on your
>>>> side?
>>> I implemented the XSD model, so I know how relative reference should
>>> work. I can't comment on why it might not work with WST. That's a Web
>>> Tools issue. You can see in *.ecore and *.genmodel files that these
>>> cross resource references also look like this, and they definitely work.
>> Yes all works well within the IDE respectively RCP started as run
>> configuration. But unfortunately not with the exported RCP and the WST
>> XML editor.
>>
>> Do you know the xsd model you implemented is also used by the WST XML
>> editor?
>>
>>>>
>>>> Martin
>>>
>
|
|
|
Re: export model to xsd with referenced generator model [message #1734723 is a reply to message #1734681] |
Fri, 10 June 2016 16:24 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Martin,
Yes, that won't work. It needs to be a logical namespace, not a
physical file location. There's no mechanism that would allow a
relative reference to "traverse" to another jar. The "platform:" scheme
is built-in to Eclipse, i.e., it can even be accessed as a java.net.URL
because there is a registered URLHandler. You should perhaps try
registering with platform:/plugin/com.xyz.b/model/schemaB.xsd and hope
that this works.
On 10.06.2016 11:30, Martin Jacob wrote:
> Ed,
>
> oh yes, the URI looks strange. I used the extension point definition
> of the catalogue is:
>
> <extension point="org.eclipse.wst.xml.core.catalogContributions">
> <catalogContribution id="opn">
> <uri name="http://xyz.com/schemaB.xsd" uri="model/schemaB.xsd"></uri>
> </catalogContribution>
> </extension>
>
>
> Which is then displayed/translated at the catalogue preferences as
> described.
> Entry element: URI
> Location: model\schemaB.xsd in jar file
> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
> URI:
> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
> Key type: Namespace name
> Key: http://xyz.com/schemaB.xsd
>
>
>
> Am 10.06.2016 um 10:26 schrieb Ed Merks:
>> Martin,
>>
>> I wonder which URIs you used the register the schemas... I'm not
>> familiar with the details of the catalog, but I imagine it's a logical
>> namespace URI to physical location mapping. A correct/proper
>> interpretation of a relative path in schema import/includes should
>> resolve the relative URI of the location against the absolute URI of the
>> containing schema, and that should produce another absolute path (just
>> as it does for an href="..." in an HMTL document).
>>
>>
>> On 10.06.2016 09:48, Martin Jacob wrote:
>>> Hi Ed,
>>>
>>> As the emf eco system is able to handle the relative path it might be
>>> an issue of the WST XML editor.
>>> So I posted a question in eclipse.webtools forum, but no response for
>>> now.
>>>
>>> some more comments below
>>>
>>>
>>> Am 09.06.2016 um 15:43 schrieb Ed Merks:
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> On 09.06.2016 11:49, Martin Jacob wrote:
>>>>> Thanks Ed,
>>>>>
>>>>> well, the namespace is correct but the schemaLocation is not.
>>>>>
>>>>> Yes, both xsd files are included in the distribution and I also
>>>>> unpack
>>>>> the plugin. But still no success using the WST XML editor.
>>>>> The only working solution is to use platform:/plugin/ instead of
>>>>> ../../.
>>>> I think whether it works or not depends on what URI is used to open
>>>> the
>>>> schema that contains this reference. Or at least it should. If the
>>>> schema itself is referenced with platform:/plugin/<plugin-id>/<path>
>>>> then the relative path itself should resolve to platform:/plugin/....
>>>> The platform:/plugin scheme should not require a version number.
>>> When I look into the catalogue entry (preferences > XML > XML Catalog)
>>> it says for the referencing schema:
>>>
>>> Entry element: URI
>>> Location: model\schemaB.xsd in jar file
>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>
>>> URI:
>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>
>>>
>>> Key type: Namespace name
>>> Key: http://xyz.com/schemaB.xsd
>>>
>>> Is there any thing suspicious?
>>>
>>>>
>>>> I know all this works for *.ecore and *.genmodel resources, so it
>>>> should
>>>> work in general. That's how relative paths should work in general.
>>>>>
>>>>> I believe when using ../../, the correct path could not be resolved,
>>>>> e.g. the plugin version.
>>>>>
>>>>> So instead of ../../com.xyz.a/model/schemaA.xsd
>>>>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not
>>>>> tested.
>>>>>
>>>>> When starting the product from the IDE it works as it takes the
>>>>> source
>>>>> code/xsd directly without a version at the "plugin" folder.
>>>> Yes it should just work.
>>> Yes it does.
>>>>>
>>>>> May be it is an issue in WST XML editor catalogue to be unable to
>>>>> find
>>>>> the imported schema?
>>>> It would certainly depend on how the schema that contains this
>>>> relative
>>>> reference itself is referenced. platform:/plugin/<plugin-id> should
>>>> work
>>>> and then the relative reference should be resolved to platform:/plugin
>>>> as well.
>>> Both schema are inside different plugins. The structure is like this:
>>> RCP
>>> + plugins
>>> + com.xyz.a_1.0.0/model/schemaA.xsd
>>> + com.xyz.b_1.0.0/model/schemaB.xsd
>>>
>>> Where schemaB.xsd is referencing schemaA.xsd
>>>
>>>>>
>>>>> Shall I create two small sample plugins to reproduce the issue on
>>>>> your
>>>>> side?
>>>> I implemented the XSD model, so I know how relative reference should
>>>> work. I can't comment on why it might not work with WST. That's a Web
>>>> Tools issue. You can see in *.ecore and *.genmodel files that these
>>>> cross resource references also look like this, and they definitely
>>>> work.
>>> Yes all works well within the IDE respectively RCP started as run
>>> configuration. But unfortunately not with the exported RCP and the WST
>>> XML editor.
>>>
>>> Do you know the xsd model you implemented is also used by the WST XML
>>> editor?
>>>
>>>>>
>>>>> Martin
>>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: export model to xsd with referenced generator model [message #1735061 is a reply to message #1734723] |
Wed, 15 June 2016 06:50 |
Martin Jacob Messages: 191 Registered: July 2009 |
Senior Member |
|
|
Ed,
I modified the extension point at
/extension/catalogContribution/uri/@uri, see below, but still no success.
<extension point="org.eclipse.wst.xml.core.catalogContributions">
<catalogContribution id="opn">
<uri name="http://xyz.com/schemaB.xsd"
uri="platform:/plugin/com.xyz.b/model/schemaB.xsd"</uri>
</catalogContribution>
</extension>
As mentioned earlier it works if I use
platform:/plugin/com.xyz.b/model/schemaB.xsd at the schemaLocation
attribute of the import. For me it seams the schemaLocation is used to
find schemaB.xsd instead of the catalogue entry which should match the
namespace URI with the file.
Do you think this is more an issue of the Editor or others?
Unfortunately I go no feedback from
news://news.eclipse.org:119/njbf5u$i8a$1@xxxxxxxxe.org.
Martin
Am 10.06.2016 um 18:24 schrieb Ed Merks:
> Martin,
>
> Yes, that won't work. It needs to be a logical namespace, not a
> physical file location. There's no mechanism that would allow a
> relative reference to "traverse" to another jar. The "platform:" scheme
> is built-in to Eclipse, i.e., it can even be accessed as a java.net.URL
> because there is a registered URLHandler. You should perhaps try
> registering with platform:/plugin/com.xyz.b/model/schemaB.xsd and hope
> that this works.
>
> On 10.06.2016 11:30, Martin Jacob wrote:
>> Ed,
>>
>> oh yes, the URI looks strange. I used the extension point definition
>> of the catalogue is:
>>
>> <extension point="org.eclipse.wst.xml.core.catalogContributions">
>> <catalogContribution id="opn">
>> <uri name="http://xyz.com/schemaB.xsd" uri="model/schemaB.xsd"></uri>
>> </catalogContribution>
>> </extension>
>>
>>
>> Which is then displayed/translated at the catalogue preferences as
>> described.
>> Entry element: URI
>> Location: model\schemaB.xsd in jar file
>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>> URI:
>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>
>> Key type: Namespace name
>> Key: http://xyz.com/schemaB.xsd
>>
>>
>>
>> Am 10.06.2016 um 10:26 schrieb Ed Merks:
>>> Martin,
>>>
>>> I wonder which URIs you used the register the schemas... I'm not
>>> familiar with the details of the catalog, but I imagine it's a logical
>>> namespace URI to physical location mapping. A correct/proper
>>> interpretation of a relative path in schema import/includes should
>>> resolve the relative URI of the location against the absolute URI of the
>>> containing schema, and that should produce another absolute path (just
>>> as it does for an href="..." in an HMTL document).
>>>
>>>
>>> On 10.06.2016 09:48, Martin Jacob wrote:
>>>> Hi Ed,
>>>>
>>>> As the emf eco system is able to handle the relative path it might be
>>>> an issue of the WST XML editor.
>>>> So I posted a question in eclipse.webtools forum, but no response for
>>>> now.
>>>>
>>>> some more comments below
>>>>
>>>>
>>>> Am 09.06.2016 um 15:43 schrieb Ed Merks:
>>>>> Martin,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> On 09.06.2016 11:49, Martin Jacob wrote:
>>>>>> Thanks Ed,
>>>>>>
>>>>>> well, the namespace is correct but the schemaLocation is not.
>>>>>>
>>>>>> Yes, both xsd files are included in the distribution and I also
>>>>>> unpack
>>>>>> the plugin. But still no success using the WST XML editor.
>>>>>> The only working solution is to use platform:/plugin/ instead of
>>>>>> ../../.
>>>>> I think whether it works or not depends on what URI is used to open
>>>>> the
>>>>> schema that contains this reference. Or at least it should. If the
>>>>> schema itself is referenced with platform:/plugin/<plugin-id>/<path>
>>>>> then the relative path itself should resolve to platform:/plugin/....
>>>>> The platform:/plugin scheme should not require a version number.
>>>> When I look into the catalogue entry (preferences > XML > XML Catalog)
>>>> it says for the referencing schema:
>>>>
>>>> Entry element: URI
>>>> Location: model\schemaB.xsd in jar file
>>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>>
>>>> URI:
>>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>>
>>>>
>>>> Key type: Namespace name
>>>> Key: http://xyz.com/schemaB.xsd
>>>>
>>>> Is there any thing suspicious?
>>>>
>>>>>
>>>>> I know all this works for *.ecore and *.genmodel resources, so it
>>>>> should
>>>>> work in general. That's how relative paths should work in general.
>>>>>>
>>>>>> I believe when using ../../, the correct path could not be resolved,
>>>>>> e.g. the plugin version.
>>>>>>
>>>>>> So instead of ../../com.xyz.a/model/schemaA.xsd
>>>>>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not
>>>>>> tested.
>>>>>>
>>>>>> When starting the product from the IDE it works as it takes the
>>>>>> source
>>>>>> code/xsd directly without a version at the "plugin" folder.
>>>>> Yes it should just work.
>>>> Yes it does.
>>>>>>
>>>>>> May be it is an issue in WST XML editor catalogue to be unable to
>>>>>> find
>>>>>> the imported schema?
>>>>> It would certainly depend on how the schema that contains this
>>>>> relative
>>>>> reference itself is referenced. platform:/plugin/<plugin-id> should
>>>>> work
>>>>> and then the relative reference should be resolved to platform:/plugin
>>>>> as well.
>>>> Both schema are inside different plugins. The structure is like this:
>>>> RCP
>>>> + plugins
>>>> + com.xyz.a_1.0.0/model/schemaA.xsd
>>>> + com.xyz.b_1.0.0/model/schemaB.xsd
>>>>
>>>> Where schemaB.xsd is referencing schemaA.xsd
>>>>
>>>>>>
>>>>>> Shall I create two small sample plugins to reproduce the issue on
>>>>>> your
>>>>>> side?
>>>>> I implemented the XSD model, so I know how relative reference should
>>>>> work. I can't comment on why it might not work with WST. That's a Web
>>>>> Tools issue. You can see in *.ecore and *.genmodel files that these
>>>>> cross resource references also look like this, and they definitely
>>>>> work.
>>>> Yes all works well within the IDE respectively RCP started as run
>>>> configuration. But unfortunately not with the exported RCP and the WST
>>>> XML editor.
>>>>
>>>> Do you know the xsd model you implemented is also used by the WST XML
>>>> editor?
>>>>
>>>>>>
>>>>>> Martin
>>>>>
>>>
>
|
|
|
Re: export model to xsd with referenced generator model [message #1735092 is a reply to message #1735061] |
Wed, 15 June 2016 13:41 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Martin,
Comments below.
On 15.06.2016 08:50, Martin Jacob wrote:
> Ed,
>
> I modified the extension point at
> /extension/catalogContribution/uri/@uri, see below, but still no success.
>
> <extension point="org.eclipse.wst.xml.core.catalogContributions">
> <catalogContribution id="opn">
> <uri name="http://xyz.com/schemaB.xsd"
> uri="platform:/plugin/com.xyz.b/model/schemaB.xsd"</uri>
> </catalogContribution>
> </extension>
>
> As mentioned earlier it works if I use
> platform:/plugin/com.xyz.b/model/schemaB.xsd at the schemaLocation
> attribute of the import.
How is the schema containing the import itself registered?
> For me it seams the schemaLocation is used to find schemaB.xsd instead
> of the catalogue entry which should match the namespace URI with the
> file.
Technically the schemaLocation on an import or include is just a "hint"
for where to find the schema. A schema processor can use or ignore that
hint.
>
> Do you think this is more an issue of the Editor or others?
What are the two schema namespaces involved and how (with which URI) are
each of them registered in the catalog?
>
> Unfortunately I go no feedback from
> news://news.eclipse.org:119/njbf5u$i8a$1@xxxxxxxxe.org.
Yes, not all forums are as responsive.
>
> Martin
>
> Am 10.06.2016 um 18:24 schrieb Ed Merks:
>> Martin,
>>
>> Yes, that won't work. It needs to be a logical namespace, not a
>> physical file location. There's no mechanism that would allow a
>> relative reference to "traverse" to another jar. The "platform:" scheme
>> is built-in to Eclipse, i.e., it can even be accessed as a java.net.URL
>> because there is a registered URLHandler. You should perhaps try
>> registering with platform:/plugin/com.xyz.b/model/schemaB.xsd and hope
>> that this works.
>>
>> On 10.06.2016 11:30, Martin Jacob wrote:
>>> Ed,
>>>
>>> oh yes, the URI looks strange. I used the extension point definition
>>> of the catalogue is:
>>>
>>> <extension point="org.eclipse.wst.xml.core.catalogContributions">
>>> <catalogContribution id="opn">
>>> <uri name="http://xyz.com/schemaB.xsd" uri="model/schemaB.xsd"></uri>
>>> </catalogContribution>
>>> </extension>
>>>
>>>
>>> Which is then displayed/translated at the catalogue preferences as
>>> described.
>>> Entry element: URI
>>> Location: model\schemaB.xsd in jar file
>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>
>>> URI:
>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>
>>>
>>> Key type: Namespace name
>>> Key: http://xyz.com/schemaB.xsd
>>>
>>>
>>>
>>> Am 10.06.2016 um 10:26 schrieb Ed Merks:
>>>> Martin,
>>>>
>>>> I wonder which URIs you used the register the schemas... I'm not
>>>> familiar with the details of the catalog, but I imagine it's a logical
>>>> namespace URI to physical location mapping. A correct/proper
>>>> interpretation of a relative path in schema import/includes should
>>>> resolve the relative URI of the location against the absolute URI
>>>> of the
>>>> containing schema, and that should produce another absolute path (just
>>>> as it does for an href="..." in an HMTL document).
>>>>
>>>>
>>>> On 10.06.2016 09:48, Martin Jacob wrote:
>>>>> Hi Ed,
>>>>>
>>>>> As the emf eco system is able to handle the relative path it might be
>>>>> an issue of the WST XML editor.
>>>>> So I posted a question in eclipse.webtools forum, but no response for
>>>>> now.
>>>>>
>>>>> some more comments below
>>>>>
>>>>>
>>>>> Am 09.06.2016 um 15:43 schrieb Ed Merks:
>>>>>> Martin,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>
>>>>>> On 09.06.2016 11:49, Martin Jacob wrote:
>>>>>>> Thanks Ed,
>>>>>>>
>>>>>>> well, the namespace is correct but the schemaLocation is not.
>>>>>>>
>>>>>>> Yes, both xsd files are included in the distribution and I also
>>>>>>> unpack
>>>>>>> the plugin. But still no success using the WST XML editor.
>>>>>>> The only working solution is to use platform:/plugin/ instead of
>>>>>>> ../../.
>>>>>> I think whether it works or not depends on what URI is used to open
>>>>>> the
>>>>>> schema that contains this reference. Or at least it should. If the
>>>>>> schema itself is referenced with platform:/plugin/<plugin-id>/<path>
>>>>>> then the relative path itself should resolve to
>>>>>> platform:/plugin/....
>>>>>> The platform:/plugin scheme should not require a version number.
>>>>> When I look into the catalogue entry (preferences > XML > XML
>>>>> Catalog)
>>>>> it says for the referencing schema:
>>>>>
>>>>> Entry element: URI
>>>>> Location: model\schemaB.xsd in jar file
>>>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>>>
>>>>>
>>>>> URI:
>>>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>>>
>>>>>
>>>>>
>>>>> Key type: Namespace name
>>>>> Key: http://xyz.com/schemaB.xsd
>>>>>
>>>>> Is there any thing suspicious?
>>>>>
>>>>>>
>>>>>> I know all this works for *.ecore and *.genmodel resources, so it
>>>>>> should
>>>>>> work in general. That's how relative paths should work in general.
>>>>>>>
>>>>>>> I believe when using ../../, the correct path could not be
>>>>>>> resolved,
>>>>>>> e.g. the plugin version.
>>>>>>>
>>>>>>> So instead of ../../com.xyz.a/model/schemaA.xsd
>>>>>>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not
>>>>>>> tested.
>>>>>>>
>>>>>>> When starting the product from the IDE it works as it takes the
>>>>>>> source
>>>>>>> code/xsd directly without a version at the "plugin" folder.
>>>>>> Yes it should just work.
>>>>> Yes it does.
>>>>>>>
>>>>>>> May be it is an issue in WST XML editor catalogue to be unable to
>>>>>>> find
>>>>>>> the imported schema?
>>>>>> It would certainly depend on how the schema that contains this
>>>>>> relative
>>>>>> reference itself is referenced. platform:/plugin/<plugin-id> should
>>>>>> work
>>>>>> and then the relative reference should be resolved to
>>>>>> platform:/plugin
>>>>>> as well.
>>>>> Both schema are inside different plugins. The structure is like this:
>>>>> RCP
>>>>> + plugins
>>>>> + com.xyz.a_1.0.0/model/schemaA.xsd
>>>>> + com.xyz.b_1.0.0/model/schemaB.xsd
>>>>>
>>>>> Where schemaB.xsd is referencing schemaA.xsd
>>>>>
>>>>>>>
>>>>>>> Shall I create two small sample plugins to reproduce the issue on
>>>>>>> your
>>>>>>> side?
>>>>>> I implemented the XSD model, so I know how relative reference should
>>>>>> work. I can't comment on why it might not work with WST. That's
>>>>>> a Web
>>>>>> Tools issue. You can see in *.ecore and *.genmodel files that these
>>>>>> cross resource references also look like this, and they definitely
>>>>>> work.
>>>>> Yes all works well within the IDE respectively RCP started as run
>>>>> configuration. But unfortunately not with the exported RCP and the
>>>>> WST
>>>>> XML editor.
>>>>>
>>>>> Do you know the xsd model you implemented is also used by the WST XML
>>>>> editor?
>>>>>
>>>>>>>
>>>>>>> Martin
>>>>>>
>>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: export model to xsd with referenced generator model [message #1735127 is a reply to message #1735092] |
Wed, 15 June 2016 17:16 |
Martin Jacob Messages: 191 Registered: July 2009 |
Senior Member |
|
|
Ed,
thanks Ed. The schema containing the import (schemaA.xsd) is registered
same as the referenced (schemaB.xsd). But schemaA.xsd is on another
plugin then schemaB.xsd.
<extension point="org.eclipse.wst.xml.core.catalogContributions">
<catalogContribution id="opn">
<uri name="http://xyz.com/schemaA.xsd" uri="model/schemaA.xsd"</uri>
</catalogContribution>
</extension>
schemaA.xsd has no (empty) namespace and schemaB.xsd has a namespace ("b").
Do you know the meaning of extension/catalogContribution/@id ?
It seams the schemaLocation only is evaluated by the schema processor
but not the catalogues entry. Does the schema processor look into the
catalogue?
Martin
Am 15.06.2016 um 15:41 schrieb Ed Merks:
> Martin,
>
> Comments below.
>
>
> On 15.06.2016 08:50, Martin Jacob wrote:
>> Ed,
>>
>> I modified the extension point at
>> /extension/catalogContribution/uri/@uri, see below, but still no success.
>>
>> <extension point="org.eclipse.wst.xml.core.catalogContributions">
>> <catalogContribution id="opn">
>> <uri name="http://xyz.com/schemaB.xsd"
>> uri="platform:/plugin/com.xyz.b/model/schemaB.xsd"</uri>
>> </catalogContribution>
>> </extension>
>>
>> As mentioned earlier it works if I use
>> platform:/plugin/com.xyz.b/model/schemaB.xsd at the schemaLocation
>> attribute of the import.
> How is the schema containing the import itself registered?
>> For me it seams the schemaLocation is used to find schemaB.xsd instead
>> of the catalogue entry which should match the namespace URI with the
>> file.
> Technically the schemaLocation on an import or include is just a "hint"
> for where to find the schema. A schema processor can use or ignore that
> hint.
>>
>> Do you think this is more an issue of the Editor or others?
> What are the two schema namespaces involved and how (with which URI) are
> each of them registered in the catalog?
>>
>> Unfortunately I go no feedback from
>> news://news.eclipse.org:119/njbf5u$i8a$1@xxxxxxxxe.org.
> Yes, not all forums are as responsive.
>>
>> Martin
>>
>> Am 10.06.2016 um 18:24 schrieb Ed Merks:
>>> Martin,
>>>
>>> Yes, that won't work. It needs to be a logical namespace, not a
>>> physical file location. There's no mechanism that would allow a
>>> relative reference to "traverse" to another jar. The "platform:" scheme
>>> is built-in to Eclipse, i.e., it can even be accessed as a java.net.URL
>>> because there is a registered URLHandler. You should perhaps try
>>> registering with platform:/plugin/com.xyz.b/model/schemaB.xsd and hope
>>> that this works.
>>>
>>> On 10.06.2016 11:30, Martin Jacob wrote:
>>>> Ed,
>>>>
>>>> oh yes, the URI looks strange. I used the extension point definition
>>>> of the catalogue is:
>>>>
>>>> <extension point="org.eclipse.wst.xml.core.catalogContributions">
>>>> <catalogContribution id="opn">
>>>> <uri name="http://xyz.com/schemaB.xsd" uri="model/schemaB.xsd"></uri>
>>>> </catalogContribution>
>>>> </extension>
>>>>
>>>>
>>>> Which is then displayed/translated at the catalogue preferences as
>>>> described.
>>>> Entry element: URI
>>>> Location: model\schemaB.xsd in jar file
>>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>>
>>>> URI:
>>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>>
>>>>
>>>> Key type: Namespace name
>>>> Key: http://xyz.com/schemaB.xsd
>>>>
>>>>
>>>>
>>>> Am 10.06.2016 um 10:26 schrieb Ed Merks:
>>>>> Martin,
>>>>>
>>>>> I wonder which URIs you used the register the schemas... I'm not
>>>>> familiar with the details of the catalog, but I imagine it's a logical
>>>>> namespace URI to physical location mapping. A correct/proper
>>>>> interpretation of a relative path in schema import/includes should
>>>>> resolve the relative URI of the location against the absolute URI
>>>>> of the
>>>>> containing schema, and that should produce another absolute path (just
>>>>> as it does for an href="..." in an HMTL document).
>>>>>
>>>>>
>>>>> On 10.06.2016 09:48, Martin Jacob wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> As the emf eco system is able to handle the relative path it might be
>>>>>> an issue of the WST XML editor.
>>>>>> So I posted a question in eclipse.webtools forum, but no response for
>>>>>> now.
>>>>>>
>>>>>> some more comments below
>>>>>>
>>>>>>
>>>>>> Am 09.06.2016 um 15:43 schrieb Ed Merks:
>>>>>>> Martin,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>>
>>>>>>> On 09.06.2016 11:49, Martin Jacob wrote:
>>>>>>>> Thanks Ed,
>>>>>>>>
>>>>>>>> well, the namespace is correct but the schemaLocation is not.
>>>>>>>>
>>>>>>>> Yes, both xsd files are included in the distribution and I also
>>>>>>>> unpack
>>>>>>>> the plugin. But still no success using the WST XML editor.
>>>>>>>> The only working solution is to use platform:/plugin/ instead of
>>>>>>>> ../../.
>>>>>>> I think whether it works or not depends on what URI is used to open
>>>>>>> the
>>>>>>> schema that contains this reference. Or at least it should. If the
>>>>>>> schema itself is referenced with platform:/plugin/<plugin-id>/<path>
>>>>>>> then the relative path itself should resolve to
>>>>>>> platform:/plugin/....
>>>>>>> The platform:/plugin scheme should not require a version number.
>>>>>> When I look into the catalogue entry (preferences > XML > XML
>>>>>> Catalog)
>>>>>> it says for the referencing schema:
>>>>>>
>>>>>> Entry element: URI
>>>>>> Location: model\schemaB.xsd in jar file
>>>>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>>>>
>>>>>>
>>>>>> URI:
>>>>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>>>>
>>>>>>
>>>>>>
>>>>>> Key type: Namespace name
>>>>>> Key: http://xyz.com/schemaB.xsd
>>>>>>
>>>>>> Is there any thing suspicious?
>>>>>>
>>>>>>>
>>>>>>> I know all this works for *.ecore and *.genmodel resources, so it
>>>>>>> should
>>>>>>> work in general. That's how relative paths should work in general.
>>>>>>>>
>>>>>>>> I believe when using ../../, the correct path could not be
>>>>>>>> resolved,
>>>>>>>> e.g. the plugin version.
>>>>>>>>
>>>>>>>> So instead of ../../com.xyz.a/model/schemaA.xsd
>>>>>>>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not
>>>>>>>> tested.
>>>>>>>>
>>>>>>>> When starting the product from the IDE it works as it takes the
>>>>>>>> source
>>>>>>>> code/xsd directly without a version at the "plugin" folder.
>>>>>>> Yes it should just work.
>>>>>> Yes it does.
>>>>>>>>
>>>>>>>> May be it is an issue in WST XML editor catalogue to be unable to
>>>>>>>> find
>>>>>>>> the imported schema?
>>>>>>> It would certainly depend on how the schema that contains this
>>>>>>> relative
>>>>>>> reference itself is referenced. platform:/plugin/<plugin-id> should
>>>>>>> work
>>>>>>> and then the relative reference should be resolved to
>>>>>>> platform:/plugin
>>>>>>> as well.
>>>>>> Both schema are inside different plugins. The structure is like this:
>>>>>> RCP
>>>>>> + plugins
>>>>>> + com.xyz.a_1.0.0/model/schemaA.xsd
>>>>>> + com.xyz.b_1.0.0/model/schemaB.xsd
>>>>>>
>>>>>> Where schemaB.xsd is referencing schemaA.xsd
>>>>>>
>>>>>>>>
>>>>>>>> Shall I create two small sample plugins to reproduce the issue on
>>>>>>>> your
>>>>>>>> side?
>>>>>>> I implemented the XSD model, so I know how relative reference should
>>>>>>> work. I can't comment on why it might not work with WST. That's
>>>>>>> a Web
>>>>>>> Tools issue. You can see in *.ecore and *.genmodel files that these
>>>>>>> cross resource references also look like this, and they definitely
>>>>>>> work.
>>>>>> Yes all works well within the IDE respectively RCP started as run
>>>>>> configuration. But unfortunately not with the exported RCP and the
>>>>>> WST
>>>>>> XML editor.
>>>>>>
>>>>>> Do you know the xsd model you implemented is also used by the WST XML
>>>>>> editor?
>>>>>>
>>>>>>>>
>>>>>>>> Martin
>>>>>>>
>>>>>
>>>
>
|
|
|
Re: export model to xsd with referenced generator model [message #1735138 is a reply to message #1735127] |
Wed, 15 June 2016 18:11 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Martin,
Comments below.
On 15.06.2016 19:16, Martin Jacob wrote:
> Ed,
>
> thanks Ed. The schema containing the import (schemaA.xsd) is
> registered same as the referenced (schemaB.xsd). But schemaA.xsd is on
> another plugin then schemaB.xsd.
>
> <extension point="org.eclipse.wst.xml.core.catalogContributions">
> <catalogContribution id="opn">
> <uri name="http://xyz.com/schemaA.xsd" uri="model/schemaA.xsd"</uri>
> </catalogContribution>
> </extension>
Yes, that's what I guessed. But it's this schema that has this poor
physical URI that can't possibility resolve the relative schemLocation
URI within that file. But you've not tried platform:/plugin for this
registration yet?
>
> schemaA.xsd has no (empty) namespace and schemaB.xsd has a namespace
> ("b").
Now does this no namespace relate to name="http://xyz.com/schemaA.xsd"?
It's it supported to the the namespace of the schema?
>
> Do you know the meaning of extension/catalogContribution/@id ?
No, I know nothing about the catalog?
>
> It seams the schemaLocation only is evaluated by the schema processor
> but not the catalogues entry. Does the schema processor look into the
> catalogue?
That all depends on Web Tools extensions, and I'm not familiar with
those. But I'm concerned you've been focused on the registration for B
and it's the schema A that contains the schemaLocation that's failing to
resolve, so it's the URI used to load A that will determine how that
relative schemaLocation resolves. So your focus should be on A's
registration.
>
>
> Martin
>
> Am 15.06.2016 um 15:41 schrieb Ed Merks:
>> Martin,
>>
>> Comments below.
>>
>>
>> On 15.06.2016 08:50, Martin Jacob wrote:
>>> Ed,
>>>
>>> I modified the extension point at
>>> /extension/catalogContribution/uri/@uri, see below, but still no
>>> success.
>>>
>>> <extension point="org.eclipse.wst.xml.core.catalogContributions">
>>> <catalogContribution id="opn">
>>> <uri name="http://xyz.com/schemaB.xsd"
>>> uri="platform:/plugin/com.xyz.b/model/schemaB.xsd"</uri>
>>> </catalogContribution>
>>> </extension>
>>>
>>> As mentioned earlier it works if I use
>>> platform:/plugin/com.xyz.b/model/schemaB.xsd at the schemaLocation
>>> attribute of the import.
>> How is the schema containing the import itself registered?
>>> For me it seams the schemaLocation is used to find schemaB.xsd instead
>>> of the catalogue entry which should match the namespace URI with the
>>> file.
>> Technically the schemaLocation on an import or include is just a "hint"
>> for where to find the schema. A schema processor can use or ignore that
>> hint.
>>>
>>> Do you think this is more an issue of the Editor or others?
>> What are the two schema namespaces involved and how (with which URI) are
>> each of them registered in the catalog?
>>>
>>> Unfortunately I go no feedback from
>>> news://news.eclipse.org:119/njbf5u$i8a$1@xxxxxxxxe.org.
>> Yes, not all forums are as responsive.
>>>
>>> Martin
>>>
>>> Am 10.06.2016 um 18:24 schrieb Ed Merks:
>>>> Martin,
>>>>
>>>> Yes, that won't work. It needs to be a logical namespace, not a
>>>> physical file location. There's no mechanism that would allow a
>>>> relative reference to "traverse" to another jar. The "platform:"
>>>> scheme
>>>> is built-in to Eclipse, i.e., it can even be accessed as a
>>>> java.net.URL
>>>> because there is a registered URLHandler. You should perhaps try
>>>> registering with platform:/plugin/com.xyz.b/model/schemaB.xsd and hope
>>>> that this works.
>>>>
>>>> On 10.06.2016 11:30, Martin Jacob wrote:
>>>>> Ed,
>>>>>
>>>>> oh yes, the URI looks strange. I used the extension point definition
>>>>> of the catalogue is:
>>>>>
>>>>> <extension point="org.eclipse.wst.xml.core.catalogContributions">
>>>>> <catalogContribution id="opn">
>>>>> <uri name="http://xyz.com/schemaB.xsd"
>>>>> uri="model/schemaB.xsd"></uri>
>>>>> </catalogContribution>
>>>>> </extension>
>>>>>
>>>>>
>>>>> Which is then displayed/translated at the catalogue preferences as
>>>>> described.
>>>>> Entry element: URI
>>>>> Location: model\schemaB.xsd in jar file
>>>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>>>
>>>>>
>>>>> URI:
>>>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>>>
>>>>>
>>>>>
>>>>> Key type: Namespace name
>>>>> Key: http://xyz.com/schemaB.xsd
>>>>>
>>>>>
>>>>>
>>>>> Am 10.06.2016 um 10:26 schrieb Ed Merks:
>>>>>> Martin,
>>>>>>
>>>>>> I wonder which URIs you used the register the schemas... I'm not
>>>>>> familiar with the details of the catalog, but I imagine it's a
>>>>>> logical
>>>>>> namespace URI to physical location mapping. A correct/proper
>>>>>> interpretation of a relative path in schema import/includes should
>>>>>> resolve the relative URI of the location against the absolute URI
>>>>>> of the
>>>>>> containing schema, and that should produce another absolute path
>>>>>> (just
>>>>>> as it does for an href="..." in an HMTL document).
>>>>>>
>>>>>>
>>>>>> On 10.06.2016 09:48, Martin Jacob wrote:
>>>>>>> Hi Ed,
>>>>>>>
>>>>>>> As the emf eco system is able to handle the relative path it
>>>>>>> might be
>>>>>>> an issue of the WST XML editor.
>>>>>>> So I posted a question in eclipse.webtools forum, but no
>>>>>>> response for
>>>>>>> now.
>>>>>>>
>>>>>>> some more comments below
>>>>>>>
>>>>>>>
>>>>>>> Am 09.06.2016 um 15:43 schrieb Ed Merks:
>>>>>>>> Martin,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09.06.2016 11:49, Martin Jacob wrote:
>>>>>>>>> Thanks Ed,
>>>>>>>>>
>>>>>>>>> well, the namespace is correct but the schemaLocation is not.
>>>>>>>>>
>>>>>>>>> Yes, both xsd files are included in the distribution and I also
>>>>>>>>> unpack
>>>>>>>>> the plugin. But still no success using the WST XML editor.
>>>>>>>>> The only working solution is to use platform:/plugin/ instead of
>>>>>>>>> ../../.
>>>>>>>> I think whether it works or not depends on what URI is used to
>>>>>>>> open
>>>>>>>> the
>>>>>>>> schema that contains this reference. Or at least it should.
>>>>>>>> If the
>>>>>>>> schema itself is referenced with
>>>>>>>> platform:/plugin/<plugin-id>/<path>
>>>>>>>> then the relative path itself should resolve to
>>>>>>>> platform:/plugin/....
>>>>>>>> The platform:/plugin scheme should not require a version number.
>>>>>>> When I look into the catalogue entry (preferences > XML > XML
>>>>>>> Catalog)
>>>>>>> it says for the referencing schema:
>>>>>>>
>>>>>>> Entry element: URI
>>>>>>> Location: model\schemaB.xsd in jar file
>>>>>>> C:\Users\jacob\Documents\dev\RCP\plugins\com.xyz.b_1.0.0.201606100929.jar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> URI:
>>>>>>> jar:file:/C:/Users/jacob/Documents/dev/RCP/plugins/com.xyz.b_1.0.0.201606100929.jar!/model/schemaB.xsd
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Key type: Namespace name
>>>>>>> Key: http://xyz.com/schemaB.xsd
>>>>>>>
>>>>>>> Is there any thing suspicious?
>>>>>>>
>>>>>>>>
>>>>>>>> I know all this works for *.ecore and *.genmodel resources, so it
>>>>>>>> should
>>>>>>>> work in general. That's how relative paths should work in
>>>>>>>> general.
>>>>>>>>>
>>>>>>>>> I believe when using ../../, the correct path could not be
>>>>>>>>> resolved,
>>>>>>>>> e.g. the plugin version.
>>>>>>>>>
>>>>>>>>> So instead of ../../com.xyz.a/model/schemaA.xsd
>>>>>>>>> ../../com.xyz.a_1.0.0/model/schemaA.xsd might work but I have not
>>>>>>>>> tested.
>>>>>>>>>
>>>>>>>>> When starting the product from the IDE it works as it takes the
>>>>>>>>> source
>>>>>>>>> code/xsd directly without a version at the "plugin" folder.
>>>>>>>> Yes it should just work.
>>>>>>> Yes it does.
>>>>>>>>>
>>>>>>>>> May be it is an issue in WST XML editor catalogue to be unable to
>>>>>>>>> find
>>>>>>>>> the imported schema?
>>>>>>>> It would certainly depend on how the schema that contains this
>>>>>>>> relative
>>>>>>>> reference itself is referenced. platform:/plugin/<plugin-id>
>>>>>>>> should
>>>>>>>> work
>>>>>>>> and then the relative reference should be resolved to
>>>>>>>> platform:/plugin
>>>>>>>> as well.
>>>>>>> Both schema are inside different plugins. The structure is like
>>>>>>> this:
>>>>>>> RCP
>>>>>>> + plugins
>>>>>>> + com.xyz.a_1.0.0/model/schemaA.xsd
>>>>>>> + com.xyz.b_1.0.0/model/schemaB.xsd
>>>>>>>
>>>>>>> Where schemaB.xsd is referencing schemaA.xsd
>>>>>>>
>>>>>>>>>
>>>>>>>>> Shall I create two small sample plugins to reproduce the issue on
>>>>>>>>> your
>>>>>>>>> side?
>>>>>>>> I implemented the XSD model, so I know how relative reference
>>>>>>>> should
>>>>>>>> work. I can't comment on why it might not work with WST. That's
>>>>>>>> a Web
>>>>>>>> Tools issue. You can see in *.ecore and *.genmodel files that
>>>>>>>> these
>>>>>>>> cross resource references also look like this, and they definitely
>>>>>>>> work.
>>>>>>> Yes all works well within the IDE respectively RCP started as run
>>>>>>> configuration. But unfortunately not with the exported RCP and the
>>>>>>> WST
>>>>>>> XML editor.
>>>>>>>
>>>>>>> Do you know the xsd model you implemented is also used by the
>>>>>>> WST XML
>>>>>>> editor?
>>>>>>>
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>
>>>>>>
>>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Mar 28 19:03:05 GMT 2024
Powered by FUDForum. Page generated in 0.26545 seconds
|