i created an extension point for one plugin(A). Another plugin(B) is setup as an extension to the ep from the first plugin.
When trying to use the extension point eclipse in A eclipse tells me that, it is not able to find configurable elements for the this extension point. The extension point itself is found.
I'm suspecting plugin B is not started at all. How can i check this?
Here is the code, where the extension point gets called:
IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();
IExtensionPoint[] extensionPoints = extensionRegistry.getExtensionPoints("A.extensionpoints");
//Prints both defined EP's
for (IExtensionPoint iExtensionPoint : extensionPoints) {
System.err.println(iExtensionPoint.getUniqueIdentifier());
System.err.println(iExtensionPoint.getExtensions().length);
}
IExtensionPoint extensionPoint = extensionRegistry.getExtensionPoint("A.extensionpoints.HavingProblemsWith");
System.err.println(extensionPoint.getLabel());//Prints the Label
System.err.println(extensionPoint.getConfigurationElements().length);// => 0
Fire up eclipse with the -console option. Then you have tools to view the status of the plugins and to start them, if you want so. It may give you some ideas on why the plugin hasn't been started.
Related
I am currently migrating an Eclipse 3.0 application to 4.4. The user data was and still should be stored in the folder C:\Users\username\AppData\Roaming\applicationname
The application is using following code to read the directory:
public static String getUserDirectory()
{
String directory = InternalPlatform.getDefault().getUserLocation().getFile();
return directory;
}
I know the code is deprecated, but following code returns the same:
public static String getUserDirectory()
{
String directory = Platform.getUserLocation().getURL().getFile();
return directory;
}
They both return C:\Users\username\user but as I said the user data should be stored at C:\Users\username\AppData\Roaming\applicationname. Did the behaviour of those methods change?
How can I realize that I store my user data under C:\Users\username\AppData\Roaming\applicationname and my application can still find the directory?
I know this has to do something with environment-variables which I don't fully understand.
I don't have a 3.x target platform at hand to compare but C:\Users\username\user looks plain wrong.
If you are interested in the details, the constructor of EquinoxLocations computes the userLocation and adds the literal 'user' the the user's home directory if no default is specified.
Hence, if you start your application with -user #user.home or -Dosgi.user.area=#user.home, the user location will be set to C:\Users\username\. Still not what you are looking for, but at least a sane value.
I think this is a bug in Equinox and recommend to file a bugzilla. If it turns out that there is a good reason for this appraoch the bug entry will still serve as documentation/reasoning.
In the meanwhile you could obtain the home directory on Windows through System.getenv( "APPDATA" ). According to this post it will return the roaming home directory.
I solved the problem by adding three properties in the Configuration tab of my config.ini.product-file:
osgi.configuration.area =
#user.home/AppData/Roaming/ApplicationName/...
osgi.user.area =
#user.home/AppData/Roaming/ApplicationName/...
osgi.instance.area =
#user.home/AppData/Roaming/ApplicationName
Now my method as stated in my question reads the paths that are configured by those properties and the config.ini file which is generated looks exactly like the one of the old build with Eclipse 3.0.
I want to programmatically (from a plugin) change the "Other flags" field in the Miscellaneous settings in the Tool Settings tab for an individual file in a CDT managed build project. (See this Eclipse documentation page for a screenshot and brief description of how this change would be made using the UI.)
Note: I've updated this twice now as I approach a solution. But instead of adding an update onto the end (as I do for shorter questions), I'm revising the entire question. If it helps to see the breadcrumbs leading to where I am now, you can read the history.
The following code will result in settings written to the .cproject file (I'll go into detail on that below), but when I open the Properties dialog for the file, and click on C/C++ Build->Settings and then Miscellaneous, the changes do not appear in the "Other flags" field (as they do when I make changes using the dialog).
IWorkbench workbench = PlatformUI.getWorkbench();
IWorkbenchWindow workbenchwindow = workbench.getActiveWorkbenchWindow();
IWorkbenchPage workbenchpage = workbenchwindow.getActivePage();
IEditorPart editorpart = workbenchpage.getActiveEditor();
IEditorInput editorinput = editorpart.getEditorInput();
IResource file = ((IFileEditorInput)editorinput).getFile();
IProject project = file.getProject();
IManagedBuildInfo buildInfo = ManagedBuildManager.getBuildInfo(project);
IConfiguration[] configurations = buildInfo.getManagedProject().getConfigurations();
IConfiguration conf = configurations[0];
IFileInfo fileInfo = conf.createFileInfo(file.getFullPath());
ITool[] tools = fileInfo.getTools();
ITool tool = tools[0];
IOption option = tool.getOptionById("my.gnu.compiler.misc.other");
String oldOptionValue = option.getDefaultValue().toString();
String newOptionValue = oldOptionValue + " -eg";
ManagedBuildManager.setOption(fileInfo, tool, option, newOptionValue);
ManagedBuildManager.saveBuildInfo(project, true);
I looked at the differences between the .cproject file where I changed the tool settings manually, and in a different .cproject file after running the above code. Below are the pertinent bits from each.
Here is the XML from the .cproject file where the tool settings were changed manually:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?fileVersion 4.0.0?><cproject storage_type_id="org.eclipse.cdt.core.XmlProjectDescriptionStorage">
<storageModule moduleId="org.eclipse.cdt.core.settings">
<cconfiguration id="com.company.product.toolchain.configuration.changed.1964078554">
...
<storageModule moduleId="cdtBuildSystem" version="4.0.0">
<configuration artifactName="${ProjName}" buildProperties="" cleanCommand="rm -f" description="" id="com.company.product.toolchain.configuration.changed.1964078554" name="changed" parent="com.company.product.toolchain.configuration.changed">
...
<fileInfo id="com.company.product.toolchain.configuration.changed.1964078554.915152327" name="code.cpp" rcbsApplicability="disable" resourcePath="src/code.cpp" toolsToInvoke="com.company.product.toolchain.compiler.1643348654.1411455203">
<tool id="com.company.product.toolchain.compiler.1643348654.1411455203" name="Company GNU compilers" superClass="com.company.product.toolchain.compiler.1643348654">
<option id="company.gnu.compiler.misc.other.789167779" name="Other flags" superClass="company.gnu.compiler.misc.other" value="-c -fmessage-length=0 -eg" valueType="string"/>
<inputType id="com.company.product.toolchain.cxxinputtype.877052163" name="C++ Input" superClass="com.company.product.toolchain.cxxinputtype"/>
<inputType id="com.company.product.toolchain.cinputtype.1390394900" name="C input" superClass="com.company.product.toolchain.cinputtype"/>
</tool>
</fileInfo>
...
And here is the XML from the .cproject file where they were changed programmatically:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?fileVersion 4.0.0?><cproject storage_type_id="org.eclipse.cdt.core.XmlProjectDescriptionStorage">
<storageModule moduleId="org.eclipse.cdt.core.settings">
<cconfiguration id="com.company.product.toolchain.configuration.changed.2057644715">
...
<storageModule moduleId="cdtBuildSystem" version="4.0.0">
<configuration artifactName="${ProjName}" buildProperties="" cleanCommand="rm -f" description="" id="com.company.product.toolchain.configuration.changed.2057644715" name="changed" parent="com.company.product.toolchain.configuration.changed">
...
<fileInfo id="com.company.product.toolchain.configuration.changed.2057644715./test3/src/code.cpp" name="code.cpp" rcbsApplicability="disable" resourcePath="test3/src/code.cpp" toolsToInvoke="com.company.product.toolchain.compiler.1482360042.1005761865">
<tool id="com.company.product.toolchain.compiler.1482360042.1005761865" name="Company GNU compilers" superClass="com.company.product.toolchain.compiler.1482360042">
<option id="company.gnu.compiler.misc.other.999025984" superClass="company.gnu.compiler.misc.other" value="-c -fmessage-length=0 -eg" valueType="string"/>
<inputType id="com.company.product.toolchain.cxxinputtype.1253686787" name="C++ Input" superClass="com.company.product.toolchain.cxxinputtype"/>
<inputType id="com.company.product.toolchain.cinputtype.1141524787" name="C input" superClass="com.company.product.toolchain.cinputtype"/>
</tool>
</fileInfo>
...
Aside from the numbers, which I assume are some kind of GUIDs, there are three differences:
For some reason, the id attribute of the fileInfo element in the programmatic changes contains the path to the file, including the project name: id="com.company.product.toolchain.configuration.changed.2057644715./test3/src/code.cpp"
The resourcePath attribute value of the fileInfo element contains the project name, only in the programmatic changes: resourcePath="test3/src/code.cpp".
The option element in the fileInfo element as a name attribute (name="Other flags") that matches the field in the dialog, only in the manual changes.
I'm guessing that one or all of these differences are preventing my programmatic changes from being "compatible" with the manual ones (so they show up in the dialog). I'm trying to figure out how to create the IFileInfo, IOption (and ITool?) objects without causing these differences. I'm trying to find how these objects are created for the dialog, but haven't yet.
Any suggestions appreciated.
Update: I got an answer from Doug Schaefer to my question on the cdt-dev mailing list. He suggested I "stick breakpoints in places and see how the UI does it." I wrote back:
I have been doing that. I set a breakpoint in org.eclipse.cdt.managedbuilder.core.ManagedBuildManager.setOption(IResourceInfo, IHoldsOptions, IOption, String) and it triggers when I open the Properties dialog for a file, expand "C/C++ Build", select "Settings", and then "Miscellaneous" in the Tool Settings tab. I can see the arguments, and presumably if I can call setOption with the same arguments I'll get the same results in the .cproject file. But I haven't been able to figure out how to do that. Do you have any suggestions for how I figure out where those objects are created so I can set breakpoints there?
Update #2: Vladimir's answer solved my problem. While I was more concerned with difference number 3 in the two .cproject file fragments above, the key was difference 2 and the inclusion of the project name in difference 1.
I changed the code to create the IFileInfo object to:
IFileInfo fileInfo = conf.createFileInfo(file.getProjectRelativePath());
...which resulted in the fileInfo element not having the project name:
<fileInfo id="com.company.product.toolchain.configuration.changed.838214286.src/code.cpp" name="code.cpp" rcbsApplicability="disable" resourcePath="src/code.cpp" toolsToInvoke="com.company.product.toolchain.compiler.2027651356.1970239371">
...and most importantly, resulted in the programmatic changes showing up in the "Other flags" field in the Miscellaneous settings in the Tool Settings tab for the individual file. (I guess the other differences in the .cproject files are not important.)
I suspect there might be problem in you IFileInfo creation. Here's the code that we use to obtain IResourceInfo for a translation unit to set per-file options:
protected IResourceInfo getResourceInfo(ITranslationUnit translationUnit, ICProjectDescription prjDescription) {
ICProject cProject = translationUnit.getCProject();
if (cProject != null) {
ICConfigurationDescription cfgDescription = prjDescription.getActiveConfiguration();
IConfiguration configuration = ManagedBuildManager.getConfigurationForDescription(cfgDescription);
IPath projectPath = translationUnit.getResource().getProjectRelativePath();
IResourceInfo ri = configuration.getResourceInfo(projectPath, true);
if (ri == null) {
ri = configuration.createFileInfo(projectPath);
}
return ri;
}
return null;
}
Note this line, in particular:
IPath projectPath = translationUnit.getResource().getProjectRelativePath();
Maybe, all you need is to use getProjectRelativePath() in your code?
Generally you can set an option to different objects, i.e. a configuration (if you want the option to apply to all files of a given type in a configuration) or a resource (if you want the option to apply only to the files in a folder or to a single file).
setOption() has multiple prototypes; it looks like you used the one that applies to a file resource.
In my GNU ARM Eclipse Plug-in I successfully used another version:
setOption(IConfiguration config, IHoldsOptions holder, IOption option, String value)
You can see an example in this file, line 583.
I guess this will work in your case too.
Using Vim Syntastic with an android project. (e.g. com.myproject.project) It's not aware of classes declared within my project but outside of the current file. e.g. the following flags errors:
import com.myproject.project.SomeClass;
...
SomeClass someclass = new SomeClass();
Saw this post Configure syntastic to work fine with Android projects which solve the problem:
Method 1:
Inside vim editor
:SyntasticJavacEditClasspath
Then add the following to the buffer window
/path-to-your-app/bin/classes
/path-to-your-android-sdk/platforms/android-19/*.jar
Method 2:
Add the following to the .vimrc:
let g:syntastic_java_javac_classpath = "/<path-to-your-app>/bin/classes:/<path-to-your-android-sdk>/platforms/android-19/*.jar"
Here is a summary of the various methods which worked for me in linux vim7.4 and Syntastic3.7.0-224 with credit to each.
Method 1 - manual creation of .syntastic_javac_config
1. Edit .vimrc and use this syntax:
let g:syntastic_java_javac_config_file_enabled = 1
2. Where you edit your vim files, add this to a file named .syntastic_javac_config
let g:syntastic_java_javac_classpath = '/home/davis/progs/princeton-algos/week1/libs/algs4.jar'
Method 2 - advantage no matter where you edit the class path is known.
1. Edit .vimrc and use this syntax:
let g:syntastic_java_javac_classpath = "/home/davis/progs/princeton-algos/week1/libs/algs4.jar"
This adds the jar and
Method 3 - Automatic generation of .syntastic_javac_config file
1. Edit .vimrc and use this syntax:
let g:syntastic_java_javac_config_file_enabled = 1
2. Edit a java file with vim
3. :SyntasticJavacEditClasspath
When the edit window opens, add the class path without quotes and a newline after each entry the class path. In my case, this is the entry
for the setting includes the current folder as well:
/home/davis/progs/princeton-algos/week1/libs/algs4.jar
.
4 :wq the edit setting window
5. Now the class path is set for syntastic when editing files from that location. If you edit from a new directory, you will need to repeat the process.
Besides the comments above, this post also helped.
I'm using JRules 6 and trying to execute a rule using the JRules API.
I create a new IlrSessionRequest object, passing a ruleset path to its constructor. When it executes, it fails, saying Syntax error in ruleset path and an error code of XU.ERROR.10048. Google isn't providing much help ..
What does the ruleset path refer to? Niaevely, I've just put in the path to the jar file that contains my XOM, but it doesn't seem to like that.
Any idea how I can find out what the ruleset path is?
The Path has to be specified in the same way it is shown on the Rule Execution Server:
/ruleApp/ruleSet without any path-information. Here is a sample of the usage in JRules 7.1. This may work different on JRules 6:
String rulesetPath= "/" + "your_ruleApp" + "/" + "your_ruleset";
IlrSessionFactory factory = new IlrPOJOSessionFactory();
IlrSessionRequest request = factory.createRequest();
request.setRulesetPath(rulesetPath);
XU = eXecution Unit so based on your explaination I would say that "JRules" is complaining because it cannot find your ruleset in your ruleapp and hence crashes.
Open the jar file (ruleapp) inside you should see at least one folder named: "your ruleapp name"
in it a folder named: "your ruleapp version" (possibly "1.0")
in it : "your ruleset name"
in it : "your ruleset version"
and in it your rule atrifacts.
Makes sense?
Possible ruleset path:
1/ ruleappName/ruleappVersion/rulesetName/rulesetVersion
2/ ruleappName/rulesetName/rulesetVersion
3/ ruleappName/ruleappVersion/rulesetName
4/ ruleappName/rulesetName
Note: Version is optional and if not specified then the latest version deployed will be used.
I coded a whole set oh Helpers and Factories for JRules (7.01 and 7.1) - some tweaks may be needed with version 6
Let me know if you are interested.
Basically there are RTSHelper and RESHelper libraries
containing static methods to create queries, business rules, extractor, ruleset, ruleapp, deploy, create a ruleset based on query and so on...
Remove ruleapp from RES after execution and a lot more...
I have some misterious problem with system proxy detection:
Actually, I have the right code to detect system proxy settings at runtime, it can handle pac files and http proxy settings as well.
It works absolutely correct, when I store and execute everything on the target station.
BUT: I run one little piece of code on the target station and store anything else (jars) on another station, on which apache webserver runs. From the main I load the classes with URLClassloader, so that piece of code loaded via network, which responsible for the proxy detection as well. And in this way the default proxy selector give DIRECT all time, it is not able to find the right settings.
I think, the problem is that I want to set the
System.setProperty("java.net.useSystemProxies","true");
In the loaded class and somehow this does not work...But when I sysout the property value, it is true.
I wrote a little test program and the only difference is that:
A)
Class.forname("a"); -> a is in the classpath
B)
URL[] url = new URL[1];
url[0] = new URL("http://1.2.3.4/dtfw");
URLClassloader u = new URLClassloader(url);
Class.forname("a", true, u);
Both piece of code work, the only different is in the output.
Does anyone have some idea?
Thanks in advance!!
Zsomi
I found the root cause of the problem:
The DefaultProxySelector is singleton per JVM and the behavior of it based on if System.setProperty("java.net.useSystemProxies","true"); is set or not.
As the URLClassloader uses it, this value is false, when it is instantiated. And when in the "a" class I try to use it, it is not able to find system proxy settings, since at instatiation this property was not set.
So I have the cause, but no solution yet.
Regards,
Zsomi