|
|
|
|
|
|
|
|
|
|
Re: Unable to launch mwe2 workflow [message #1027640 is a reply to message #1027317] |
Wed, 27 March 2013 08:03 |
Christian Schwarz Messages: 31 Registered: July 2009 |
Member |
|
|
Thanks for your help. I figured out that org.eclipse.platform and org.eclipse.xtext.sdk + its dependencies is not enough. I also added all the mwe stuff and plugins that are not part of any feature like hamcrest and junit. In the end i got 42 features selected in my target platform i guess this are more than 200-Plugins. Here are my results of the sample project:
- org.xtext.example.mydsl contains no errors and compiles, but when i try to run the GenerateMyDsl.mwe2 i get: java.lang.ClassNotFoundException: org.eclipse.xtend.expression.ExecutionContext
- org.xtext.example.mydsl.sdk contains no errors and compiles
- org.xtext.example.mydsl.tests does not resolve the junit packages although it is included as implicit dependency in the target platform
- org.xtext.example.mydsl.ui does not resolve org.eclipse.ui.ide;bundle-version="3.5.0" because i am running on e4.2, but that okay for now
I think there is no other solution for my current project to chase the complie error i have to leave them. Because we don't need the generated ui plugin of our dsl we can life with that. Whenever we have to change our language we switch our project target platform to ${eclipse-home} were every thing is fine for xtext (but not the rest of our project) and generate the code again. This is not the best solution but i guess it the only workaround on the horiziont.
[Updated on: Wed, 27 March 2013 08:04] Report message to a moderator
|
|
|
Re: Unable to launch mwe2 workflow [message #1027807 is a reply to message #1027640] |
Wed, 27 March 2013 12:39 |
|
Hi
I created a brand new Xtext project (as you did) and created this
juno.target file
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?>
<target name="juno" sequenceNumber="0">
<locations>
<location includeAllPlatforms="false" includeConfigurePhase="true"
includeMode="planner" includeSource="true" type="InstallableUnit">
<unit id="org.eclipse.platform.feature.group"
version="4.2.1.v20130118-173121-9MF7GHYdG0B5kx4E_SkfZV-1mNjVATf67ZAb7"/>
<unit id="org.eclipse.xtext.sdk.feature.group"
version="2.3.1.v201208210947"/>
<repository location="http://download.eclipse.org/releases/juno"/>
</location>
</locations>
</target>
if I set this as the target platform everything works perfectly, and I
can run the mwe2 workflow without any error...
(hamcrest and junit stuff are dragged in automatically since they are
dependencies)
you were talking about a standard .target definition file, weren't you?
cheers
Lorenzo
On 03/27/2013 09:03 AM, Christian Schwarz wrote:
> Thanks for your help. I figured out that org.eclipse.platform and
> org.eclipse.xtext.sdk + its dependencies is not enough. I also added all
> the mwe stuff and plugins that are not part of any feature like hamcrest
> and junit. In the end i got 42 features selected in my target platform i
> guess this are more than 200-Plugins. Here are my results of the sample
> project:
>
>
> org.xtext.example.mydsl contains no errors and compiles, but when i try
> to run the GenerateMyDsl.mwe2 i get: java.lang.ClassNotFoundException:
> org.eclipse.xtend.expression.ExecutionContext
> org.xtext.example.mydsl.sdk contains no errors and compiles
> org.xtext.example.mydsl.tests does not resolve the junit packages
> although it is included as implicit dependency in the target platform
> org.xtext.example.mydsl.ui does not resolve
> org.eclipse.ui.ide;bundle-version="3.5.0" because i am running on e4.2,
> but that okay for now
>
>
> I think there is no other solution for my current project to chase the
> complie error i have to leave them. Because we don't need the generated
> ui plugin of our dsl we can life with that. Whenever we have to change
> our language we switch our project target platform to ${eclipse-home}
> were every thing is fine for xtext (but not the rest of our project) and
> generate the code again. This is not the best solution but i guess it
> the only workaround on the horiziont.
>
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
|
Powered by
FUDForum. Page generated in 0.05173 seconds