I have setup an Ant runtime property in Preferences -> Ant -> Runtime -> Properties. It is named build.tools and has value ${workspace_loc:/ivd-build}
I have a build.xml with the following
<project name="myProject">
<target name="test">
<echo>"${build.tools}"</echo>
</target>
</project>
If I choose "Run in same JRE as workspace" I get (1)
[echo] "C:\Users\myuser\ws\seqflow-ivd\trunk\ivd-build"
If I choose "Separate JRE" I get (2)
[echo] "${workspace_loc:/ivd-build}"
So in the latter case the property is not resolved properly.
I would prefer the behavior of (1) but running in a separate JRE and I get this behavior on another machine. So I think it is some kind of setting somewhere, I just cannot find it.
Any suggestions?
Windows 7
Issue both seen with eclipse mars and neon.
Java 1.8u66
I have found the cause of the problem.
Besides the build.tools property I also have another property (other.tools) which is rarely used. The cases where build.tools could not be resolved was caused by the fact that other.tools could not be resolved. When I corrected or removed other.tools, then build.tools resolved correctly (as (1)).
This means that if you want to use the "Separate JRE" setting for your Ant job, you need to ensure that all properties can be resolved even if you do not use them from your Ant script.
Related
I would like to specify a specific Eclipse VM argument to all of the JUnit tests I run from Eclipse i.e.
-Dlog4j.configuration=log4j-dev.properties
This is because I want a specific log4j configuration file to be picked up by all my JUnit tests instead of the default log4j.properties file.
As of now I have to specify the above VM argument (in Run Configurations -> Arguments -> VM arguments) for each of my JUnit tests making it cumbersome because I have many tests.
You do not need to give the JVM a different property name. The logging code searches for the log4j.properties file using the classpath. So all you need to do is ensure that your test log4j.properties file is in a location that it will find before the release file.
I use Maven, which lays out files in directories to make that easy. My release log4j.properties goes in the directory src/main/resources. My test version goes in src/test/resources. The Eclipse build path (classpath) is set up to search src/test/resources before src/main/resources, so your unit tests use the test file. The JAR (or WAR) build instructions use the files from src/main/resources.
Eclipse gives you the ability to define default VM arguments that are applied to any launch which uses that VM. You could use that in your situation by defining a JRE configuration with the VM argument you want for log4j and then setting up all JUnit launches to use that JRE definition.
In Preferences, Java > Installed JREs and use the Add... button to define a JRE. In the JRE Definition dialog there is a field for Default VM arguments. Give this JRE definition a useful name such as "JDK 7 for JUnit" so that you can easily identify it.
Then in your JUnit launch(es), on the JRE tab, select the JRE definition you created.
This is for running files as Ant builds in Eclipse. I have my Ant set up, now I need to install the Maven Ant Tasks. I followed the instructions on the Maven website: downloaded the JAR and put it in my .ant/lib, and double checked that my environment variables were correct. When I try to run as an Ant build in Eclipse, however, it gives me this error:
No types or tasks have been defined in this namespace yet
This appears to be an antlib declaration.
Action: Check that the implementing library exists in one of:
-C:\Users\arempel\Documents\eclipse\eclipse\plugins\org.apache.ant_1.8.3.v201301120609\lib
-C:\Users\arempel\.ant\lib
-a directory added on the command line with the -lib argument
Now I know there are a ton of resolved questions like this that have been answered, but I've tried all of the solutions I could find to no avail. I've tried using -lib in prompt, tried setting the classpath variable, tried playing around with my environment variables, but I'm still screwing up somehow.
Does anyone know what I'm doing wrong, what I'm missing?
When running Ant within Eclipse, it is Eclipse itself which is managing the classpath of Ant.
Look into the global preferences of Eclipse, and then into the Ant/Runtime panel. The first tab, 'Classpath' is the one you want to modify. Click on the 'Global Entries' and then hit the button 'Add JARs...'. Select the jar of the Maven Ant Tasks and you're done.
I am trying to get ANT to create an HTML report of a JUNIT test in Eclipse but after I created the ANT build I get the following errors when I run it:
[junitreport] Processing C:\Documents and Settings\Administrator\workspace\Home\junit\TESTS-TestSuites.xml to C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\null785926900
[junitreport] Loading stylesheet jar:file:/C:/ANT/apache-ant-1.8.3/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
[junitreport] : Error! The first argument to the non-static Java function 'replace' is not a valid object reference.
[junitreport] : Error! Cannot convert data-type 'void' to 'reference'.
[junitreport] : Fatal Error! Could not compile stylesheet
[junitreport] Failed to process C:\Documents and Settings\Administrator\workspace\Home\junit\TESTS-TestSuites.xml
What do I need to do to fix this?
Here are the sections of my Build.xml I am trying to run:
<target name="Home">
<mkdir dir="${junit.output.dir}"/>
<junit fork="yes" printsummary="withOutAndErr">
<formatter type="xml"/>
<test name="Home" todir="${junit.output.dir}"/>
<classpath refid="Home.classpath"/>
</junit>
</target>
<target name="junitreport">
<junitreport todir="${junit.output.dir}">
<fileset dir="${junit.output.dir}">
<include name="TEST-*.xml"/>
</fileset>
<report format="frames" todir="${junit.output.dir}"/>
</junitreport>
</target>
When I got this error I had to right click on my build.xml file in Eclipse, choose the "Run as Ant build..." option (3rd one in the menu) then click the JRE tab and select the "Run in the same JRE as the workspace" option and then proceeded to run the script. For some reason this fixed the problem. I honestly don't know why.
The Eclipse Bug is clearly documented Bug 384757. The analysis suggests that Oracle introduced the bug. I need Java version 7 but JunitReport needs Java version 5 and early versions of Java version 6. The obvious way is to add the "bootclasspath" argument to the Ant junitreport task while the Java problem is fixed by Oracle in a future release. Unfortunately Ant task junitreport does not support the bootclasspath option. Is this something the people supporting Ant could do?
I met this situation while running my java program on Ubuntu 12.04 with *java 1.7.0_51* on Eclipse SDK Juno. I take Bhagyaraj's suggestion which is using apache-ant-1.9.2 instead.
(p.s. The default ant version of Eclipse Juno is *org.apache.ant_1.8.3*, and I use apache-ant-1.9.3)
You may following my steps to setup.
Download apache-ant-1.9.3-bin.zip and extract to a place where you want.
Open your eclipse and choose Window --> Preferences
You can see the Preferences window. On the left hand side please choose ant --> runtime
Now focus on right hand-site of the window. Make sure you are now on Classpath tab and choose Ant Home Entries(Default).The buttons on the right which is Ant Home... is now click-able.
No doubt, click on Ant Home... button and choose the folder where your ant-1.9.3 is. In this step, if you choose wrong folder, Eclipse may show the error message something like Specified Ant home does not contain a "lib" directory. If you choose the right directory, Ant Home Entries(Default) will become **Ant Home Entries()
Don't forget to click apply.
After change those, while you right click on build.xml file and choose Run --> 1 Ant Build, the error message won't show because your ant is now 1.9.3.
I also download apache-ant-1.8.4 to run my build file, but the error can't be solved.
I used the jdk1.6.45 and latest apache-ant-1.9.2-bin\
Problem solved.
As per note on MikeBach
This is bug#,
please read:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=384757
Fixed in Ant.
Regards,
Bhagyaraj
If you are using Eclipse/JUnit report with JDK 1.7, please use JDK 1.6. There is a bug in JDK 1.7 with Eclipse/JUnit report similar to what you describe. This may be a similar report: https://netbeans.org/bugzilla/show_bug.cgi?id=201022
I've tried using a few different JRE/JDK settings (all 1.6 and 1.7) with various problems (this or lack of access to XSL file in jar) for each.
It's not a perfect solution obviously but I don't seem to run into these issues if the JUnit report is "raw" in the buildfile -- not wrapped in a target.
Poor workaround obviously in that targets are an important aspect of Ant but sometimes for reporting build targets/dependencies aren't so mission critical. It's not so much of an issue for me yet because I'm running these reports in kindof a one-off fashion rather than as part of a build.
The Bug was introduced in Java 7u5 according to this comment.
Another comment explains how to workaround it, changing the bootclasspath. (DISCLAIMER: I didn't try and test this.)
This solution, however, worked fine for me:
Download ant-1.9.4
Eclipse>>Preferences>>Ant>>Runtime>>AntHomeEntries
Remove all 1.8.x classpath entries
Add all libs from 1.9.4 instead
According to Ant Changes, this has been fixed since 1.9.1
I am currently using PDE build in headless mode to build my OSGI Bundle project.
The PDE Antrunner task uses an Eclipse installation and I am just pointing it to my local Eclipse installation.
unfortunatelly my eclipse installation is about 260MB big, but I assume that a PDE build does NOT require all of those plugins in a standard eclipse installation.
Does anyone now what is the minimum list of plugins I need for doing a headless PDE build?
All of my dependencies I actually have in a custom target platform folder, so I guess the only thing I need from my eclipse installation are the dependencies which PDE build actually needs. But what are those?
Can I shrink my installation to a very minimum?
My goal is to also check-in this "build-eclipse" folder into my project's SVN so that when you check it out, you have everything you need to start a full build, without touching any build.properties. But I don't want to commit 266MB of eclipse if I maybe need only 20MB of it.
Thanks
Christoph
I finally needed to do this myself today (to address a problem I was having where directories with spaces in their names weren't being included in the bundle PDE Build produced). I eventually got something that could build my collection of (Java-based) plug-ins. I don't know whether it's "minimal", but it's Java PDE Build-focused and much smaller than a full Eclipse IDE install.
I took rough notes; there could be a few omissions or superfluous steps here, but in the main it should guide.
I:
Fired up a recent Eclipse IDE (in my case, the 3.5 instance I use at the moment).
Used a scratch workspace, so changes to the target platform wouldn’t mess up my “real” projects.
Made sure the target platform was set to the place I wanted to draw my PDE builder's plug-ins from (in my case, just my running Eclipse). (Window | Preferences... | Plug-in Development | Target Platform)
Created a new empty project.
Created a new Product Configuration within that project (using the "basic settings").
On the new product configuration's "Overview" page, unchecked “The product includes native launcher artifacts.”
On Dependencies, specified the following plug-ins as constituting the product:
org.eclipse.pde.build
org.apache.ant
org.eclipse.jdt.core
Checked “Include optional dependencies . . .”
Clicked “Add Required Plug-ins”.
Right-clicked product definition in Package Explorer and picked “Export… | Eclipse product”.
Told it where I wanted my PDE builder instance to go.
Unchecked “Synchronize before exporting”.
Unchecked “Generate metadata repository”.
Clicked "Finish".
Now I can (continue to) launch a PDE Build from my normal Ant build by invoking a macro like the following (is there a better way?):
<macrodef name="build-a-product">
<attribute name="config-dir"/>
<sequential>
<property name="product-build-file" value="${pde-builder-path}\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml" />
<java jar="${pde-builder-path}\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar" fork="yes" failonerror="yes" >
<arg value="-application" />
<arg value="org.eclipse.ant.core.antRunner" />
<arg value="-buildfile" />
<arg value="${product-build-file}" />
<arg value="-Dbuilder=#{config-dir}" />
<arg value="-Dbasedir=${basedir}" />
</java>
</sequential>
</macrodef>
I can't directly answer your question, but I can wave my hands around a little bit, some of which might help you find a real answer.
In my PDE experience I have found it very useful to distinguish:
The Eclipse IDE I was using for interactive editing
The "Eclipse" installation I was using for headless PDE builds
The "target platform" (set of plug-ins/features/etc. the thing I'm building depends on)
It sounds like these are clear, separate concepts in your head as well: you have already isolated the "target platform" and are looking to isolate your interactive Eclipse from your PDE builder.
You could try creating a new (blank) workspace in your interactive Eclipse (just to be sure you're looking at it, not at your target platform), opening the "Plug-ins" view, right-clicking a promising-looking plug-in like org.eclipse.pde.build, and choosing "Open Dependencies". The "Flat Layout" might be a more useful way to view the results than the hierarchical, though in my Eclipse I don't seem to be able to copy and paste this list.
In my case this didn't mention anything in the JDT which makes me think that actually trying to build a Java-based plug-in would fail, but hopefully that would provide another lead (e.g. "can't find org.eclipse.jdt", or something).
It seems like there "ought" to be a way to use the Software Updates mechanism, Target Platform, or Buckminster to just name one plug-in and have all the others fall into place. Maybe you could use the Target Platform, select the plug-in you need, hit the button to select required ones, then somehow export a "build" that would effectively just collect all those plug-ins?
I confess that we just checked in an interactive Eclipse some time ago and use it as our PDE builder. We don't use it interactively, and we do maintain a separate target platform as well. Our PDE builder is clearly not minimal, but could also perhaps stand to be, so I hope you'll update this space with your discoveries.
I have added all common targets like (init, clean, getivy, etc) in ./common/common.xml and added:
<import file="${basedir}/common/common.xml"/>
in build.xml.
When I build the project, its working fine. But, When I open build.xml in Eclipse IDE, I see some "Red" marks underneath targets which have a dependency targets that are defined in common.xml. And when I do mouse over those Red marked targets, I see a message saying that:
Target init does not exist in this project.
To clarify, the common folder is added through svn:externals. Does this need extra configurations in Eclipse?
I have Eclipse Indigo Service Release 1 Build id: 20110916-0149 with ant 1.8.2 and the described problem with import seems to be fixed as Steve already mentioned. But the problem still exists for include and no answer seems to solve it for me. I searched the bugtracker shortly but don't have the time to be sure and test in the latest eclipse version and post a bug in the bugtracker.
Edit:
I had the problem with import again after refactoring the folder structure in the project and moving the buildfile. Although I started "Validate" on the project, the validation cached the old location and did'nt realize the move. I had to close the editor and the warning disappeared.
If your build.xml, and the common directory are at the same directory level then just try
<import file="common/common.xml" />
This works for me fine.
Use the include path ${basedir}/common/common.xml because . is probably the directory in which Eclipse is installed.
I found a post online here where someone found a workaround. You just need to make the file import not the first line in the ant build file. If you put it after a property declaration for instance the error goes away. This worked fine for me and eclipse is happy now.
The specific problem we had seemed to be because we
were importing common build.xml files into our project-specific build files, but the import was having problems when it is the first line in our
project-specific build file.
However, if I put a property task before the import, it seems to work fine. I am guessing this much force some initialization that wasn't occurring with only the <import>. I have no idea why this same issue doesn't happen in either command line with Ant 1.8, or with Eclipse using Ant 1.7.