Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » export model to xsd with referenced generator model
export model to xsd with referenced generator model [message #1734442] Wed, 08 June 2016 11:52 Go to next message
Martin Jacob is currently offline Martin JacobFriend
Messages: 185
Registered: July 2009
Senior Member
Hi,

I run into a problem when exporting an xsd from a genmodel which
references to another generator model. I want to use the XST XML editor,
which uses the xsd for content assistant and validation, to edit the xml
file which could be read from the generated ecore model.

Problem:

First the referenced schema was exported from an *.genmodel
(schemaA.genmodel). Then the schema referencing to the previously
exported schema was exported but the imported namespace from the
referenced generator model was not correct.

import statement:
<xsd:import namespace="http://xyz.com/schemaA.xsd"
schemaLocation="../../com.xyz.a/model/schemaA.xsd"/>

The schemaLocation contains this ../../ which works perfectly when
starting the RCP from the IDE. But after the RCP export the schemaA.xsd
could not be found.

platform:/plugin/ should be used instead of ../../



Workaround: replacing ../../ "manually" by platform:/plugin/.


Question: Is there a setting to generate the xsd by using
platform:/plugin/ instead of ../../? May be a setting at the *.genmodel?

Martin
Re: export model to xsd with referenced generator model [message #1734512 is a reply to message #1734442] Thu, 09 June 2016 06:05 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 29539
Registered: July 2009
Senior Member
Martin,

Comments below.


On 08.06.2016 13:52, Martin Jacob wrote:
> Hi,
>
> I run into a problem when exporting an xsd from a genmodel which
> references to another generator model. I want to use the XST XML
> editor, which uses the xsd for content assistant and validation, to
> edit the xml file which could be read from the generated ecore model.
>
> Problem:
>
> First the referenced schema was exported from an *.genmodel
> (schemaA.genmodel). Then the schema referencing to the previously
> exported schema was exported but the imported namespace from the
> referenced generator model was not correct.
The namespace isn't correct? It should just be the nsURI of the
EPackage. It's hard to imagine how it can not be correct... What is
the value and what should it be?
>
> import statement:
> <xsd:import namespace="http://xyz.com/schemaA.xsd"
> schemaLocation="../../com.xyz.a/model/schemaA.xsd"/>
>
> The schemaLocation contains this ../../ which works perfectly when
> starting the RCP from the IDE. But after the RCP export the
> schemaA.xsd could not be found.
Did you include it in the build.properties to be in the binary bundle?
If should be available at runtime in that case.
>
> platform:/plugin/ should be used instead of ../../
The ../.. should work even at runtime, as long as you've included it in
the build.properties so it's available at runtime in the binary
distribution.
>
>
>
> Workaround: replacing ../../ "manually" by platform:/plugin/.
>
>
> Question: Is there a setting to generate the xsd by using
> platform:/plugin/ instead of ../../? May be a setting at the *.genmodel?
No, but that shouldn't be necessary.
>
> Martin
Re: export model to xsd with referenced generator model [message #1734548 is a reply to message #1734512] Thu, 09 June 2016 09:49 Go to previous messageGo to next message
Martin Jacob is currently offline Martin JacobFriend
Messages: 185
Registered: July 2009
Senior Member
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 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.

May be it is an issue in WST XML editor catalogue to be unable to find
the imported schema?

Shall I create two small sample plugins to reproduce the issue on your side?

Martin
Re: export model to xsd with referenced generator model [message #1734577 is a reply to message #1734548] Thu, 09 June 2016 13:43 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 29539
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
Re: export model to xsd with referenced generator model [message #1734649 is a reply to message #1734577] Fri, 10 June 2016 07:48 Go to previous messageGo to next message
Martin Jacob is currently offline Martin JacobFriend
Messages: 185
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 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 29539
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
>>
Re: export model to xsd with referenced generator model [message #1734681 is a reply to message #1734659] Fri, 10 June 2016 09:30 Go to previous messageGo to next message
Martin Jacob is currently offline Martin JacobFriend
Messages: 185
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 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 29539
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
>>>>
>>
Re: export model to xsd with referenced generator model [message #1735061 is a reply to message #1734723] Wed, 15 June 2016 06:50 Go to previous messageGo to next message
Martin Jacob is currently offline Martin JacobFriend
Messages: 185
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 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 29539
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
>>>>>>
>>>>
>>
Re: export model to xsd with referenced generator model [message #1735127 is a reply to message #1735092] Wed, 15 June 2016 17:16 Go to previous messageGo to next message
Martin Jacob is currently offline Martin JacobFriend
Messages: 185
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 Go to previous messageGo to next message
Ed Merks is currently online Ed MerksFriend
Messages: 29539
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
>>>>>>>>
>>>>>>
>>>>
>>
Re: export model to xsd with referenced generator model [message #1735350 is a reply to message #1735138] Fri, 17 June 2016 13:52 Go to previous message
Martin Jacob is currently offline Martin JacobFriend
Messages: 185
Registered: July 2009
Senior Member
Hi Ed,

attached please find 2 plugins.

Plugin com.xyz.b has a ecore model, schema (b.xsd), etc.

Plugin com.xyz.a has a schema (a.xsd) referencing to x.xsd.

I think all is fine from EMF point of view but after exporting the
product the catalogue entry can't be found by the XML editor. Which is
none of your issues I belive.

For me my workaround to replace the schemaLocation with
platform:/plugin/com.xyz.b/model/b.xsd will be my solution to use the
WST XML editor.

Thanks for all your comments. I will try to get some feedback from
webtools forum.

Cheers, Martin
  • Attachment: com.xyz.zip
    (Size: 65.19KB, Downloaded 40 times)
Previous Topic:restricting access to XMI from EMFStore client.
Next Topic:[EMFStore] How to resolve checksum errors?
Goto Forum:
  


Current Time: Fri Sep 21 03:40:06 GMT 2018

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

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

Back to the top