Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Epsilon » "Resource not found" when epsilon.emf.register and permanently=true
"Resource not found" when epsilon.emf.register and permanently=true [message #574262] Mon, 17 August 2009 18:34
Antonio Garcia-Dominguez is currently offline Antonio Garcia-DominguezFriend
Messages: 309
Registered: January 2010
Senior Member
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--
Previous Topic:Wrong object type instantiated when using "new" inside EVL Quick Fixes and other issues
Next Topic:Different behavior in remove and removeAll?
Goto Forum:
  


Current Time: Thu Nov 27 00:47:24 GMT 2014

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

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