I'm looking for an eclipse plugin which can at least search where the current JSP is included (or the path mentioned for example in custom "include like" tags or comment or anything). Similar like doing copy qualified name and do a file search with the correct path.In IDEA it's called Analyze Backward Dependencies and it works for JSPs too (at least for the standard includes).
A better one would be to show all the JSPs where the current one is included and show all the included JSPs recursively as a tree maybe so I can navigate in it easily. I'm not sure if this can be done to be usable (I think it would be slow).
Another feature I would like if I click on a variable's name it jumps to where it's declared with even if it's declared in a different JSP.IDEA can do this too.
I have a simple solution for the first one but I can't add more functionality to it as I'm not familiar with the eclipse plugin system and RCP and I don't really have time to learn it.
And please don't tell me to use IDEA because unfortunately that's not an option at work.
Related
I'm developing a struts2 webapp for months now using maven to manage my dependencies and I've just discovered LESS. I have installed and configured the LESS plug-in for Eclipse but it's really annoying to right click > run as > LESS compiler every time I save the .less file due to a modification of its content or something...
The thing is that I've been researching on how to plug in grunt.js (recently discovered task runners too) into maven (as explained here) but I think it's quite hard and I wondered if somebody knew an alternative to this.
In my struts2 project I have both the front and back-end of my webapp.I know it's not the right approach and if I could start all over again I would separate them into two different projects, but now it's too late (disadvantages of the learning proccess, we're not born knowing it all).
Having said all this, how can I set up a kind of task for watching my .less files and automatically compile them into .css when saved/changed?
I also found this ant task here, but I dont really know if it's what I'm looking for.
There are a lot of Java Less compiler (see Java Compiler for Less CSS?), so you can execute one of them by your build tool (e.g. Ant - maybe you need to write a simple Java application, which use the chosen compiler).
If you use Maven (or can switch to it) to project management, then you can use one of lesscss-maven-plugin:
biz.gabrys.maven.plugins:lesscss-maven-plugin
org.lesscss:lesscss-maven-plugin
see more...
It is possible to create an ant task to compile certain .less files into CSS whenever they are modified, and more or less is what I was looking for, but grunt seems to be more flexible as you can tell it to watch all your files with .less extension and in this solution I've found you have to declare in an .xml file the .less files you want ant to watch.
This is not explicitly what I was looking for so I'll leave this question open for now as I'll keep researching on how to make this solution more dynamic and see if it is possible to avoid the fact of defining every .less source and .css target you want.
Link to solution here
When writting RCP Plug-ins it often happens that i need to declare and reference IDs in the extension specification (i.e. in the plugin.xml) and also in my java code. When I change one of those, I also have to change the duplicate.
I'm not sure if the problem is already that the same IDs must be used in the code and the plug-in declaration, but thats how the eclipse plug-in templates do it. If that's the root of the problem: how to prevent it?
If it's the correct way, to declare and reference IDs in the plugin.xml and in the java code: how to prevent that code dulication?
Also inside the plugin.xml there is something that may be regarded as duplication: ID definitions and the references pointing at them. If I change the definition, all references have to be updated. One could do that by simply replacing all text-occurence. But I normally edit the plugin.xml in the Plug-in Manifest Editor (i.e. in the forms, not in the plain text XML). Is there a way to refactor the IDs from inside the forms, without touching the plain text xml and without the fault prone approach of simple text replacement?
If you are referring to properties such as Bundle-SymbolicName then you should think of it as a package name, i.e something that shouldn't change at all.
Several of the other fields can very easily be externalized to strings, this is to simplify translations. See this help page. A wizard is available on the overview tab in the manifest editor.
There are quite a few questions with similar titles, but please read on as this is subtly different and I've not yet been able to find a solution in the many answers given to those other questions.
Scenario:
I have an external JAR file with a separate HTML tree javadoc. I have pointed Eclipse at the javadoc by completing the JAR's "Javadoc Location" in the build path dialogue. The source is not available to Eclipse.
At first it looks like this is working fine. If I hover over a class name (say, Wibble) the corresponding javadoc text pops up.
However, if I hover over a method (say the word create in blah = Wibble.create();), I get the pop-up "...the Javadoc could not be found..." which is confusing as it's just shown me the javadoc for the Wibble class.
Indeed, if I click on the icon within the pop-up to "Open Attached Javadoc in a Browser" it correctly opens the HTML and presents me with the text for the method that it just said it could not find!
Technical notes:
My Eclipse version is Android Developer Tools, Build: v22.2.1, though this was happening on vanilla Eclipse before I updated to the ADT version.
The javadoc is being generated by command line using the Doclava doclet.
Any suggestions about either what might be wrong in the javadoc, or in eclipse settings, or...?
EDIT In the course of subsequent experimentation I've found that this problem only occurs with a combination of Eclipse and javadoc generated by Doclava. My pragmatic solution has been to generate the javadoc twice - once for human readability by using Doclava, and once for Eclipse readability using vanilla Javadoc.
If anyone knows these systems in depth I'd still love to know why.
(In order to not leave this 'unanswered' now that I have a solution)
In the course of subsequent experimentation I've found that this problem only occurs with a combination of Eclipse and javadoc generated by Doclava. My pragmatic solution has been to generate the javadoc twice - once for human readability by using Doclava, and once for Eclipse readability using vanilla Javadoc.
If anyone knows these systems in depth I'd still love to know why.
I am looking for a way to link from a comment inside a .java file to another file somewhere in the project folder (like CMD-clicking a Java Type links to the Type declaration). In my case I am working on a (Spring Roo backed) web application, so I have controllers and view files.
What I have in mind may look like this (Javadoc-oriented but of course not parsed but used directly as a link):
public String orderlist(ModelMap modelMap){
modelMap.addAttribute("orders", Order.findAllOrders());
// #link("/WEB-INF/views/order/list.jspx")
return "order/list";
}
I want to CMD-click on the comment link to open the file.
I am heavily using Working Sets, filters and of course CMD+SHIFT+R ("Open Resource"), which are all great, but this might come in handy working on a controller and the corresponding view (especially in a team). Is this possible somehow, a basic feature that I missed completely so far or even total nonsense for some reason? I realize that those links should be considered when, for example, refactor|move the view file.
The feature you're describing is Eclipse's hyperlink detectors: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_ui_workbench_texteditor_hyperlinkDetectors.html. Unfortunately I'm not sure an implementation as you're describing is likely available.
There's an URLHyperlinkDetector that can pick up URLs, so you could potentially put a file:// URL in a comment and link to that, but I think that Eclipse is hard-wired to assume it's something that can be opened in it's browser. It's worth a shot, but of course the absolute paths would break sharing across teams/machines.
You could try your hand at contributing your own via a plugin that your team could install. Here's an implementation we created in Aptana Studio for picking up relative URIs in files and opening them in editors if possible: https://github.com/aptana/studio3/blob/development/plugins/com.aptana.editor.common/src/com/aptana/editor/common/text/hyperlink/HyperlinkDetector.java
I'm evaluating the possibility of developing an Eclipse plugin to modify the source code of some Java files.
The Eclipse plugin should:
add one menu option or context menu option to launch the modification process.
add a key binding
only alter the UI in that way when an editor has been open on a Java file.
the modification process would not open a dialog, or maybe, a very simple one.
the modification process would traverse the AST of the Java file and would modify it.
Considering that we have no experience with Eclipse plugins and we need spend time in reading docs, how much time do you estimate in developing that plugin?
Thanks in advance.
It's really not that difficult at all... I had students in my design patterns class doing it for an assignment (adding/removing javabean getters and setters)
See http://help.eclipse.org/ganymede/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_manip.htm
[EDIT: added the following article reference]
And a great article on it at http://www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html (from 2006 -- there may be a few API changes since)
Yes, writing plugins takes a little getting used to, but so does any API.
And you can modify the AST -- see the page I reference above.
(I should note that the above link is from the eclipse help, which can also be accessed via Help->Help Contents inside Eclipse -- there's a lot of good info in there, but it's just a starting point)
You'll probably spend quite some time cursing the complexity of the eclipse plugin system. There are some example plugin development projects that can be very helpful if they cover the area you're working in.
I'd say you're looking at 2-4 days of work, spent mainly getting familiar with the platform - someone with a lot of experience writing eclipse plugins would probably take no more than an hour.
However, your step 5 could be tricky. I don't know how easy it is to access and change the Java AST; my experience is based on developing an editor plugin for an exotic file format rather than Java code.
Well, the four first points are easy to achieve, even by monkey coders that look at the eclipse PDE documentation shipped with Eclipse. These can be achieve in 1 day of work, maybe 2.
The hardest point is really the fifth one and the kind of modification you expect to do. Acting directly on the editor content is simple, accessing the editor internal AST and modifying it is really a bigger challenge and I doubt that it could be achieve in less than a week by unexperimented people (it can take longer, depending of what kind of modification you want to apply).