For compilation of my Java code, I would like to know if its possible to use one version of the JRE(rt.jar) and use javac belonging to another version of JDK. If yes, how do we include it in the build.xml in Ant? Thanks in advance!
Yes, you can. You use the executable attribute to specify the exact location of javac you want to use, so you can point to another JDK. And you need to set the fork attribute to yes.
<javac fork="yes" executable="...path.../jdk/bin/javac">
Related
I am making use of a library project which uses ant to build. My project however is using SCons because I need a far more complex build setup. Now I would like to use ant via SCons but NOT impose the problematic CLASSPATH issues and installation that ant requires.
So I am currently thinking of writing a build.xml parser, which turns the ant into SCons tasks.
Does anyone know whether this has been done before?
As far as I can tell there is no such parser in existence, which I partly believe is because there is great difference in how SCons and ant work. Especially when it comes to dependency resolution. It should be possible, but the translated file output will be very little SCons like, quite unreadable and probably quite difficult to maintain. Which pretty much defeats the whole reason to use SCons in the first place.
Since the library already uses ant, it would probably be a good idea to just incorporate the running of ant into SCons. If SCons can use ant, then you won't have to maintain the library build script (unless it is you that maintain the ant also)
Have you seen this: http://geosoft.no/development/android.html? We're also looking at converting an ANT based android build into our over-arching SCONS build and this looks like a good starting point.
I am using FindBugs to generate a report for my application by using Ant target. In the report, it is mixed with french and english. Does anybody know to generate a report only with english?
Thanks in advance!
Ikeforward
If you use the downloaded version of findbugs, you can just invoke it with
LANG="C" ./findbugs
Or however you start it, the LANG="C" has to be in the environment. This should work on most (all?) operating systems. There is some documentation about the i18n environment variables at the Open Group. An example how to do this with Ant is available here:
http://findbugs.sourceforge.net/manual/datamining.html#antexample
(asking Google for "ant findbugs language" had this at it's first result, I hope it works)
According to http://findbugs.sourceforge.net/manual/running.html
I think that you should use the following
-Duser.language=en
to have the whole thing in English.
Waldheinz's answer may work for you. The more general answer is that you probably need to change the locale that FindBugs is running in. The way to do this depends on how you're running it (command line, or from eclipse, or from ant...) and what operating system you're using. This page may provide you with the rest of the info you need - but probably not. If not, provide specifics.
I am using Apache Ant to generate Javadoc for my program which has many projects (or modules). However, I want to generate Javadoc for Interfaces only, and I do not know how to check if a file is a class or interface in Ant. Someone suggested me that I should use <fileset> and specify a list of files to exclude or include. However, there are hundreds of files in my program and specifying a list of class files to exclude is impossible.
Does anyone have some ideas, please?
I don't believe this is possible unless you write your own custom ant-task, (which wouldn't be that hard actually) and reference that in your Ant-script.
Another, (much uglier) way would be to generate the complete java-doc and remove non-interface files. These could for instance be identified by looking at the allclasses-frame.html:
ComponentView
<I>Composite</I>
where you have both the type (in the title=...) and file (href=...) available.
Have you considered writing your own doclet? Instead of trying to get ant to do the work, create a doclet that knows how to discard every non-interface. Then, using the javadoc task in ant is simple.
Hope that helps.
Some Ant targets require an URL to be defined as property (like the ivy pattern) and since the file:// protocol is different on Windows (either file:/ or file:///) and Unix (file://) it makes the entire script less portable.
Is there a nice way to handle the file protocol without messing around with properties and Ant conditions?
Using file:/// should work on both systems. But perhaps the PathConvert task can help you out here?
I finally decided to use the Condition task of Ant:
<condition property="file.protocol" value="file:///" else="file://">
<os family="dos"/>
</condition>
I've been hitting a java.lang.OutOfMemoryError: PermGen error when compiling a project with ant under Linux with jdk 1.5.0_11. the same project compiles under windows without problem.
Usually this relates to the MaxPermSize allocated to the JVM. Irakli Nadareishvili has one of the best explanations of PermGen errors and guide to setting Java HotSpot VMOptions (e.g. -XX:MaxPermSize=128M)
In this case, I quickly narrowed the issue down to a particular bpelc ant task
<bpelc input="${build.dir}/bpel/bpel.xml"
out="${build.dir}/output" rev="${version}" home="${bpel.home}"/>
Now I don't think bpelc takes the compilerarg element like javac:
<javac srcdir="${src.dir}"
destdir="${classes.dir}"
classpathref="libraries">
<compilerarg value="-XX:MaxPermSize=128M"/>
</javac>
So how to fix the error for the bpelc task? The best solution I've come up with so far is to set the ANT_OPTS environment variable. This seems to have avoided the problem to date.
export ANT_OPTS=-XX:MaxPermSize=128m
Can anyone shed more light? Is that a sure-fire fix?
When the bpelc task executes inside the original JVM running ant, then setting ANT_OPTS (or something equivalent) is the only possible solution.
One such equivalent thing might be to refactor that task to a second ant build file and run that using a separate JVM. Not really nicer, but depending on your environment it might be easier to implement.