I'm working on a project with a build.xml to generate a JAR file.
When I try to build it I get this error:
Buildfile: D:\xxxxx\trunk\project-java\build.xml
BUILD FAILED D:\xxxxxtrunk\project-java\build.xml:25: Reference
task.path not found.
Total time: 140 milliseconds
Build.xml with the line where it crashes.
<?xml version="1.0"?>
<project name="xxxxx" default="prepare-release" basedir=".">
<property name="project.dir" value="."/>
<property file="${project.dir}/build.properties"/>
<property file="${project.dir}/svn.properties"/>
<property name="dist.dir" value="${project.dir}/dist"/>
<property name="build.dir" value="${project.dir}/build"/>
<property name="src.dir" value="${dist.dir}/${dist.type}/src"/>
<property name="release.dir" value="${project.dir}/release"/>
<!-- load svn tasks -->
// Pb on this line
<typedef resource="org/tigris/subversion/svnant/svnantlib.xml"
classpathref="task.path" />
What can it be? Thanks for your help.
BUILD FAILED D:\xxxxxtrunk\project-java\build.xml:25: Reference task.path not found.
Well, where is the classpath task.path defined in your build.xml file?
When you define a task via <taskdef>, you need to do several things:
You need to specify the jar file where the task exists.
You need to specify the class that contains the task, and how to find it in the jar. This can be done in one of two ways:
You say the class is in com.foo.bar.mytask, and then give it a name.
You can specify a resource in the jar (either a properties file or an XML file) which pretty much says what class is associated with each name (which is what resource="org/tigris/subversion/svnant/svnantlib.xml" is doing.
Finally, you need to specify how to find that jar file.
That last one you're missing. You specified a reference to a classpath called task.path, but didn't actually define that classpath.
There are several things you can do:
You can put the jar into the $ANT_HOME/lib directory. When you define a task via <taskdef/>, Ant automatically looks there. I'm not fond of this because it means that you build doesn't work on other users' machines because they may not have that jar installed.
You can define a classpath to find it.
This is my preference, and here's how I usually do it.
<taskdef resource="org/tigris/subversion/svnant/svnantlib.xml">
<classpath>
<fileset dir="${basedir}/antlib/svnant}"/>
</classpath>
</taskpath>
In your project, create a directory called ${basedir}/antlib/svnant and put all five jars that came with this SVNAnt task in that directory. This way, all of the jars you need for your optional build tasks are now inside your project. If someone checks out your project from the version control system, they automatically get the needed task jars.
I put all of my optional ant task jars in that ${basedir}/antlib directory, and put each in their own directory in that directory.
Remember I said one of the things you need is to specify the class that contains the task?.
Here's what that org/tigris/subversion/svnant/svnantlib.xml file you specified looks like in svnant.jar:
<?xml version="1.0"?>
<antlib>
<!-- Tasks -->
<taskdef name="svn"
classname="org.tigris.subversion.svnant.SvnTask" />
<!-- Types -->
<typedef name="svnFileSet"
classname="org.tigris.subversion.svnant.types.SvnFileSet" />
<!-- Selectors -->
<typedef name="svnNormal"
classname="org.tigris.subversion.svnant.selectors.Normal" />
<typedef name="svnAdded"
classname="org.tigris.subversion.svnant.selectors.Added" />
<typedef name="svnReplaced"
classname="org.tigris.subversion.svnant.selectors.Replaced" />
<typedef name="svnModified"
classname="org.tigris.subversion.svnant.selectors.Modified" />
<typedef name="svnConflicted"
classname="org.tigris.subversion.svnant.selectors.Conflicted" />
<typedef name="svnIgnored"
classname="org.tigris.subversion.svnant.selectors.Ignored" />
<typedef name="svnUnversioned"
classname="org.tigris.subversion.svnant.selectors.Unversioned" />
<typedef name="svnLocked"
classname="org.tigris.subversion.svnant.selectors.Locked" />
<typedef name="svnMissing"
classname="org.tigris.subversion.svnant.selectors.Missing" />
<typedef name="svnDeleted"
classname="org.tigris.subversion.svnant.selectors.Deleted" />
<!-- Conditions -->
<typedef name="svnExists"
classname="org.tigris.subversion.svnant.conditions.Exists" />
</antlib>
It's just a map of task names to classes inside the jar.
Search your entire build.xml, the transitive closure of
included files, and all super projects for the string "task.path".
If missing or not of the following form, add or correct the form. Be sure you're not trying to identify it in some manner other than an #id attribute setting.
<path id="task.path">
...
</path>
If found but in a super project (which calls the current project via ant or antcall tasks), set the inheritrefs attribute to true to pass along the definition.
If found but in a parallel task that also defines the same #id
value, the last task to finish will override the other's reference. Consider cleaning things up to avoid ambiguity.
See also: Ant objects and references: what is the scope of a reference's ID?
Related
I created my own ant task using the instructions here. In my ant script, I create the <taskdef> like this:
<!-- myUploader.xml -->
<taskdef name="fileUpload" classname="com.awt.client.UploaderTask" classpath="lib/fileUploader.jar" />
<target name="setup" description="some required setup before taskdef!">
<!-- checking for required jars, etc... -->
</target>
And then I can import the script that invokes this as an ant task:
<!-- build.xml -->
<import file="myUploader.xml" />
<fileUpload server="${server}" username="${username}" password="${password}" appname="TestApp" appversion="13" />
This all works fine. Now, there is a bit of setup I would like to happen in myUploader.xml before the taskdef occurs. <taskdef> does not like if, unless, or depends. How can I ensure that my setup task is called before <taskdef> is done?
One way is to move the taskdef inside the setup target:
<target name="setup" description="some required setup before taskdef!">
<!-- checking for required jars, etc... -->
<taskdef name="fileUpload" classname="com.awt.client.UploaderTask" classpath="lib/fileUploader.jar" />
</target>
Then in the main buildfile, after importing myUploader.xml, invoke the setup target which is now responsible for defining your custom task.
Or you can move the part of the setup target to outside (becoming a top-level section):
<project>
<!-- do required setup here -->
<taskdef name="fileUpload" classname="com.awt.client.UploaderTask" classpath="lib/fileUploader.jar" />
...
I wrote Java tool (in this case is iOffloadMaker) which also contains own-defined Ant Task as the main launcher to launch the tool with Ant. I bundled all external jar libraries into delivered my tool's jar. I also provide a simple Ant build.xml file to launch my tool:
<?xml version="1.0"?>
<project name="TestBound" default="main" basedir=".">
<!-- Sets varables which can later be used. -->
<property name="src.dir" value="src" />
<property name="build.dir" value="bin" />
<property name="dist.dir" value="dist" />
<property name="libs.dir" value ="libs" />
<path id="build.classpath">
<fileset dir="${libs.dir}">
<include name="**/*.jar"/>
</fileset>
<pathelement location=".\iOffloadMaker.jar"/>
</path>
<!-- define offload maker task -->
<taskdef name="iOffloadMaker" classname="com.richardle.ioffload.OffloadMakerTask" classpathref= "build.classpath"/>
...
<!-- Creates the build, docs and dist directory-->
<target name="modify" description="modify the source code" >
<iOffloadMaker projectFolder="${basedir}">
</iOffloadMaker>
</target>
...
<target name="main" depends="compile">
<description>Main target</description>
</target>
</project>
The thing is that, Ant Task could not refer to classes in jar libraries inside my tool jar file. Hence, when I run ant, it throw exception as
D:\SOFTWARE\Android\TestBound>ant modify
Buildfile: D:\SOFTWARE\Android\TestBound\build.xml
modify:
[iOffloadMaker] Offload Maker is executing...
BUILD FAILED
D:\SOFTWARE\Android\TestBound\build.xml:40: java.lang.NoClassDefFoundError: org/
xmlpull/v1/XmlPullParserException
at com.richardle.ioffload.offloadmaker.ApplicationProject.<init>(Applica
tionProject.java:30)
at com.richardle.ioffload.offloadmaker.OffloadMaker.execute(OffloadMaker
.java:121)
at com.richardle.ioffload.OffloadMakerTask.execute(OffloadMakerTask.java
:26)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57)
I am sure that all necessary libs are bundled into iOffloadMaker.jar. The thing is that Ant Task loader could not see classes of dependency jars inside my jar file.
If I do not bundled all dependencies into jar, but deliver them in dependency folder along with iOFfloadMaker.jar, it work as I expected. But I want to bundle all dependencies and my tool source code into one delivery jar file.
Is there a solution for this problem?
The standard Java classloader isn't able to handle recursive JARs (i.e. JARs that are bundled inside of other JARs).
This page lists a couple of solutions for that: http://www.jdotsoft.com/JarClassLoader.php
Please let me know which one worked for you.
I am studying how ant work and I have some doubts related to it. I have an ant xml script definition file that begin in this way:
<?xml version="1.0"?>
<project name="Peacock Engine" default="default"> <!-- "default" is the default target -->
<tstamp />
<!-- ============================================ -->
<!-- Load build properties -->
<!-- ============================================ -->
<property name="project.buildfile" value="build.num" />
<property file="${project.buildfile}" />
<property file="info.properties" />
<!-- ============================================ -->
<!-- Specify the classpath -->
<!-- ============================================ -->
<path id="project.classpath">
<fileset dir="${project.libdir}">
<include name="${project.libs}" />
</fileset>
</path>
<!-- ============================================ -->
<!-- The default target -->
<!-- ============================================ -->
<target name="default" depends="jar"/>
Now help me to analyze this:
1) project tag is the root target and I use it to specify the project attributes.
2) : what exactly do this line?
3) Then I have these lines:
<property name="project.buildfile" value="build.num" />
<property file="${project.buildfile}" />
<property file="info.properties" />
What exactly do? I think that the first line create something like a variable named project.buildfile and load into it the content of a file named build.num
REgarding the following 2 lines I have few idea about what they do...can you help me?
4) Then in the ant script I find these lines:
<!-- ============================================ -->
<!-- Specify the classpath -->
<!-- ============================================ -->
<path id="project.classpath">
<fileset dir="${project.libdir}">
<include name="${project.libs}" />
</fileset>
</path>
I tryed to search on the web but I have totaly no idea about this section
5) Finnslly I have this section that is the definition of the default target that is the default action that is executed when I launch the ant script withous specify a specific task (a specific target):
<!-- ============================================ -->
<!-- The default target -->
<!-- ============================================ -->
<target name="default" depends="jar"/>
I am not totally sure about it but I think that by this line I am sayng that the default behavior of the ant script is to compile the program and that the compiled program is put it inside a Jar file.
Someone can help me to understand better this script code?
Tnx
Andrea
1) and 2) This sets the name of the project to "Peacock Engine" and sets the default task to the task named "default" (see 5)). The default task will be executed if you invoke Ant without providing a specific task:
<project name="Peacock Engine" default="default">
3) <property name="project.buildfile" value="build.num" /> creates a property which you can access anywhere in your Ant file with ${project.buildfile}. The value of the property will be build.num
<property file="${project.buildfile}" /> makes use of the above defined property. It basically loads the file "build.num" and makes all properties that are defined in this file available for further use. How does a property file work ? Have a look at the ant documentation of the property file task.
<property file="info.properties" /> loads another property file called "info.properties" and also makes all the properties in this file available to Ant.
4)
<path id="project.classpath">
<fileset dir="${project.libdir}">
<include name="${project.libs}" />
</fileset>
</path>
This tag defines a classpath. The path tag encloses a fileset. The fileset includes all libraries in ${project.libdir} that include the name ${project.libs}. Both are variables that might have been defined by including the property files above.
Effectively this tag gives you a set of libraries that can be included anywhere in the build file by referencing it's id (project.classpath).
5) <target name="default" depends="jar"/> see 1). The project tag references this target as default target when no target is supplied. This target has another target which it depends on. The target named in "depends" will be executed before "default". Again, if "jar" has another target that it depends on, this target will be executed first, and so on. It is a "call-graph". See the documentation on targets for more information on this.
You may want to have a look at the Ant documentation for writing a simple build file as a starting point to get more familiar with Ant.
1) project tag is the root target and I use it to specify the project attributes.
The project tag simply names the project, you also have the default target defined. The project tag is not, itself, a target.
<property name="project.buildfile" value="build.num" />
Creates a property named project.buildfile and sets the value to 'build.num'
<property file="${project.buildfile}" />
reads a set of properties from a file, the name of which is stored in the property project.buildfile, the value of which, in this case, is 'build.num'.
<property file="info.properties" />
reads a set of properties from a file named 'info.properties'
<path id="project.classpath">
<fileset dir="${project.libdir}">
<include name="${project.libs}" />
</fileset>
</path>
Creates a path named 'project.classpath'. The path will have the root defined in the projectlib.dir property and contains all files defined in the project.libs property
<target name="default" depends="jar"/>
means that the target default is dependent on the target jar successfully completing first. Ant will run the jar target automatically to satisfy this requirement.
Apache maintains a manual for Ant here
You should go to Ant Manual and read through it. It'll help you understand many of your questions.
Project Line
Ant files are XML files, and XML files have a root entity that encloses all the other entities. This is what the <project> entity is. Here's a simple Ant build.xml file:
<project>
<echo message="Hello, World!"/>
</project>
The sole task in this file (<echo>) is enclosed in the <project> XML entity.
The <project> entity can take some attributes:
name: The name of the Ant project. This is available in the ${ant.project.name} property.
default: The default target you want to execute. Ant basically has a two-level hierarchy. There are targets and there are tasks. A target is what you want to execute (compile, package, execute, clean, etc.), and targets contain tasks to accomplish what you want to do.
basedir: The base directory used when you specify a directory. The default is the current directory.
XML Namespaces: Don't worry about this one for now. You won't be using this until you get more comfortable with Ant.
Property Lines:
Then I have these lines:
<property name="project.buildfile" value="build.num" />
<property file="${project.buildfile}" />
<property file="info.properties" />
Ant uses something called properties which you can think of as variables. However, once a property is set, it can't be changed. For example:
<property name="foo" value="This is the initial value of foo"/>
<property name="foo" value="This is my new value"/>
The first line sets ${foo} to This is the initial value of foo. The second line does nothing. In fact, it doesn't fail or anything. It simply doesn't reset the value.
You can use this to adjust your build system by creating property files that Ant will read in first before the build takes place. The first line sets a property called ${project.buildfile} to the file build.num. This is the build number. The second line reads in all the properties in this file and sets their values. The third line reads in another property file that may setup other properties. Here's a quick example:
<project>
<property file="build.num"/>
<property name="build.number" value="Not Set"/>
<echo message="The build number is ${build.number}"/>
</project>
Let's say there's no file called build.num. In this case, ${build.number} is set to Not Set, and the build file will print out:
The build number is Not Set
Now, let's make a file called build.num, and it is this:
build.number = 1234
Now, when I run the build, it will read in the property build.number from the build.num file. The <property name="build.number" value="Not Set"/> won't change the build number since it was already set. The build will now print out:
The build number is 1234
Now, let's say I run my build like this:
$ ant -Dbuild.number=9876
I am setting ${build.number} on my command line. The build will still read in the file build.num, but won't set ${build.number} from it since I've already set it. The line <property name="build.number" value="Not Set"/> will also be ignored since ${build.number} is already set.
Path
Then in the ant script I find these lines:
<!-- ============================================ -->
<!-- Specify the classpath -->
<!-- ============================================ -->
<path id="project.classpath">
<fileset dir="${project.libdir}">
<include name="${project.libs}" />
</fileset>
</path>
There are two types of data in Ant. One is the properties which I mentioned above. The other are Paths. A Path is a series of files or directories. You see this in Unix and Windows with the PATH environment variable:
$ echo $PATH
$ /bin:/usr/bin:/usr/local/bin:/home/david/bin
If I type in a command, the operating system will search each of my directories in the PATH to find that command. In Java, you have the CLASS_PATH which are the jars you need to compile your project.
This is setting a path called project.classpath. It basically takes all of the jars that matches the <fileset> criteria and puts them in a path that can be used later, maybe for the compilation.
Targets:
<target name="default" depends="jar"/>
As I mentioned earlier, Ant has a two level hierarchy: Targets are the things you want to accomplish. Think of them as a program. A compile target is a program to compile your code. Targets contain tasks that need to be done to run the target.
Some tasks depend upon other tasks. For example, a target to test my code will be dependent upon the target to compile the code. I can't test my code without it first compiling:
<target name="test" depends="compile">
....
</target>
Some targets simply specify other targets. For example, I have a target called all. This runs the target to clean up my directory structure and get rid of any previously built files, compile my code, run tests, and then to package up my code:
<target name="all" depends="clean,compile,test,package"/>
The all target doesn't do anything itself. It's just a way to combine all of the other targets into one easy to use target. I run all, and everything I need to do a complete build is done.
In this case, the developer is defining a target called default that runs the jar target. You can see in their <project> entity that the default target for this project is called default, so if I run Ant without specifying a target, it will run the default target.
This is a bit convoluted. The developer could have left this out, and simply set default="jar" in the <project> entity.
As I mentioned before, go to the Ant Manual and it will help you learn Ant. Plus, give you a reference you can use to learn more about these various tasks.
Dude Maven is the new kid on the block. Try it and you won't need ANT. I have been using it for a month now and no more going back to ANT. There are a lot of tutorials online on how to used it with your projects. Maven Website
I am using eclipse, and I am having difficulty in creating jar files.
So I have codes like getClass().getResource("/imagesfolder/dog.jpg").
How would I create Jar files such that the folder containing my images will also be included. Because error occurs if my Jar file is not in my bin folder with the class files and the imagesfolder.
I tried File>Export>Java>Executable Jar>Save in desktop but when I double click it, it does not start. I tried cmd and it worked but with errors that it can't find imagesfolder.
How will I do a jar file in a separate directory that executes with a double click
I have a class TreeIcon; it uses two images, and I store them in a folder 'images' which is within the package of TreeIcon. For whatever reason, I made the package of TreeIcon spacecheck.images (it could just as easily have been com.mycompany.images). Therefore I used following code to access my images:
expandedIcon = new ImageIcon(TreeIcon.class.getResource("images/Expanded.GIF"));
where the 'images' here is the name of the folder containing just the images, not the one that is part of the package. I.E., in my tree structure for the program source, the images are in a folder named spacecheck.images.images.
Note that there's no slash at the start of my string; this means it references a path relative to that of the class. Putting the slash in front of the spec causes getResource to regard the path as absolute within your jar, so I could also have used the string "/spacecheck/images/images/Expanded.GIF".
ANT is The Way
In eclipse you can use Ant to build your .jar file.
From ant.apache.org
Apache Ant is a Java library and command-line tool whose mission is to
drive processes described in build files as targets and extension
points dependent upon each other. The main known usage of Ant is the
build of Java applications. Ant supplies a number of built-in tasks
allowing to compile, assemble, test and run Java applications. Ant can
also be used effectively to build non Java applications, for instance
C or C++ applications. More generally, Ant can be used to pilot any
type of process which can be described in terms of targets and tasks.
Ant is written in Java. Users of Ant can develop their own "antlibs"
containing Ant tasks and types, and are offered a large number of
ready-made commercial or open-source "antlibs".
Ant is extremely flexible and does not impose coding conventions or
directory layouts to the Java projects which adopt it as a build tool.
Software development projects looking for a solution combining build
tool and dependency management can use Ant in combination with Apache
Ivy.
The Apache Ant project is part of the Apache Software Foundation.
Search with google and you will find many documentation, I will show the basic way to do it.
The Build.xml file
First of all create a new file xml, for example "Build.xml" this will be the file that Ant will read.
The you start writing inside it this:
<?xml version="1.0" encoding="UTF-8"?>
This is the basic line you have always to include.
<project name="NameOfYourProject" default="try_jar" basedir=".">
This (with its closing tag </project> at the end of the file, is the main tag, declaring the name of the project and the first task (default) that will be executed, each task is something Ant will do, and is called "Target", you can create a single target that do everything or various target that do few things each, in this case you can create different "flow-chart" that ant will follow. For example I usually create 3 route for Ant: try_jar that is used just to try if all is working in the jar without doing many things, new_version_jar that is the same of try_jar but will update version number, will sign the jar and some other stuff, and javadoc that creates the javadoc for the project. Il will show you the basic try_jar.
<description>
This buildfile is used to build the jar of the game.
</description>
No need to explanation.
<!-- ================= File and Directory Names ==================== -->
<property name="src" location="${basedir}/src" />
<property name="conf" location="${basedir}/conf" />
<property name="build" location="${basedir}/build" />
<property name="dist" location="${basedir}/dist" />
<property name="app.name" value="MyAppName" />
<property name="dist.jarHome" value="${user.home}/MyApplicationMainFolder" />
<property name="app.version" value="0.2" />
<tstamp />
<property name="jar.name" value="${app.name}_${app.version}.${DSTAMP}.jar" />
<property name="jar.completePath" value="${dist.jarHome}/${jar.name}" />
Here we declare the base properties of the jar, we tell it where the source code is, where the build folder should be and so on. We also choose to put all the app in a folder in the base user home (in mac this is /user/UserName/) and create the name for the file that will include the name (obviously) the version and the time when this jar is created. This avoid duplicated or overriding of files that we may want to keep.
<property name="shared.lib" value="${basedir}/lib" />
Here we must specify the directory in which jar files needed by this plugin to run are stored
<!-- =============== Custom Ant Task Definitions =================== -->
<property name="compile.debug" value="true" />
<property name="compile.deprecation" value="false" />
<property name="compile.optimize" value="true" />
This are configuration params for ant
<!-- ================== External Dependencies ======================= -->
<property name="LWJGL" value="lwjgl.jar" />
<property name="Timer" value="timer.jar" />
<property name="Database" value="hsqldb.jar" />
<property name="Splice" value="jarsplice-0.25.jar" />
Here you must specify your external dependencies (something like easymock or powermock if you want to create a test target.
<!-- ================== Compilation Classpath ======================= -->
<path id="compile.classpath">
<fileset dir="${src}">
<include name="**/*.java" />
<exclude name="**/server/*.java"/>
</fileset>
<fileset dir="${shared.lib}">
<include name="**/*.jar" />
</fileset>
</path>
This is what And (with javac command) will build, you have to specify all the folders you want to build and to add (with <fileset>) any jar that is in the buildpath
<!-- =================== All Target ================================ -->
<!-- ================== Try_jar Target ============================ -->
<target name="try_jar" depends="compile, dist, clean_class_files, run" description="Clean build and dist directories, then compile, create jar and finally run" />
This is our target, as specified in "default" the first line, and will run this. Depends tells Ant what it should do before this target. A you can read it will compile, create the jar (dist), remove the class files, and run it.
<!-- ================== Clean Target ============================== -->
<target name="clean" description="Delete old build and dist directories">
<delete dir="${build}" />
<delete dir="${dist}" />
</target>
This is very clear, before to compile a new version we want to remove any old class file to avoid problems. You may think that this is never called, but pay attention to the dependencies of each target.
<!-- ================== Prepare Target ============================= -->
<target name="prepare" depends="clean">
<mkdir dir="${build}" />
<mkdir dir="${build}/classes" />
<mkdir dir="${build}/lib" />
<copy todir="${build}/lib">
<fileset dir="${shared.lib}" includes="${Timer}, ${LWJGL}, ${Database}" />
</copy>
</target>
This prepare the path, creating new needed folders (like build and build/classes) and adding the external dependencies jars.
<!-- ================== Compile Target =========================== -->
<target name="compile" depends="prepare" description="Compile Java sources">
<mkdir dir="${build}/classes" />
<javac srcdir="${src}" destdir="${build}/classes" encoding="8859_1" debug="${compile.debug}" deprecation="${compile.deprecation}" optimize="${compile.optimize}" source="1.6" target="1.6">
<classpath refid="compile.classpath" />
</javac>
</target>
This is the main compiling target, as you can see it depends on prepare (that depends on clean) so until now we are using all <target> tags.
Ant compile .java files using <javac> tag, that needs to know where the source files are, where to put .class files, the encoding, and the three params we specified earlier.
<!-- =================== Dist Target ================================ -->
<target name="dist" description="Creates Jar archive">
<!-- Create the time stamp -->
<tstamp>
<format property="compile.timestamp" pattern="yyyyMMddHHmm" />
</tstamp>
<!-- update version in manifest -->
<replaceregexp file="${basedir}/manifestClient" match="Implementation-Version: .*" replace="Implementation-Version: ${app.version}.${compile.timestamp}" />
<!-- Create Jar file -->
<jar destfile="${jar.completePath}" manifest="${basedir}/manifest">
<fileset dir="${build}/classes" excludes="**/*.bak" />
<fileset dir="${src}/" excludes="mh/" />
<fileset dir="${shared.lib}/native/macosx" />
<zipfileset src="${shared.lib}/${Timer}" />
<zipfileset src="${shared.lib}/${LWJGL}" />
<zipfileset src="${shared.lib}/${Database}" />
</jar>
</target>
this creates the real jar. <tstamp> and <replaceregexp> are used to update the version in the manifest, you can remove them.
Jar tag will create the .jar file, we specified what files to add in the jar that will be avaible to my classes inside. We have also to specify a manifest that will discuss later.
<!-- =================== Delete .class Target===================== -->
<target name="clean_class_files" description="Delete .class files stored inside build directory and dist folder">
<delete dir="${build}" />
<delete dir="${dist}" />
</target>
This target deletes the two folder used to store .class files (and obviously all the files inside).
<!-- ================== Run Target =============================== -->
<target name="run" description="Run MagicHogwarts">
<java jar="${jar.completePath}" fork="true">
</java>
</target>
The end of our build.xml file, that is the run target that runs the jar.
This is almost what you need to compile and and the correct resources to a jar, if something is not like you are expecting, simply try few times and all will go right.
This is the manifest:
Manifest-Version: 1.0
Created-By: 1.6.0 (Sun Microsystems Inc.)
Main-Class: package.to.class.with.main
Built-by: Gianmarco
Implementation-Vendor: Gianmarco
Implementation-Title: Title
I hope this will be useful to you.
I am editing few things to make the post better, but no contents will be different.
We are developing an Eclipse product made of several plugins, some of them developed by us. Each of our plugins has be defined as an Eclipse plugin project in workspace and has two folders, source and test. Recently I noticed that we are delivering the test classes to the user like the our source classes. Now I want to remove the test classes from the result of our product. Shall I remove the test folder from the Java build path (see the attachment)? And what else I should do to don't deploy our tests to the end-user?
To build the project we are using the eclipse standard ant script to create our zip file. I don't find where can I exclude test files. Here is the the Ant script:
<property name="allElementsFile" value="${eclipse.pdebuild.scripts}/productBuild/allElements.xml"/>
<import file="${eclipse.pdebuild.scripts}/build.xml"/>
<property name="pluginPath" value=""/>
<property name="pluginList" value=""/>
<property name="featureList" value=""/>
<property name="includeLaunchers" value="true"/>
<property name="generatedBuildProperties" value=""/>
<condition property="nestedInclusions" value="true">
<istrue value="${p2.gathering}" />
</condition>
<!-- ===================================================================== -->
<!-- main entry point to setup, fetch, generate, build etc. Use -->
<!-- the customTargets.xml to modify the build behaviour. -->
<!-- ===================================================================== -->
<target name="main" description="the main build target">
<antcall target="preBuild" />
<antcall target="processRepos"/>
<antcall target="generateFeature"> <!-- Generate the feature to drive the fetch -->
<param name="verify" value="false"/>
</antcall>
<antcall target="fetch" />
<antcall target="generateFeature"> <!-- We are calling generate feature a second time so that we can get the pack / unpack clause fixed -->
<param name="verify" value="true"/>
</antcall>
<antcall target="generate" />
<antcall target="process" />
<antcall target="assemble" />
<antcall target="package" />
<antcall target="postBuild" />
</target>
<!-- ===================================================================== -->
<!-- Generate a container feature based on the product file -->
<!-- The plugin or feature containing the .product file will need to exist -->
<!-- already, use preSetup or postSetup to fetch it if necessary -->
<!-- ===================================================================== -->
<target name="generateFeature">
<eclipse.generateFeature
featureId="org.eclipse.pde.build.container.feature"
buildDirectory="${buildDirectory}"
baseLocation="${baseLocation}"
productFile="${product}"
verify="${verify}"
pluginPath="${transformedRepoLocation}${path.separator}${pluginPath}"
configInfo="${configs}"
pluginList="${pluginList}"
featureList="${featureList}"
includeLaunchers="${includeLaunchers}"
buildPropertiesFile="${generatedBuildProperties}"
nestedInclusions="${nestedInclusions}"
filterP2Base="${filterP2Base}"
/>
</target>
</project>
This is an issue with your deployment procedure/script. Are you using Eclipse to build the jar ?
It should not have to do with the build path, you should keep your test source in the build path if you use Eclipse to code them.
Usually a deployment procedure using Ant or Maven will exclude the test classes from the result (jar, war, ...). It is also advisable to automatically run the tests before the jar is created.
To remove test files (if you defined for every plugin project a source folder and a test folder) from the code while building a pde project using pde ant scripts you should remove the test folder from the build.properties of that project. The build.properties is a part of plugin.xml