I would like to write "private" comments in Eclipse while working on Java projects. In other words, I would like to write comments associated with areas in the Java classes that only I can see but other developers working on the project cannot. The comments therefore cannot be regular comments in the source code. Ideally I would select an area on a Java source file and have a view in the perspective allowing me to write and read my comments associated with the selected area. Those comments should be persisted in a file(s) outside of the Java source files of the project.
I understand that as other developers modify the Java code my comments might become stale and I will have to eventually have to work to alleviate this problem. I am not worried about the persistence right now, either.
How do I handle the Eclipse part of the challenge, i.e. create my own view in/to which I can write/read comments and have it associated with locations in the source files? Or, can I display comments lines in the source files that are not saved along with the source so that they are "private"?
This sounds like what you can already do with the Bookmarks View, aside from the text presentation in the view itself being rather limited.
Related
I have a cup of source files in a certain folder structure in my file system. I want to use this structure for a project in the IAR Workbench. Thinking of Eclipse, that could be so easy! But in the IAR Workbench, the folders will become to "Groups", which are only kind of virtual folders. The Workbench doesn't care about folders.
Is there some easy and fast way to import them?
Up to now I have to add the groups manually each and then add the files to the groups, and that's really annoying!
Is there maybe a tool to generate a proper project file (*.ewp) out of a file/folder structure path?
This would help me a lot!
You should have a look at IAR Project/Add Project Connection command.
Although IAR doesn't seem to have any public documentation on the xml syntax, or at least I couldn't find any, you can find Infineon DAVE (Config.xml) and Freescale PE (ProjectInfo.xml) files if you search around. These can be used as examples to figure out the syntax on how to write your own xml files in one of these interfaces, to allow you to specify where all your c, h, assembly and library files are from where ever they may be in your file system. They also allow you to define preprocessor includes for compiler/assembler, and DAVE allows you to define a path variable, which is also very useful.
See: https://mcuoneclipse.com/2013/11/01/iar-arm-v6-7-comes-with-improved-processor-expert-support/
I have modified a DAVE Config.xml file and found it EXTREMELY useful for managing and migrating even just a handful of project files. For example to upgrade to a new release with all files having a new directory root, you just change a single line in the xml file (defining the new root), and all source files, compiler includes etc are all updated to the new level. No more manually editing the preprocessor includes or replacing all the files in the project. And no more fiddling around with ../../ file system hierarchy navigation stuff, you just specify directly (or indirectly via a path to) where the files are, no more relative from where your project happens to be. VERY NICE.
IAR should consider opening this up (documenting) for general users, as it is very useful for project management and migration. While at it they should also consider generalizing the xml syntax a little bit and allow for definition of IAR group heading names, specifying linker file name, and definitely allowing multiple xml files to be included (connected) (so that subprojects can be easily added or removed without effecting the other subproject definition files) and a few basic things like that.
If they where to do a bang up job on this, they might consider allowing most/all aspects of IAR project configuration that might be required by the subproject, to be defined in these xml files, and then entire (sub)projects could just be plopped down anywhere and be up an running extremely quickly (OK, just let me dream a bit :)
For anyone who happens upon this you may want to check out https://github.com/IARSystems/project-migration-tools. They have a tool for pulling in file trees 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.
hey everyone, we just added a nightly action to process the entire source tree with doxygen and place the output onto development webserver.
We also already have a sharepoint structure which holds design documents for various modules/projects. Currently, the level at which we are keeping this documentation is relatively high. We discuss structures of modules and talk about the major classes, but never go down to the individual method level. I wanted to bridge that gap by having hyperlinks in the SDS word documents that would point to doxygen output.
I noticed the links look like this:
http://example.com/docs/ProjectName/d4/d98/class_c_reader.html
http://example.com/docs/ProjectName/d4/d16/class_c_stream.html
The part that sketches me out a bit is "d4", "d98" and "d16" strings in the path. If I copy these links and create the hyperlinks, does anyone know if these URLs are guaranteed be preserved in the future. As I said, entire doxygen output gets regenerated nightly.
You can disable the d4/d98 subdirectories by disabling CREATE_SUBDIRS in the doxygen configuration.
Whether the name of the HTML files will stay the same I do not know for sure but from what I have seen when using doxygen it seems so. If you want to know for sure you can always look at the doxygen source.
Probably these links will not stay permanent.
Furthermore, Doxygen has a XML representation of the generated documentation but even this interface resp. the corresponding DSD has been changed with new releases of doxygen. This is quite frustrating, as we had used the XML representation for a similar application with the assumption that the structures would be kept identical with every new release.
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
When a text conflict occurs in Bazaar (and many other dvcs) a .BASE, .THIS and .OTHER file is produced. Its then up to the user to make use of an 3 way merge tool to merge the conflict and then mark it as resolved.
I would like to get hold of all the registered merge viewers in eclipse and give the user an option to merge the conflict with any one of these. (with the TextMergeViewer being an default option). I suspect that I would need to some how programmatically provide the 3 files to these mergeviewers and maybe write some custom code to wrap the BASE, THIS and OTHER files to tell the merge viewer where the differences are. (interpret the "herringbone" markers like <<<<<<<. etc)
Not exactly an answer, but at least some starting points:
You could try looking into the code of the current Compare Viewer using the Plug-in Spy (directly available with eclipse3.5)
(source: eclipse.org)
(ALT+SHIFT+F1)
Most of the eclipse sources are also available here.
The org.eclipse.compare.CompareUI is a start, for example.
Once you have a basic understanding of how the Compare mechanism works as a plugin, you can write an fragment (also illustrated here) to extend the current compare plugin.