I have the pleasure of working on a embeded java program, which was writen 10+ years ago from a third party company. Source and project files were included.
It was imported into Eclipse and ported to a higher java version (17).
Now I'm stuck when trying to build the program. It uses ProGuard. The newest version was added to the project files. Config file proguard.pro was changed to discard rt.jar utilization in favore of the new methods. However, now I'm getting a error message:
BUILD FAILED
C:\mypath\build.xml:16: taskdef class proguard.ant.ProGuardTask cannot be found
using the classloader AntClassLoader[C:\mypath\obf\proguard.jar]
build.xml (original) is as follows:
<target name="obfuscate" description="obfuscate a jar file" depends="jar">
<taskdef name="proguard" classname="proguard.ant.ProGuardTask" classpath="obf/proguard.jar" />
<proguard configuration="obf/proguard.pro" />
</target>
The 'obf' folder is inside the project (sublevel of build.xml). File proguard.jar is inside of it. Anyone haveing any clues why would this error show? No other changes were made beside the listed ones.
So, it turned out that with new versions, the notation is not as it once was.
<taskdef resource="proguard/ant/task.properties" classpath="${proguard.path}/lib/proguard-ant.jar" />
I'm trying to generate the documentation, using javadoc, from one or two downloaded jar files (with the source of course, after having extracted everything).
But using javadoc, even in an Ant file, I'm being prevented from generating this because of silly things, specifically "package XXX does not exist" and "cannot find symbol"... I just want javadoc to put the text of these things (external references) in the html docs, but to document all the .java files it finds...
NB for anyone interested this is the download page with the download files (containing source) from which I'm trying to generate the API documentation: http://logback.qos.ch/download.html
Following Mark Rotteveel's help, my Ant build file now looks like this:
<?xml version="1.0" ?>
<project name="document logback core" default="doc">
<target name="doc">
<mkdir dir="javadoc" />
<property name="excludedPackages"
value="org.codehaus.*,javax.mail.*"/>
<javadoc destdir="javadoc" sourcepath="src" packagenames="main.*"
excludepackagenames="${excludedPackages}"
additionalparam="-Xdoclint:none" />
</target>
</project>
... but it still gives errors 1) about packages not being found, including "org.codehaus.[xxx...]" and "javax.mail.[xxx...]" and 2) about symbols not being found (although this may go away if I can solve the missing packages errors).
NB the build is said to be successful, but I get complaints about no source files being found (where there are indeed commented .java files), and no html at all is generated under \javadoc.
later, following Tony Pierce's success in generating these docs
Installed Ant 1.9.6, changed path accordingly, checked to make sure this was the version being used... tried again. Failed again. This was the end of my output:
[javadoc]
D:\Desktop\Downloads\logback-1.1.7.tar\logback-1.1.7\logback-core\src\test\java\ch\qos\logback\core\appender\ConsoleAppenderTest.java:32:
error: package org.junit does not exist [javadoc] import static
org.junit.Assert.assertEquals; [javadoc]_______________________^
[javadoc] javadoc: error - No public or protected classes found to
document. [javadoc] 1 error [javadoc] 100 warnings
BUILD SUCCESSFUL Total time: 2 seconds
It does create the javadoc folder... but this is empty.
NB about the above "package does not exist" error (there were many others): this one is particularly mystifying as I thought Ant somehow included junit by default (NB I am a complete newbie at Ant, just working through "Ant in Action").
But... with the Ant javac task you can set includeAntRuntime="true" ... according to this book that makes Ant's own junit.jar be included. Unfortunately the javadoc task doesn't support this attribute.
later still
My thinking was a bit muddled on this, to be honest: the simplest way I have found to compile javadocs from third-party source jars is just by extracting and then using the command line, typically:
javadoc -d docs -Xmaxwarns 10 -Xmaxerrs 10 -Xdoclint:none -sourcepath
. -subpackages ch.qos.logback.core
... as for javadoc for one's own code this doesn't seem to be a problem in Gradle (I was only glimpsing at Ant, aware that the future is Gradle... and it's not particularly difficult to get to grips with the basics).
NB If you install the Gradle STS plugin for Eclipse, and then create a new project using Gradle STS wizard your build file contains the line
apply plugin: 'eclipse'
... one of the effects of which is that by default the source as well as the executables for all your third-party dependencies will be downloaded under GRADLE_HOME during the build. Pretty good!
Java 8 introduced doclint which will treat certain problems as an error and not produce the documentation. It is possible to disable this by specifying the commandline option -Xdoclint:none.
See also: Turning off doclint in JDK 8 Javadoc
Eg in Ant you would need to do add a additionalparam="-Xdoclint:none" attribute to the javadoc task. A (slightly modified) example from Jaybird:
<target name="javadocs" depends="init,set-driver-sources">
<mkdir dir="${build.docs}"/>
<javadoc destdir="${build.docs}"
author="true"
version="true"
windowtitle="${Name} API"
doctitle="${Name}"
extdirs="${module.thirdparty}"
additionalparam="-Xdoclint:none"
excludepackagenames="${excludedPackages}"
bottom="Copyright © 2001-2015 Jaybird (Firebird JDBC/JCA) team. All rights reserved.">
<arg line="${java.module.arg}"/>
<classpath refid="javac.driver.classpath"/>
<sourcepath>
<pathelement path="${source.java}"/>
<pathelement path="${source.jna-client}"/>
</sourcepath>
<sourcepath refid="source.java.openoffice"/>
<sourcepath refid="source.java.additional"/>
<link href="http://docs.oracle.com/javase/7/docs/api/"/>
</javadoc>
</target>
Compile Errors With Custom Doclet with Java 9 or later
The -Xdoclint:none is an option of the standard doclet which will not work for custom doclets.
If you have a custom doclet and don't care about compilation errors, you can pass the --ignore-source-errors option either to the javadoc command line tool or to javax.tools.DocumentationTool.getTask(...) if you invoke your doclet programmatically.
The --ignore-source-errors option is not documented. Maybe because it might be removed in future. The clean way is to add all required libraries to the classpath (via the -classpath option to actually resolve the compilation errors).
I simplified your build file a bit and built the javadoc successfully. Here's what I did:
Downloaded the logback zip
Expanded the sources jars inside into a src directory
Ran ant 1.9.6 under java 8 with this:
<?xml version="1.0" ?>
<project name="document logback core" default="doc">
<target name="doc">
<mkdir dir="javadoc" />
<javadoc destdir="javadoc" sourcepath="src"
additionalparam="-Xdoclint:none" />
</target>
</project>
It produced a lot of warnings, but created a javadoc directory filled with html.
I removed excludepackagenames and dropped the packagenames element. In any case, packagenames="main.*" prevents the javadoc generation because the only root packages in the jar are ch and org.
I would like to run the GWT compiler from my Ant buildfile with the compiler the following flags:
-compileReport
-XsoycDetailed
-extra
-XfragmentCount <x> (where <x> is an integer that I'll determine over time)
I looked into ant-gwt, which seemed pretty stable, however after a thorough inspection of the documentation and code, it doesn't seem like that plugin can handle these GWT compiler options.
Checking out the GWT command-line tools, I see a code snippet for an Ant task that runs a GWT class called com.google.gwt.dev.Compiler from inside a buildfile:
<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler">
<classpath>
<pathelement location="src"/>
<path refid="project.class.path"/>
</classpath>
<!-- add jvmarg -Xss16M or similar if you see a StackOverflowError -->
<jvmarg value="-Xmx256M"/>
<!-- Additional arguments like -style PRETTY or -logLevel DEBUG -->
<arg value="com.example.foo.Foo"/>
</java>
Is this the correct way to run the GWT compiler from Ant (that ant-gwt probably wraps)? I think the word dev in the package name is throwing me off: is this some smart compiler stub or is it actually the GWT compiler?
If not, then what is the proper way to run GWT from inside of Ant? The only other thing I can think of would be to kick off a Python script from inside the Ant task, and have the Python script call the GWT compiler, but even then, not sure what command-line tool to call from that Python script (maybe webAppCreator?). Thanks in advance.
After downloading GWT from http://code.google.com/p/google-web-toolkit/downloads/list, extract the content from zip folder. Please refer the build scripts "build.xml" provided by GWT team in "sample" folder projects like "Hello" .
or
Example Hello World Ant build.xml
Modify 4th line to add your compiler options - <property name="gwt.args" value="-draftCompile -ea -style pretty -logLevel TRACE -workDir work" />
com.google.gwt.dev.Compiler is the GWT compiler; dev is for developer tools: compiler, DevMode, etc.
BTW, the documentation for the compiler is here.
Based on suggestions from my previous question on programmers.SE, I have split my current project into three subdirectories (swing, common, and android) and created separate Ant scripts in each one. Now I easily created NetBeans projects in the swing and common and was able to set the proper dependencies to compile the Swing app. Then when I go to use classes from the "common" project, I realize that I need to have another Ant script for the Android build process.
So now I have four Ant scripts used to build different parts of my project, along with separate src, test, and other supporting directories for each project. The first problem I encountered is that both NetBeans and the ant script for my "android" project want to use "build.xml" in my "common" project for various build tasks, some of which have name clashes. I decided I want to consolidate all of these projects back into one directory with src, test, etc. subdirectories. The source code is already organized into separate packages for each of the projects and I thought this would make it simpler since I can have a single Ant build script with separate tragets for the Swing and Android builds.
Now the problem I am running into is that when I try to build the "android" project, it wants to build all the Swing classes as well. This brings up a lot of compiler errors. I have even modified the <javac> task in an attempt to exclude the bbct.swing package hierarchy from compileing:
<javac encoding="${java.encoding}"
source="${java.source}" target="${java.target}"
debug="true" extdirs="" includeantruntime="false"
destdir="${out.classes.absolute.dir}"
bootclasspathref="project.target.class.path"
verbose="${verbose}"
classpathref="project.javac.classpath"
fork="${need.javac.fork}"
excludes="${source.dir}/bbct/swing/**"> <------- here
<src path="${source.absolute.dir}" />
<src path="${gen.absolute.dir}" />
<compilerarg line="${java.compilerargs}" />
</javac>
Ant still insists on compiling my classes which use Swing, though.
So I have two questions:
What is the best way to organize this project? Would you suggest one of the two that I have tried or something else entirely?
If I stick with my most recent solution, how do I make javac ignore the Swing-based source files in my project?
Between How to exclude a source package using javac in Ant? and How can I exclude sources in a javac task in ant?, I found a solution using an <exclude> elements, rather than the excludes attribute. Here is the relevant <javac> task:
<javac encoding="${java.encoding}"
source="${java.source}" target="${java.target}"
debug="true" extdirs="" includeantruntime="false"
destdir="${out.classes.absolute.dir}"
bootclasspathref="project.target.class.path"
verbose="${verbose}"
classpathref="project.javac.classpath"
fork="${need.javac.fork}">
<src path="${source.absolute.dir}" />
<exclude name="bbct/swing/**" />
<src path="${gen.absolute.dir}" />
<compilerarg line="${java.compilerargs}" />
</javac>
Addendum:
I suspect that the core of this solution lies in using a path relative to the source attribute or the <src> element. This means that an excludes element should work just as well using a relative path. I haven't tested this yet, though.
I want the javac task to use jars from the system classpath, by which I mean the classpath that is set in the shell's environment before ant is started. That classpath is
CLASSPATH=D:\local\lib\java\*;.;C:\lib\java\*;C:\lib\java\db\*
on my system. I have popular jars there that are used by many projects. The basic snippet I use in the build file is
<target name="build">
<mkdir dir="${obj}" />
<javac srcdir="${src}" destdir="${obj}"
includes="**/*.java"
excludes="**/package-info.java **/deprecated/*.java"
includeAntRuntime="no" debug="true" debuglevel="source,lines"
>
<compilerarg value="-Xlint"/>
</javac>
</target>
That way ant only passes the output directory as classpath.
[javac] '-classpath'
[javac] 'D:\dev\tbull-projects\jsonc\obj'
(jsonc is the project I'm working on, and D:\dev\tbull-projects\jsonc is the working directory.)
I browsed the documentation for a while and came up with two attempts. First one was adding the attribute classpath="${java.class.path}" to the javac tag. That would pass a tremendously long classpath to the compiler, listing every single jar from ant's own lib directory and finally tools.jar from the JDK. Not the classpath that I wanted.
The second shot was setting
<property name="build.sysclasspath" value="first" />
before javac was invoked, and that got me in the right direction. Now these lines were among the output:
dropping D:\dev\tbull-projects\jsonc\D:\local\lib\java\* from path as it doesn't exist
dropping D:\dev\tbull-projects\jsonc\C:\lib\java\* from path as it doesn't exist
dropping D:\dev\tbull-projects\jsonc\C:\lib\java\db\* from path as it doesn't exist
dropping D:\dev\tbull-projects\jsonc\C:\Program Files\Java\jdk1.6.0_18\jre\lib\sunrsasign.jar from path as it doesn't exist
dropping D:\dev\tbull-projects\jsonc\C:\Program Files\Java\jdk1.6.0_18\jre\classes from path as it doesn't exist
Well, you can imagine that these paths really don't exist. I just don't get why ant constructed them this way. It would know how to do path arithmetic on Windows, would it?
Maybe my approach is flawed more fundamentally, so I'll let you know what I'm actually after. So I'm developing this project (a library), which uses another library. The project is gonna be open source, so I want other developers to be able to build it after they have downloaded the dependency library and placed it somewhere in their classpath.
From what I saw in other questions about ant+classpath, it appears that it's a custom fashion to distribute the dependency libs with the source code (so the classpath can be just like ./libs). But I surely don't want to have jars in my git repo. So how could that be done?
Set includeJavaRuntime=true in javac task.
<target name="build">
<mkdir dir="${obj}" />
<javac srcdir="${src}" destdir="${obj}"
includes="**/*.java"
excludes="**/package-info.java **/deprecated/*.java"
includeAntRuntime="no" includeJavaRuntime="true"
debug="true" debuglevel="source,lines">
<compilerarg value="-Xlint"/>
</javac>
</target>
Why wouldn't you set CLASSPATH in Ant? It's perfectly suited to do just that. You're making a mistake if you do anything else. Not only will it work, bu your build.xml will document the requirements as well.
When javac compiles the code , it tries to find the files in rt.jar in a symbol file called ct.sym (which is also present in lib directory). some files are missing in this symbol file.
i have to add a compile option to ignore symbol file and look directly in rt.jar.
so i have used this option -XDignore.symbol.file for ant i put this value in javac tag. it works perfectly if you use eclipse or any other ide .
<compilerarg value="-XDignore.symbol.file"/>
So , whenever you get ClassNotFoundException in using classes from rt.jar , and if the class is still present there , just try to add this argument in java compiler
To reference rt.jar from ant you may use:
<fileset dir="${java.home}/lib" includes="rt.jar"/>
Original details were found here: http://www.javaroots.com/2013/01/javac-error-using-classes-from-rtjar.html
If someone is new to java/ANT world, people who suggest maven are idiots
whatever happened to KISS principle?
OP, instead of using javascript abomination try this
<project default="build">
<property name="src" value="src" />
<property name="obj" value="obj" />
<property name="parent.dir" value="/jakarta-tomcat/common/lib" />
<path id="project.class.path">
<pathelement location="lib/" />
<fileset dir="${parent.dir}" includes="**/*.jar" />
</path>
<target name="build">
<delete dir="${obj}" />
<mkdir dir="${obj}" />
<javac srcdir="${src}" destdir="${obj}" includes="**/*.java" excludes="**/package-info.java **/deprecated/*.java" debug="true" debuglevel="source,lines" classpathref="project.class.path" />
</target>
It's pretty clear the folks behind java, and (or at least), ant, really really really don't want to see $CLASSPATH end up as storage for user installed libraries of the sort that 95% of other mainstream languages (C/C++, perl, python, ruby, etc. etc.) use. So this is a tough paradigm to swallow if you are used to general programming in most other mainstream languages.
The disinclination goes so far that it is obvious ant intentionally strips $CLASSPATH out of the environment, but an easy way around this is to just use a different variable.
<property name="classpath" location="${env.JAVALIBPATH}"/>
This will then work, no fuss, with both <javac> and <java> commands (classpath="${classpath}) which is good, because if you try this instead:
<property name="classpath" location="${env.CLASSPATH}"/>
There is no includeAntRuntime="false" option to <java> which would allow this to work. You simply cannot get $CLASSPATH in and someone has gone to lengths to make sure of it (without, apparently, and yikes, adding in a ponderous javascript hack).
Of course that means you need to use a separate env variable and for your distributed/production version stick to the Java "Sorry no user libs!" paradigm. That's not a big problem if you use a variable name that, if it becomes involved, will almost certainly be undefined on the target system.
Alternatively, there are the Maven Ant Tasks. These will allow you to use Maven's dependency mechanism in a way that, IMO, is cleaner than Ivy. But it's still not a great solution.
Soo... seems I have to answer the question myself. Passing the original classpath to the javac task can be achieved with this:
<!-- load environment into the env property -->
<property environment="env" />
<javac srcdir="${src}" destdir="${obj}"
includes="**/*.java"
excludes="**/package-info.java **/deprecated/*.java"
includeAntRuntime="no" includeJavaRuntime="no"
debug="true" debuglevel="source,lines"
>
<!-- add -classpath option manually -->
<compilerarg value="-classpath" />
<compilerarg value="${env.CLASSPATH}" />
<compilerarg value="-Xlint"/>
</javac>
That does the trick at least so far that the javac task now gets passed the correct classpath. Yet it will still not work, javac now spits these complaints:
[javac] warning: [path] bad path element "D:\local\lib\java\*": no such file or directory
[javac] warning: [path] bad path element "C:\lib\java\*": no such file or directory
[javac] warning: [path] bad path element "C:\lib\java\db\*": no such file or directory
This is a straight lie, these paths do very much exist. I use them all the time, and if I manually craft an equivalent javac invocation at the shell, it works like a charm. I suspect ant's javac doesn't resolve the jar files in those directories. I have to examine that.
UPDATE
It is indeed as I suspected, the wildcard is not resolved to the individual present jar files by the javac task. I managed to do the resolving manually, and now it works as it should. And that resolving was in fact a struggle on its own. So I'll leave the solution here for those poor souls fighting the same stupidity, hopefully before they ask people that have nothing else to do than bullshitting around (yes Anon, talking about you).
Turns out, ant lacks the most basic functionality that you would expect from a build tool. Also turns out that I'm not the first one to notice that. While solutions are rare, there is a very good post about Using JavaScript to make Apache Ant less painful, which really saved my day. Yes, ant can indeed be scripted, which seems not to be widely known, although it is not kept secret. You can safely assume, that Javascript is already available without installing additional libraries if you run ant on Java 6.
Soo... down to business. Here is the thing:
<target name="expand_classpath">
<script language="javascript"><![CDATA[
// the original classpath
var ocp = java.lang.System.getenv("CLASSPATH");
// ... split in parts
var ocp_parts = ocp.split(project.getProperty("path.separator"));
// where our individual jar filenames go,
// together with pure directories from ocp_parts
var expanded_parts = [ ];
for each (var part in ocp_parts) {
if (part.endsWith('*')) {
var dir = part.substring(0, part.length() - 1);
var f = new java.io.File(dir);
// don't know how to construct a java.io.FilenameFilter,
// therefore filter the filenames manually
for each (var file in f.listFiles())
if (file.getPath().endsWith('.jar'))
expanded_parts.push(file.getPath());
} else
expanded_parts.push(part);
}
var expanded = expanded_parts.join(project.getProperty("path.separator"));
project.setProperty("classpath.expanded", expanded);
]]></script>
<!-- <echo message="classpath.expanded = ${classpath.expanded}" /> -->
</target>
<target name="build" depends="expand_classpath">
<mkdir dir="${obj}" />
<javac srcdir="${src}" destdir="${obj}"
classpath="${classpath.expanded}"
includes="**/*.java"
excludes="**/package-info.java **/deprecated/*.java"
includeAntRuntime="no" includeJavaRuntime="no"
debug="true" debuglevel="source,lines"
>
<compilerarg value="-Xlint"/>
<compilerarg value="-Xlint:-fallthrough"/>
</javac>
</target>
I will assume that your "popular" JARs are well-known open-source projects. This means that they're available in the Maven central repository.
While I believe that using Maven is the best answer to this question, you can also hack something using Ant's <get> task. For example, to download the JUnit JAR (may have typos):
<property name="dependency.dir" value="${basedir}/dependencies"/>
<property name="junit.jar" value="junit-4.8.2.jar"/>
<property name="junit.url" value="http://search.maven.org/remotecontent?filepath=junit/junit/4.8.2/${junit.jar}"/>
<target name="download.dependencies">
<mkdir dir="${dependency.dir}/>
<get url="${junit.url}" dest="${dependency.dir}/${junit.jar}"/>
</target>
Of course, if you do this then you'll have to carefully configure your build scripts so that you don't do the download with every run. And you'll increase load on the Maven Central repository.