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.
Related
In some cases I need to mark (several) lines of code in Eclipse. For example when reviewing, or when testing. Is there a feature or plug-in in Eclipse which can help me to that?
For now I'm just putting #REVIEWED or #TOBEREVIEWED on lines or around blocks. But that is a lot of work.
Any ideas?
EDIT: I'm aware of the Bookmark feature, but that seems to cover only 1 line.
EDIT2: I'm also aware of Task tags like TODO and FIXME, thanks E-Riz
You can use custom task tags in comments (the default is //TODO), which are automatically added to the Markers or Problems views in Eclipse. for example, you could create a custom task tag like //TO-REVIEW.
It's not exactly marking blocks of code, since it's essentially a marker for one line, but it is a convenient way to track and locate them. See the Eclipse Help page for more details.
Why not use some code review features of external server like GitHub?
I mean it could be nice to comment and discuss code blocks just within Eclipse,
but it is much overhead to develop and maintain comparing to web-based solution (that would be universal).
Then possibly such server has similar feature support as Eclipse plugin.
For example
if you use git, you can check GitHub and Eclipse EGit and Eclipse Mylyn tasks.
For perforce there is job concept (similar to issues).
So it leads to understanding that what you actually need is issue-tracker integrated into Eclipse that can conveniently point to code blocks. Again depends on your SCM.
You can us Eclipse plugin like Jupiter for code review. It will help to identify issues (if any) in code blocks with review comments without touching actual code.
The code review comments get stored in jupiter files in your respective project.
Developer can see those issues, fix and comment on them.
I have to do an enhancement to an eclipse application and create a diff-viewer which compares two files(.blx) format. But, the application as such doesn't have the org.eclipse.compare bundle in its target platform. Now, if I include the bundle, the option Compare With comes with any pair of selections.
So, Instead of using extension points, I included the source of org.eclipse.compare in my plugin. But, Now I don't know if I should also create the extension points and use the same.
I am unable to create the structure compare pane.
You are in for a fair amount of work (I'm working on a similar thing now). Start with the Compare documentation and read it carefully. Depending on how close what you are doing is to a text compare, you might be able to get away with simply subclassing things and using the extension points. However, if you have other requirements (non-textual) then it's likely that you will need to copy some of the code.
I don't recommend that you use the source of the plugin directly however. Just make sure you add it to your application as a dependency.
I am wondering whether or not to commit Javadoc files to my project's SVN repository.
I have read about SVN good practices, including several interesting questions on SO, but none has already been asked specifically on javadoc handling.
At first I was agreeing with the arguments that only source code should be versioned, and I thought that javadoc was really easy do re-build with Eclipse, or from a javadoc.xml ant file for example, but I also thought of these points :
Javadoc files are light, text-encoded, and changes to these files are easily trackable with diff tools.
It seems interesting to easily track changes to the javadoc, since in the case of a "public" javadoc, any change of it would probably mean a change in the API.
People willing to look at the javadoc do not necessarily want to get the whole project and compile it, so putting it in the repo seems as good an idea as another to allow for efficient sharing/tracking.
What are your thoughts about this? Please answer with constructive, non-subjective arguments. I am interested in understanding which case scenarios encourage the versioning of Javadoc, and which make it seem a bad choice.
One argument against would be merge conflicts, and as a former SVN user I hate merging with SVN. Even with Git this is just another step of work to do if those problems occur. And if your in a bigger team regular merges are daily work.
Another argument against would be, if a some people don't want the whole source tree, put the whole project under some CI system like Hudson and trigger the creation of the javadocs on a regular basis, like commits and publish them somewhere.
Conclusio for me is: don't version javadocs.
I recently added some javadoc output to a version control system (since github shows the contents of branch gh_pages as a website, this was the easiest way to put them on the web).
One problem here is that javadoc puts in every file the date/time of the javadoc run, so you always have changes to all your files from one commit to the next. So don't expect to be able to have a useful diff which shows you what documentation really changed between your versions, as long as you don't manage to somehow ignore these comment lines when diffing.
(Actually, due to another question I found out how to omit the timestamp.)
And of course, you should always be able to regenerate your javadoc from a checkout of the old sources. And for released libraries, publish the javadoc of the released version with it.
For third party-libraries which you are using inside your project as jar files (or anything that you don't compile yourself) it might be useful to store the javadoc corresponding to the version used inside the source tree (and thus be versioned, too), though. (When using Maven, you usually can download a javadoc jar together with the runnable jar of the library, so then it doesn't apply.)
Short answer: no, don't version your Javadocs.
The Javadocs are generated from your code, analogous to your .class files. If your API changes and you need to release a new version of the docs, you can always revert to that revision (or do a new check out) and generate the Javadocs from there.
My two cents...
I don't know how many times I've WISHED I had old versions of Javadocs available. For example, I may be using an old version of a third-party library, but the API docs for that library are based on the current code. All well and good if you're using the current code, but if you're on an older version, the javadocs could actually mislead you on how to use the class in question.
This is probably more of an issue with libraries you distribute than with your own internal code, but it is something I've run into now and again
Does anyone know of a built-in way to have Hudson keep track of how many files are changed, added or deleted in the source code repository in each build ? I'd like to plot the results in the same way that the JUnit test results graphs show the numbers of passing and failing tests for each build.
The Measurement Plots plugin and the Plot Plugin look like they might give me a starting point, but i'm wondering if there might be a more specific plugin or feature already available.
My SCM system is CVS, but I'd like a generic solution that would work with other SCM systems.
I don't believe there are any existing plugins that will do this directly.
If it doesn't need to be specifically tracked for each build (that is if you are really more interested in changes over time), then I would suggest setting up Sonar, which tracks daily changes from your builds and integrates fantastically with Hudson, or FishEye which connects directly to your SCM system.
But why not try to write the plugin for Hudson? Seems like the sort of thing that people might like to visualize as a per-build metric.
I think this question is more generic than specific to Hudson. You're probably going to have to write a little code by yourself. Unfortunately, I don't think any solution will be SCM agnostic because Hudson tends to use the SCM tools themselves to do the SCM bits.
I couldn't find any off-the-shelf solutions, so here's what I see would have to be done:
Find the SCM command that you are using (i.e., svn up, cvs -n).
Use wc -l or some other command to count the number of lines in output. This will give you an estimate to the number of changed/added/deleted files.
Parse the output if you want the names of individual files that have been added/changed/deleted.
Unfortunately, I don't think there's an SCM-agnostic way of doing this. Perhaps the best you could do is find a pure-Java CVS/SVN client implementation that you could modify to keep track of files as they come in from the SCM.
I've been looking into checkstyle recently as part of some research into standard coding conventions. Though it seems like it is perfectly suitable for brand new projects, it seems to have a huge barrier to adoption for already existing projects as it doesn't seem to supply a method of only checking new or edited code. Maybe I'm wrong?
If you have a codebase that has never had a coding standard it could be a massive effort to get the whole codebase inline with a standard all at once. Allowing it to be done incrementally over time as code naturally evolves seems like a more reasonable approach. But it doesn't seem like a possibility with checkstyle.
I assume this would have to be a tie in with a source control system in order to be possible. Is that possible with Checkstyle or is there another tool that can provide this functionality?
As far as I known, Checkstyle is meant to analyze source, without considering its history or revisions.
To add that kind of feature means script checkstyle analysis to feed it with the exact sub-set of files representing the delta.
But then, certain kind of checks would be likely to fail or to miss in their analysis, like duplicate code check.
So for that kind of incremental analysis, you not only need to restrict the set of sources, but also the set of rules you want to enforce, for some of those rules only make sense on the all sources.
So, why couldn't you run a full check on each file and then filter results based on changes managed by your source control system? Anything like that exist?
Not to my knowledge, especially with plugin like eclipse-cs for eclipse: it they analyze a file, they will display all warnings, even though the source control mentions the file has not changed since a given revision.
Only an external script would be able to do this:
The principle is simple (although it could be a bit slow at execution time):
for each file, do a diff to check if modification have been made
if yes,
do a svn blame to annotate lines with the revision number which contained the last change.
Then analyze the file with checkstyle.
The script can then filter the warning for the line being currently modified (or for all the lines modified after a given revision).
We developed a Checkstyle plugin for SCM-Manager, a tool for managing git, subversion and mercurial repositories. If activated it is possible to check committed source code against your Checkstyle rules. If the check found errors, the commit is aborted.