I want to start findBugs on existing project (on command line there are currently 522 bugs).
How can I set in the ant file (under findbugs target) the option to fail the build if there are more than 522 bugs found?
I want to actually fail the ant build and not to understanf it manually from the output report.
Thanks.
That may not be possible. You can use data mining task and do some special handling. http://findbugs.sourceforge.net/manual/datamining.html
This may go a bit too far, but I'm adding it as an answer none the less.
You can use sonar for that. Sonar is a free platform to measure and track code quality. It has findbugs metrics included.
It has the Build Breaker Plugin, which will break your build on certain conditions.
You need to write a custom ant task, deriving from Ant's Task base class, which adds a log listener that sets a property and removes itself afterwards. The custom task will fetch the current Project and add the log listener via addLogListener(...).
The log listener needs to identify when findBugs is logging, discern which log message is the one that lists the number of bugs, parse that line, set the property and remove itself from the set of log listeners.
Once you have that task, you need to also write a new condition, as Ant doesn't ship with a numeric comparison condition. Then you can use your custom condition in the fail task, like any other condition.
<findBugCountListener prefix="findbugs.count"/>
<findBugs ...>
</findBugs>
<fail>
<condition property="allupper">
<and>
<isset property="findbugs.count"/>
<greaterThan value="${findbugs.count}" limit="522"/>
</and>
</condition>
</fail>
Ideally your listener will then set an Ant property, with the number of bugs. You can then use AntContrib's Assert task to throw a build exception if the number of bugs is too high.
Yes, it is more manual work than simply configuring a few tags, but at least it is possible with Ant due to it's ability to load custom extensions. It isn't like Ant was written with explicit knowledge of the findBugs plugin (which naturally had to be written afterwards).
Another alternative is to find the source code of the findBugs ANT plugin, and assuming it has a license that allows legal modification, modify the ANT plugin to have a new "additional" property, setCount="propName" and then capture and set the property within the existing findBugs ANT plugin.
Quite an old question, but maybe this is useful for someone else: There is a rather simple way to achieve the desired behavior by setting the warningsProperty attribute of the findbugs task and afterwards letting fail check for the property's value:
<findbugs ... warningsProperty="findbugs.warnings">
...
</findbugs>
<fail>
<condition><istrue value="${findbugs.warnings}"/></condition>
</fail>
(Needless to say that findbugs is abandoned now, but there is spotbugs as a successor.)
Related
When I build my Xamarin project the version of the jarsigner tool it uses is ALWAYS from \Java\jdk1.6.0_39\bin\
I was wondering if we could change to different version of JDK.
Looking at the build output it seems to boil down to whatecer MSBuild../Xamerin/Android.Build.Tasks.dll tells it.... (see below)
Is there a way to get the build to point to another path...a later version of the JDK?whatever
11>Using "AndroidSignPackage" task from assembly "C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Build.Tasks.dll".
11>Task "AndroidSignPackage"
11> C:\Program Files (x86)\Java\jdk1.6.0_39\\bin\jarsigner.exe
Looking at the Xamarin's Custom MSBuild Task Library (C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Build.Tasks.dll) AndroidSignPackage extends AndroidToolTask which extends the built in ToolTask class. It also looks like they properly implemented it as well so you should be able to simply pass the additional optional parameter ToolPath.
If you're calling the task directly from MSBuild as part of a custom build process the command might looks like this:
<AndroidSignPackage
UnsignedApk="pathtounsignedapk"
SignedApkDirectory="signedapkoutputdir"
Keystore="yourkeystorelocation"
KeyAlias="thekeyaliasusedtosign"
StorePass="thepasswordforthekeystore"
ToolPath="NEWPATHTOJAVASDK" />
If you're trying to do this integrated within the Visual Studio Environment you'll need to start groveling around in their *.Targets file and chase it down, if you're not comfortable with MSBuild I do not recommend doing so.
BEYOND THIS POINT NO WARRANTY GROVELING IN UNDOCUMENTED LAND COULD AND WILL BREAK AT THE LEAST OPPORTUNE TIME AS PER MURPHY
In my version of the Xamarin Toolchain in Xamarin.Android.Common.targets (C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets) we see that the AndroidSignPackage is called from within the _Sign target, it appears that, at least in this version, are passing the ToolPath attribute, which in this version is defined as $(JarsignerToolPath), looking further up in the .targets file we see that this is defined as follows:
<CreateProperty Value="$(_JavaSdkDirectory)\bin">
<Output TaskParameter="Value" PropertyName="JarsignerToolPath"
Condition="'$(JarsignerToolPath)' == ''"
/>
</CreateProperty>
It looks like they were really nice (at least in this version) at validate that $(JarsignerToolPath) is not defined prior to setting this value, if it is this task will not do anything and take the existing value.
At this point in time you have a couple of options, what it boils down to is they'll respect the MSBuild Property $(JarsignerToolPath) however it comes in before this build process. If you read the documentation on MSBuild you'll see that you can define that property in a couple of ways.
The most popular (and my recommendation) is to declare it straight up in your MSBuild Script (remember that CSPROJ files are just MSBuild Scripts) in one of the property groups (I'd recommend under a build configuration) you can simply define this property explicitly for example:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|JDK17' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
... (Additional properties trimmed) ...
<JarsignerToolPath>C:\Program Files (x86)\Java\jdk1.7.0_71\bin</JarsignerToolPath>
</PropertyGroup>
Alternatively you can set an Environment variable prior to launching Visual Studio/MSBuild process performing the build that sets the JarsignerToolPath to the correct property.
Obviously you can use the above knowledge to take it even further and look to research if you could replace $(_JavaSdkDirectory)...
I was running into a curious problem today and would like to get some more info on that, as my google-fu proved to be insufficient for that.
What happened
The scenario is as follows: I have a straightforward Netbeans project, which contains a .java file that makes use of some annotations, which are handled by the Netbeans annotation processor (org.openide.filesystems.annotations.LayerGeneratingProcessor to be precise) to create a .xml file during compilation.
All of this worked fine up until today, when I accidentally forgot to add the dependency for the annotation processor to my new project (i.e. core/org-openide-filesystems.jar). Without that dependency being present I witnessed the strangest behavior: a build (via Netbeans as well as directly via ant on the commandline) would report to be successful, yet no .class files were generated at all.
What really threw me off was that the build call come back with a success. Not a single warning or other indicator that something was amiss.. just no classes generated and a tiny little .jar file that only contained the Bundle.properties files, but again no .class files.
The workaround
So much for the scenario itself. After a while I eventually came to find out about a javac option that would lead the compiler to finally tell me that something went wrong: -XDdev. I have never seen this option before and from my googling all I could find was that these kind of options are referred to as Hidden Options. But I haven't found a good listing of what hidden options are available and what they're good for. Any reference on that would be much appreciated.
Anyways, adding this option to the compile, the actual javac call would spit out a large stacktrace that eventually boils down to a ClassNotFoundException for the LayerGeneratorProcessor class. Lo and behold, once I added the dependency for that class to the project everything builds fine again.
The remaining problem
What is funny (as in scary) is that even despite this exception being printed to stderr and indicating that annotation processing failed, the overall javac call succeeds! It still comes back with build successful and acts as if everything was fine. Without the -XDdev option, one would not even have any indication at all from the output that something went wrong.
Finally, my actual question: is there some way to turn this behavior into a proper error? While -XDdev is fine to find out the problem, it requires you to look at the build output, which especially in a CI context will not be feasible. I would like to protect others and myself from accidentally forgetting the dependency in the future by somehow switching this behavior to a proper build error such that we are also notified by the CI system in those cases.
I'm trying to learn some ant for a Struts 1.x project that I was thrown onto. Mainly I'm trying to find a good referent for the inherent variables/properties of ant...beginners tutorial. Any GOOD reference really.
A couple lines of the ant file that I've been trying to figure out just for example...
<available file=${deploy.ant.docbase.dir}/WEB-INF/sun-web.xml" property="sun.web.present"/>
and
<replace file="${temp.sun.web}">
<replacetoken><![CDATA[<!DOCTYPE]]></replacetoken>
<replacevalue<![CDATA[<!-- <!DOCTYPE]]></replacevalue> //in ant is <!-- the comment out flag?
</replace>
I did do some searching and only could find ant build examples without explanation, but if it is covered and I just didn't find it a link will suffice. No reason to make someone reexplain it....I just couldn't find it.
Your first code block refers to the "available" ant task. It sets the property sun.web.present if the given file exists.
In your second code block, "<!--" starts an XML comment ("-->" closes one). This is true for all XML, not just ant build.xml files. In this case it is using the "replace" ant task to replace "<!DOCTYPE" with "<!-- <!DOCTYPE" within the file named by temp.sun.web.
In general an ant build file has targets like "build" or "clean". These depend on each other so that "test" runs "build" first. The targets are implemented by "tasks", where each XML tag refers to a task. You can read their manual and refer to the per-task docs for how each task works.
The Ant Manual is your friend. There's a link Ant tasks on the left side of the page. Click on that link, and then the List of Tasks link. That will list all of the Ant tasks on the left and their explanation on the right. There, you'll see the available task and the replace task.
Unfortunately, the Ant manual uses Frames (bad Ant Manual! Bad Ant Manual!), so I can't supply a link that will list both the
(Shameless bid for reputation)
The example doesn't use a built-in property. Most Ant targets won't, because after properties are first set they are immutable. Instead, Ant scripts usually define their own properties. The Ant manual lists the properties that Ant predefines.
If you want to get into the guts of Ant, I recommend the Manning "Ant in Action" book.
I have the following problem. I have something like 300 Eclipse Plugins. Now, as part of an ant script I want to read all MANIFEST.MF files and then look for the execution environment string.
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Now, this string has several possible values. I want to create a report that lists the execution environment for each plug-in. That part is not really a problem as I can use some kind of regexp to obtain it.
My problem is that I want also to create some kind of summary for tracking changes at a glance, something like:
JS2E-1.4: 50 Plugins
JS2E-1.5: 150 Plugins
JS2E-1.6: 74 Plugins
Anyone has some suggestions on how could I go around this?
EDIT: Reason for using ANT is that I want to integrate it with a nightly build script
I would definitively go for hard-coded Ant task and decompose the problem in two tasks:
the first task takes a jar file and outputs a plugin-info.xml file that contains various infos, like the environment
the second task parses all these xml files and creates an XML summary report
This will of course generate (n+1) XML files for n plugins and some will find this way too much.
The nice end effect with that approach is that you can generate either detail or aggregated reports very easily (with some XSLT magic.) or even graphs.
If i were to do it myself, i probably would just write a perl script.
If it has to be done from Ant, i would write an Ant Task to do it.
I would suggest just printing each executable environment on System.out and then post process with "|sort| uniq -c".
You can use the math task from the ant-contrib project
I had to do it, I'd probably go for some shell script or custom code
I would like to append the output JAR filename of a Netbeans project with some version number: something like 1.0, 2.0b or even a Subversion revision number. I can't seem to find anything on this, though. I am also not sure if this would the responsibility of the build system (Ant) or if the IDE (Netbeans) can delegate the process. Is there a centralised, clean way of doing this?
IMO, this is the responsibility of the build system, not of the IDE. Let me say it in other way: don't rely on your IDE to build your project, use a build tool. Using an IDE is fine during development but being IDE dependent to build a project is not a good thing (what if you change your IDE tomorrow, what if you want to build your project on another machine/OS without that IDE, what if you want to build your project on a headless machine, what if you want to automate your build, what if someone wants to build that project and doesn't have that IDE, etc, etc). Really, this is what build systems are for.
Now, regarding your initial request, there are plenty ways to add a version number. One of them is to use the Ant's BuildNumber task:
This is a basic task that can be used to track build numbers.
It will first attempt to read a build number from a file (by default, build.number in the current directory), then set the property build.number to the value that was read in (or to 0, if no such value). It will then increment the number by one and write it back out to the file. (See the PropertyFile task if you need finer control over things such as the property name or the number format.)
Use it for example like this:
<target name="jar" depends="compile">
<property name="version.num" value="1.00"/>
<buildnumber file="build.num"/>
<jar destfile="foo-${version.num}-b${build.number}.jar"
basedir="."
includes="**/*.class"
/>
</target>
Or you could indeed add subversion revision number. An easy way to do this seems to install the SVNAnt task and use the status task:
<target name="revisionnumber">
<!-- get the svn revision number -->
<svn>
<status path="application.cfm" revisionProperty="svn.revision" />
</svn>
<echo>Sandbox Revision: ${svn.revision}</echo>
</target>
Finally, another option would be to use Maven instead of Ant which has a built-in version management feature as pointed out by cetnar.
I'm not sure if it's the best way, but we put it in MANIFEST.MF file like this:
Implementation-Version: 2.0b
We can get this value programmatically like this:
String version_num = this.getClass().getPackage().getImplementationVersion();
If you feel like using a tool to handle your builds then there are lots about, such as CruiseControl, which is ANT based and has pretty deep integration with your source code control.
I use it to automatically increment a build number and use that as the last digit in my version number for the jar, e.g. 1.4.168, where 168 is the build number. I am just about to get it to put a label into CVS just before the fetch with the build number so I know exactly what code is in the jar.
Well is done default by Maven. Even if you want name your jar file with more detailed information you can use build number plugin.
EDIT
At begining I misunderstood your question so following part relates to adding this information inside jar files.
You can do it yourself by creating manifest file. In Maven it you can tune proces of creating manifest file by additional configuration. I suppouse (I'm sure) that in Ant should be similar functionality.
you can use maven for vesion and read it from pom.
read this article:
Embedding the maven version number
at
http://happygiraffe.net/blog/2008/10/01/embedding-the-maven-version-number/