I'm using Hudson continuous integration tool. I also run the checkstyle plugin as part of the build, and publish the checkstyle analysis result in Hudson. How could I make the build fail if I encounter a checkstyle error/warning?
I tried to add a rule to the Parsing Rules File, but this doesn't seem to work.
Thank you in advance.
It could be solved with Checkstyle plugin for Hudson/Jenkins. You can read about it here.
gradle-estilo-plugin provides the ability to fail the build if checkstyle task encountered errors. It also lets you specify rules in your build.gradle file instead of having separate files like checkstyle.xml, suppressions.xml, impor-control.xml etc.
You can instruct the estilo plugin to fail the build as:
estilo {
ignoreWarnings false
}
On a side note, I must point out that I wrote this plugin myself and I use it extensively in all of my projects.
Related
In our project we use checkstyle as static analyzer (as maven plugin, I mean maven-checkstyle-plugin). I am new to this tool, and there is one thing I want to find out - what is the difference between failOnError and failOnViolation?
I think the plugin documentation is pretty clear, but the minimum expectation is going to be:
Do you want a log of the errors before failing the build? Then use failOnViolation
Or
Do you want to fail the build immediately, without waiting for errors to be logged? Then use failsOnError
Of course, if you set logViolationsToConsole to false (or on the CLI as -Dcheckstyle.console=false), then both act almost identically and can cause some confusion.
I've been using c3p0 with hibernate for a couple of years. When looking at exception stack traces, I see classes such as com.mchange.v2.c3p0.impl.NewProxyPreparedStatement in the stack. I went looking for the source code for these classes and came across the curous com.mchange.v2.c3p0.codegen package.
In particular, it looks like JdbcProxyGenerator is metaprogramming in Java. I'm having a hard time understanding the codegen mechanism and why it is used. The built jar contains these generated classes, so I'm assuming these classes are built during the build, perhaps as part of a two-phase build. The codegen package does not appear to be in the generated jar.
Any insight would be appreciated, just for my own curiosity. Thanks!
yes, you are absolutely right.
c3p0 uses code generation to generate non reflective proxy implementations of large JDBC interfaces, "java bean" classes with lots of properties, and some classes containing debug and logging flags (to set up conditional compilation within the build).
You can always see the generated classes by typing ant codegen in the source distribution, and then looking at the build/codebase directory. The latest binary distribution of c3p0 (0.9.2-pre2) includes the generated sources in a src.jar file, which you can also find as a maven artifact at http://repo1.maven.org/maven2/com/mchange/c3p0/0.9.2-pre2-RELEASE/c3p0-0.9.2-pre2-RELEASE-sources.jar
I hope this helps!
I would like to write a junit test for my Checkstyle extension. Can someone show me how to do it? I know there is a project in github called JUnit-Checkstyle-Test-Wrapper. However, I don't see how using this tool would help me get to my extension and verify its values.
thanks.
Probably the best reference for how to test your checkstyle extension (I assume you've added a checker) is to look at the checkstyle source code, and just copy & change one of the existing tests. For example, here is the test for HeaderCheck. This is probably the best way to start. Remember you can actually extend the Checkstyle test classes.
take a look at a lot of examples for custom Checkstyle checks and UTs for them https://github.com/sevntu-checkstyle/sevntu.checkstyle/tree/master/sevntu-checks
We work with a lot of legacy code and we think about introducing some metrics for new code. Is it possible to let Findbugs and Checkstyle run on changed files only instead of a complete project?
It would be nice to assure that only file with a minimum of quality is checked in, but the code base itself is not (yet) touched and evaluated not to confuse people by thousands of issues.
In theory, it would be possible. You would use a shell script to parse the SVN (or whatever SCM) change logs after a given start date, identify the .java files from these change sets and build two patterns from these:
The Findbugs Maven Plugin expects a comma-separated list of class (or
package) names for the parameter onlyAnalyze, so you'll have
to translate file names to fully qualified class names (this will get
tricky when you're dealing with inner classes)
The Maven Checkstyle Plugin is even worse, it expects a
configuration file for its packageNamesLocation parameter.
Unfortunately, only packages are allowed, not individual files. So
you'll have to translate file names to packages.
In the above examples I assume that you are using maven. I am pretty sure that similar things can be done with ant, but I wouldn't know.
I myself would probably use a Groovy script instead of a shell script to achieve the above results.
Findbugs has ant tasks that can do diffs against different findbugs results to see just the deltas, so only reporting new bugs, see
http://findbugs.sourceforge.net/manual/datamining.html
I'm looking for some way to replace patterns in files with values, during build time.
E.g. a configuration file may look the same except that different machines requires different hostnames in some setting. In that case i want to have a template file, where hostname is replaced with ##hostname##
Then when building, I want to create separate versions of the file with the patter replaced with the correct value for each environment.
In ant you could use "replace", is there something similar in maven2? I know that I can run ant form maven, but if theres a maven plugin doing it, I'd prefer that one.
I found http://code.google.com/p/maven-replacer-plugin/
but it's very new...
Suggestions?
Thanks!
The resource plugin is what does filtering in Maven. IIRC it supports the ant syntax as well as the ${foo} maven syntax.
keep up with the maven-replacer-plugin, the project is still alive and well
Maven's resource filtering might help you out.
Why don't you use the Maven-ant plug-in?