This question already has an answer here:
Can I use ivy dependency info in my ant build file
(1 answer)
Closed 8 years ago.
In my ant script, I want to intercept ivy dependency names so that I can use those names inside the script. The reason is that the dependency names are not always known ahead of time. The ivy.xml file gets dynamically updated with dependencies of the users's choosing and the build script has to use those.
Is there a way to intercept ivy dependency names using ivy:retrieve?
Thanks.
One of our projects is using a workaround, where you define ivy-tokens.xml, which contains tokens for the items not known in advance, and then the build script copies this file to ivy.xml, replaces the tokens and only then starts the Ivy related tasks.
Related
So, at work, I frequently have to create virtually identical ant scripts. Basically the application we provide to our clients is designed to be easily extensible, and we offer a service of designing and creating custom modules for it. Because of the complexity of our application, with lots of cross dependencies, I tend to develop the module within our core dev environment, compile it using IntelliJ, and then run a basic ant script that does the following tasks:
1) Clean build directory
2) Create build directory and directory hierarchy based on package paths.
3) Copy class files (and source files to a separate sources directory).
4) Jar it up.
The thing is, to do this I need to go through the script line by line and change a bunch of property names, so it works for the new use case. I also save all the scripts in case I need to go back to them.
This isn't the worst thing in the world, but I'm always looking for a better way to do things. Hence my idea:
For each specific implementation I would provide an ant script (or other file) of just properties. Key-value pairs, which would have specific prefixes for each key based on what it's used for. I would then want my ant script to run the various tasks, executing each one for the key-value pairs that are appropriate.
For example, copying the class files. I would have a property with a name like "classFile.filePath". I would want the script to call the task for every property it detects that starts with "classFile...".
Honestly, from my current research so far, I'm not confident that this is possible. But... I'm super stubborn, and always looking for new creative options. So, what options do I have? Or are there none?
It's possible to dynamically generate ANT scripts, for example the following does this using an XML input file:
Use pure Ant to search if list of files exists and take action based on condition
Personally I would always try and avoid this level of complexity. Ant is not a programming language.
Looking at what you're trying to achieve it does appear you could benefit from packaging your dependencies as jars and using a Maven repository manager like Nexus or Artifactory for storage. This would simplify each sub-project build. When building projects that depend on these published libraries you can use a dependency management tool like Apache ivy to download them.
Hope that helps your question is fairly broad.
I'm trying to unify a build process, running one build to get multiple packages. My first shot at this is just having a central build script call <ant> or <subant> on each project's build.xml file. I'm using Ant 1.6, and I've run into a funny problem: either I use the <ant> task, and I can specify multiple targets but not multiple build files, or I use the <subant> task, and I can specify multiple build files but not multiple targets.
I realize there's a few solutions here already:
Just upgrade to Ant 1.7 already; <antcall> can do multiple targets there.
Edit the separate project build files to have a variety of top-level targets, so I can call each individual file with just one target, and use <antcall>.
Copy-paste a lot of <ant> tasks, with a little help from <macrodef> to help the sanity.
Is there something I've missed, that will allow me to do what I want from this single central build.xml without a) editing individual project files, b) writing lots of repetitive code, or c) upgrading Ant, and that d) doesn't require editing every time I add a new project?
I would like to simplify my main build scripts, and I'd like to have the ability to reuse certain common ant tasks as a library, but I'd also like them to be easily available as a package.
For instance, I've got a task which sets up the Flex environment variables that I need to build a variety of projects. I can (And am currently) include those scripts by relative path from another location in source control. But what I want to do is make a single download-able package that I can grab via Ivy that contains all of these generic tasks.
A jar seems the most natural solution, since this is doable from java (Use the class loader to access the file inside the jar.), but I can't seem to find a "native" way in Ant to just get the xml file.
In short, I want to do:
<import file="some.jar!bootstrap.xml">
But that doesn't work.
Is there someway to do this? Any other suggestions for making a library of ant scripts would be much appreciated as well.
From what I understand you're trying to extract a file containing more ant tasks from your jar and then tell ant to execute the tasks in those extracted files. Since the files are static, you'd probably be better off creating actual java Task definitions in your jar and declaring them in your ant build file. However, if you don't want to do that, you can just use the Unzip ant task to extract the resource out of the jar and onto the file system and then use the Ant task to execute the extracted file.
IIRC there's ongoing work in Ant to support this but it's not supported in any published version.
For those of you that use Ant with multiple projects, where do you put the build.xml files? Do you put one in each project, or do you put them in a separate project that contains all your Ant-related files?
The usual recommendation is to put a build.xml in each project. But this has a few drawbacks:
It makes it hard to reuse common targets in multiple projects.
Sometimes you want to use Ant to export a project from source control and deploy it. Obviously you can't do this if the build file is in the project itself.
But if you put them all in a common location:
People need to be aware of their location to use them; they can't just use "ant -find" to find the current project's file.
You can't have different build instructions for different branches of the project.
What do you guys do?
EDIT: Thanks for the good suggestions so far. As far Maven, these aren't Java projects, and I get the impression that Maven is only meant for Java.
Place the Ant files with the project. That is the de facto standard and recommended by the creator of Ant. I will try to address some of the issues you have brought up:
Reuse of common targets should be done using techniques as described by Eric Hatcher in his book Java Development with Ant. Basically, you extract all commonality into a some top level files that all other Ant files "inherit" from.
Using Ant to export a project from source control seems odd to me, but if you want to do this, use a different Ant file :-) You can make a target like ant export -Dproject=foo/bar.
For Ant, I recommend you grab that book - it has a ton of helpful techniques.
The real recommendation I would make though is to drop Ant and convert over to Maven - like the Apache Software Foundation did (they maintain both Ant and Maven).
If you're working with independent projects, you can:
put your build.xml at the top level
place common Ant definitions (Antlib) into another project (e.g. config)
use svn:externals to import the common Antlib definition (from 'config') into your project
EDIT The trick with svn:externals is that if you link to the HEAD of some common files, it may happen that they will change after a couple of months/years. So each time you tag, you should change the svn:externals to point to a fix version of the included project. This may come handy when a project has to be rebuild years after it was last built.
My rule of thumb is to put the build.xml file in the directory under which all files are referenced. In other words, no relative paths should start with "../". Where I live, that usually means putting it in the "trunk" directory, which has src, lib, build, docs, etc underneath it.
Doing this makes the paths much cleaner in the file, and it makes it obvious how to build the project.
Where I have multiple projects that need to build, I will create a separate build.xml for each project, and a central build.xml in the directory all the project are in that calls those other build.xml files. That gives you a lot of flexibility with very little work.
I'd expect an Ant build file to be located at the top of a project (it's already a pain to have to look at a the build file to "discover" how to build the project, so if I have to locate it first, it'll drive me totally crazy). Now, regarding all the drawbacks you mentioned, I'm tempted to say: why don't you use Maven?
The way I have done this is in the past (Now I just use Maven):
Have a build.xml in the root of each project
Create an overarching build.xml
for all projects and place it in
the trunk of my repository
The overarching buid.xml has
checkout tasks for each project.
I am guessing when you mentioned
export from repository, you
actually meant import.
The overarching build file also
defines the dependencies, if any
You may update individual projects using each project's individual build file
If you do have common tasks defined, you may inherit from a common build file as well as someone else suggested.
Looks like your set of projects might be a good candidate for migration to Maven, I realize it is not always possible but if you have time, you might want to look into it.
It seems that ant dependency management isn't great to say the least... But, is there hope?
Today there are better choices for build or project management such as maven, ivy but I'm stuck with a bunch of ant project that depend on one another so I was wondering if there's an "ant best practice" for managing dependencies.
Specifically in my case I have:
w.war
a.jar
b.jar
c.jar
w.war is the war file I deploy to the web server. In the war file I use a.jar. a.jar depends on b.jar, so I happily package b.jar into w as well... That's sort of OK until...
The problem starts when b.jar depends on c.jar. The author of a.jar knows about its dependency on b.jar so it can package b.jar into w.war, but it is not aware of the dependency of b.jar on c.jar. Moreover, the author of b.jar could later add even more dependencies such as "b.jar depends on e.jar", so the author of a.jar has no chance following these dependencies as they add up.
What I'd like to have is define "a depends on b" and "b depends on c" (in a different build.xml file) and use ant magic to compile them all into w.war.
Is that possible? If not, is there a Best-Practice?
I'm this-close to just rewriting is all in maven, but it's a lot of work... Is there hope to ant?
If you already use Ant, then your best bet is to use Ivy for dependency management.
http://ant.apache.org/ivy/
It provides a rich set of ant tasks for dependency manipulation.
Just to disillusion you: dependency management in combination with a build system is hard! Unless you have a really simple example, this is not a no-brainer, and you will have to invest some work.
If you want to or have to use Ant, Ivy is definitely a good choice. Being an official sub-project of Ant, it integrates relatively smoothly.
I've been using Ivy for the last 4 years (way before it joined Apache) and haven't had any regret.
Without knowing much about your Ant files, it's a little bit difficult to give a definitive answer but I guess that the projects are build in one go. This means that they can't individually publish their artifacts (or jar files) into a central repository.
The solution is to use both a central (for common libraries) and local (for your project) repositories. You can take a look at my public projects and especially the ivysettings.xml file because they use exactly this very principle.
Here's my take: use the best of both worlds: Maven just for dependencies and Ant for your day-to-day build heavy-lifting:
Why you should use the Maven Ant Tasks instead of Maven or Ivy
There's a new open source build system for Java called EBuild (features) that is a great alternative to Ant/Ivy as it is especially good at dependency management.
There's some detailed articles on the deficiencies of Ant and also Maven on the site.