I need to update an existing ear file using ant task excluding some of the jar files, which will be available on WAS shared libraries. I don't want to create ear again, need to only update already built ear, as I have seen posts to update ear but those are creating a new ear. My problem is, i don't want to re-create the ear.
This is a way for doing it through maven, but I want to do it through ear task ant.
Thanks.
The Ant ear, war, and jar tasks might be able to update ears, wars, and jars, but I wouldn't depend upon it. Creating ears is a very quick task -- a few brief seconds, so it was never an issue I explored.
If you can't recreate the ear because the files you need are no longer available, you can try unzipping the ear, set what you need, and rebuild it from scratch.
<unzip src="${ear.file}"
destdir="${temp.location}"/>
<delete file="${ear.file}"/>
<here be dragons.../>
<zip destfile="${ear.file}"
basedir="${temp.location}"/>
You could use <patternset/>s, or <zipfileset/>s to control what gets zipped and unzipped, but it's probably easier unzipping and rebuilding.
If it makes you feel better, you can use <ear/> instead of <zip>, but you'll have to specify the appxml parameter. It's just easier to use <zip/>.
Related
I want to be able to have one set of build/props files that will build as many EAR projects as I tell it to.
Each EAR project will have its own set of modules, WARs, JARS, etc.
I'm want to set in a props file what each EAR project consists of, and I want to tell the build each time which EAR(s) to build.
In general, what is a good way to structure the build/props files?
So far, I have one build.xml file and one props file.
In the props file, I have an entry for each EAR project, for example:
Foo=fooWar, foojar
Bar=barWar, barJar1, barJar2
Not sure if that's a good idea or not, and I'm thinking how to tell the build which projects to build.
Since it could be many projects, I'm thinking I would want another props entry like:
projectsToBuild=Foo, Bar
And then before each build, the build person would edit "projectsToBuild".
Is this a good road to go down?
If you're building multiple projects in one hit, then it sounds like you don't have any proper dependency management in place. Have a look at using Apache Ivy to publish and retrieve from a shared repository (e.g. Artifactory), so that you can decouple your project and build them independently.
I am using ant externally, i.e. I construct org.apache.tools.ant.Project dynamically
in my program: setup its Tasks, Targets etc., then I want to create build.xml file. How is possible? How possible export this project into ordinal ant build.xml?
I've been working with the ant codebase a lot recently, and I'm afraid I don't think this is possible.
Since you're the one generating the project in the first place, it might be easier if you generate the XML at the same time.
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.