As this article says, a start level is simply a non-negative integer value. But I checked the start level of "org.eclipse.osgi" in \configuration\org.eclipse.equinox.simpleconfigurator\bundles.info
org.eclipse.osgi,3.18.100.v20220817-1601,plugins/org.eclipse.osgi_3.18.100.v20220817-1601.jar,-1,true
-1 ? Why ?
This is the value of the BundleInfo.NO_LEVEL constant - which means this bundle doesn't have a start level.
org.eclipse.osgi contains the EclipseStarter class which contains the main entry point. It is called by Java rather than being started by the OSGi framework.
Related
First of all , I am new to Acceleo and the modeling features of eclipse. What I am trying to do is just to create a simple test file. So for starters, I created a main module:
comment encoding = UTF-8 /]
[module generate('file:/C:/Users/maria/Documents/workspace/org.eclipse.acceleo.module.m2tTransformation/model/PSMMetamodel.ecore')]
[template public generateElement( aServicePSM : ServicePSM)]
[comment #main/]
[file ('test.java', false, 'UTF-8')]
Test
[/file]
[/template]
When i run this I get:
The generation failed to generate any file because there are no model elements that matches at least the type of the first parameter of one of your main templates.
The problem may be caused by a problem with the registration of your metamodel, please see the method named "registerPackages" in the Java launcher of your generator. It could also come from a missing [comment #main/] in the template used as the entry point of the generation.
Also the URI I use is the nsURI attribute value I set to the root of metamodel. I am sure that my input model does contain ServicePSM elements.
What am i doing wrong?
Thanks in advance.
This issue will arise in two cases
You do not have an element of the proper type in your model
The metamodel cannot be resolved
From your message I think we can safely ignore 1. since it seems you have at least one ServicePSM in your model, so we need to address 2.
If you look at your module, you've declared it to generate on metamodel file:/C:/Users/maria/Documents/workspace/org.eclipse.acceleo.module.m2tTransformation/model/PSMMetamodel.ecore. However, EMF rarely, if ever, uses this kind of URIs to refer to its metamodels. If you open your actual model with the text editor (right click > Open With > Text Editor), you can look at the URI that's actually been used to reference the metamodel with the "xmlns" tags at the start.
For example, if I open a model that references OCL elements, I can see xmlns:ocl.ecore="http://www.eclipse.org/ocl/1.1.0/Ecore". You have to make sure you use the same URI in your module file as what you see EMF using in the model file, in this case, it would be http://www.eclipse.org/ocl/1.1.0/Ecore.
I'm using NDepend to help manage a project and I was just asked to get an ordered list of dependencies (for build ordering of different solutions) based on what was using, both directly and indirectly, a given assembly.
NDepend provides a fine way of finding those modules that are dependent on that assembly, but no way of ordering it in the way I want. For instance I can run
from a in Assemblies
let depth0 = a.DepthOfIsUsing("Assembly1".MatchAssembly())
where depth0 >= 0 orderby depth0
select new { a, depth0 }
and that will get me a list like this
Assembly1 0
Assembly2 1
Assembly3 1
Assembly4 2
Which essentially means that Assembly2 and Assembly3 have direct dependencies on Assembly1, and Assembly4 has a dependency on either Assembly2 or Assembly3.
My problem exists because Assembly3 has a dependency on Assembly1 AND Assembly2. And if Assembly4 only had a dependency on Assembly 2, I'd like to see a list like this:
Assembly1 0
Assembly2 1
Assembly3 2
Assembly4 2
If Assembly4 also had a dependency on Assembly3, then the list should look like this:
Assembly1 0
Assembly2 1
Assembly3 2
Assembly4 3
Now I can export the original list to a dependency graph, and view it horizontally, and manually fill out that dependency list myself, but I've actually got 123 assemblies in my hierarchy and that's a hell of a job, especially when I have other processing to do after that (something I know can't be achieved with NDepend), so I'd rather find a way of do this in CQL.
Anyone with ninja NDepend skills know how I can achieve this?
Thanks.
I'm debugging my Scala SBT project in IntelliJ Idea 13.
However, it seems to me that I'm getting less info on my local variables as I used to.
Two Problems:
(minor) First of all, hovering over a variable doesn't show me its current value (I need to have alt pressed, even though I've checked the corresponding setting in
Debugger > Data Views > Auto tooltips for values .
(major) Second: See this screenshot:
http://www.directupload.net/file/d/3517/kdtr4k6j_png.htm
Once I enter the while loop, I don't get any information on the current value of the variables as defined above (e.g. RkNN_q). Why is that?
If I remember correctly, this used to be different.
I have set the Scala Debugging info level to: "Source, line number and local variable information".
(Same problems occur in IntellIj Idea 12)
Thank you very much in advance for your help!
I mistakenly have duplicate entries in my plugin.xml. But the eclipse IDE didn't complain. Shouldn't it?
Semantics for extension points vary. Eclipse only performs basic data type validation on the extension data at design time. The extension point handlers typically perform further validation at runtime, but the depth of that validation varies from one extension point to another. Problems detected at runtime will be reported in the error log.
I have an Eclipse plugin and I am aiming for 3.1 or 3.2 as a minimum version to support. The problem is that some of my code only works in version 3.5 and above (see my other question: Is there an alternative to CaretListener in Eclipse?).
Now that I have code that works in the older versions and different code that works in the newer versions, is there a way that I can call the newer code only if my plugin is running in version 3.5 or above and then revert to the old code if running anything older?
As a test, I've created two plugins that have the same class within it (just doing slightly different things). I have marked the org.eclipse.ui dependency as a minimum of 3.5 in one plugin and 3.1 as a minimum in the other but I can't get the one that relies on 3.5 to be ignored in older versions...
Can anyone help?
Thanks,
Alan
You could use org.eclipse.core.runtime.Platform to get the org.eclipse.ui Bundle and check the version.
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
// then do something with that
Register MyListener if >=3.5, and OldMyListener otherwise.
EDIT:
Right, the above is only good for capturing differences in runtime behaviour.
Eclipse supports a couple of tricks for only loading some classes.
The easiest from a development point of view is the trick that #ShiDoiSi mentioned.
Bundle myBundle = org.osgi.framework.FrameworkUtil.getBundle(this.class);
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
Version cutOff = new Version(3,5,0);
final Executable processListener;
if (ui.compareTo(cutOff)<0) {
Class pc = myBundle.loadClass("my.pkg.OldListenerProcess");
processListener = (Executable) pc.newInstance();
} else {
Class pc = myBundle.loadClass("my.pkg.ListenerProcess");
processListener = (Executable) pc.newInstance();
}
processListener.execute(targetObject);
Another option that uses more of the eclipse framework would be defining your own extension point so that contributions from other bundles can decide which version to use. Basically it's the same pattern as above, except the version checking is done by the dependency ranges on the plugin the contributes the Executable to run. Depend on org.eclipse.ui [0.0.0,3.5.0) for the old way, and simply specifying org.eclipse.ui 3.5.0 (that's an open ended range on 3.5.0) for the current way. Then you can read your extension and instantiate the class provided.
If you were creating extra plugins for this (a little heavy weight for the 2 differences) you could define a command in your main plugin, and have the extra plugins provide the equivalent handler. The plugins would still have to have dependency ranges so that only one would load for the <3.5 or >=3.5 case. Then using the command API you could execute the command (and the correct handler would run).
ICommandService cmdS
= (ICommandService) workbenchWindow.getService(ICommandService.class);
Command process = cmdS.getCommand("my.pkg.ListenerProcess");
ParameterizedCommand cmd = new ParameterizedCommand(process, null);
IHandlerService handlerS
= (IHandlerService) workbenchWindow.getService(IHandlerService.class);
IEvaluationContext ctx = handlerS.createContextSnapshot(false);
ctx.addVariable("toAddListener", targetObject);
handlerS.executeCommandInContext(cmd, null, ctx);
Then your implementation of handler would use HandlerUtil.getVariable(event, "toAddListener") to extract the object you need from the ExecutionEvent.
It sounds to me that you should be supplying two plugins, one supporting version 3.1 to "just below" 3.5, and the other one from 3.5 upwards. So you don't really get to choose, it's basically the Eclipse plugin layer choosing the right one based on your version ranges.
Or if you provide just the compiled class files, then of course you could load the required class dynamically based on testing the version of the running Eclipse.