|
|
|
Re: OCLinEcore - UI Dependency? [message #735019 is a reply to message #734934] |
Mon, 10 October 2011 16:17 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
I'm not clear why you think an instance of org.eclipse.ui.IWorkbench is
needed.
If you want no UI then that should be easy; the challenge is to
correctly populate the ResourceSet(s).
It looks as if you're trying to do exactly the same as the normal JUnit
tests that we run standalone, so you may like to look at the
org.eclipse.ocl.examples.xtext.tests plugin if you want tro use the new
Pivot model or org.eclipse.ocl.ecore.tests for the traditional Ecore model.
Regards
Ed Willink
On 10/10/2011 14:24, thomas.kipar wrote:
> Hi,
>
> actually, I do not want to run this as java stand-alone application
> but as eclipse application without any UI plugins. The posted
> exception suggests that this is not possible (instance of
> org.eclipse.ui.IWorkbench is needed).
>
> If I just run my application with all plugins, everything works fine.
> Since I do not want my application to conatain any UI, this is not the
> way to go. I do not know which plugins I really need in order to use
> my generated model code (enriched with OCL statements) to run. I think
> I need
>
> - org.eclipse.ocl.examples.pivot
> - org.eclipse.ocl.examples.library (otherwise I get an exception
> saying no OCL lib could be found).
>
> Still, this does not seem to be enough. If I only select these plugins
> (and required plugins as well), I receive the following exception:
>
> org.eclipse.ocl.examples.pivot.delegate.OCLDelegateException: OCL
> evaluation result of 'execplan::execplan::ExecutionNode.next' is invalid
> at
> org.eclipse.ocl.examples.pivot.delegate.OCLSettingDelegate.get(OCLSettingDelegate.java:72)
> at
> org.eclipse.emf.ecore.util.BasicSettingDelegate$Stateless.dynamicGet(BasicSettingDelegate.java:191)
> at
> de.biotronik.osiris.core.model.execplan.impl.ExecutionNodeImpl.getNext(ExecutionNodeImpl.java:124)
> at de.biotronik.osiris.unittests.TestTest.testIt(TestTest.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
> at
> org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
>
>
> So some plugin must be missing in order to evaluate the OCL statements
> correctly. Unfortunately, I am not able to figure out which ones (and
> if an UI plugin is required as well which would prevent the usage of
> OCL enriched ecore models for me). Would be glad if you could help me
> out.
>
> Kind regards,
>
> Thomas
|
|
|
Re: OCLinEcore - UI Dependency? [message #735743 is a reply to message #735019] |
Wed, 12 October 2011 15:55 |
thomas.kipar Messages: 13 Registered: July 2011 |
Junior Member |
|
|
Hi,
thanks for your response. For now, I am not loading my model from a resource but create it "by hand" with help of the generated model factory. This is why I have no resource set at this time. Still, it should work (I think) - but it does not. I had a look at the unit tests, there all models are loaded from files (this is at least what I saw). Note that I want to run my unit test as plugin-test.
Moreover: What is the difference between the "new Pivot model" and the "traditional Ecore model"?
edit: Oksy, the tests runs if I select the following plugins to start as well (when running my eclipse unit test):
- org.eclipse.ocl.examples.xtext.essentialocl.ui
- org.eclipse.ocl.examples.xtext.xtext.console
- org.eclipse.ocl.examples.xtext.oclinecore.ui
- org.eclipse.ocl.examples.xtext.completeocl.ui
- org.eclipse.ocl.examples.xtext.oclsdlib.ui
So something must happen when those plugins are activated that is required for using my OCL defined methods (that I probably can also do without using them, I guess?).
Regards,
Thomas
[Updated on: Wed, 12 October 2011 16:05] Report message to a moderator
|
|
|
|
Re: OCLinEcore - UI Dependency? [message #997923 is a reply to message #735762] |
Wed, 09 January 2013 02:06 |
|
I have the same issue and am very thankful that you have posted this list of dependencies. I also do not understand why a resource set and resource should be mandatory to run this functionality. If they are, then a hint in the documentation of OclInEcore may be useful. This is one of the many times that I have found xText to be forcing users to learn the technology, even if that is not pertinent for the task at hand. It seems sad to lug the bulk of UI plugins around when what you really want to do is write some queries over data... I wish the OCL project in Eclipse was based on something less cumbersome.
|
|
|
Re: OCLinEcore - UI Dependency? [message #997925 is a reply to message #735762] |
Wed, 09 January 2013 02:09 |
|
I have the same issue and am very thankful that Thomas has posted this list of implicit dependencies. Like him I do not understand why a resource set and resource should be mandatory to run this functionality. If they are, then a hint in the documentation of OclInEcore may be useful. This is one of the many times that I have found xText to be forcing users to learn the technology, even if that is not pertinent for the task at hand. It seems sad to lug the bulk of UI plugins around when what you really want to do is write some queries over data... I wish the OCL project in Eclipse was based on something less cumbersome.
|
|
|
Re: OCLinEcore - UI Dependency? [message #998021 is a reply to message #997923] |
Wed, 09 January 2013 07:46 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
I think you expect too much and fail to appreciate what you get for free...
When Eclipse works well you have a number of build blocks that fit
together to allow advanced facilities to build on more basic facilities.
If for instance OCL provided its own editor rather than exploiting
Xtext, the editor might not exist at all yet, it would have an
inconsistent look and feel, have fewer features and would almost
certainly be substantially more buggy. Xtext provides an excellent frame
work that eliminates at least 90%, perhaps 99% of the work in developing
a second editor. I'm sorry it's not 100%. Clearly there is still scope
for improvement.
As a programmatic user, you have choices
- program the entire thing yourself
- exploit Eclipse facilities
- exploit some other framework
When exploiting Eclipse you must recognize the vast amount of free work
that has been contributed, and so you should expect to spend much much
more time researching/code reading rather than writing, since by
exploiting Eclipse frameworks you can often have very simple solutions
once you find them.
You should also recognize how much you have received for free and
endeavour to contribute constructively so that imperfections into the
building blocks and their integrations can be corrected, or by providing
tutorials that help other avoid your problems.
Quite apart from EMF's needs for a Resource and a ResourceSet, OCL's are
very justified. Consider allInstances(). It is necessary to discover
related objects. Clearly the universe of all instances is impractical
since the Pentagon may be unhappy to allow you to view their instances,
and you probably don't want your program to spend forever examining them
anyway. All instances is therefore defined as those in the prevailing
ResourceSet. If your instances are not so contained, OCL cannot work.
Less obviously efficient shareable implementation of a type system needs
ResourceSets (or something proprietary and similar).
The OCLinEcore documentation could certainly be a lot better, but I have
to compromise between time spent improving the code, improving the
documentation and helping users on newsgroups.... A basic understanding
of EMF is assumed for anyone programming an EMF-based application.
Please be constructive and realistic in criticizing free software.
Regards
Ed Willink
On 09/01/2013 02:06, Jörn Guy Süss wrote:
> I have the same issue and am very thankful that you have posted this
> list of dependencies. I also do not understand why a resource set and
> resource should be mandatory to run this functionality. If they are,
> then a hint in the documentation of OclInEcore may be useful. This is
> one of the many times that I have found xText to be forcing users to
> learn the technology, even if that is not pertinent for the task at
> hand. It seems sad to lug the bulk of UI plugins around when what you
> really want to do is write some queries over data... I wish the OCL
> project in Eclipse was based on something less cumbersome.
|
|
|
Powered by
FUDForum. Page generated in 0.02913 seconds