I have a custom XML format that links to Java resources. For the sake of simplicity let's assume my XML file would look like this:
<root>
<java-class>my.fully.qualified.class.name</java-class>
</root>
Eventually my references will be somewhat more complicated. It will not contain the fully qualified class name directly and I will need some logic to resolve the correct class, but I want to keep the example as simple as possible here.
Now I want it to be possible to Strg+Click on the element's text and want IntelliJ to carry me to the .java file, just like it is possible in Spring-XML files. In the IDEA Plugin Development FAQ there is a link called "How do I add custom references to Java elements in XML files?" which so much sounds like exactly what I need. Unfortunately it links to a discussion where someone is more or less done implementing something like this, having some minor problems. Nevertheless I understood that I probably need to write an implementation of the interface com.intellij.psi.PsiReference. Googling for "PsiReference" and "IntelliJ" or "IDEA" unfortunately did not bring up any tutorials on how to use it, but I found the class XmlValueReference which sounds useful. Yet again googling for "XmlValueReference" did not turn up anything useful on how to use the class. At least the PSI Cookbook tells me that I can find the Java class by using JavaPsiFacade.findClass(). I'd be thankful for any tutorials, hints and the like, that tell the correct usage.
The above linked discussion mentions that I need to call registry.registerReferenceProvider(XmlTag.class, provider) in order to register my provider once I eventually managed to implement it, but of which type is "registry" and where do I get it from?
First of all, here's a nice tutorial that came up a few days ago, which explains the basics of IntelliJ plugin development (you should take a look at the section Reference Contributor).
You will likely have to define your own PsiReferenceContributor, which will be referenced in your plugin.xml like this:
<psi.referenceContributor implementation="com.yourplugin.YourReferenceContributor"/>
In your reference contributor, there's a method registerReferenceProviders(PsiReferenceRegistrar) where you will be able to call registry.registerReferenceProvider(XmlTag.class, provider).
Finally, in your instance of PsiReferenceProvider, you will have to test the tag name to filter out tags which don't contain class references, then find the right Java class using JavaPsiFacade.findClass().
From my experience, the best place to get help regarding IntelliJ plugin development is JetBrains' forums.
Related
Is there a way to get the raw XML text which another plugin has contributed to an extension point?
The normal way to access data that is contributed to an extension point is to use IConfigurationElement objects:
IConfigurationElement[] configElems = Platform.getExtensionRegistry()
.getConfigurationElementsFor(LANGUAGES_EXTENTION_POINT_ID);
But I already have JAXB parser for the kind of data that is contributed to this extension point. I'd like to use that one instead of Eclipse's classes.
EDIT 1: An alternative would be to use some kind of Eclipse-configuratoin-to-JAXB bridge library. But I don't find any.
EDIT 2: It's probably possible to find the plugin.xml of the contributing plug-in and read that manually... Probably not a good idea.
EDIT 3: I think I will do this: Instead of contributing the data directly clients get to give a file name. I then read that file using my old parser.
No, I don't see anything that would give you the XML.
getConfigurationElementsFor gives you information extracted from many different plugin.xml files so it is not clear what XML could be returned anyway.
org.eclipse.core.internal.registry.ExtensionRegistry is the extension registry implementation, but a lot of the information that uses comes from org.eclipse.core.internal.registry.RegistryObjectManager.
I want to find all the child plug-ins of a feature ? I know the name of the feature, but IWorkspaceRoot.getProject(String) does not really help me. I get an IProject that I don't know how to convert to a feature object (IFeature ?). Maybe I am on the wrong track and there is a better / easier way to do this. Any ideas ?
You could check that a selected IProject is a feature project by checking for the nature called org.eclipse.pde.FeatureNature.
Then you could try to use IProject.getAdapter(IFeature.class) call, the cast the result to IFeature. I did not try this with feature projects, but works well with Java projects.
The correct answer is the use of PDECore static class. This class provides a FeatureModelManager, that would provide the corresponding information:
FeatureModelManager manager = PDECore.getDefault().getFeatureModelManager();
How to obtain this information? I looked with the plug-in spy to find which project defines the 'Deployable Features' export wizard (use Alt+Shift+F3 when the wizard is selected), and then looked at the implementation of the wizard class, where the addPages() method contains the previously described code block.
Suppose I am working on exposing some of my server-side classes to a GWT application, but certain parts could be done much better using GWT-specific components (like JSNI, for instance).
What are some techniques for doing so without being too hacky?
For instance, I am aware of using a subpackage and using the <super-source/> tag, but this requires the package names to be different, which causes eclipse to complain. The general solution in the community is to then tell eclipse to use that as a source folder, but then eclipse complains about there being two classes with the same name.
Ideally, there would just be a way to keep everything in a single source tree, and actually have different classes which apply the alternate implementations. This would feel like a more OO approach.
I would like to add a suffix to a class like _gwt which accomplishes this automatically, and I know I could write a script to do this kind of transformation, but that is a kludge for sure.
I've been considering using Google's GIN/GUICE libraries for my projects in general, and I think there might be some kind of a solution there, but I am not sure as I have not thoroughly investigated it.
What are some solutions you have tried in the past on GWT projects?
The easiest way to have split implementations is to use super-source code, but only enough to instantiate a uniquely-named instance or dispatch to a different method. Ideally, the super-source implementation is just a few lines long, and not so bad that you can't roll it by hand.
To work around the Eclipse / javac double-mapping and package name issues, the GWT source uses two top-level roots for user code: user/src and user/super. For example, the AutoBeans package has a split-implementation of JSON quoting and evaluation, one for the JVM and one for the browser.
There's really no non-kludgy way to implement super-source, as this is a feature way outside what you can specify in the language. There's nothing that lets you say "use this implementation in this environment" without the use of some external tool.
If you've used javadoc and then come to doxygen, you may know what I mean when I say I miss the hierarchical (frame-based) view that made jumping from class to class and method to method easy. (For those who haven't seen it, imagine a tree-navigator in an IDE or over a filesystem).
How can I get Doxygen to include a navigation tree, if it's even possible?
A similar question was asked in October, but that was just about stylesheet alternatives and only one turned up. I think I'm looking for something more major.
Note that all you need to do to get the tree on the left in Quinn's example is setting GENERATE_TREEVIEW to YES in the config file.
At a basic level, Doxygen output is what it is, and I don't think there's "a better way to view" static HTML content. I think what you want is for Doxygen to produce HTML output that is more similar to Javadoc, which has both pros and cons. (The biggest drawback is that it's unlikely to happen, due to the effort involved and the broad user base.)
I manage a project that is documented using Doxygen, and I'm not sure to what degree my config uses the Doxygen defaults, but I get a sections in the left frame for a flat class list and a class hierarchy. Also, since I have diagrams enabled, the Graphical Class Hierarchy is a fairly quick way to jump to where I want. I haven't delved into Doxygen modules, so I don't have any experience with whether that might segment things similar to how Javadoc does with packages.
By default all I get in intellisense are the functions and its signature. I would prefer if I could also get documentation with the intellisense. I realise that I am supposed to place an xml file that contains this documentation along with my dll.
From where can I get this is file? Or is there some other way for me to achieve this?
For the immediate future, there's no way to get the XML documentation short of grabbing the Structuremap source and building it yourself.
As for why that's not included with the distribution, I'm not sure. My only guess is that back when xml-based configuration with SM was more prevalent, Jeremy was concerned about confusion between StructureMap.xml the intellisense file, and StructureMap.xml the configuration file.
That's pure speculation however. For the real scoop you'd have to post on the SM-mailing list. Regardless, for the time being, you have to roll your own from the source. I've done this as well for the same reason, and it wasn't too painful.
-Scott
Edit - Instructions for doing this follow.
Using your favorite SVN client (if you don't have one, I recommend TortoiseSVN) grab the latest from https://structuremap.svn.sourceforge.net/svnroot/structuremap/trunk/ . If you want the same bits that are in 2.5.3, I think you'll want revision 234. Otherwise, just grab the head and build from that. (If you aren't familiar with SVN, find a tutorial that explains what I'm talking about)
Open up the StructureMap solution in Visual Studio (under the Source subdirectory). Right click the StructureMap project, Go to Properties > Build and ensure the option for XML output documentation is checked.
Build and enjoy.