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>
Related
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">
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 have to automate quite a lot in my current project. For this, I use ANT as it provides quite some commands. However, I have to use ant-contrib as I need for loops and other additional parts.
I use a model driven approach and have to automate the whole chain containing several models until the final model is created.
Is there an alternative to ANT that also provides an easy way to specify task execution? Maybe a DSL for this purpose? Is there anything like this out there?
If you have a modern version of Ant (e.g. 1.8.1) you can use the scriptcondition task/element to run arbitrary scripts with all the control flow of a proper programming language in it.
Something like this:
<condition>
<scriptcondition language="javascript" value="true">
for(var i in self) { println(i); }
self.setValue('true');
</scriptcondition>
</condition>
See also: http://ant.apache.org/manual/index.html
You could use any scripting language that suits your requirements:
e.g.
Bash/Shell Scripting (or PowerShell I suppose)
Something a bit more cross platform and ubiquitous...
Perl
Python
Ruby
...or something more build oriented.
Make
Rake
I'd be interested in which bits of Ant you find useful - I presume it's the tasks and not the language itself, or the declarative bit of Ant. If that's true, I'd suggest Groovy, Jython or Jruby would let you wrap the Ant tasks in code that's more suitable for your needs, without a line of XML.
you can leverage existing ant scripts, and switch to groovy!
using http://groovy.codehaus.org/Using+Ant+from+Groovy
And there is always the shell ... sh, batch or WSH or Powershell or if you have it: Python, Perl etc. can get you quite far.
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.
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.