How to execute a good refactor of a big ant script that involves many projects?
I am very new in Ant (I came from Maven and, at this time, Ant is my nightmare).
I have the following situation:
In the Eclipse workspace I have some Java project that interact with each other composing a final single application.
One of this project (named CrystalIceGUI ) that implement the application GUI contain in itself the unique build.xml Ant script that, simplifying at most, do the following operation:
1) Compile all projects (which are seen as dependencies of the CrystalIceGUI project)
2) For each project create a directory named Release (in the proper project) and put in it the .jar file related to this project. (For example one of these projects is named ShellExtBridge , so the Ant script will create the following directory: ShellExtBridge/Release and put the created .jar file of the ShellExtBridge in this directory.
3) Finally create the following structure for the main project ( CrystalIceGUI ): Create a directory named Relaese into the CrystalIceGUI project and in this directory put the .jar file related to the CrystalIceGUI project .
Furthermore, create this directory CrystalIceGUI/Release/lib that contains all the .jar created before for the dependencise projects.
And now my problem: the boss ask to me to create a single Ant script for each project . These Ant script have simply to create a Release folder into each project, create the jar for the project and put the jar in this Release folder. But I am a bit confused about how I have to do it.
My idea is this one: For each project I take from the old Ant script (the script that execute all the work in the main project) the section related to the project on which I am working.
For example for the previous subproject named ShellExtBridge : I take this section of code from my old build.xml ant script:
<target name="shellextbridge"
description="Packs classes of shellextbridge">
<mkdir dir="${project.libdir}" />
<javac srcdir="${deps.shellextbridge.dir}/Project/src" destdir="${deps.shellextbridge.dir}/Project/bin"/>
<jar destfile="${deps.shellextbridge.dir}/Release/${deps.shellextbridge.jar}" index="false">
<fileset dir="${deps.shellextbridge.dir}/Project/bin"/>
<manifest>
<attribute name="Created-By" value="${info.software.author}" />
<attribute name="Main-Class" value="com.techub.crystalice.rmi.Main"/>
</manifest>
</jar>
<copy file="${deps.shellextbridge.dir}/Release/${deps.shellextbridge.jar}" tofile="${project.libdir}/${deps.shellextbridge.jar}"/>
<copy file="${deps.shellextbridge.dir}/Release/${deps.shellextbridge.jar}" tofile="${project.deploy}/lib/${deps.shellextbridge.jar}"/>
<copy file="${deps.shellextbridge.dir}/Release/${deps.shellextbridge.jar}" tofile="${project.dev.deploy.dir}/${deps.shellextbridge.jar}"/>
</target>
and I put it into a new build.xml ant script that is specific for the ShellExtBridge project (changind the paths)
Can be a good solution to do what they ask me?
Sorry if I have dwelt but having never seen ant until yesterday I have many doubts about how to act
Tnx
Andrea
Coming from Maven you're accustomed to standard project source code layouts, you'll also be familiar with build plugins.
First of all I would suggest identifying common pieces of build logic and consider creating a set of ANT macrodefs. Next investigate how to create an ANTlib to hold your build's macrodefs. This would a jar file that could be included in each build, holding the common build logic.
Finally, if you decide to hold your common logic in an ANTLIB this means you can support build versioning, emulating how Maven supports different versions of a build plugin. Very useful in situations where you need to make changes without breaking older builds.
For more details see the following answer:
With regards to defining common build logic; reusing it across multiple projects; and defining common build phases in Ant, I would suggest that you have a look at how Netbeans sets up its projects. This will give you a fair enough understanding on build.xml reuse.
Let us say that you start with identifying 5 phases - clean, init, build, dist, release (etc). You could create a base file (located probably at $root.dir/build/common.xml). In this file you can go ahead and create the sequence in which targets will be invoked.
Now if you look at how Netbeans sets up the projects you will notice that a target - say build - would invoke targets -pre-build, -do-build, -post-build. Effectively all the actual code is present in these additional targets. The advantage of doing this is that in the individual module (where this common.xml has been imported) you can override only those portions of the build that require special handling.
This way, you can move each project individually over to the modular build system.
Once you have the basic script running, then you can potentially look at leveraging libraries like Ivy (dependency management) to work with the packaging etc.
Alternatively, if you are planning on moving things to an extensible & modular system, then I would also recommend that you use Gradle - this is a Ant friendly, Java based build platform. The reason I suggest it is because, you are eventually going to end up building custom tasks or doing a whole bunch of jugglery just to satisfy small requirements ... which you could probably do it better via scripting code.
Hope this helps you.
链接地址: http://www.djcxy.com/p/44406.html上一篇: ANT执行任务与WINEPREFIX