Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMF Compare] Does EMF Compare really need to know about IFile and so on?
[EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123020] Tue, 27 May 2008 17:54 Go to next message
Jason Henriksen is currently offline Jason HenriksenFriend
Messages: 231
Registered: July 2009
Senior Member
Hi All,

I'm using EMF inside of a server to process XML (SOAP messages) From an
eclipse point of view I'm running headless, but really I'm up inside
of a servlet container using XML that comes in from a network connection.

The minor annoyance (I hesitate to call it a problem) is that EMF
Compare is requiring me to add the jars to hold IFile and IResource and
all this. It seems like EMF compare shouldn't have those kinds of
dependencies. I'm not using it inside eclipse at all, so I don't really
want all the eclipse meta-file-system stuff sitting around inside my
servlet container.

What are your thoughts on that? Are those classes just used for
convenience or is this indicative of a deeper need that I don't
understand yet?

Thanks,

Jason
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123032 is a reply to message #123020] Tue, 27 May 2008 19:15 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

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

Guys,

I notice this is the case purely, because of

| *public static *EObject load(IFile file, ResourceSet resourceSet) *throws *IOException {
EObject result = *null*;

*final *Map<String, String> options = *new *HashMap<String, String>();
options.put(XMLResource.OPTION_ENCODING, System.getProperty(ENCODING_PROPERTY));
// First tries to load the IFile assuming it is in the workspace
Resource modelResource = createResource(URI.createPlatformResourceURI(
file.getFullPath().toOSString(), *true*), resourceSet);
*try *{
modelResource.load(options);
} *catch *(IOException e) {
// If it failed, load the file assuming it is in the plugins
resourceSet.getResources().remove(modelResource);
modelResource = createResource(
URI.createPlatformPluginURI(file.getFullPath().toOSString(), *true*), resourceSet);
*try *{
modelResource.load(options);
} *catch *(IOException ee) {
// If it fails anew, throws the first IOException
*throw *e;
}
}
// Returns the first root of the loaded model
*if *(modelResource.getContents().size() > 0)
result = modelResource.getContents().get(0);
*return *result;
}|



I'm not sure I understand how the |createPlatformPluginURI|. A resource
might fail to load because some reference within it is wrong, and this
code will make it throw away that almost correct result and try
something that's almost bound to be completely meaningless. It seems a
bit unfortunate to introduce a hard IResource dependency for a utility
like this. Note also that the OPTION_ENCODING is a save option so has no
impact on loading. Maybe you should get rid of it. At worst, I suppose
you could make IResource an optional dependency; it might be necessary
to move the body of the method to a static nested class to avoid eager
class loading... You'd have to test that it works standalone without
loading that class when you call some other utility method...


jason henriksen wrote:
> Hi All,
>
> I'm using EMF inside of a server to process XML (SOAP messages) From
> an eclipse point of view I'm running headless, but really I'm up
> inside of a servlet container using XML that comes in from a network
> connection.
>
> The minor annoyance (I hesitate to call it a problem) is that EMF
> Compare is requiring me to add the jars to hold IFile and IResource
> and all this. It seems like EMF compare shouldn't have those kinds of
> dependencies. I'm not using it inside eclipse at all, so I don't
> really want all the eclipse meta-file-system stuff sitting around
> inside my servlet container.
>
> What are your thoughts on that? Are those classes just used for
> convenience or is this indicative of a deeper need that I don't
> understand yet?
>
> Thanks,
>
> Jason


