Home » Modeling » TMF (Xtext) » Re: first time problem running workflow (mwe 0.7.0)
| |
| Re: first time problem running workflow (mwe 0.7.0) [message #54979 is a reply to message #54925] |
Thu, 02 July 2009 21:26   |
 Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Krzysztof,
my previous post has been submitted to fast. Actually a platform:/plugin
uri will not help you, because the workflow does not know about
registered plugins etc.
I didn't find another solution than you. It seems you really have to be
evil and copy the genmodel. Maybe somebody else knows the trick how to
avoid this?
Regards,
Sebastian
Am 02.07.2009 22:46 Uhr, schrieb Krzysztof Kowalczyk:
> I don't know how to do all the things right so I added TMF news group
> and believe that somebody will help with the rest.
>
> > What I meant was that my created DSL has ERefeferences to UML Class
> > entity etc so that I may load UML classes from a .uml file into my DSL.
> >
> > As such I needed to put something like
> >
> > <RegisterEcoreFile value="./model/UML.ecore"/> in my workflow having
> > put a copy of UML.ecore in local dir. I thought it better to register(?)
> > this by pointing to the plugin containing the ecore directly. However, I
> > don't know if this is possible?
>
> Don't do that, some projects does include changes in code generated
> from ecore models. AFAIK UML project is one of them so you should use
> generated code not the dynamic version IMHO. Unfortunately UML need
> different handling in most cases (its own metamodel, its own setup etc.)
>
> What you need is to register the generated UML model by registering the
> generated EPackage:
>
> <bean class="org.eclipse.emf.mwe.utils.StandaloneSetup">
> <registerGeneratedEPackage value="org.eclipse.uml2.uml.UMLPackage"/>
> </bean>
>
> You also need small change like that in your Xtext workflow:
>
> <fragment
> class="org.eclipse.xtext.generator.ecore.EcoreGeneratorFragment "
> genModels="platform:/plugins/org.eclipse.uml2.uml/model/UML.genmodel "
> />
>
> But actually this will not work (I never liked uri), can somebody
> correct that? Is the copying genmodel and using "platform:/resource/"
> instead, the only solution? It works, but is pure evil IMO ;)
>
> Regards,
> Krzysztof Kowalczyk
|
|
| | |
| Re: first time problem running workflow (mwe 0.7.0) [message #55222 is a reply to message #55167] |
Fri, 03 July 2009 10:06 |
Ed Merks
Messages: 33184
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010409080708050806070800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sven,
EMF can even deal with accessing deeply nested jars:
A connection that can access an entry in an archive, and then
recursively an entry in that archive, and so on. For example, it can
be used just like jar: or zip:, only the archive paths can repeat,
e.g.,
archive:file:///c:/temp/example.zip!/org/example/nested.zip! /org/example/deeply-nested.html
The general recursive pattern is
archive:$nestedURL${/!$archivePath$}+
So the nested URL for the example above is
file:///c:/temp/example.zip
Since the nested URL may itself contain archive schemes, the
subsequence of the archive paths that should be associated with the
nested URL is determined by finding the nth archive separator, i.e.,
the nth !/, where n is the number of ":"s before the first "/" of
the nested URL, i.e., the number of nested schemes. For example, for
a more complex case where the nested URL is itself an archive-based
scheme, e.g.,
archive:jar:file:///c:/temp/example.zip!/org/example/nested. zip!/org/example/deeply-nested.html
the nested URL is correctly parsed to skip to the second archive
separator as jar:file:///c:/temp/example.zip!/org/example/nested.zip
Sven Efftinge wrote:
> Don't copy the genmodel but use a file URI which points to the
> genmodel in the jar.
> Don't know the exact syntax, but I guess you'll find it by looking
> into the code and JavaDocs of EMF's URI class.
>
> It's something like this as I remember:
>
> file:/my/absolute/path/org.eclipse.uml2.uml.jar!/model/UML.g enmodel
>
> Sven
>
> Krzysztof Kowalczyk schrieb:
>> Sebastian Zarnekow pisze:
>>> Hi Krzysztof,
>>>
>>> my previous post has been submitted to fast. Actually a
>>> platform:/plugin uri will not help you, because the workflow does
>>> not know about registered plugins etc.
>> I know that unfortunately. In xtext we have:
>>
>> import "http://www.eclipse.org/uml2/3.0.0/UML"
>>
>> and in workflow we have:
>>
>> <bean class="org.eclipse.emf.mwe.utils.StandaloneSetup"
>> platformUri="${runtimeProject}/.."
>> >
>> <registerGeneratedEPackage value="org.eclipse.uml2.uml.UMLPackage"/>
>> </bean>
>> ...
>> <fragment
>> class="org.eclipse.xtext.generator.ecore.EcoreGeneratorFragment "
>> genModels="platform:/resource/myproject/UML.genmodel"
>> />
>>
>> and I got a feeling that something is bad here :(
>>
>> As I understand this is an osgi/ eclipse plugins stuff that workflow
>> ignores. In active workbench, uri:
>> "http://www.eclipse.org/uml2/3.0.0/UML" allow to find both the
>> genmodel and the epackage. Maybe there is a way to dump registered
>> metamodels and make them visible to the workflow? Or handle the
>> "platform:/plugin" uri somehow? Model and genmodel should be visible
>> to workflow without copying as they are already on classpath.
>>
>> Regards,
>> Krzysztof Kowalczyk
--------------010409080708050806070800
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">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sven,<br>
<br>
EMF can even deal with accessing deeply nested jars:<br>
<blockquote>
<p>A connection that can access an entry in an archive, and then
recursively an entry in that archive, and so on. For example, it can be
used just like jar: or zip:, only the archive paths can repeat, e.g., </p>
<pre> archive:<a class="moz-txt-link-freetext" href=" file:///c:/temp/example.zip!/org/example/nested.zip!/org/exa mple/deeply-nested.html"> file:///c:/temp/example.zip!/org/example/nested.zip!/org/exa mple/deeply-nested.html</a>
</pre>
The general recursive pattern is
<pre> archive:$nestedURL${/!$archivePath$}+
</pre>
So the nested URL for the example above is
<pre> <a class="moz-txt-link-freetext" href="file:///c:/temp/example.zip">file:///c:/temp/example.zip</a>
</pre>
<p>Since the nested URL may itself contain archive schemes, the
subsequence of the archive paths that should be associated with the
nested URL is determined by finding the nth archive separator, i.e.,
the nth !/, where n is the number of ":"s before the first "/" of the
nested URL, i.e., the number of nested schemes. For example, for a more
complex case where the nested URL is itself an archive-based scheme,
e.g., </p>
<pre> archive:<a class="moz-txt-link-freetext" href=" jar:file:///c:/temp/example.zip!/org/example/nested.zip!/org /example/deeply-nested.html"> jar:file:///c:/temp/example.zip!/org/example/nested.zip!/org /example/deeply-nested.html</a>
</pre>
the nested URL is correctly parsed to skip to the second archive
separator as <a class="moz-txt-link-freetext" href="jar:file:///c:/temp/example.zip!/org/example/nested.zip">jar:file:///c:/temp/example.zip!/org/example/nested.zip</a><br>
</blockquote>
<br>
<br>
Sven Efftinge wrote:
<blockquote cite="mid:h2kh2n$adb$1@build.eclipse.org" type="cite">Don't
copy the genmodel but use a file URI which points to the genmodel in
the jar.
<br>
Don't know the exact syntax, but I guess you'll find it by looking into
the code and JavaDocs of EMF's URI class.
<br>
<br>
It's something like this as I remember:
<br>
<br>
<a class="moz-txt-link-freetext" href=" file:/my/absolute/path/org.eclipse.uml2.uml.jar!/model/UML.g enmodel "> file:/my/absolute/path/org.eclipse.uml2.uml.jar!/model/UML.g enmodel </a>
<br>
<br>
Sven
<br>
<br>
Krzysztof Kowalczyk schrieb:
<br>
<blockquote type="cite">Sebastian Zarnekow pisze:
<br>
<blockquote type="cite">Hi Krzysztof,
<br>
<br>
my previous post has been submitted to fast. Actually a
platform:/plugin uri will not help you, because the workflow does not
know about registered plugins etc.
<br>
</blockquote>
I know that unfortunately. In xtext we have:
<br>
<br>
import <a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/uml2/3.0.0/UML">"http://www.eclipse.org/uml2/3.0.0/UML"</a>
<br>
<br>
and in workflow we have:
<br>
<br>
<bean class="org.eclipse.emf.mwe.utils.StandaloneSetup"
<br>
platformUri="${runtimeProject}/.."
<br>
>
<br>
<registerGeneratedEPackage
value="org.eclipse.uml2.uml.UMLPackage"/>
<br>
</bean>
<br>
....
<br>
<fragment
<br>
class="org.eclipse.xtext.generator.ecore.EcoreGeneratorFragment "
<br>
genModels="platform:/resource/myproject/UML.genmodel "
<br>
/>
<br>
<br>
and I got a feeling that something is bad here :(
<br>
<br>
As I understand this is an osgi/ eclipse plugins stuff that workflow
ignores. In active workbench, uri:
<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/uml2/3.0.0/UML">"http://www.eclipse.org/uml2/3.0.0/UML"</a> allow to find both the genmodel
and the epackage. Maybe there is a way to dump registered metamodels
and make them visible to the workflow? Or handle the "platform:/plugin"
uri somehow? Model and genmodel should be visible to workflow without
copying as they are already on classpath.
<br>
<br>
Regards,
<br>
Krzysztof Kowalczyk
<br>
</blockquote>
</blockquote>
</body>
</html>
--------------010409080708050806070800--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Thu Jul 18 19:20:29 GMT 2024
Powered by FUDForum. Page generated in 0.04887 seconds |
] 
Search
Help
Register
Login
Home
