Eclipse Community Forums: Epsilon » "Resource not found" when epsilon.emf.register and permanently=true

Help

Home

Home » Modeling » Epsilon » "Resource not found" when epsilon.emf.register and permanently=true

Show: Today's Messages :: Show Polls :: Message Navigator

"Resource not found" when epsilon.emf.register and permanently=true [message #480592]

Mon, 17 August 2009 18:34

Eclipse User

Originally posted by: nyoescape.gmail.com

This is a multi-part message in MIME format.
--------------000200050906080706040500
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello everyone,

The other day I needed to perform an ETL transformation from an Ecore
model, and I wanted to use its metamodel URI instead of depending on
where it was exactly in the workspace.

I added a line like this to my Ant buildfile after the source Ecore file
had been generated from the Emfatic source:

<epsilon.emf.register file="${ecore.location}" permanently="true"/>

However, it said that the resource
"platform:/resource/home/.../mymodel.ecore" did not exist. Using this
instead worked, so I assumed that it was something in the way the
permanently attribute (false by default, if I'm not mistaken) was
interpreted:

<epsilon.emf.register file="${ecore.location}"/>

I looked at the code in o.e.e.workflow.tasks.emf.RegisterTask and it
appeared that though EmfUtil#register was OK with getting a file URI,
EmfRegistryManager#addMetamodel expected a path relative to the
workspace location. However, it was getting the absolute path to the file:

EmfRegistryManager.getInstance().addMetamodel(file.getAbsolu tePath());

I've attached a patch which modifies RegisterTask so it tries to first
convert the absolute file path to a workspace relative path, and then
hands it to EmfRegistryManager#addMetaModel. It does work, but it could
be cleaner, I guess :-D.

The bug report is available at:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=286849

Cheers,
Antonio

--------------000200050906080706040500
Content-Type: text/x-patch;
name="fix-emf-register-permanently.patch"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="fix-emf-register-permanently.patch"

SW5kZXg6IGFudC9vcmcvZWNsaXBzZS9lcHNpbG9uL3dvcmtmbG93L3Rhc2tz L2VtZi9SZWdp
c3RlclRhc2suamF2YQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBhbnQvb3JnL2VjbGlw c2UvZXBzaWxv
bi93b3JrZmxvdy90YXNrcy9lbWYvUmVnaXN0ZXJUYXNrLmphdmEJKHJldmlz acOzbjogNTI1
KQorKysgYW50L29yZy9lY2xpcHNlL2Vwc2lsb24vd29ya2Zsb3cvdGFza3Mv ZW1mL1JlZ2lz
dGVyVGFzay5qYXZhCShjb3BpYSBkZSB0cmFiYWpvKQpAQCAtMTMsNiArMTMs OCBAQAogaW1w
b3J0IGphdmEuaW8uRmlsZTsNCiANCiBpbXBvcnQgb3JnLmFwYWNoZS50b29s cy5hbnQuQnVp
bGRFeGNlcHRpb247DQoraW1wb3J0IG9yZy5lY2xpcHNlLmNvcmUucmVzb3Vy Y2VzLklGaWxl
Ow0KK2ltcG9ydCBvcmcuZWNsaXBzZS5jb3JlLnJlc291cmNlcy5SZXNvdXJj ZXNQbHVnaW47
DQogaW1wb3J0IG9yZy5lY2xpcHNlLmVtZi5jb21tb24udXRpbC5VUkk7DQog aW1wb3J0IG9y
Zy5lY2xpcHNlLmVtZi5lY29yZS5FUGFja2FnZTsNCiBpbXBvcnQgb3JnLmVj bGlwc2UuZXBz
aWxvbi5lbWMuZW1mLkVtZlV0aWw7DQpAQCAtMzMsNyArMzUsMjEgQEAKIAkJ dHJ5IHsNCiAJ
CQlFbWZVdGlsLnJlZ2lzdGVyKFVSSS5jcmVhdGVGaWxlVVJJKGZpbGUuZ2V0 QWJzb2x1dGVQ
YXRoKCkpLCBFUGFja2FnZS5SZWdpc3RyeS5JTlNUQU5DRSk7DQogCQkJaWYg KHBlcm1hbmVu
dGx5KSB7DQotCQkJCUVtZlJlZ2lzdHJ5TWFuYWdlci5nZXRJbnN0YW5jZSgp LmFkZE1ldGFt
b2RlbChmaWxlLmdldEFic29sdXRlUGF0aCgpKTsNCisJCQkgICAgLy8gTWFw IHRoZSBhYnNv
bHV0ZSBwYXRoIHRvIHRoaXMgZmlsZSB0byBhbiBJRmlsZQ0KKwkJCSAgICBq YXZhLm5ldC5V
UkkgbG9jYXRpb24gPSBmaWxlLnRvVVJJKCk7DQorCQkJICAgIElGaWxlW10g d29ya3NwYWNl
RmlsZXMNCisJCQkgICAgICA9IFJlc291cmNlc1BsdWdpbi5nZXRXb3Jrc3Bh Y2UoKS5nZXRS
b290KCkNCisJCQkgICAgICAgICAgICAgICAgICAgICAgIC5maW5kRmlsZXNG b3JMb2NhdGlv
blVSSShsb2NhdGlvbik7DQorCQkJICAgIGlmICh3b3Jrc3BhY2VGaWxlcy5s ZW5ndGggPT0g
MCkgew0KKwkJCSAgICAgIGZhaWwoIkZpbGUgIiArIGZpbGUuZ2V0QWJzb2x1 dGVQYXRoKCkN
CisJCQkgICAgICAgICAgICsgIiBpcyBub3QgYXZhaWxhYmxlIGluIHRoZSBj dXJyZW50IHdv
cmtzcGFjZSIpOw0KKwkJCSAgICB9DQorCQkJICAgIGVsc2Ugew0KKwkJCSAg ICAgIC8vIGdl
dEZ1bGxQYXRoKCkgcmV0dXJucyB0aGUgd29ya3NwYWNlIHJlbGF0aXZlIHBh dGgNCisJCQkg
ICAgICAvLyBhZGRNZXRhbW9kZWwgbmVlZHMgKGFzIGl0IHVzZXMgVVJJI2Ny ZWF0ZVBsYXRm
b3JtUmVzb3VyY2VVUkkpDQorCQkJCSAgRW1mUmVnaXN0cnlNYW5hZ2VyLmdl dEluc3RhbmNl
KCkuYWRkTWV0YW1vZGVsKA0KKwkJCQkgICAgICB3b3Jrc3BhY2VGaWxlc1sw XS5nZXRGdWxs
UGF0aCgpLnRvU3RyaW5nKCkpOw0KKwkJCSAgICB9DQogCQkJfQ0KIAkJfSBj YXRjaCAoRXhj
ZXB0aW9uIGUpIHsNCiAJCQlmYWlsKGUuZ2V0TWVzc2FnZSgpKTsNCg==
--------------000200050906080706040500--

Report message to a moderator

Re: "Resource not found" when epsilon.emf.register and permanently=true [message #480594 is a reply to message #480592]

Mon, 17 August 2009 18:37

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Hi Antonio,

(At the risk of sounding like a broken record :)) Many thanks for
reporting this and for providing a patch. I'll investigate for potential
regressions tomorrow and get back to you.

Cheers,
Dimitris

Antonio García Domínguez wrote:
> Hello everyone,
>
> The other day I needed to perform an ETL transformation from an Ecore
> model, and I wanted to use its metamodel URI instead of depending on
> where it was exactly in the workspace.
>
> I added a line like this to my Ant buildfile after the source Ecore file
> had been generated from the Emfatic source:
>
> <epsilon.emf.register file="${ecore.location}" permanently="true"/>
>
> However, it said that the resource
> "platform:/resource/home/.../mymodel.ecore" did not exist. Using this
> instead worked, so I assumed that it was something in the way the
> permanently attribute (false by default, if I'm not mistaken) was
> interpreted:
>
> <epsilon.emf.register file="${ecore.location}"/>
>
> I looked at the code in o.e.e.workflow.tasks.emf.RegisterTask and it
> appeared that though EmfUtil#register was OK with getting a file URI,
> EmfRegistryManager#addMetamodel expected a path relative to the
> workspace location. However, it was getting the absolute path to the file:
>
> EmfRegistryManager.getInstance().addMetamodel(file.getAbsolu tePath());
>
> I've attached a patch which modifies RegisterTask so it tries to first
> convert the absolute file path to a workspace relative path, and then
> hands it to EmfRegistryManager#addMetaModel. It does work, but it could
> be cleaner, I guess :-D.
>
> The bug report is available at:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=286849
>
> Cheers,
> Antonio
>

Report message to a moderator

Re: "Resource not found" when epsilon.emf.register and permanently=true [message #481004 is a reply to message #480594]

Wed, 19 August 2009 10:34

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Hi Antonio,

I've applied the patch and committed to the SVN. Thanks again!

Cheers,
Dimitris

Dimitris Kolovos wrote:
> Hi Antonio,
>
> (At the risk of sounding like a broken record :)) Many thanks for
> reporting this and for providing a patch. I'll investigate for potential
> regressions tomorrow and get back to you.
>
> Cheers,
> Dimitris
>
> Antonio García Domínguez wrote:
>> Hello everyone,
>>
>> The other day I needed to perform an ETL transformation from an Ecore
>> model, and I wanted to use its metamodel URI instead of depending on
>> where it was exactly in the workspace.
>>
>> I added a line like this to my Ant buildfile after the source Ecore file
>> had been generated from the Emfatic source:
>>
>> <epsilon.emf.register file="${ecore.location}" permanently="true"/>
>>
>> However, it said that the resource
>> "platform:/resource/home/.../mymodel.ecore" did not exist. Using this
>> instead worked, so I assumed that it was something in the way the
>> permanently attribute (false by default, if I'm not mistaken) was
>> interpreted:
>>
>> <epsilon.emf.register file="${ecore.location}"/>
>>
>> I looked at the code in o.e.e.workflow.tasks.emf.RegisterTask and it
>> appeared that though EmfUtil#register was OK with getting a file URI,
>> EmfRegistryManager#addMetamodel expected a path relative to the
>> workspace location. However, it was getting the absolute path to the
>> file:
>>
>> EmfRegistryManager.getInstance().addMetamodel(file.getAbsolu tePath());
>>
>> I've attached a patch which modifies RegisterTask so it tries to first
>> convert the absolute file path to a workspace relative path, and then
>> hands it to EmfRegistryManager#addMetaModel. It does work, but it could
>> be cleaner, I guess :-D.
>>
>> The bug report is available at:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=286849
>>
>> Cheers,
>> Antonio
>>

Report message to a moderator