I have a big Java project with thousands of compilation warnings. I would like to find a way to prevent developers commiting files with warnings, so gradually all warnings would disappear. If I commit a file with compilation error Eclipse displays an error message, but I couldnt find any way to do the same with warnings. The closest thing I found was The Commit warning checker http://commitwarncheck.sourceforge.net/ but that is not really integrated into the commit process, it just provides a view. Is there any better solution?
I see 2 options. First, at least with Subclipse, there's an Eclipse preference for this: Window / Preferences / Team / SVN / "Commit resources with warnings". There's one for "errors" as well. Both can be set to "Yes", "No", or "Prompt". However, this will require you to make sure that your entire team keeps these options set as you'd expect - as well as making sure that they have all of the other Eclipse preferences set to generate the same errors / warnings.
Using Subclipse 1.6.18:
Another option is to make use of SVN commit hooks, essentially the beginnings of a Continuous Integration (CI) process. You could actually check for a limited set of things, and allow/deny the commit at that time, but I'd start worrying about commit performance. A better option might be a true CI process that runs a build (either scheduled, or potentially even per-commit) - and emails or otherwise alerts the developer if an issue is detected.
The complication with this later option is repeating the Eclipse build - including detection of all Eclipse-configured errors and warnings - in a scripted manner. (If anyone finds a great way of doing this, please let me know! Eclipse provides a scriptable option for using its code formatter, but I've not seen a similar option for checking for errors / warnings using the checks provided by Eclipse.)
Otherwise, you'll probably be better off starting to migrate over to tools such as Checkstyle and FindBugs that work equally well both inside and outside of Eclipse. (However, relating back to my own interest above, I've not found any combination of a few tools - including these - that can at least match the same checks that Eclipse provides.) Combine this with Maven / m2e, providing a common build configuration / process that can be shared by both Eclipse and your CI system, and you should be in good shape.
Related
When triggering Maven lifecycle entries in IntelliJ IDEA (clean+install for example), the IDE launches the associated Java with plexus-classworlds-<version>.jar from the associated Maven installation.
Sometimes (mostly) the Java launch takes up to 2 minutes before the Maven action starts.
Any thoughts what could cause this? I'd like to use this integrated feature instead of Maven command line calls (which work "normal" regarding no delay).
Network related Java problems might be, I'm inside Intranet, Firewall, custom proxy.
There is no status or logmessage regarding the Java launch except for the time indicator in the run window.
Problem - well - "solved" by adding java as an exlusion for the av scanner (avira).
I am generating the Javadoc of my project using maven (with the javadoc:javadoc goal).
I have also configured the Javadoc Location property of my project to the folder where maven generates the Javadoc. Then I can easily see the full Javadoc of a class from the Eclipse Javadoc view by selecting "Open Attached Javadoc in a Browser".
However, every time I do some changes in the documentation I need to explicitly recreate the documentation with maven, before I can see the documentation updates in the browser.
Is there a way I can instruct Eclipse to automatically generate the Javadoc files when a file is saved ?
I know this is probably not a good idea when not focused on writing documentation, since it may slow down a bit Eclipse. However, when my main task is writing documentation, a bit of automation in this sense will be appreciated. I guess the right solution passes by updating the documentation of only the files that were saved (and not triggering the whole Javadoc generation process), but I do not know if such a thing is possible.
If you're using the Maven Integration for Eclipse (m2e), you can set up a plugin execution filter so that m2e knows that you desire a particular plugin execution to be also executed in Eclipse. You would want to have the plugin run in the background:
<execute >
<runOnIncremental>true</runOnIncremental>
</execute >
The flip side of this all is that it will run your entire Javadoc execution whenever you save something, incremental is misleading in that sense. It may clog up your Eclipse, and not just "a bit", like you say in the updated question. Every plugin execution that does more than the absolute trivial should be heavily scrutinized.
A truly incremental solution will not come from Maven, since it has no sense of only parts of the project having to be built. Rather, you would need Eclipse to do this directly. I think the same thing happens for Java compilation: it is done by Eclipse itself, incrementally. However, according to the Javadoc FAQ:
A9. Can I incrementally build a document from different runs of Javadoc?
Basically no (...)
We call this incremental build and are considering it for a future release.
But nothing is impossible :)
In my case there are two reason for doing that:
Sometimes people by mistake import classes which present in macbooks JDKs but absent in Linux. That causes build to fail on ci servers which are Linux based boxes. I doesn’t happen frequently, but when it does happened I'm thinking that there should be some smarter way to find out that earlier.
Unused imports trigger warning in IDE/code analysis. From time to time somebody need to spend time on cleaning up this stuff. Even if its just single right click in IDE you still need to commit your changes and make sure everything alright on build.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail locally if there are any.
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
UPDATE:
I followed yegor256 suggestion and incorporated Checkstyle task with initially small subset of Sun Code Conventions (unused imports is one of them) and made it break a build if violations found.
After one week of trial we've got zero unused imports in our codebase and surprisingly zero complaints about this rule (by the way, Checkstyle is really fast: analyzing ~100KLoc taking less than one second).
As for using IDE for such analysis: yes, it good choice, but having this kind of checks run as part of automated build is better.
What you're trying to do is called static code analysis. Checkstyle can help you. If you're using Maven, this plugin will do the automation for you: http://maven.apache.org/plugins/maven-checkstyle-plugin/
You can also take a look at qulice.com (I'm one of its developers), which integrates a few static analysis tools and pre-configures them (incl. Checkstyle, PMD, FindBugs).
If you are using eclipse IDE or IntelliJ IDEA, you can configure them to
1a. organize imports / remove unused imports on save or before commit (see cleanup preferences)
1b. switch the "unused imports" warning to an error (see error settings)
2a. configure a jre which does not include com.* stuff
2b. configure the warning of proprietary api usage from the jre to be an error
You might still want to check that on the build server, though. In this case the more complicated stuff like configuring CheckStyle would still be necessary.
I'm curious if there is any way to find unused imports programmatically (lets say from unit test) and fail build locally if there are any.
I use IntelliJ to organise imports, this removes all the unused imports. You can do this with one hot key from the top of you code base to correct all the imports. (It also has over 700 other types of static checks and fixes)
Maybe failing a build because of unused import sounds harsh, but if it saves time for team overall it makes sens to do so (would love to hear opinion on that as well).
I have IntelliJ check in code which formatted and with imports organised so the issue never arises in the first place. ;)
In Computer Science the name given to such a process of analyzing the code without executing is known as static code analysis.
Try using an IDE, I am using Eclipse, which marks all the Unused imports and Unused Variables or methods in with a Yellow color underline....
Aren't these unrelated questions? If you import classes only present in the local JDK, these imports are used (just unsatisfied). For either problem, I recommend solving it in the IDE so the problem will be detected when code is written, rather than prior to checkin (the earlier the detection, the easier the fix ...).
In eclipse, you could prevent unsatisfied imports with access rules, and automatically fix imports whenever a source file is saved by enabling the appropriate save action. If you check these settings into version control, you can easily share them with the team.
I see lot of comments in same way that use this IDE or that IDE. But all my friends try to understand the difference. Doing something programmatically is different and using IDE is different.
If I want a process to be programmatic then suggestion of IDE is not useful. It might be possible some one is asking this question because he is building complete process and this step is part of it. How opening IDE would help him on different machines and OS where CI is working?
I too building one tool on similar lines. I achieved it up to some level but it programmatically open IDE and close it automatically and fixes source code too. But opening same in Linux might be a question for me.
Understanding some one's view before answering is really very important.
Since recently it's much slower running a program in Debug mode in Eclipse Galileo.
I'm not aware of any changes.
Do you know what could be the cause? Running it normally is not a problem.
Another "debugging break" is the use of method entry/exit breakpoints.
Did you try to remove all breakpoint definitions once?
Sometimes i think Eclipse is getting out of synch with some of its internal/displayed state. Perhaps you should try to setup a new (not copy) of your workspace. This sometimes helps me to recover from spurious features.
This is how you can remove all breakPoints
Eclipse -> Run -> Remove All Breakpoints - for removing all Breakpoints for all Time
Eclipse -> Run -> Skip All Breakpoints - for temporary remove breakpoints
I faced this issue lot of time. Solution is simple, Remove all breakpoints.
(Run >> Remove All Breakpoints)
I was just running a program in Eclipse debug mode that was almost instant without debugging but when I ran it in debug mode, it was really slow. I went through and deleted a ton of random useless breakpoints I wasn't using and then the program sped up A LOT (200x or so).
Disable 'Show method result after a step operation'.
I have found that i often forget that i have a bunch of expressions added to the expressions panel that are no longer needed that are none the less being evaluated (or are failing to evaluate) and this slows stuff down a good deal. Make sure that you keep those expressions cleared out when not needed.
Close eclipse... clear %temp% folder, temp folder... disable breakpoints... in most cases this will definitely solve the problem.
What kind of JVM are you attaching to? I found in my experience, that in debug mode IBM JDK is slow like hell.
For all JVMs, check if you have conditional breakpoints with expensive condition. Try disable breakpoints. You may have exception breakpoints or expressions. Try disable or remove them.
In my case, Eclipse was trying to build files, which I was doing manually.
Going to Window -> Preferences -> Run/Debug -> Launching, and then disabling "Build (if required) before Launching" underneath General Options solved the slowness.
Clearing temp files on Windows fixed it for me
"C:\\Documents and Settings\\{user}\\Local Settings\\Temp"
Normally Java Virtual Machine turns off Just in time compiler (JIT) when running in debug mode. On IBM WebSphere, the IBM JDK is heavy de-optimized and will be very slow.
By the way debugging also make impossible to recompile and optimize the code.
Relay on logging for complex debugging: it will save your days on production, where you cannot debug for sure.
With all the learning over the years working with eclipse, here are couple of suggestions
keep your open projects to minimal what you actually need
keep it lean and thin - uninstall the plugins/features which you don't use (mylnn, validations etc).
No matter what you do, the eclipse tend to get slower over the time. The ultimate solution to get a responsive IDE is to recycle your existing workspace (create new workspace and bring in the projects which you need).
Before you run your application in debug mode press on (disable all breakpoints) and you wont experience slow loading or any problems. After your application has started just enable the breakpoints and then you can debug your code.
I faced this issue recently after upgrading my macOS version.
I wasn't able to fix the slow debugger with all the above solutions, I ended up installing a newer version of eclipse, and everything works prefect after that.
It happened to me once and the problem was, I had the folder with ALL my projects source code in the Source Look-up. This way, not only the debugger got really slow (because it probably crawled all my files) but also I could not do a lot of things such as inline execution.
The takeaway: check your Source Look-up. When debugging right-click in any thread from the Debug view, choose Edit Source Look-up and see what what you can/should remove from there. In my case, it was a spurious folder, other times you may have too many projects, folders, JARs etc. and may remove some.
Recently i was having extreme slow performance debug, both in eclipse and visual studio code (vs code)
In my case, the problem was with lombok configuration in JPA entities.
I changed the #Data anottation to #Getters and #Setters.
Looks like hashCode() and equals() implementantion of lombok was in conflict with JPA.
I've had the same problem. The work around i'm using is to just set a single break point and run to it. After that I don't try to step over or continue i just restart the test and move my break point to the next line I want to view. I am using JUnit with Mockito in Intellij. I'm guessing it has something to do with the byte code manipulation not matching the actual code in intellij. (In intellij, there is an implementation internal to intellij for running JUnit tests. Mockito may not play will with it)
suppose i have a project with lots of todos, some unintentionally left there, some no longer relevant, some represent future possible features etc.
i know that most IDEs can show/filter/sort them, but im looking for a way to enforce a more strict policy.
what im looking for is some maven plugin that i can bind to the test phase that looks for TODOs of a specific format (for example //TODO-Ver ...) and, if any are found, generates a test failure (which would then be visible via hudson, emails will be sent, alarms would go off, heads will roll etc).
this extra execution would be bound to the test phase under some profile that will only be activated close to the dev cycle end or something.
my question is has anyone done anything like this before ?
what code inspection tools can be tailored to look for TODOs by regexp, and what maven plugin can be used to run said inspection tools ? is it possible to do from a unit test ?
any comments/ideas/suggestions would be welcome.
Checkstyle can do that (see the TodoComment check) and you could use the maven checkstyle plugin and its checkstyle:check goal to check the code and fail the build in case of violation (usually during the verify phase).
The checkstyle plugin has already been pointed out, so I'll introduce the Taglist Maven plugin that looks for TODO, FIXME tags in the source code and can produce a report of the usages of all such tags. Of course, it is customizable, so you can put in your own tags to search for; regexes also seem to be supported.