--------------040701050007030404000502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
I notice this is the case purely, because of <br>
<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">&nbsp;&nbsp;</font><font
color="#7f0055"><b>public&nbsp;static&nbsp;</b></font ><font color="#000000">EObject&nbsp;load</font><font
color="#000000">(</font><font color="#000000"> IFile&nbsp;file,&nbsp;ResourceSet&nbsp;resourceS et </font><font
color="#000000">)&nbsp;</font><font color="#7f0055"><b>throws&nbsp;</b></font><font
color="#000000">IOException&nbsp;</font><font color="#000000">{</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">EObject&nbsp;result&nbsp;=&nbsp; </font><font
color="#7f0055"><b>null</b></font><font color="#000000">;</font><br>
<font color="#ffffff"></font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>final&nbsp;</b></font><font
color="#000000"> Map&lt;String,&nbsp;String&gt;&nbsp;options& amp;nbsp;=&nbsp; </font><font
color="#7f0055"><b>new&nbsp;</b></font><font color="#000000">HashMap&lt;String,&nbsp;String&gt; </font><font
color="#000000">()</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">options.put</font><font
color="#000000">(</font><font color="#000000">XMLResource.OPTION_ENCODING,&nbsp;System.getProperty </font><font
color="#000000">(</font><font color="#000000">ENCODING_PROPERTY</font><font
color="#000000">))</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#3f7f5f"> //&nbsp;First&nbsp;tries&nbsp;to&nbsp;load&a mp;nbsp;the&nbsp;IFile&nbsp;assuming&nbsp;it& ;nbsp;is&nbsp;in&nbsp;the&nbsp;workspace </font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000"> Resource&nbsp;modelResource&nbsp;=&nbsp;createRe source </font><font
color="#000000">(</font><font color="#000000">URI.createPlatformResourceURI</font><font
color="#000000">(</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#000000">file.getFullPath</font><font
color="#000000">()</font><font color="#000000">.toOSString</font><font
color="#000000">()</font><font color="#000000">,&nbsp;</font><font
color="#7f0055"><b>true</b></font><font color="#000000">)</font><font
color="#000000">,&nbsp;resourceSet</font><font color="#000000">)</font><font
color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>try&nbsp;</b></font><font
color="#000000">{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">modelResource.load</font><font
color="#000000">(</font><font color="#000000">options</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">}&nbsp;</font><font
color="#7f0055"><b>catch&nbsp;</b></font><font color="#000000">(</font><font
color="#000000">IOException&nbsp;e</font><font color="#000000">)&nbsp;{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#3f7f5f"> //&nbsp;If&nbsp;it&nbsp;failed,&nbsp;load&am p;nbsp;the&nbsp;file&nbsp;assuming&nbsp;it&n bsp;is&nbsp;in&nbsp;the&nbsp;plugins </font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">resourceSet.getResources</font><font
color="#000000">()</font><font color="#000000">.remove</font><font
color="#000000">(</font><font color="#000000">modelResource</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">modelResource&nbsp;=&nbsp;createResource </font><font
color="#000000">(</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">URI.createPlatformPluginURI</font><font
color="#000000">(</font><font color="#000000">file.getFullPath</font><font
color="#000000">()</font><font color="#000000">.toOSString</font><font
color="#000000">()</font><font color="#000000">,&nbsp;</font><font
color="#7f0055"><b>true</b></font><font color="#000000">)</font><font
color="#000000">,&nbsp;resourceSet</font><font color="#000000">)</font><font
color="#000000">;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#7f0055"><b>try&nbsp;</b></font><font
color="#000000">{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#000000">modelResource.load</font><font
color="#000000">(</font><font color="#000000">options</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">}&nbsp;</font><font
color="#7f0055"><b>catch&nbsp;</b></font><font color="#000000">(</font><font
color="#000000">IOException&nbsp;ee</font><font color="#000000">)&nbsp;{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#3f7f5f"> //&nbsp;If&nbsp;it&nbsp;fails&nbsp;anew,& ;nbsp;throws&nbsp;the&nbsp;first&nbsp;IOExceptio n </font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#7f0055"><b>throw&nbsp;</b></font><font
color="#000000">e;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">}</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">}</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#3f7f5f"> //&nbsp;Returns&nbsp;the&nbsp;first&nbsp;roo t&nbsp;of&nbsp;the&nbsp;loaded&nbsp;model </font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>if&nbsp;</b></font><font
color="#000000">(</font><font color="#000000">modelResource.getContents</font><font
color="#000000">()</font><font color="#000000">.size</font><font
color="#000000">()&nbsp;</font><font color="#000000">&gt;&nbsp;</font><font
color="#990000">0</font><font color="#000000">)</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">result&nbsp;=&nbsp;modelResource.getContents </font><font
color="#000000">()</font><font color="#000000">.get</font><font
color="#000000">(</font><font color="#990000">0</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>return&nbsp;</b></font><font
color="#000000">result;</font><br>
<font color="#ffffff">&nbsp;&nbsp;</font><font color="#000000">}</font></code>
</td>
<!-- end source code --> </tr>
</tbody>
</table>
</div>
<!-- = END of automatically generated HTML code = -->
<!-- ======================================================== --><br>
<br>
I'm not sure I understand how the <code><font color="#000000">createPlatformPluginURI</font></code>.&nbsp;
A resource might fail to load because some reference within it is
wrong, and this code will make it throw away that almost correct result
and try something that's almost bound to be completely meaningless.&nbsp; It
seems a bit unfortunate to introduce a hard IResource dependency for a
utility like this. Note also that the OPTION_ENCODING is a save option
so has no impact on loading.&nbsp; Maybe you should get rid of it.&nbsp; At
worst, I suppose you could make IResource an optional dependency; it
might be necessary to move the body of the method to a static nested
class to avoid eager class loading...&nbsp; You'd have to test that it works
standalone without loading that class when you call some other utility
method...<br>
<br>
<br>
jason henriksen wrote:
<blockquote cite="mid:g1hht2$4l5$1@build.eclipse.org" type="cite">Hi
All,
<br>
<br>
I'm using EMF inside of a server to process XML (SOAP messages)&nbsp; From
an &nbsp;eclipse point of view I'm running headless, but really I'm up
inside of a servlet container using XML that comes in from a network
connection.
<br>
<br>
The minor annoyance (I hesitate to call it a problem) is that EMF
Compare is requiring me to add the jars to hold IFile and IResource and
all this.&nbsp; It seems like EMF compare shouldn't have those kinds of
dependencies.&nbsp; I'm not using it inside eclipse at all, so I don't
really want all the eclipse meta-file-system stuff sitting around
inside my servlet container.
<br>
<br>
What are your thoughts on that?&nbsp; Are those classes just used for
convenience or is this indicative of a deeper need that I don't
understand yet?
<br>
<br>
&nbsp;Thanks,
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; Jason
<br>
</blockquote>
<br>
</body>
</html>

--------------040701050007030404000502--
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123256 is a reply to message #123032] Wed, 28 May 2008 09:48 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030404060205060708010605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed, Jason,

We do have an example launching EMF Compare stand-alone, and this works
without any of the org.eclipse.core.* jars. The only required
dependencies to launch EMF Compare standalone are :

- org.eclipse.emf.common 2.3 or higher
- org.eclipse.emf.ecore 2.3 or higher
- org.eclipse.emf.ecore.xmi 2.3 or higher
- org.eclipse.emf.compare 0.8 or higher
- org.eclipse.emf.compare.diff 0.8 or higher
- org.eclipse.emf.compare.match 0.8 or higher

The utility method Ed is pointing to is something that can obviously not
be used in a standalone app, it shouldn't even be called when using EMF
Compare via the MatchService and DiffService Classes.

Of course, I might very well have broken something in the last builds...
Can you confirm your use case doesn't work with only the 6 jars above
and create a bugzilla if so?

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123269 is a reply to message #123256] Wed, 28 May 2008 09:52 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000503020502060507000706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

As a side note, Ed : thanks for pointing out that the OPTION_ENCODING is
a save option, I will get rid of those since I used it everywhere for
loading :D.

laurent Goubet a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123310 is a reply to message #123256] Wed, 28 May 2008 11:18 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Laurent,

Perhaps you should consider making the plugin dependency on core
resources optional. That way someone could use this in an RCP
application without the resources plugin; that's what we did in
org.eclipse.emf.ecore... It's good to test that you can call another
utility method in that class without causing the IFile class to be
loaded to be sure that only clients that use that one utility method
will actually need core.resources.


laurent Goubet wrote:
> Ed, Jason,
>
> We do have an example launching EMF Compare stand-alone, and this
> works without any of the org.eclipse.core.* jars. The only required
> dependencies to launch EMF Compare standalone are :
>
> - org.eclipse.emf.common 2.3 or higher
> - org.eclipse.emf.ecore 2.3 or higher
> - org.eclipse.emf.ecore.xmi 2.3 or higher
> - org.eclipse.emf.compare 0.8 or higher
> - org.eclipse.emf.compare.diff 0.8 or higher
> - org.eclipse.emf.compare.match 0.8 or higher
>
> The utility method Ed is pointing to is something that can obviously
> not be used in a standalone app, it shouldn't even be called when
> using EMF Compare via the MatchService and DiffService Classes.
>
> Of course, I might very well have broken something in the last
> builds... Can you confirm your use case doesn't work with only the 6
> jars above and create a bugzilla if so?
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Guys,
>>
>> I notice this is the case purely, because of
>>
>> | *public static *EObject load(IFile file, ResourceSet resourceSet)
>> *throws *IOException {
>> EObject result = *null*;
>>
>> *final *Map<String, String> options = *new *HashMap<String,
>> String>();
>> options.put(XMLResource.OPTION_ENCODING,
>> System.getProperty(ENCODING_PROPERTY));
>> // First tries to load the IFile assuming it is in the workspace
>> Resource modelResource =
>> createResource(URI.createPlatformResourceURI(
>> file.getFullPath().toOSString(), *true*), resourceSet);
>> *try *{
>> modelResource.load(options);
>> } *catch *(IOException e) {
>> // If it failed, load the file assuming it is in the plugins
>> resourceSet.getResources().remove(modelResource);
>> modelResource = createResource(
>>
>> URI.createPlatformPluginURI(file.getFullPath().toOSString(), *true*),
>> resourceSet);
>> *try *{
>> modelResource.load(options);
>> } *catch *(IOException ee) {
>> // If it fails anew, throws the first IOException
>> *throw *e;
>> }
>> }
>> // Returns the first root of the loaded model
>> *if *(modelResource.getContents().size() > 0)
>> result = modelResource.getContents().get(0);
>> *return *result;
>> }|
>>
>>
>>
>> I'm not sure I understand how the |createPlatformPluginURI|. A
>> resource might fail to load because some reference within it is
>> wrong, and this code will make it throw away that almost correct
>> result and try something that's almost bound to be completely
>> meaningless. It seems a bit unfortunate to introduce a hard
>> IResource dependency for a utility like this. Note also that the
>> OPTION_ENCODING is a save option so has no impact on loading. Maybe
>> you should get rid of it. At worst, I suppose you could make
>> IResource an optional dependency; it might be necessary to move the
>> body of the method to a static nested class to avoid eager class
>> loading... You'd have to test that it works standalone without
>> loading that class when you call some other utility method...
>>
>>
>> jason henriksen wrote:
>>> Hi All,
>>>
>>> I'm using EMF inside of a server to process XML (SOAP messages)
>>> From an eclipse point of view I'm running headless, but really I'm
>>> up inside of a servlet container using XML that comes in from a
>>> network connection.
>>>
>>> The minor annoyance (I hesitate to call it a problem) is that EMF
>>> Compare is requiring me to add the jars to hold IFile and IResource
>>> and all this. It seems like EMF compare shouldn't have those kinds
>>> of dependencies. I'm not using it inside eclipse at all, so I don't
>>> really want all the eclipse meta-file-system stuff sitting around
>>> inside my servlet container.
>>>
>>> What are your thoughts on that? Are those classes just used for
>>> convenience or is this indicative of a deeper need that I don't
>>> understand yet?
>>>
>>> Thanks,
>>>
>>> Jason
>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123324 is a reply to message #123310] Wed, 28 May 2008 11:31 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070301050600090705080606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

I didn't know there was a way to set "optional" dependencies, just
commited this change on our plugins (Jason : we're currently building
for RC2, this change will appear in that build).

Yet I wonder : what exactly does setting a dependency "optional"
changes? As I mentionned earlier, we could already use EMF Compare stand
alone (no eclipse headless or whatnot, directly via java -jar on a
builded jar of a simple "main" class launching a comparison), and that
worked fine without having org.eclipse.core.* jars in the classpath.

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123336 is a reply to message #123324] Wed, 28 May 2008 12:01 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Laurent,

Comments below.

laurent Goubet wrote:
> Ed,
>
> I didn't know there was a way to set "optional" dependencies, just
> commited this change on our plugins (Jason : we're currently building
> for RC2, this change will appear in that build).
When you learn something new, it's a good day. :-P
>
> Yet I wonder : what exactly does setting a dependency "optional" changes?
If something is a normal dependency you are declaring that the plugin
will only work if the plugins on which it depends are actually present.
An optional dependency specifies that your plugin will make use of the
dependency if present, but will continue to function well even when the
dependency is not present. So for Ecore we've designed it such that it
can exploit IResources (for things like handling platform:/resource
URIs) but will also work fine if you don't make use of IResources.
> As I mentionned earlier, we could already use EMF Compare stand alone
> (no eclipse headless or whatnot, directly via java -jar on a builded
> jar of a simple "main" class launching a comparison), and that worked
> fine without having org.eclipse.core.* jars in the classpath.
Yes, I was just wondering if that test used any of the other methods in
the utility class. Sometimes Java's class loader is a bit eager and in
those cases, moving the code to a separate class (like our EclipseUtil
classes) helps to defer to loading...
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Laurent,
>>
>> Perhaps you should consider making the plugin dependency on core
>> resources optional. That way someone could use this in an RCP
>> application without the resources plugin; that's what we did in
>> org.eclipse.emf.ecore... It's good to test that you can call another
>> utility method in that class without causing the IFile class to be
>> loaded to be sure that only clients that use that one utility method
>> will actually need core.resources.
>>
>>
>> laurent Goubet wrote:
>>> Ed, Jason,
>>>
>>> We do have an example launching EMF Compare stand-alone, and this
>>> works without any of the org.eclipse.core.* jars. The only required
>>> dependencies to launch EMF Compare standalone are :
>>>
>>> - org.eclipse.emf.common 2.3 or higher
>>> - org.eclipse.emf.ecore 2.3 or higher
>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>> - org.eclipse.emf.compare 0.8 or higher
>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>
>>> The utility method Ed is pointing to is something that can obviously
>>> not be used in a standalone app, it shouldn't even be called when
>>> using EMF Compare via the MatchService and DiffService Classes.
>>>
>>> Of course, I might very well have broken something in the last
>>> builds... Can you confirm your use case doesn't work with only the 6
>>> jars above and create a bugzilla if so?
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Ed Merks a écrit :
>>>> Guys,
>>>>
>>>> I notice this is the case purely, because of
>>>>
>>>> | *public static *EObject load(IFile file, ResourceSet
>>>> resourceSet) *throws *IOException {
>>>> EObject result = *null*;
>>>>
>>>> *final *Map<String, String> options = *new *HashMap<String,
>>>> String>();
>>>> options.put(XMLResource.OPTION_ENCODING,
>>>> System.getProperty(ENCODING_PROPERTY));
>>>> // First tries to load the IFile assuming it is in the workspace
>>>> Resource modelResource =
>>>> createResource(URI.createPlatformResourceURI(
>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>> *try *{
>>>> modelResource.load(options);
>>>> } *catch *(IOException e) {
>>>> // If it failed, load the file assuming it is in the plugins
>>>> resourceSet.getResources().remove(modelResource);
>>>> modelResource = createResource(
>>>>
>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>> *true*), resourceSet);
>>>> *try *{
>>>> modelResource.load(options);
>>>> } *catch *(IOException ee) {
>>>> // If it fails anew, throws the first IOException
>>>> *throw *e;
>>>> }
>>>> }
>>>> // Returns the first root of the loaded model
>>>> *if *(modelResource.getContents().size() > 0)
>>>> result = modelResource.getContents().get(0);
>>>> *return *result;
>>>> }|
>>>>
>>>>
>>>>
>>>> I'm not sure I understand how the |createPlatformPluginURI|. A
>>>> resource might fail to load because some reference within it is
>>>> wrong, and this code will make it throw away that almost correct
>>>> result and try something that's almost bound to be completely
>>>> meaningless. It seems a bit unfortunate to introduce a hard
>>>> IResource dependency for a utility like this. Note also that the
>>>> OPTION_ENCODING is a save option so has no impact on loading.
>>>> Maybe you should get rid of it. At worst, I suppose you could make
>>>> IResource an optional dependency; it might be necessary to move the
>>>> body of the method to a static nested class to avoid eager class
>>>> loading... You'd have to test that it works standalone without
>>>> loading that class when you call some other utility method...
>>>>
>>>>
>>>> jason henriksen wrote:
>>>>> Hi All,
>>>>>
>>>>> I'm using EMF inside of a server to process XML (SOAP messages)
>>>>> From an eclipse point of view I'm running headless, but really
>>>>> I'm up inside of a servlet container using XML that comes in from
>>>>> a network connection.
>>>>>
>>>>> The minor annoyance (I hesitate to call it a problem) is that EMF
>>>>> Compare is requiring me to add the jars to hold IFile and
>>>>> IResource and all this. It seems like EMF compare shouldn't have
>>>>> those kinds of dependencies. I'm not using it inside eclipse at
>>>>> all, so I don't really want all the eclipse meta-file-system stuff
>>>>> sitting around inside my servlet container.
>>>>>
>>>>> What are your thoughts on that? Are those classes just used for
>>>>> convenience or is this indicative of a deeper need that I don't
>>>>> understand yet?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>
>>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123349 is a reply to message #123336] Wed, 28 May 2008 12:13 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090502070802040104090103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

Thanks for the clarification, I guess this "optional" resolution for
dependencies is only set to give this information to clients but isn't
actually used by either compiler or builder then.

As for your latter question, we use methods from this utility class
throughout the code of EMF Compare, and the example is no exception... I
might very well be lucky with the class loader (for once).

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123362 is a reply to message #123349] Wed, 28 May 2008 12:23 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Laurent,

Comments below.

laurent Goubet wrote:
> Ed,
>
> Thanks for the clarification, I guess this "optional" resolution for
> dependencies is only set to give this information to clients but isn't
> actually used by either compiler or builder then.
Exactly. It's also useful for clients building a minimal runtime
configuration (in the Run configurations dialogs) since optional
dependencies won't be included.
>
> As for your latter question, we use methods from this utility class
> throughout the code of EMF Compare, and the example is no exception...
> I might very well be lucky with the class loader (for once).
Class loaders do generally try to be very lazy.
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Laurent,
>>
>> Comments below.
>>
>> laurent Goubet wrote:
>>> Ed,
>>>
>>> I didn't know there was a way to set "optional" dependencies, just
>>> commited this change on our plugins (Jason : we're currently
>>> building for RC2, this change will appear in that build).
>> When you learn something new, it's a good day. :-P
>>>
>>> Yet I wonder : what exactly does setting a dependency "optional"
>>> changes?
>> If something is a normal dependency you are declaring that the plugin
>> will only work if the plugins on which it depends are actually
>> present. An optional dependency specifies that your plugin will make
>> use of the dependency if present, but will continue to function well
>> even when the dependency is not present. So for Ecore we've designed
>> it such that it can exploit IResources (for things like handling
>> platform:/resource URIs) but will also work fine if you don't make
>> use of IResources.
>>> As I mentionned earlier, we could already use EMF Compare stand
>>> alone (no eclipse headless or whatnot, directly via java -jar on a
>>> builded jar of a simple "main" class launching a comparison), and
>>> that worked fine without having org.eclipse.core.* jars in the
>>> classpath.
>> Yes, I was just wondering if that test used any of the other methods
>> in the utility class. Sometimes Java's class loader is a bit eager
>> and in those cases, moving the code to a separate class (like our
>> EclipseUtil classes) helps to defer to loading...
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Ed Merks a écrit :
>>>> Laurent,
>>>>
>>>> Perhaps you should consider making the plugin dependency on core
>>>> resources optional. That way someone could use this in an RCP
>>>> application without the resources plugin; that's what we did in
>>>> org.eclipse.emf.ecore... It's good to test that you can call
>>>> another utility method in that class without causing the IFile
>>>> class to be loaded to be sure that only clients that use that one
>>>> utility method will actually need core.resources.
>>>>
>>>>
>>>> laurent Goubet wrote:
>>>>> Ed, Jason,
>>>>>
>>>>> We do have an example launching EMF Compare stand-alone, and this
>>>>> works without any of the org.eclipse.core.* jars. The only
>>>>> required dependencies to launch EMF Compare standalone are :
>>>>>
>>>>> - org.eclipse.emf.common 2.3 or higher
>>>>> - org.eclipse.emf.ecore 2.3 or higher
>>>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>>>> - org.eclipse.emf.compare 0.8 or higher
>>>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>>>
>>>>> The utility method Ed is pointing to is something that can
>>>>> obviously not be used in a standalone app, it shouldn't even be
>>>>> called when using EMF Compare via the MatchService and DiffService
>>>>> Classes.
>>>>>
>>>>> Of course, I might very well have broken something in the last
>>>>> builds... Can you confirm your use case doesn't work with only the
>>>>> 6 jars above and create a bugzilla if so?
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Guys,
>>>>>>
>>>>>> I notice this is the case purely, because of
>>>>>>
>>>>>> | *public static *EObject load(IFile file, ResourceSet
>>>>>> resourceSet) *throws *IOException {
>>>>>> EObject result = *null*;
>>>>>>
>>>>>> *final *Map<String, String> options = *new *HashMap<String,
>>>>>> String>();
>>>>>> options.put(XMLResource.OPTION_ENCODING,
>>>>>> System.getProperty(ENCODING_PROPERTY));
>>>>>> // First tries to load the IFile assuming it is in the workspace
>>>>>> Resource modelResource =
>>>>>> createResource(URI.createPlatformResourceURI(
>>>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>>>> *try *{
>>>>>> modelResource.load(options);
>>>>>> } *catch *(IOException e) {
>>>>>> // If it failed, load the file assuming it is in the plugins
>>>>>> resourceSet.getResources().remove(modelResource);
>>>>>> modelResource = createResource(
>>>>>>
>>>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>>>> *true*), resourceSet);
>>>>>> *try *{
>>>>>> modelResource.load(options);
>>>>>> } *catch *(IOException ee) {
>>>>>> // If it fails anew, throws the first IOException
>>>>>> *throw *e;
>>>>>> }
>>>>>> }
>>>>>> // Returns the first root of the loaded model
>>>>>> *if *(modelResource.getContents().size() > 0)
>>>>>> result = modelResource.getContents().get(0);
>>>>>> *return *result;
>>>>>> }|
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not sure I understand how the |createPlatformPluginURI|. A
>>>>>> resource might fail to load because some reference within it is
>>>>>> wrong, and this code will make it throw away that almost correct
>>>>>> result and try something that's almost bound to be completely
>>>>>> meaningless. It seems a bit unfortunate to introduce a hard
>>>>>> IResource dependency for a utility like this. Note also that the
>>>>>> OPTION_ENCODING is a save option so has no impact on loading.
>>>>>> Maybe you should get rid of it. At worst, I suppose you could
>>>>>> make IResource an optional dependency; it might be necessary to
>>>>>> move the body of the method to a static nested class to avoid
>>>>>> eager class loading... You'd have to test that it works
>>>>>> standalone without loading that class when you call some other
>>>>>> utility method...
>>>>>>
>>>>>>
>>>>>> jason henriksen wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I'm using EMF inside of a server to process XML (SOAP messages)
>>>>>>> From an eclipse point of view I'm running headless, but really
>>>>>>> I'm up inside of a servlet container using XML that comes in
>>>>>>> from a network connection.
>>>>>>>
>>>>>>> The minor annoyance (I hesitate to call it a problem) is that
>>>>>>> EMF Compare is requiring me to add the jars to hold IFile and
>>>>>>> IResource and all this. It seems like EMF compare shouldn't
>>>>>>> have those kinds of dependencies. I'm not using it inside
>>>>>>> eclipse at all, so I don't really want all the eclipse
>>>>>>> meta-file-system stuff sitting around inside my servlet container.
>>>>>>>
>>>>>>> What are your thoughts on that? Are those classes just used for
>>>>>>> convenience or is this indicative of a deeper need that I don't
>>>>>>> understand yet?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jason
>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123531 is a reply to message #123362] Thu, 29 May 2008 08:02 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030700020205080009060605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jason,

A little update; I indeed found a problem with this
org.eclipse.core.runtime dependency when calling some of ModelUtils'
utility methods (seems I _was_ lucky with the class loader after all).

As Ed suggested, I will move the offending methods to another utility
class (probably EclipseModelUtils) in order to get rid of these direct
dependencies to org.eclipse.core.runtime.* as per bug 234544
https://bugs.eclipse.org/bugs/show_bug.cgi?id=234544 .

Thank you for your feedback.

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123741 is a reply to message #123531] Thu, 29 May 2008 16:57 Go to previous messageGo to next message
Jason Henriksen is currently offline Jason HenriksenFriend
Messages: 231
Registered: July 2009
Senior Member
You guys are fantastic. Thanks!

Jason


laurent Goubet wrote:
> Jason,
>
> A little update; I indeed found a problem with this
> org.eclipse.core.runtime dependency when calling some of ModelUtils'
> utility methods (seems I _was_ lucky with the class loader after all).
>
> As Ed suggested, I will move the offending methods to another utility
> class (probably EclipseModelUtils) in order to get rid of these direct
> dependencies to org.eclipse.core.runtime.* as per bug 234544
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=234544 .
>
> Thank you for your feedback.
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Laurent,
>>
>> Comments below.
>>
>> laurent Goubet wrote:
>>> Ed,
>>>
>>> Thanks for the clarification, I guess this "optional" resolution for
>>> dependencies is only set to give this information to clients but
>>> isn't actually used by either compiler or builder then.
>> Exactly. It's also useful for clients building a minimal runtime
>> configuration (in the Run configurations dialogs) since optional
>> dependencies won't be included.
>>>
>>> As for your latter question, we use methods from this utility class
>>> throughout the code of EMF Compare, and the example is no
>>> exception... I might very well be lucky with the class loader (for
>>> once).
>> Class loaders do generally try to be very lazy.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Ed Merks a écrit :
>>>> Laurent,
>>>>
>>>> Comments below.
>>>>
>>>> laurent Goubet wrote:
>>>>> Ed,
>>>>>
>>>>> I didn't know there was a way to set "optional" dependencies, just
>>>>> commited this change on our plugins (Jason : we're currently
>>>>> building for RC2, this change will appear in that build).
>>>> When you learn something new, it's a good day. :-P
>>>>>
>>>>> Yet I wonder : what exactly does setting a dependency "optional"
>>>>> changes?
>>>> If something is a normal dependency you are declaring that the
>>>> plugin will only work if the plugins on which it depends are
>>>> actually present. An optional dependency specifies that your plugin
>>>> will make use of the dependency if present, but will continue to
>>>> function well even when the dependency is not present. So for Ecore
>>>> we've designed it such that it can exploit IResources (for things
>>>> like handling platform:/resource URIs) but will also work fine if
>>>> you don't make use of IResources.
>>>>> As I mentionned earlier, we could already use EMF Compare stand
>>>>> alone (no eclipse headless or whatnot, directly via java -jar on a
>>>>> builded jar of a simple "main" class launching a comparison), and
>>>>> that worked fine without having org.eclipse.core.* jars in the
>>>>> classpath.
>>>> Yes, I was just wondering if that test used any of the other methods
>>>> in the utility class. Sometimes Java's class loader is a bit eager
>>>> and in those cases, moving the code to a separate class (like our
>>>> EclipseUtil classes) helps to defer to loading...
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Laurent,
>>>>>>
>>>>>> Perhaps you should consider making the plugin dependency on core
>>>>>> resources optional. That way someone could use this in an RCP
>>>>>> application without the resources plugin; that's what we did in
>>>>>> org.eclipse.emf.ecore... It's good to test that you can call
>>>>>> another utility method in that class without causing the IFile
>>>>>> class to be loaded to be sure that only clients that use that one
>>>>>> utility method will actually need core.resources.
>>>>>>
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Ed, Jason,
>>>>>>>
>>>>>>> We do have an example launching EMF Compare stand-alone, and this
>>>>>>> works without any of the org.eclipse.core.* jars. The only
>>>>>>> required dependencies to launch EMF Compare standalone are :
>>>>>>>
>>>>>>> - org.eclipse.emf.common 2.3 or higher
>>>>>>> - org.eclipse.emf.ecore 2.3 or higher
>>>>>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>>>>>> - org.eclipse.emf.compare 0.8 or higher
>>>>>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>>>>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>>>>>
>>>>>>> The utility method Ed is pointing to is something that can
>>>>>>> obviously not be used in a standalone app, it shouldn't even be
>>>>>>> called when using EMF Compare via the MatchService and
>>>>>>> DiffService Classes.
>>>>>>>
>>>>>>> Of course, I might very well have broken something in the last
>>>>>>> builds... Can you confirm your use case doesn't work with only
>>>>>>> the 6 jars above and create a bugzilla if so?
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Ed Merks a écrit :
>>>>>>>> Guys,
>>>>>>>>
>>>>>>>> I notice this is the case purely, because of
>>>>>>>>
>>>>>>>> | *public static *EObject load(IFile file, ResourceSet
>>>>>>>> resourceSet) *throws *IOException {
>>>>>>>> EObject result = *null*;
>>>>>>>>
>>>>>>>> *final *Map<String, String> options = *new *HashMap<String,
>>>>>>>> String>();
>>>>>>>> options.put(XMLResource.OPTION_ENCODING,
>>>>>>>> System.getProperty(ENCODING_PROPERTY));
>>>>>>>> // First tries to load the IFile assuming it is in the
>>>>>>>> workspace
>>>>>>>> Resource modelResource =
>>>>>>>> createResource(URI.createPlatformResourceURI(
>>>>>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>>>>>> *try *{
>>>>>>>> modelResource.load(options);
>>>>>>>> } *catch *(IOException e) {
>>>>>>>> // If it failed, load the file assuming it is in the plugins
>>>>>>>> resourceSet.getResources().remove(modelResource);
>>>>>>>> modelResource = createResource(
>>>>>>>>
>>>>>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>>>>>> *true*), resourceSet);
>>>>>>>> *try *{
>>>>>>>> modelResource.load(options);
>>>>>>>> } *catch *(IOException ee) {
>>>>>>>> // If it fails anew, throws the first IOException
>>>>>>>> *throw *e;
>>>>>>>> }
>>>>>>>> }
>>>>>>>> // Returns the first root of the loaded model
>>>>>>>> *if *(modelResource.getContents().size() > 0)
>>>>>>>> result = modelResource.getContents().get(0);
>>>>>>>> *return *result;
>>>>>>>> }|
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure I understand how the |createPlatformPluginURI|. A
>>>>>>>> resource might fail to load because some reference within it is
>>>>>>>> wrong, and this code will make it throw away that almost correct
>>>>>>>> result and try something that's almost bound to be completely
>>>>>>>> meaningless. It seems a bit unfortunate to introduce a hard
>>>>>>>> IResource dependency for a utility like this. Note also that the
>>>>>>>> OPTION_ENCODING is a save option so has no impact on loading.
>>>>>>>> Maybe you should get rid of it. At worst, I suppose you could
>>>>>>>> make IResource an optional dependency; it might be necessary to
>>>>>>>> move the body of the method to a static nested class to avoid
>>>>>>>> eager class loading... You'd have to test that it works
>>>>>>>> standalone without loading that class when you call some other
>>>>>>>> utility method...
>>>>>>>>
>>>>>>>>
>>>>>>>> jason henriksen wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> I'm using EMF inside of a server to process XML (SOAP
>>>>>>>>> messages) From an eclipse point of view I'm running headless,
>>>>>>>>> but really I'm up inside of a servlet container using XML that
>>>>>>>>> comes in from a network connection.
>>>>>>>>>
>>>>>>>>> The minor annoyance (I hesitate to call it a problem) is that
>>>>>>>>> EMF Compare is requiring me to add the jars to hold IFile and
>>>>>>>>> IResource and all this. It seems like EMF compare shouldn't
>>>>>>>>> have those kinds of dependencies. I'm not using it inside
>>>>>>>>> eclipse at all, so I don't really want all the eclipse
>>>>>>>>> meta-file-system stuff sitting around inside my servlet container.
>>>>>>>>>
>>>>>>>>> What are your thoughts on that? Are those classes just used
>>>>>>>>> for convenience or is this indicative of a deeper need that I
>>>>>>>>> don't understand yet?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #123802 is a reply to message #123741] Thu, 29 May 2008 17:30 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Jason,

Yes, we've got quite the excellent group here! :-)


jason henriksen wrote:
>
> You guys are fantastic. Thanks!
>
> Jason
>
>
> laurent Goubet wrote:
>> Jason,
>>
>> A little update; I indeed found a problem with this
>> org.eclipse.core.runtime dependency when calling some of ModelUtils'
>> utility methods (seems I _was_ lucky with the class loader after all).
>>
>> As Ed suggested, I will move the offending methods to another utility
>> class (probably EclipseModelUtils) in order to get rid of these
>> direct dependencies to org.eclipse.core.runtime.* as per bug 234544
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=234544 .
>>
>> Thank you for your feedback.
>>
>> Laurent Goubet
>> Obeo
>>
>> Ed Merks a écrit :
>>> Laurent,
>>>
>>> Comments below.
>>>
>>> laurent Goubet wrote:
>>>> Ed,
>>>>
>>>> Thanks for the clarification, I guess this "optional" resolution
>>>> for dependencies is only set to give this information to clients
>>>> but isn't actually used by either compiler or builder then.
>>> Exactly. It's also useful for clients building a minimal runtime
>>> configuration (in the Run configurations dialogs) since optional
>>> dependencies won't be included.
>>>>
>>>> As for your latter question, we use methods from this utility class
>>>> throughout the code of EMF Compare, and the example is no
>>>> exception... I might very well be lucky with the class loader (for
>>>> once).
>>> Class loaders do generally try to be very lazy.
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Ed Merks a écrit :
>>>>> Laurent,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> laurent Goubet wrote:
>>>>>> Ed,
>>>>>>
>>>>>> I didn't know there was a way to set "optional" dependencies,
>>>>>> just commited this change on our plugins (Jason : we're currently
>>>>>> building for RC2, this change will appear in that build).
>>>>> When you learn something new, it's a good day. :-P
>>>>>>
>>>>>> Yet I wonder : what exactly does setting a dependency "optional"
>>>>>> changes?
>>>>> If something is a normal dependency you are declaring that the
>>>>> plugin will only work if the plugins on which it depends are
>>>>> actually present. An optional dependency specifies that your
>>>>> plugin will make use of the dependency if present, but will
>>>>> continue to function well even when the dependency is not
>>>>> present. So for Ecore we've designed it such that it can exploit
>>>>> IResources (for things like handling platform:/resource URIs) but
>>>>> will also work fine if you don't make use of IResources.
>>>>>> As I mentionned earlier, we could already use EMF Compare stand
>>>>>> alone (no eclipse headless or whatnot, directly via java -jar on
>>>>>> a builded jar of a simple "main" class launching a comparison),
>>>>>> and that worked fine without having org.eclipse.core.* jars in
>>>>>> the classpath.
>>>>> Yes, I was just wondering if that test used any of the other
>>>>> methods in the utility class. Sometimes Java's class loader is a
>>>>> bit eager and in those cases, moving the code to a separate class
>>>>> (like our EclipseUtil classes) helps to defer to loading...
>>>>>>
>>>>>> Laurent Goubet
>>>>>> Obeo
>>>>>>
>>>>>> Ed Merks a écrit :
>>>>>>> Laurent,
>>>>>>>
>>>>>>> Perhaps you should consider making the plugin dependency on core
>>>>>>> resources optional. That way someone could use this in an RCP
>>>>>>> application without the resources plugin; that's what we did in
>>>>>>> org.eclipse.emf.ecore... It's good to test that you can call
>>>>>>> another utility method in that class without causing the IFile
>>>>>>> class to be loaded to be sure that only clients that use that
>>>>>>> one utility method will actually need core.resources.
>>>>>>>
>>>>>>>
>>>>>>> laurent Goubet wrote:
>>>>>>>> Ed, Jason,
>>>>>>>>
>>>>>>>> We do have an example launching EMF Compare stand-alone, and
>>>>>>>> this works without any of the org.eclipse.core.* jars. The only
>>>>>>>> required dependencies to launch EMF Compare standalone are :
>>>>>>>>
>>>>>>>> - org.eclipse.emf.common 2.3 or higher
>>>>>>>> - org.eclipse.emf.ecore 2.3 or higher
>>>>>>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>>>>>>> - org.eclipse.emf.compare 0.8 or higher
>>>>>>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>>>>>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>>>>>>
>>>>>>>> The utility method Ed is pointing to is something that can
>>>>>>>> obviously not be used in a standalone app, it shouldn't even be
>>>>>>>> called when using EMF Compare via the MatchService and
>>>>>>>> DiffService Classes.
>>>>>>>>
>>>>>>>> Of course, I might very well have broken something in the last
>>>>>>>> builds... Can you confirm your use case doesn't work with only
>>>>>>>> the 6 jars above and create a bugzilla if so?
>>>>>>>>
>>>>>>>> Laurent Goubet
>>>>>>>> Obeo
>>>>>>>>
>>>>>>>> Ed Merks a écrit :
>>>>>>>>> Guys,
>>>>>>>>>
>>>>>>>>> I notice this is the case purely, because of
>>>>>>>>>
>>>>>>>>> | *public static *EObject load(IFile file, ResourceSet
>>>>>>>>> resourceSet) *throws *IOException {
>>>>>>>>> EObject result = *null*;
>>>>>>>>>
>>>>>>>>> *final *Map<String, String> options = *new
>>>>>>>>> *HashMap<String, String>();
>>>>>>>>> options.put(XMLResource.OPTION_ENCODING,
>>>>>>>>> System.getProperty(ENCODING_PROPERTY));
>>>>>>>>> // First tries to load the IFile assuming it is in the
>>>>>>>>> workspace
>>>>>>>>> Resource modelResource =
>>>>>>>>> createResource(URI.createPlatformResourceURI(
>>>>>>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>>>>>>> *try *{
>>>>>>>>> modelResource.load(options);
>>>>>>>>> } *catch *(IOException e) {
>>>>>>>>> // If it failed, load the file assuming it is in the
>>>>>>>>> plugins
>>>>>>>>> resourceSet.getResources().remove(modelResource);
>>>>>>>>> modelResource = createResource(
>>>>>>>>>
>>>>>>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>>>>>>> *true*), resourceSet);
>>>>>>>>> *try *{
>>>>>>>>> modelResource.load(options);
>>>>>>>>> } *catch *(IOException ee) {
>>>>>>>>> // If it fails anew, throws the first IOException
>>>>>>>>> *throw *e;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> // Returns the first root of the loaded model
>>>>>>>>> *if *(modelResource.getContents().size() > 0)
>>>>>>>>> result = modelResource.getContents().get(0);
>>>>>>>>> *return *result;
>>>>>>>>> }|
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure I understand how the |createPlatformPluginURI|.
>>>>>>>>> A resource might fail to load because some reference within it
>>>>>>>>> is wrong, and this code will make it throw away that almost
>>>>>>>>> correct result and try something that's almost bound to be
>>>>>>>>> completely meaningless. It seems a bit unfortunate to
>>>>>>>>> introduce a hard IResource dependency for a utility like this.
>>>>>>>>> Note also that the OPTION_ENCODING is a save option so has no
>>>>>>>>> impact on loading. Maybe you should get rid of it. At worst,
>>>>>>>>> I suppose you could make IResource an optional dependency; it
>>>>>>>>> might be necessary to move the body of the method to a static
>>>>>>>>> nested class to avoid eager class loading... You'd have to
>>>>>>>>> test that it works standalone without loading that class when
>>>>>>>>> you call some other utility method...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> jason henriksen wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> I'm using EMF inside of a server to process XML (SOAP
>>>>>>>>>> messages) From an eclipse point of view I'm running
>>>>>>>>>> headless, but really I'm up inside of a servlet container
>>>>>>>>>> using XML that comes in from a network connection.
>>>>>>>>>>
>>>>>>>>>> The minor annoyance (I hesitate to call it a problem) is that
>>>>>>>>>> EMF Compare is requiring me to add the jars to hold IFile and
>>>>>>>>>> IResource and all this. It seems like EMF compare shouldn't
>>>>>>>>>> have those kinds of dependencies. I'm not using it inside
>>>>>>>>>> eclipse at all, so I don't really want all the eclipse
>>>>>>>>>> meta-file-system stuff sitting around inside my servlet
>>>>>>>>>> container.
>>>>>>>>>>
>>>>>>>>>> What are your thoughts on that? Are those classes just used
>>>>>>>>>> for convenience or is this indicative of a deeper need that I
>>>>>>>>>> don't understand yet?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Jason
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #618989 is a reply to message #123020] Tue, 27 May 2008 19:15 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31033
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040701050007030404000502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Guys,

I notice this is the case purely, because of

| *public static *EObject load(IFile file, ResourceSet resourceSet) *throws *IOException {
EObject result = *null*;

*final *Map<String, String> options = *new *HashMap<String, String>();
options.put(XMLResource.OPTION_ENCODING, System.getProperty(ENCODING_PROPERTY));
// First tries to load the IFile assuming it is in the workspace
Resource modelResource = createResource(URI.createPlatformResourceURI(
file.getFullPath().toOSString(), *true*), resourceSet);
*try *{
modelResource.load(options);
} *catch *(IOException e) {
// If it failed, load the file assuming it is in the plugins
resourceSet.getResources().remove(modelResource);
modelResource = createResource(
URI.createPlatformPluginURI(file.getFullPath().toOSString(), *true*), resourceSet);
*try *{
modelResource.load(options);
} *catch *(IOException ee) {
// If it fails anew, throws the first IOException
*throw *e;
}
}
// Returns the first root of the loaded model
*if *(modelResource.getContents().size() > 0)
result = modelResource.getContents().get(0);
*return *result;
}|



I'm not sure I understand how the |createPlatformPluginURI|. A resource
might fail to load because some reference within it is wrong, and this
code will make it throw away that almost correct result and try
something that's almost bound to be completely meaningless. It seems a
bit unfortunate to introduce a hard IResource dependency for a utility
like this. Note also that the OPTION_ENCODING is a save option so has no
impact on loading. Maybe you should get rid of it. At worst, I suppose
you could make IResource an optional dependency; it might be necessary
to move the body of the method to a static nested class to avoid eager
class loading... You'd have to test that it works standalone without
loading that class when you call some other utility method...


jason henriksen wrote:
> Hi All,
>
> I'm using EMF inside of a server to process XML (SOAP messages) From
> an eclipse point of view I'm running headless, but really I'm up
> inside of a servlet container using XML that comes in from a network
> connection.
>
> The minor annoyance (I hesitate to call it a problem) is that EMF
> Compare is requiring me to add the jars to hold IFile and IResource
> and all this. It seems like EMF compare shouldn't have those kinds of
> dependencies. I'm not using it inside eclipse at all, so I don't
> really want all the eclipse meta-file-system stuff sitting around
> inside my servlet container.
>
> What are your thoughts on that? Are those classes just used for
> convenience or is this indicative of a deeper need that I don't
> understand yet?
>
> Thanks,
>
> Jason


--------------040701050007030404000502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
I notice this is the case purely, because of <br>
<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">&nbsp;&nbsp;</font><font
color="#7f0055"><b>public&nbsp;static&nbsp;</b></font ><font color="#000000">EObject&nbsp;load</font><font
color="#000000">(</font><font color="#000000"> IFile&nbsp;file,&nbsp;ResourceSet&nbsp;resourceS et </font><font
color="#000000">)&nbsp;</font><font color="#7f0055"><b>throws&nbsp;</b></font><font
color="#000000">IOException&nbsp;</font><font color="#000000">{</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">EObject&nbsp;result&nbsp;=&nbsp; </font><font
color="#7f0055"><b>null</b></font><font color="#000000">;</font><br>
<font color="#ffffff"></font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>final&nbsp;</b></font><font
color="#000000"> Map&lt;String,&nbsp;String&gt;&nbsp;options& amp;nbsp;=&nbsp; </font><font
color="#7f0055"><b>new&nbsp;</b></font><font color="#000000">HashMap&lt;String,&nbsp;String&gt; </font><font
color="#000000">()</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">options.put</font><font
color="#000000">(</font><font color="#000000">XMLResource.OPTION_ENCODING,&nbsp;System.getProperty </font><font
color="#000000">(</font><font color="#000000">ENCODING_PROPERTY</font><font
color="#000000">))</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#3f7f5f"> //&nbsp;First&nbsp;tries&nbsp;to&nbsp;load&a mp;nbsp;the&nbsp;IFile&nbsp;assuming&nbsp;it& ;nbsp;is&nbsp;in&nbsp;the&nbsp;workspace </font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000"> Resource&nbsp;modelResource&nbsp;=&nbsp;createRe source </font><font
color="#000000">(</font><font color="#000000">URI.createPlatformResourceURI</font><font
color="#000000">(</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#000000">file.getFullPath</font><font
color="#000000">()</font><font color="#000000">.toOSString</font><font
color="#000000">()</font><font color="#000000">,&nbsp;</font><font
color="#7f0055"><b>true</b></font><font color="#000000">)</font><font
color="#000000">,&nbsp;resourceSet</font><font color="#000000">)</font><font
color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>try&nbsp;</b></font><font
color="#000000">{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">modelResource.load</font><font
color="#000000">(</font><font color="#000000">options</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">}&nbsp;</font><font
color="#7f0055"><b>catch&nbsp;</b></font><font color="#000000">(</font><font
color="#000000">IOException&nbsp;e</font><font color="#000000">)&nbsp;{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#3f7f5f"> //&nbsp;If&nbsp;it&nbsp;failed,&nbsp;load&am p;nbsp;the&nbsp;file&nbsp;assuming&nbsp;it&n bsp;is&nbsp;in&nbsp;the&nbsp;plugins </font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">resourceSet.getResources</font><font
color="#000000">()</font><font color="#000000">.remove</font><font
color="#000000">(</font><font color="#000000">modelResource</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">modelResource&nbsp;=&nbsp;createResource </font><font
color="#000000">(</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">URI.createPlatformPluginURI</font><font
color="#000000">(</font><font color="#000000">file.getFullPath</font><font
color="#000000">()</font><font color="#000000">.toOSString</font><font
color="#000000">()</font><font color="#000000">,&nbsp;</font><font
color="#7f0055"><b>true</b></font><font color="#000000">)</font><font
color="#000000">,&nbsp;resourceSet</font><font color="#000000">)</font><font
color="#000000">;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#7f0055"><b>try&nbsp;</b></font><font
color="#000000">{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#000000">modelResource.load</font><font
color="#000000">(</font><font color="#000000">options</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">}&nbsp;</font><font
color="#7f0055"><b>catch&nbsp;</b></font><font color="#000000">(</font><font
color="#000000">IOException&nbsp;ee</font><font color="#000000">)&nbsp;{</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#3f7f5f"> //&nbsp;If&nbsp;it&nbsp;fails&nbsp;anew,& ;nbsp;throws&nbsp;the&nbsp;first&nbsp;IOExceptio n </font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; </font><font color="#7f0055"><b>throw&nbsp;</b></font><font
color="#000000">e;</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">}</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#000000">}</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#3f7f5f"> //&nbsp;Returns&nbsp;the&nbsp;first&nbsp;roo t&nbsp;of&nbsp;the&nbsp;loaded&nbsp;model </font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>if&nbsp;</b></font><font
color="#000000">(</font><font color="#000000">modelResource.getContents</font><font
color="#000000">()</font><font color="#000000">.size</font><font
color="#000000">()&nbsp;</font><font color="#000000">&gt;&nbsp;</font><font
color="#990000">0</font><font color="#000000">)</font><br>
<font color="#ffffff"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font color="#000000">result&nbsp;=&nbsp;modelResource.getContents </font><font
color="#000000">()</font><font color="#000000">.get</font><font
color="#000000">(</font><font color="#990000">0</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff">&nbsp;&nbsp;&nbsp;&nbsp;</font ><font color="#7f0055"><b>return&nbsp;</b></font><font
color="#000000">result;</font><br>
<font color="#ffffff">&nbsp;&nbsp;</font><font color="#000000">}</font></code>
</td>
<!-- end source code --> </tr>
</tbody>
</table>
</div>
<!-- = END of automatically generated HTML code = -->
<!-- ======================================================== --><br>
<br>
I'm not sure I understand how the <code><font color="#000000">createPlatformPluginURI</font></code>.&nbsp;
A resource might fail to load because some reference within it is
wrong, and this code will make it throw away that almost correct result
and try something that's almost bound to be completely meaningless.&nbsp; It
seems a bit unfortunate to introduce a hard IResource dependency for a
utility like this. Note also that the OPTION_ENCODING is a save option
so has no impact on loading.&nbsp; Maybe you should get rid of it.&nbsp; At
worst, I suppose you could make IResource an optional dependency; it
might be necessary to move the body of the method to a static nested
class to avoid eager class loading...&nbsp; You'd have to test that it works
standalone without loading that class when you call some other utility
method...<br>
<br>
<br>
jason henriksen wrote:
<blockquote cite="mid:g1hht2$4l5$1@build.eclipse.org" type="cite">Hi
All,
<br>
<br>
I'm using EMF inside of a server to process XML (SOAP messages)&nbsp; From
an &nbsp;eclipse point of view I'm running headless, but really I'm up
inside of a servlet container using XML that comes in from a network
connection.
<br>
<br>
The minor annoyance (I hesitate to call it a problem) is that EMF
Compare is requiring me to add the jars to hold IFile and IResource and
all this.&nbsp; It seems like EMF compare shouldn't have those kinds of
dependencies.&nbsp; I'm not using it inside eclipse at all, so I don't
really want all the eclipse meta-file-system stuff sitting around
inside my servlet container.
<br>
<br>
What are your thoughts on that?&nbsp; Are those classes just used for
convenience or is this indicative of a deeper need that I don't
understand yet?
<br>
<br>
&nbsp;Thanks,
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; Jason
<br>
</blockquote>
<br>
</body>
</html>

--------------040701050007030404000502--
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619006 is a reply to message #123032] Wed, 28 May 2008 09:48 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030404060205060708010605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed, Jason,

We do have an example launching EMF Compare stand-alone, and this works
without any of the org.eclipse.core.* jars. The only required
dependencies to launch EMF Compare standalone are :

- org.eclipse.emf.common 2.3 or higher
- org.eclipse.emf.ecore 2.3 or higher
- org.eclipse.emf.ecore.xmi 2.3 or higher
- org.eclipse.emf.compare 0.8 or higher
- org.eclipse.emf.compare.diff 0.8 or higher
- org.eclipse.emf.compare.match 0.8 or higher

The utility method Ed is pointing to is something that can obviously not
be used in a standalone app, it shouldn't even be called when using EMF
Compare via the MatchService and DiffService Classes.

Of course, I might very well have broken something in the last builds...
Can you confirm your use case doesn't work with only the 6 jars above
and create a bugzilla if so?

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619009 is a reply to message #123256] Wed, 28 May 2008 09:52 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000503020502060507000706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

As a side note, Ed : thanks for pointing out that the OPTION_ENCODING is
a save option, I will get rid of those since I used it everywhere for
loading :D.

laurent Goubet a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619015 is a reply to message #123256] Wed, 28 May 2008 11:18 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31033
Registered: July 2009
Senior Member
Laurent,

Perhaps you should consider making the plugin dependency on core
resources optional. That way someone could use this in an RCP
application without the resources plugin; that's what we did in
org.eclipse.emf.ecore... It's good to test that you can call another
utility method in that class without causing the IFile class to be
loaded to be sure that only clients that use that one utility method
will actually need core.resources.


laurent Goubet wrote:
> Ed, Jason,
>
> We do have an example launching EMF Compare stand-alone, and this
> works without any of the org.eclipse.core.* jars. The only required
> dependencies to launch EMF Compare standalone are :
>
> - org.eclipse.emf.common 2.3 or higher
> - org.eclipse.emf.ecore 2.3 or higher
> - org.eclipse.emf.ecore.xmi 2.3 or higher
> - org.eclipse.emf.compare 0.8 or higher
> - org.eclipse.emf.compare.diff 0.8 or higher
> - org.eclipse.emf.compare.match 0.8 or higher
>
> The utility method Ed is pointing to is something that can obviously
> not be used in a standalone app, it shouldn't even be called when
> using EMF Compare via the MatchService and DiffService Classes.
>
> Of course, I might very well have broken something in the last
> builds... Can you confirm your use case doesn't work with only the 6
> jars above and create a bugzilla if so?
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Guys,
>>
>> I notice this is the case purely, because of
>>
>> | *public static *EObject load(IFile file, ResourceSet resourceSet)
>> *throws *IOException {
>> EObject result = *null*;
>>
>> *final *Map<String, String> options = *new *HashMap<String,
>> String>();
>> options.put(XMLResource.OPTION_ENCODING,
>> System.getProperty(ENCODING_PROPERTY));
>> // First tries to load the IFile assuming it is in the workspace
>> Resource modelResource =
>> createResource(URI.createPlatformResourceURI(
>> file.getFullPath().toOSString(), *true*), resourceSet);
>> *try *{
>> modelResource.load(options);
>> } *catch *(IOException e) {
>> // If it failed, load the file assuming it is in the plugins
>> resourceSet.getResources().remove(modelResource);
>> modelResource = createResource(
>>
>> URI.createPlatformPluginURI(file.getFullPath().toOSString(), *true*),
>> resourceSet);
>> *try *{
>> modelResource.load(options);
>> } *catch *(IOException ee) {
>> // If it fails anew, throws the first IOException
>> *throw *e;
>> }
>> }
>> // Returns the first root of the loaded model
>> *if *(modelResource.getContents().size() > 0)
>> result = modelResource.getContents().get(0);
>> *return *result;
>> }|
>>
>>
>>
>> I'm not sure I understand how the |createPlatformPluginURI|. A
>> resource might fail to load because some reference within it is
>> wrong, and this code will make it throw away that almost correct
>> result and try something that's almost bound to be completely
>> meaningless. It seems a bit unfortunate to introduce a hard
>> IResource dependency for a utility like this. Note also that the
>> OPTION_ENCODING is a save option so has no impact on loading. Maybe
>> you should get rid of it. At worst, I suppose you could make
>> IResource an optional dependency; it might be necessary to move the
>> body of the method to a static nested class to avoid eager class
>> loading... You'd have to test that it works standalone without
>> loading that class when you call some other utility method...
>>
>>
>> jason henriksen wrote:
>>> Hi All,
>>>
>>> I'm using EMF inside of a server to process XML (SOAP messages)
>>> From an eclipse point of view I'm running headless, but really I'm
>>> up inside of a servlet container using XML that comes in from a
>>> network connection.
>>>
>>> The minor annoyance (I hesitate to call it a problem) is that EMF
>>> Compare is requiring me to add the jars to hold IFile and IResource
>>> and all this. It seems like EMF compare shouldn't have those kinds
>>> of dependencies. I'm not using it inside eclipse at all, so I don't
>>> really want all the eclipse meta-file-system stuff sitting around
>>> inside my servlet container.
>>>
>>> What are your thoughts on that? Are those classes just used for
>>> convenience or is this indicative of a deeper need that I don't
>>> understand yet?
>>>
>>> Thanks,
>>>
>>> Jason
>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619017 is a reply to message #123310] Wed, 28 May 2008 11:31 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070301050600090705080606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

I didn't know there was a way to set "optional" dependencies, just
commited this change on our plugins (Jason : we're currently building
for RC2, this change will appear in that build).

Yet I wonder : what exactly does setting a dependency "optional"
changes? As I mentionned earlier, we could already use EMF Compare stand
alone (no eclipse headless or whatnot, directly via java -jar on a
builded jar of a simple "main" class launching a comparison), and that
worked fine without having org.eclipse.core.* jars in the classpath.

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619020 is a reply to message #123324] Wed, 28 May 2008 12:01 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31033
Registered: July 2009
Senior Member
Laurent,

Comments below.

laurent Goubet wrote:
> Ed,
>
> I didn't know there was a way to set "optional" dependencies, just
> commited this change on our plugins (Jason : we're currently building
> for RC2, this change will appear in that build).
When you learn something new, it's a good day. :-P
>
> Yet I wonder : what exactly does setting a dependency "optional" changes?
If something is a normal dependency you are declaring that the plugin
will only work if the plugins on which it depends are actually present.
An optional dependency specifies that your plugin will make use of the
dependency if present, but will continue to function well even when the
dependency is not present. So for Ecore we've designed it such that it
can exploit IResources (for things like handling platform:/resource
URIs) but will also work fine if you don't make use of IResources.
> As I mentionned earlier, we could already use EMF Compare stand alone
> (no eclipse headless or whatnot, directly via java -jar on a builded
> jar of a simple "main" class launching a comparison), and that worked
> fine without having org.eclipse.core.* jars in the classpath.
Yes, I was just wondering if that test used any of the other methods in
the utility class. Sometimes Java's class loader is a bit eager and in
those cases, moving the code to a separate class (like our EclipseUtil
classes) helps to defer to loading...
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Laurent,
>>
>> Perhaps you should consider making the plugin dependency on core
>> resources optional. That way someone could use this in an RCP
>> application without the resources plugin; that's what we did in
>> org.eclipse.emf.ecore... It's good to test that you can call another
>> utility method in that class without causing the IFile class to be
>> loaded to be sure that only clients that use that one utility method
>> will actually need core.resources.
>>
>>
>> laurent Goubet wrote:
>>> Ed, Jason,
>>>
>>> We do have an example launching EMF Compare stand-alone, and this
>>> works without any of the org.eclipse.core.* jars. The only required
>>> dependencies to launch EMF Compare standalone are :
>>>
>>> - org.eclipse.emf.common 2.3 or higher
>>> - org.eclipse.emf.ecore 2.3 or higher
>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>> - org.eclipse.emf.compare 0.8 or higher
>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>
>>> The utility method Ed is pointing to is something that can obviously
>>> not be used in a standalone app, it shouldn't even be called when
>>> using EMF Compare via the MatchService and DiffService Classes.
>>>
>>> Of course, I might very well have broken something in the last
>>> builds... Can you confirm your use case doesn't work with only the 6
>>> jars above and create a bugzilla if so?
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Ed Merks a écrit :
>>>> Guys,
>>>>
>>>> I notice this is the case purely, because of
>>>>
>>>> | *public static *EObject load(IFile file, ResourceSet
>>>> resourceSet) *throws *IOException {
>>>> EObject result = *null*;
>>>>
>>>> *final *Map<String, String> options = *new *HashMap<String,
>>>> String>();
>>>> options.put(XMLResource.OPTION_ENCODING,
>>>> System.getProperty(ENCODING_PROPERTY));
>>>> // First tries to load the IFile assuming it is in the workspace
>>>> Resource modelResource =
>>>> createResource(URI.createPlatformResourceURI(
>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>> *try *{
>>>> modelResource.load(options);
>>>> } *catch *(IOException e) {
>>>> // If it failed, load the file assuming it is in the plugins
>>>> resourceSet.getResources().remove(modelResource);
>>>> modelResource = createResource(
>>>>
>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>> *true*), resourceSet);
>>>> *try *{
>>>> modelResource.load(options);
>>>> } *catch *(IOException ee) {
>>>> // If it fails anew, throws the first IOException
>>>> *throw *e;
>>>> }
>>>> }
>>>> // Returns the first root of the loaded model
>>>> *if *(modelResource.getContents().size() > 0)
>>>> result = modelResource.getContents().get(0);
>>>> *return *result;
>>>> }|
>>>>
>>>>
>>>>
>>>> I'm not sure I understand how the |createPlatformPluginURI|. A
>>>> resource might fail to load because some reference within it is
>>>> wrong, and this code will make it throw away that almost correct
>>>> result and try something that's almost bound to be completely
>>>> meaningless. It seems a bit unfortunate to introduce a hard
>>>> IResource dependency for a utility like this. Note also that the
>>>> OPTION_ENCODING is a save option so has no impact on loading.
>>>> Maybe you should get rid of it. At worst, I suppose you could make
>>>> IResource an optional dependency; it might be necessary to move the
>>>> body of the method to a static nested class to avoid eager class
>>>> loading... You'd have to test that it works standalone without
>>>> loading that class when you call some other utility method...
>>>>
>>>>
>>>> jason henriksen wrote:
>>>>> Hi All,
>>>>>
>>>>> I'm using EMF inside of a server to process XML (SOAP messages)
>>>>> From an eclipse point of view I'm running headless, but really
>>>>> I'm up inside of a servlet container using XML that comes in from
>>>>> a network connection.
>>>>>
>>>>> The minor annoyance (I hesitate to call it a problem) is that EMF
>>>>> Compare is requiring me to add the jars to hold IFile and
>>>>> IResource and all this. It seems like EMF compare shouldn't have
>>>>> those kinds of dependencies. I'm not using it inside eclipse at
>>>>> all, so I don't really want all the eclipse meta-file-system stuff
>>>>> sitting around inside my servlet container.
>>>>>
>>>>> What are your thoughts on that? Are those classes just used for
>>>>> convenience or is this indicative of a deeper need that I don't
>>>>> understand yet?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>
>>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619024 is a reply to message #123336] Wed, 28 May 2008 12:13 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090502070802040104090103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ed,

Thanks for the clarification, I guess this "optional" resolution for
dependencies is only set to give this information to clients but isn't
actually used by either compiler or builder then.

As for your latter question, we use methods from this utility class
throughout the code of EMF Compare, and the example is no exception... I
might very well be lucky with the class loader (for once).

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619028 is a reply to message #123349] Wed, 28 May 2008 12:23 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31033
Registered: July 2009
Senior Member
Laurent,

Comments below.

laurent Goubet wrote:
> Ed,
>
> Thanks for the clarification, I guess this "optional" resolution for
> dependencies is only set to give this information to clients but isn't
> actually used by either compiler or builder then.
Exactly. It's also useful for clients building a minimal runtime
configuration (in the Run configurations dialogs) since optional
dependencies won't be included.
>
> As for your latter question, we use methods from this utility class
> throughout the code of EMF Compare, and the example is no exception...
> I might very well be lucky with the class loader (for once).
Class loaders do generally try to be very lazy.
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Laurent,
>>
>> Comments below.
>>
>> laurent Goubet wrote:
>>> Ed,
>>>
>>> I didn't know there was a way to set "optional" dependencies, just
>>> commited this change on our plugins (Jason : we're currently
>>> building for RC2, this change will appear in that build).
>> When you learn something new, it's a good day. :-P
>>>
>>> Yet I wonder : what exactly does setting a dependency "optional"
>>> changes?
>> If something is a normal dependency you are declaring that the plugin
>> will only work if the plugins on which it depends are actually
>> present. An optional dependency specifies that your plugin will make
>> use of the dependency if present, but will continue to function well
>> even when the dependency is not present. So for Ecore we've designed
>> it such that it can exploit IResources (for things like handling
>> platform:/resource URIs) but will also work fine if you don't make
>> use of IResources.
>>> As I mentionned earlier, we could already use EMF Compare stand
>>> alone (no eclipse headless or whatnot, directly via java -jar on a
>>> builded jar of a simple "main" class launching a comparison), and
>>> that worked fine without having org.eclipse.core.* jars in the
>>> classpath.
>> Yes, I was just wondering if that test used any of the other methods
>> in the utility class. Sometimes Java's class loader is a bit eager
>> and in those cases, moving the code to a separate class (like our
>> EclipseUtil classes) helps to defer to loading...
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Ed Merks a écrit :
>>>> Laurent,
>>>>
>>>> Perhaps you should consider making the plugin dependency on core
>>>> resources optional. That way someone could use this in an RCP
>>>> application without the resources plugin; that's what we did in
>>>> org.eclipse.emf.ecore... It's good to test that you can call
>>>> another utility method in that class without causing the IFile
>>>> class to be loaded to be sure that only clients that use that one
>>>> utility method will actually need core.resources.
>>>>
>>>>
>>>> laurent Goubet wrote:
>>>>> Ed, Jason,
>>>>>
>>>>> We do have an example launching EMF Compare stand-alone, and this
>>>>> works without any of the org.eclipse.core.* jars. The only
>>>>> required dependencies to launch EMF Compare standalone are :
>>>>>
>>>>> - org.eclipse.emf.common 2.3 or higher
>>>>> - org.eclipse.emf.ecore 2.3 or higher
>>>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>>>> - org.eclipse.emf.compare 0.8 or higher
>>>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>>>
>>>>> The utility method Ed is pointing to is something that can
>>>>> obviously not be used in a standalone app, it shouldn't even be
>>>>> called when using EMF Compare via the MatchService and DiffService
>>>>> Classes.
>>>>>
>>>>> Of course, I might very well have broken something in the last
>>>>> builds... Can you confirm your use case doesn't work with only the
>>>>> 6 jars above and create a bugzilla if so?
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Guys,
>>>>>>
>>>>>> I notice this is the case purely, because of
>>>>>>
>>>>>> | *public static *EObject load(IFile file, ResourceSet
>>>>>> resourceSet) *throws *IOException {
>>>>>> EObject result = *null*;
>>>>>>
>>>>>> *final *Map<String, String> options = *new *HashMap<String,
>>>>>> String>();
>>>>>> options.put(XMLResource.OPTION_ENCODING,
>>>>>> System.getProperty(ENCODING_PROPERTY));
>>>>>> // First tries to load the IFile assuming it is in the workspace
>>>>>> Resource modelResource =
>>>>>> createResource(URI.createPlatformResourceURI(
>>>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>>>> *try *{
>>>>>> modelResource.load(options);
>>>>>> } *catch *(IOException e) {
>>>>>> // If it failed, load the file assuming it is in the plugins
>>>>>> resourceSet.getResources().remove(modelResource);
>>>>>> modelResource = createResource(
>>>>>>
>>>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>>>> *true*), resourceSet);
>>>>>> *try *{
>>>>>> modelResource.load(options);
>>>>>> } *catch *(IOException ee) {
>>>>>> // If it fails anew, throws the first IOException
>>>>>> *throw *e;
>>>>>> }
>>>>>> }
>>>>>> // Returns the first root of the loaded model
>>>>>> *if *(modelResource.getContents().size() > 0)
>>>>>> result = modelResource.getContents().get(0);
>>>>>> *return *result;
>>>>>> }|
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm not sure I understand how the |createPlatformPluginURI|. A
>>>>>> resource might fail to load because some reference within it is
>>>>>> wrong, and this code will make it throw away that almost correct
>>>>>> result and try something that's almost bound to be completely
>>>>>> meaningless. It seems a bit unfortunate to introduce a hard
>>>>>> IResource dependency for a utility like this. Note also that the
>>>>>> OPTION_ENCODING is a save option so has no impact on loading.
>>>>>> Maybe you should get rid of it. At worst, I suppose you could
>>>>>> make IResource an optional dependency; it might be necessary to
>>>>>> move the body of the method to a static nested class to avoid
>>>>>> eager class loading... You'd have to test that it works
>>>>>> standalone without loading that class when you call some other
>>>>>> utility method...
>>>>>>
>>>>>>
>>>>>> jason henriksen wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I'm using EMF inside of a server to process XML (SOAP messages)
>>>>>>> From an eclipse point of view I'm running headless, but really
>>>>>>> I'm up inside of a servlet container using XML that comes in
>>>>>>> from a network connection.
>>>>>>>
>>>>>>> The minor annoyance (I hesitate to call it a problem) is that
>>>>>>> EMF Compare is requiring me to add the jars to hold IFile and
>>>>>>> IResource and all this. It seems like EMF compare shouldn't
>>>>>>> have those kinds of dependencies. I'm not using it inside
>>>>>>> eclipse at all, so I don't really want all the eclipse
>>>>>>> meta-file-system stuff sitting around inside my servlet container.
>>>>>>>
>>>>>>> What are your thoughts on that? Are those classes just used for
>>>>>>> convenience or is this indicative of a deeper need that I don't
>>>>>>> understand yet?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jason
>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619058 is a reply to message #123362] Thu, 29 May 2008 08:02 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1881
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030700020205080009060605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jason,

A little update; I indeed found a problem with this
org.eclipse.core.runtime dependency when calling some of ModelUtils'
utility methods (seems I _was_ lucky with the class loader after all).

As Ed suggested, I will move the offending methods to another utility
class (probably EclipseModelUtils) in order to get rid of these direct
dependencies to org.eclipse.core.runtime.* as per bug 234544
https://bugs.eclipse.org/bugs/show_bug.cgi?id=234544 .

Thank you for your feedback.

Laurent Goubet
Obeo

Ed Merks a
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619073 is a reply to message #123531] Thu, 29 May 2008 16:57 Go to previous message
Jason Henriksen is currently offline Jason HenriksenFriend
Messages: 231
Registered: July 2009
Senior Member
You guys are fantastic. Thanks!

Jason


laurent Goubet wrote:
> Jason,
>
> A little update; I indeed found a problem with this
> org.eclipse.core.runtime dependency when calling some of ModelUtils'
> utility methods (seems I _was_ lucky with the class loader after all).
>
> As Ed suggested, I will move the offending methods to another utility
> class (probably EclipseModelUtils) in order to get rid of these direct
> dependencies to org.eclipse.core.runtime.* as per bug 234544
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=234544 .
>
> Thank you for your feedback.
>
> Laurent Goubet
> Obeo
>
> Ed Merks a écrit :
>> Laurent,
>>
>> Comments below.
>>
>> laurent Goubet wrote:
>>> Ed,
>>>
>>> Thanks for the clarification, I guess this "optional" resolution for
>>> dependencies is only set to give this information to clients but
>>> isn't actually used by either compiler or builder then.
>> Exactly. It's also useful for clients building a minimal runtime
>> configuration (in the Run configurations dialogs) since optional
>> dependencies won't be included.
>>>
>>> As for your latter question, we use methods from this utility class
>>> throughout the code of EMF Compare, and the example is no
>>> exception... I might very well be lucky with the class loader (for
>>> once).
>> Class loaders do generally try to be very lazy.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Ed Merks a écrit :
>>>> Laurent,
>>>>
>>>> Comments below.
>>>>
>>>> laurent Goubet wrote:
>>>>> Ed,
>>>>>
>>>>> I didn't know there was a way to set "optional" dependencies, just
>>>>> commited this change on our plugins (Jason : we're currently
>>>>> building for RC2, this change will appear in that build).
>>>> When you learn something new, it's a good day. :-P
>>>>>
>>>>> Yet I wonder : what exactly does setting a dependency "optional"
>>>>> changes?
>>>> If something is a normal dependency you are declaring that the
>>>> plugin will only work if the plugins on which it depends are
>>>> actually present. An optional dependency specifies that your plugin
>>>> will make use of the dependency if present, but will continue to
>>>> function well even when the dependency is not present. So for Ecore
>>>> we've designed it such that it can exploit IResources (for things
>>>> like handling platform:/resource URIs) but will also work fine if
>>>> you don't make use of IResources.
>>>>> As I mentionned earlier, we could already use EMF Compare stand
>>>>> alone (no eclipse headless or whatnot, directly via java -jar on a
>>>>> builded jar of a simple "main" class launching a comparison), and
>>>>> that worked fine without having org.eclipse.core.* jars in the
>>>>> classpath.
>>>> Yes, I was just wondering if that test used any of the other methods
>>>> in the utility class. Sometimes Java's class loader is a bit eager
>>>> and in those cases, moving the code to a separate class (like our
>>>> EclipseUtil classes) helps to defer to loading...
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Ed Merks a écrit :
>>>>>> Laurent,
>>>>>>
>>>>>> Perhaps you should consider making the plugin dependency on core
>>>>>> resources optional. That way someone could use this in an RCP
>>>>>> application without the resources plugin; that's what we did in
>>>>>> org.eclipse.emf.ecore... It's good to test that you can call
>>>>>> another utility method in that class without causing the IFile
>>>>>> class to be loaded to be sure that only clients that use that one
>>>>>> utility method will actually need core.resources.
>>>>>>
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Ed, Jason,
>>>>>>>
>>>>>>> We do have an example launching EMF Compare stand-alone, and this
>>>>>>> works without any of the org.eclipse.core.* jars. The only
>>>>>>> required dependencies to launch EMF Compare standalone are :
>>>>>>>
>>>>>>> - org.eclipse.emf.common 2.3 or higher
>>>>>>> - org.eclipse.emf.ecore 2.3 or higher
>>>>>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>>>>>> - org.eclipse.emf.compare 0.8 or higher
>>>>>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>>>>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>>>>>
>>>>>>> The utility method Ed is pointing to is something that can
>>>>>>> obviously not be used in a standalone app, it shouldn't even be
>>>>>>> called when using EMF Compare via the MatchService and
>>>>>>> DiffService Classes.
>>>>>>>
>>>>>>> Of course, I might very well have broken something in the last
>>>>>>> builds... Can you confirm your use case doesn't work with only
>>>>>>> the 6 jars above and create a bugzilla if so?
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Ed Merks a écrit :
>>>>>>>> Guys,
>>>>>>>>
>>>>>>>> I notice this is the case purely, because of
>>>>>>>>
>>>>>>>> | *public static *EObject load(IFile file, ResourceSet
>>>>>>>> resourceSet) *throws *IOException {
>>>>>>>> EObject result = *null*;
>>>>>>>>
>>>>>>>> *final *Map<String, String> options = *new *HashMap<String,
>>>>>>>> String>();
>>>>>>>> options.put(XMLResource.OPTION_ENCODING,
>>>>>>>> System.getProperty(ENCODING_PROPERTY));
>>>>>>>> // First tries to load the IFile assuming it is in the
>>>>>>>> workspace
>>>>>>>> Resource modelResource =
>>>>>>>> createResource(URI.createPlatformResourceURI(
>>>>>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>>>>>> *try *{
>>>>>>>> modelResource.load(options);
>>>>>>>> } *catch *(IOException e) {
>>>>>>>> // If it failed, load the file assuming it is in the plugins
>>>>>>>> resourceSet.getResources().remove(modelResource);
>>>>>>>> modelResource = createResource(
>>>>>>>>
>>>>>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>>>>>> *true*), resourceSet);
>>>>>>>> *try *{
>>>>>>>> modelResource.load(options);
>>>>>>>> } *catch *(IOException ee) {
>>>>>>>> // If it fails anew, throws the first IOException
>>>>>>>> *throw *e;
>>>>>>>> }
>>>>>>>> }
>>>>>>>> // Returns the first root of the loaded model
>>>>>>>> *if *(modelResource.getContents().size() > 0)
>>>>>>>> result = modelResource.getContents().get(0);
>>>>>>>> *return *result;
>>>>>>>> }|
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure I understand how the |createPlatformPluginURI|. A
>>>>>>>> resource might fail to load because some reference within it is
>>>>>>>> wrong, and this code will make it throw away that almost correct
>>>>>>>> result and try something that's almost bound to be completely
>>>>>>>> meaningless. It seems a bit unfortunate to introduce a hard
>>>>>>>> IResource dependency for a utility like this. Note also that the
>>>>>>>> OPTION_ENCODING is a save option so has no impact on loading.
>>>>>>>> Maybe you should get rid of it. At worst, I suppose you could
>>>>>>>> make IResource an optional dependency; it might be necessary to
>>>>>>>> move the body of the method to a static nested class to avoid
>>>>>>>> eager class loading... You'd have to test that it works
>>>>>>>> standalone without loading that class when you call some other
>>>>>>>> utility method...
>>>>>>>>
>>>>>>>>
>>>>>>>> jason henriksen wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> I'm using EMF inside of a server to process XML (SOAP
>>>>>>>>> messages) From an eclipse point of view I'm running headless,
>>>>>>>>> but really I'm up inside of a servlet container using XML that
>>>>>>>>> comes in from a network connection.
>>>>>>>>>
>>>>>>>>> The minor annoyance (I hesitate to call it a problem) is that
>>>>>>>>> EMF Compare is requiring me to add the jars to hold IFile and
>>>>>>>>> IResource and all this. It seems like EMF compare shouldn't
>>>>>>>>> have those kinds of dependencies. I'm not using it inside
>>>>>>>>> eclipse at all, so I don't really want all the eclipse
>>>>>>>>> meta-file-system stuff sitting around inside my servlet container.
>>>>>>>>>
>>>>>>>>> What are your thoughts on that? Are those classes just used
>>>>>>>>> for convenience or is this indicative of a deeper need that I
>>>>>>>>> don't understand yet?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: [EMF Compare] Does EMF Compare really need to know about IFile and so on? [message #619077 is a reply to message #123741] Thu, 29 May 2008 17:30 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31033
Registered: July 2009
Senior Member
Jason,

Yes, we've got quite the excellent group here! :-)


jason henriksen wrote:
>
> You guys are fantastic. Thanks!
>
> Jason
>
>
> laurent Goubet wrote:
>> Jason,
>>
>> A little update; I indeed found a problem with this
>> org.eclipse.core.runtime dependency when calling some of ModelUtils'
>> utility methods (seems I _was_ lucky with the class loader after all).
>>
>> As Ed suggested, I will move the offending methods to another utility
>> class (probably EclipseModelUtils) in order to get rid of these
>> direct dependencies to org.eclipse.core.runtime.* as per bug 234544
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=234544 .
>>
>> Thank you for your feedback.
>>
>> Laurent Goubet
>> Obeo
>>
>> Ed Merks a écrit :
>>> Laurent,
>>>
>>> Comments below.
>>>
>>> laurent Goubet wrote:
>>>> Ed,
>>>>
>>>> Thanks for the clarification, I guess this "optional" resolution
>>>> for dependencies is only set to give this information to clients
>>>> but isn't actually used by either compiler or builder then.
>>> Exactly. It's also useful for clients building a minimal runtime
>>> configuration (in the Run configurations dialogs) since optional
>>> dependencies won't be included.
>>>>
>>>> As for your latter question, we use methods from this utility class
>>>> throughout the code of EMF Compare, and the example is no
>>>> exception... I might very well be lucky with the class loader (for
>>>> once).
>>> Class loaders do generally try to be very lazy.
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Ed Merks a écrit :
>>>>> Laurent,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> laurent Goubet wrote:
>>>>>> Ed,
>>>>>>
>>>>>> I didn't know there was a way to set "optional" dependencies,
>>>>>> just commited this change on our plugins (Jason : we're currently
>>>>>> building for RC2, this change will appear in that build).
>>>>> When you learn something new, it's a good day. :-P
>>>>>>
>>>>>> Yet I wonder : what exactly does setting a dependency "optional"
>>>>>> changes?
>>>>> If something is a normal dependency you are declaring that the
>>>>> plugin will only work if the plugins on which it depends are
>>>>> actually present. An optional dependency specifies that your
>>>>> plugin will make use of the dependency if present, but will
>>>>> continue to function well even when the dependency is not
>>>>> present. So for Ecore we've designed it such that it can exploit
>>>>> IResources (for things like handling platform:/resource URIs) but
>>>>> will also work fine if you don't make use of IResources.
>>>>>> As I mentionned earlier, we could already use EMF Compare stand
>>>>>> alone (no eclipse headless or whatnot, directly via java -jar on
>>>>>> a builded jar of a simple "main" class launching a comparison),
>>>>>> and that worked fine without having org.eclipse.core.* jars in
>>>>>> the classpath.
>>>>> Yes, I was just wondering if that test used any of the other
>>>>> methods in the utility class. Sometimes Java's class loader is a
>>>>> bit eager and in those cases, moving the code to a separate class
>>>>> (like our EclipseUtil classes) helps to defer to loading...
>>>>>>
>>>>>> Laurent Goubet
>>>>>> Obeo
>>>>>>
>>>>>> Ed Merks a écrit :
>>>>>>> Laurent,
>>>>>>>
>>>>>>> Perhaps you should consider making the plugin dependency on core
>>>>>>> resources optional. That way someone could use this in an RCP
>>>>>>> application without the resources plugin; that's what we did in
>>>>>>> org.eclipse.emf.ecore... It's good to test that you can call
>>>>>>> another utility method in that class without causing the IFile
>>>>>>> class to be loaded to be sure that only clients that use that
>>>>>>> one utility method will actually need core.resources.
>>>>>>>
>>>>>>>
>>>>>>> laurent Goubet wrote:
>>>>>>>> Ed, Jason,
>>>>>>>>
>>>>>>>> We do have an example launching EMF Compare stand-alone, and
>>>>>>>> this works without any of the org.eclipse.core.* jars. The only
>>>>>>>> required dependencies to launch EMF Compare standalone are :
>>>>>>>>
>>>>>>>> - org.eclipse.emf.common 2.3 or higher
>>>>>>>> - org.eclipse.emf.ecore 2.3 or higher
>>>>>>>> - org.eclipse.emf.ecore.xmi 2.3 or higher
>>>>>>>> - org.eclipse.emf.compare 0.8 or higher
>>>>>>>> - org.eclipse.emf.compare.diff 0.8 or higher
>>>>>>>> - org.eclipse.emf.compare.match 0.8 or higher
>>>>>>>>
>>>>>>>> The utility method Ed is pointing to is something that can
>>>>>>>> obviously not be used in a standalone app, it shouldn't even be
>>>>>>>> called when using EMF Compare via the MatchService and
>>>>>>>> DiffService Classes.
>>>>>>>>
>>>>>>>> Of course, I might very well have broken something in the last
>>>>>>>> builds... Can you confirm your use case doesn't work with only
>>>>>>>> the 6 jars above and create a bugzilla if so?
>>>>>>>>
>>>>>>>> Laurent Goubet
>>>>>>>> Obeo
>>>>>>>>
>>>>>>>> Ed Merks a écrit :
>>>>>>>>> Guys,
>>>>>>>>>
>>>>>>>>> I notice this is the case purely, because of
>>>>>>>>>
>>>>>>>>> | *public static *EObject load(IFile file, ResourceSet
>>>>>>>>> resourceSet) *throws *IOException {
>>>>>>>>> EObject result = *null*;
>>>>>>>>>
>>>>>>>>> *final *Map<String, String> options = *new
>>>>>>>>> *HashMap<String, String>();
>>>>>>>>> options.put(XMLResource.OPTION_ENCODING,
>>>>>>>>> System.getProperty(ENCODING_PROPERTY));
>>>>>>>>> // First tries to load the IFile assuming it is in the
>>>>>>>>> workspace
>>>>>>>>> Resource modelResource =
>>>>>>>>> createResource(URI.createPlatformResourceURI(
>>>>>>>>> file.getFullPath().toOSString(), *true*), resourceSet);
>>>>>>>>> *try *{
>>>>>>>>> modelResource.load(options);
>>>>>>>>> } *catch *(IOException e) {
>>>>>>>>> // If it failed, load the file assuming it is in the
>>>>>>>>> plugins
>>>>>>>>> resourceSet.getResources().remove(modelResource);
>>>>>>>>> modelResource = createResource(
>>>>>>>>>
>>>>>>>>> URI.createPlatformPluginURI(file.getFullPath().toOSString(),
>>>>>>>>> *true*), resourceSet);
>>>>>>>>> *try *{
>>>>>>>>> modelResource.load(options);
>>>>>>>>> } *catch *(IOException ee) {
>>>>>>>>> // If it fails anew, throws the first IOException
>>>>>>>>> *throw *e;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> // Returns the first root of the loaded model
>>>>>>>>> *if *(modelResource.getContents().size() > 0)
>>>>>>>>> result = modelResource.getContents().get(0);
>>>>>>>>> *return *result;
>>>>>>>>> }|
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure I understand how the |createPlatformPluginURI|.
>>>>>>>>> A resource might fail to load because some reference within it
>>>>>>>>> is wrong, and this code will make it throw away that almost
>>>>>>>>> correct result and try something that's almost bound to be
>>>>>>>>> completely meaningless. It seems a bit unfortunate to
>>>>>>>>> introduce a hard IResource dependency for a utility like this.
>>>>>>>>> Note also that the OPTION_ENCODING is a save option so has no
>>>>>>>>> impact on loading. Maybe you should get rid of it. At worst,
>>>>>>>>> I suppose you could make IResource an optional dependency; it
>>>>>>>>> might be necessary to move the body of the method to a static
>>>>>>>>> nested class to avoid eager class loading... You'd have to
>>>>>>>>> test that it works standalone without loading that class when
>>>>>>>>> you call some other utility method...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> jason henriksen wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> I'm using EMF inside of a server to process XML (SOAP
>>>>>>>>>> messages) From an eclipse point of view I'm running
>>>>>>>>>> headless, but really I'm up inside of a servlet container
>>>>>>>>>> using XML that comes in from a network connection.
>>>>>>>>>>
>>>>>>>>>> The minor annoyance (I hesitate to call it a problem) is that
>>>>>>>>>> EMF Compare is requiring me to add the jars to hold IFile and
>>>>>>>>>> IResource and all this. It seems like EMF compare shouldn't
>>>>>>>>>> have those kinds of dependencies. I'm not using it inside
>>>>>>>>>> eclipse at all, so I don't really want all the eclipse
>>>>>>>>>> meta-file-system stuff sitting around inside my servlet
>>>>>>>>>> container.
>>>>>>>>>>
>>>>>>>>>> What are your thoughts on that? Are those classes just used
>>>>>>>>>> for convenience or is this indicative of a deeper need that I
>>>>>>>>>> don't understand yet?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Jason
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
Previous Topic:[EMF Compare] Innacuracies while comparing lists of very similar elements
Next Topic:[Compare] is it possible for the diff to hold the old values?
Goto Forum:
  


Current Time: Mon Apr 06 10:12:19 GMT 2020

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

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

Back to the top