Run NetBeans project just with ant

Question

I have a sample code that was built with Netbeans.

It has a build.xml file so I downloaded ant and try to run it.

I've got this error message:

...... nbproject\build-impl.xml:76: Platform is not correctly set up

For what I can see, this is fixed by "simply" downloading Netbeans and running the sample from there, but... I don't want to install it to run a 10 files sample.

Is there a workaround to run Netbeans projects with Java? What's the correct .properties file I have to modify?

Solution 1

It is possible to run the NetBeans generated projects straight from Java/ANT, but you may need to manually set some of the properties and/or add paths to jar files.

Unfortunately, NetBeans tends to include taskdef's using their own JAR files and reference properties that are defined only in the /nbproject/private/private.properties files, which usually get set when you first open the NetBeans project or modified as you edit the project in the IDE.

If you inspect the build-impl.xml you should be able to find the property and derive what value needs to be set(OS platform), then either:

• create/set the property in the /nbproject/private.properties
• add that property definition in the parent build.xml
• pass in the commandline when invoking your ant target using -DPlatform=Foo

Personally, I like the structure of the NetBeans generated ANT files and targets, but hate how much custom/proprietary stuff they jam in that makes it hard to run without NetBeans.

For example:

ant -Dplatforms.JDK_1.7.home=/opt/jdk 

Solution 2

I've just successfully built NetBeans project with ant. These were the things I had to do:

• Copy <NetBeans-folder>/java2/ant to a "Netbeanless" machine
• Copy nbproject/project.properties to, say, ant.properties
• Replace every ${} expression in ant.properties with it's value
• Add platform.<platform-name>.home=<path to platform>
• Add libs.CopyLibs.classpath=<path to nb-ant>/extra/org-netbeans-modules-java-j2seproject-copylibtask.jar
• Add other needed classpaths into javac.classpath (e.g. path to servlet-api.jar)
• ant -propertyfile ant.properties

It works, but doesn't make me happy. I would either like to find the way to reuse project.properties, or to automatically translate it to a "resolved" version (step 3). Build could then be automated.

Solution 3

I just faced the same problem. I hope I could get rid of netbeans to go to eclipse and maven, just for that.

But here is a good link to export a ant built project from netbeans into a continuous integration server (or could be into any other IDE too).

Technique is going pretty well. Here is a summary:

1. install netbeans on the CI server (there is an option to do it without gui, use -silent on the netbeans installer)
2. include nbproject in SVN
3. add to ignore list the private folder
4. create your own private folder on CI server
5. make it point to a folder of your CI server (mimicking a private user folder in the account used for CI)
6. copy a real folder from a user to this folder and change every path (replace strings) to point to your netbeans install on your CI server.

And it should work.

Solution 4

I just went through this exercise with my NetBeans 7.0 project. What I was able to do was copy my build.properties file from my .netbeans\7.0 directory on my Windows system and make a server.properties file for my build server. This isn't much of a stretch, since every developer's build.properties may vary, so having another file for the server is to be expected. I then put together a simple server-build.xml file that references this file and does only the basics of init, compile, dist, and clean. I committed these two files to my CVS repository at the top level of my project directory, since they don't conflict with other project files and serve as a reminder in case something needs to be updated. Now I can build my project on my CI server with "ant -f server-build.xml" and everything just works.

My whole init section looks like this, giving my server paths priority, but including the necessary information from the NetBeans project properties.

<target name="init">
    <property file="server.properties"/>
    <property file="nbproject/project.properties"/>
</target>

I also had to do something similar when defining the ant tasks for my nested projects:

<target name="compile">
    <ant antfile="${project.MyProj-common}/build.xml" inheritall="false" target="jar">
        <property location="${build.dir}" name="dist.ear.dir"/>
        <property file="server.properties"/>
        <property file="${project.MyProj-common}/nbproject/project.properties"/>
    </ant>
    ...
</target>

I had to copy the j2ee.platform.classpath from project.properties to my server.properties file to ensure the references to j2ee.server.home resolved as I needed. I didn't expect to have to do this, but the classpath was wrong otherwise, causing the build to fail.

Thanks for the information on this question, as it helped guide me to this solution.

View more solutions

Comments

[OscarRyz]

Well. I know that I have to set manually "some" properties, and the first thing I did was to opent the build-impl.xml file ( the second was google the error message and the third was post here ). Turns out that I don't know is WHAT property to set up nor how. What is the value expected or what should be modified. I appreciate your answer but... mhh wasn't that helpful :(

[OscarRyz]

I guess I have to download the 50 - 120 mb of Netbeans ( I don't know how much it is ) just to run 5 kb of java files :( :( ... Nahhh I would probably compile them directly from the command line.

[Mads Hansen]

Oscar, it is hard to guess at what properties and values need to be set without looking at the build-impl.xml. Could you post it?

[Snicolas]

you'r missing the point, the question is how to run the build file with ant without netbeans (for instance an continuous integration server)

[Leif Gruenwoldt]

@Snicolas that's precisely what I do (using Jenkins). Perhaps your ant files generated by netbeans have some interesting dependencies on netbeans itself. That's not the case for me though.

[Snicolas]

we have a lot of dependencies due to our use of the mobility platform. so we are in case number 2 of the doc I pointed out and you, lucky you, are in case 1.

[Petter Friberg]

A link to a solution is welcome, but please ensure your answer is useful without it: add context around the link so your fellow users will have some idea what it is and why it’s there, then quote the most relevant part of the page you're linking to in case the target page is unavailable. Answers that are little more than a link may be deleted.