I need to easily test my annotation processors, so I prepared Ant script to launch javac with all the necessary options set. Unfortuantely, as stated in another thread:
By default the task compares the timestamps of .java and
corresponding .class files, and only tells the Java compiler to
recompile source files that are newer than their corresponding object
files, or that don't have an object file at all.
It's great for me most of the times but not when I need to test my annotation processor for which I need javac to be launched each time, no matter if corresponding .class file already exist.
Is there any way to disable this ant default behaviour? I looked through all options of javac task but found nothing. Is there any solution other then cleaning output directory?
Based on your quote if you delete the .class files, the compiler will be forced to recompile the .java file
Related
I need to create a war file through ant build without a manifest file. I want the war to me created without the manifest file.
I am using tag in build.xml to create the war.
you can use <zip/> task with .war extension for destfile attribute to achieve the same result as the <war/> task (without manifest.mf).
<zip destfile="..\...\WarFile.war"basedir="..\basedir" update="true"/>
in case WarFile.war already exists, although you've written I need to create a war file , the attribute update="true" will be of use (by only updating and not overwriting the file).
All a war file is is a zip file in a specific format. That is libraries go in a particular place, class files go elsewhere, etc. The <war> task has sub-entities like <classes/> and <lib> that make configuring a war file correctly without knowing exactly where everything has to go.
However, you can correctly format the war yourself, and use <zip/>.
Why don't you want a manifest file? A manifest, if you don't specify anything, will contain nothing but the Java version used for the build, and the Ant version and won't affect the execution of your war at all.
What you can do is put useful information into the manifest. For example, we use Jenkins for our builds, and we put in the Jenkins project name and the build number which helps us understand what was included in the war.
There's no reason not to use a manifest file. And, a manifest file can contain useful information (which is accessible to the Java program too).
In Sonar documentation there are two properties options, the sonar.tests and sonar.binaries.
# path to test source directories (optional)
sonar.tests=testDir1,testDir2
# path to project binaries (optional), for example directory of Java bytecode
sonar.binaries=binDir
Questions:
If sonar.tests and sonar.binaries are added to my Ant target, how do they show up in Sonar? What would be different in Sonar if I did/did not set these properties?
Should sonar.binaries contain both source binaries and test binaries, or only source?
Can .jar files be given to both properties instead of path to actual .class files and/or .java files?
Answers:
If you do not set those 2 properties, you won't have test results ("sonar.tests") nor violations detected by Findbugs or bytecode-based tools ("sonar.binaries").
"sonar.binaries" should contain only compiled sources, not tests
No. Only "sonar.libraries" can (and actually must) point to JAR files.
i have never seen this strange -
i am into maintenance project where i got a build.xml and i never installed ant. ant is bundled into the project and so i use -
ant deploy_project.
but when i look at build.xml i cannot find any target named "deploy_project".
can anyone help me how the "deploy_project" target gets executed without this target being present in build.xml?
I suspect that since i didn't install ant by myself and is bundled with the project, any configuration of ant may have been overridden...but how to find it is where i am stuck, can any one pls help me?
(I am sure the target isn't present in build.xml).
thanks much in advance.
Run the following command:
$ ant -p
This will usually print out all the targets in your build.xml. Or at least the ones with descriptions.
Also look for <import file="..."> statements in your build.xml. These allow you to import other Ant build files which can contain targets that aren't in your build.xml. I suspect, if you do a search for the string deploy_project in your build.xml, and you can't find a target by that name, you have an import statement somewhere in your build.xml, so search for <import.
If you are SURE that the target is not present, and you are not specifying the build file with -f option, then only 1 explanation I can think of -
your ANT_HOME is somewhere else and there will be another build.xml there.
(Quickest way to check is find it - SET for Windows echo $PATH for Unix), find the value for ANT_HOME and in the same directory, a build.xml will be present with your *INVISIBLE* target
If you have searched the C: drive and still cannot find any build.xml, then the bundled ANT you have might be a customized one or an ANT wrapper. Meaning have a .bat file called ant.bat which accepts deploy_project as an argument and then maps it to another task using variable substitution. So look for a batch file ant.bat or anything titled ant.
Problem description:
Consider the following command line call (called for Delphi 2009 compiler):
dcc32.exe --no-config --peflags:1 Project.dpr
Will this call use the Project.dproj or Project.dof configuration files ?
If yes, will the command line options take precedence over the configuration file(s) ?
If not, where the build configuration will be taken from if the dcc32.cfg file is not loaded in this case ?
Problem background:
I know that MSBuild should be used since Delphi 2007 but in fact, it's the reason why I'm asking. I found that InnoSetup uses this batch file for building its projects and I have serious problems to link the JEDI JVCL library to it (it's a pure nightmare). So I'd like to configure the project settings to use MSBuild, but I'm not sure what build settings are used in the above command line call.
--no-config means that dcc32.cfg is not loaded, neither from the compiler executable directory, nor from the project directory.
The rules for applying options specified in .dproj and .dof files are not affected. Those options are applied and any command line options take precedence.
I'm having problems building my project, using an Ant script, from the command prompt using Ant itself. It can't find a certain import for a particular Java file in my project (which has nearly 5,000 source files as it is). The import is included in a .jar package whose location I have set in the Ant file itself. (As a pathelement, along with other needed JARs that either are fine, or haven't tried to been used when the crash occurs). The crash happens with javac, with the simple message of "import etc.ect.* cannot be found at line etc" Oddly enough, I can build the project just fine from the Ant file using an IDE like Eclipse. Any ideas what could be wrong? Thanks!
Wow, the solution was completely unrelated. It was a dumb fault in the java code where the class was trying to import .* from a directory that only had folders in it. For some reason, Eclipse didn't seem to mind, but javac did!
Eclipse's root classloader contains a lot of classes, when you run ant from console there's much less.
Just tell javac task to use the required .jar, and you'll be fine.
You should post the stack trace, does it say "import required by ..."? ( I forget the exact text). Likely there's a jar that's available in your eclipse environment that is not included in your ant script. Look in the stack trace for the missing class to identify the jar that's not being included in your build.