I'm using Ant 1.8.1 and StarTeam 2008 R2.
I noticed in previous versions of Ant there were optional tasks which could be used to access a StarTeam repository.
These tasks seem to be absent in Ant 1.8.1? What happened to them? Do any tasks exist to do this, or do you have to create your own tasks using the StarTeam SDK 10.4 (which looks straightforward enough, but I wouldn't want to duplicate an existing effort)?
These tasks are present in the ant-starteam.jar.
I've noticed my binary distributions of ant 1.6 and 1.7 has this jar in the lib directory. But 1.8 does not.
This URL http://www.docjar.com/docs/api/org/apache/tools/ant/taskdefs/optional/starteam/package-index.html still defines these classes as part of the javadoc API for ant 1.8, so I guess it should work if you add the ant-starteam.jar into the ant/lib directory
I am using Ant 1.8.2 on OS X and was able to use the ant-starteam.jar for 1.7.1. Had to pass the location of the starteam library to ant like so
ant -lib "/Applications/starteam-en-10.4.7-java/lib/"
Saw this pointer on another forum. T
Related
I am working with a third party framework that I am integrating gradle into. I am calling some old ant tasks. The problem is that the third party framework wants me to use:
either its own ant, that is packaged with it
a specific ant version, in this case 1.9.1
Unfortunately there is no way to set the ant version that is used by gradle. I can not figure out if its is possible to point gradle to any specific version within my environment.
So what do you think I could do?
Thanks in advance,
Denis.
If you need to use a different Ant version than the one that comes with Gradle, you'll have to call out to Ant via a JavaExec or Exec task, rather than using Gradle's built-in Ant support.
I'm trying to diagnose a failure in my ant file when it runs a Worklight task. I have a small ant file containing a simple reference to a Worklight task. This works correctly.
<target name="rawBuildApplication" >
<app-builder
applicationFolder="${applicationSource}"
environments="mobilewebapp"
nativeProjectPrefix="xxx"
outputFolder="${outputFolder}"/>
</target>
However when I invoke this ant file from a build control ant file (actually from the RTC build system) I get a failure (below), showing worklight failing to find an apache Java class. I assume there's some simple environmental difference, perhaps a classpath. It might help to figure it out if I knew where Worklight loaded the apache commons from. Right now I can't see anything in my environment in the case that works that points any apache Jar.
myAntFile.xml:146: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.deleteQuietly(Ljava/io/File;)Z
at com.worklight.builder.util.BuilderUtils.<clinit>(BuilderUtils.java:672)
at com.worklight.builder.config.UserBuildConfiguration$Builder.<init>(UserBuildConfiguration.java:203)
at com.worklight.ant.builders.ApplicationBuilderTask.createBuildConfiguration(ApplicationBuilderTask.java:149)
at com.worklight.ant.builders.ApplicationBuilderTask.execute(ApplicationBuilderTask.java:80)
Edited: the cause is the use of -lib to add the RTC toolkit directory, exactly why this clashes and how to work around yet to be determined
Usually means you have version of the commons jar in your classpath, and its overriding the one packaged in the worklight-ant.jar. the apache commons files are inside the worklight-ant.jar file
Additional info from djna: I can confirm that when adding the Rational Team Concert (RTC) 3.0 toolkit to the ant classpath, either explicitly with -lib, or when selecting that option in the RTC Build definition some conflicting commons jars are added to the classpath. Worklight packages the classes it needs in its jar, but the -lib folder seems to take precedence.
My workaround is to replace the conflicting jars with later ones. I used these jars
commons-io-2.4.jar
commons-codec-1.8.jar
httpclient-4.2.5.jar
httpcore-4.2.4.jar
httpmime-4.2.5.jar
I guess the other alternative is to upgrade to a newer RTC, but in our environment that's not currently possible.
My problem is the following:
I would like to use the propertyregex task in ant. The project I am working on is built on various different servers and I don't want to configure (install the ant-nodeps.jar) every server. The source needs to include everything, that is not installed on the system by default.
So now I would need to add the ant-nodeps.jar to the ant classpath from within the build file. Does somebody know how to do that?
Cheers,
Robert
The propertyregex task is part of ant-contrib and can be installed as part of your build using Apache ivy
Checkout the following example, which demonstrates how to download and use the "for" task (also from the ant-contrib project):
Problems getting my ANT builds to work after OS upgrade
The one downside is that ivy does not come pre-packaged with ANT, so the following answer has a tip on how to bootstrap your ANT builds. Once ivy is started it can be used to pull down everything else your build needs.
Ivy fails to resolve a dependency, unable to find cause
Update
While I understand you requirement to have no change on the target platforms, it's a very difficult problem to solve if you must also match several old versions of the build software. I have found incompatibilities between the latest ANT and 5 year old versions like 1.7 (ANT 1.6.5 is now 8 years old....)
What I do is install a very limited number of ANT versions on my Jenkins slave nodes. Build jobs can then only choose from these and then use ivy to download all other 3rd party software dependencies (This setup emulates how you'd manage a set of Maven projects).
I suspect you're using ANT to run your deployments? If that is the case I would suggest switching to something like Groovy, which can be deployed as a single jar file and can pull down dependencies on the fly, using Grape.
I am stuck with Ant 1.7.1 for the moment for reasons I wont get into. I'd like to be able to use the SshSession Ant task to create SSH tunnels to some of my servers. But SshSession was introduced only in Ant 1.8.0.
I have no experience with custom Ant tasks. Would it be difficult to backport this task from 1.8.0 to 1.7.1 ? Where should I go to learn more on how to do that ?
Thanks for your help !
It looks like the source for the SShSession task is compatible with ant 1.7. Get the source for this task, and compile against ant 1.7 and the jsch jar. Then create a taskdef pointing to the class you've just created (jsch.jar will need to be in the ant lib dir or specified using the -lib option) and you should be good to go.
Warning : since version 1.3.6 the anttask.jar as been renamed ant-metricstask.jar
As of version 1.3.2 the metrics plugin contains some ant tasks that can be used for headless operations as part of a nightly build for example. This section describes how to do this.
Where can i get it? I can not find it anywhere.
Are you looking for ant-metricstask.jar?
It's available in the eclipse plugin downloadable at
http://sourceforge.net/projects/metrics/files/
Point eclipse directly at the URL or download the updatesite_1.3.6.zip and you can get the jar inside.