Published by Adam Myatt on 26 Mar 2008 at 08:55 pm
Exploring Ant Build File Changes for Java Web Projects in NetBeans 6.1
While working with a Java Web Application in NetBeans, I noticed some slight changes in the Ant build file for my project between NetBeans 6.0 and 6.1. This article explores some of the problems these changes caused to help out anyone with similar issues.
I started with a Java Web Application that was created in NetBeans 6.0.1. After adding some JSP files and several Java source files, I committed everything in the project to my CVS repository.
For some of my projects, I utilize the Hudson continuous integration build server. Using a standard deployment of Hudson, I configured the project to poll the SCM every 60 minutes, check out the code from CVS (if changes had been committed), and trigger the NetBeans project’s Ant build file (calling several specific targets like compile, dist, and so on.
My builds have been functioning correctly for several weeks using this standard setup. I recently opened one of those projects in NetBeans 6.1 Beta and have been thoroughly enjoying the new features (faster startup, better JSP parsing in the Source Editor). After adding some JAR files as libraries and making several configuration changes, I committed the entire project (particularly the build-related files in the nbproject directory).
Suddenly, my build for that project started failing. The console output reported by Hudson was :
-init-check:
BUILD FAILED
D:/projects/hudson-server/data/jobs/MyWebProjectl/workspace/nbproject/build-impl.xml:149: The Java EE server classpath is not correctly set up. Your active server type is Tomcat55. Either open the project in the IDE and assign the server or setup the server classpath manually. For example like this:
ant -Duser.properties.file=<path_to_property_file> (where you put the property “j2ee.platform.classpath” in a .properties file)
or ant -Dj2ee.platform.classpath=<server_classpath> (where no properties file is used)Total time: 2 seconds
finished: FAILURE
I undid the configuration changes one by one, but the build failed regardless of what I reset. Apparently the property j2ee.platform.classpath is now required. I did a DIFF on the nbproject/build-impl.xml file and discovered several changes.
The -init-check target includes property checks including this new one :
<fail unless=”j2ee.platform.classpath”>
The Java EE server classpath is not correctly set up. Your active server type is ${j2ee.server.type}.
Either open the project in the IDE and assign the server or setup the server classpath manually.
For example like this:
ant -Duser.properties.file=<path_to_property_file> (where you put the property “j2ee.platform.classpath” in a .properties file)
or ant -Dj2ee.platform.classpath=<server_classpath> (where no properties file is used)
</fail>
I hadn’t really taken notice of this property in the build file before, but it is referenced in a number of other targets such as:
-init-macrodef-javac,
-init-macrodef-junit,
-init-macrodef-java,
-init-macrodef-nbjpda,
-init-macrodef-debug,
compile-jsps,
-do-compile-single-jsp,
connect-debugger,
javadoc-build,
-do-compile-test,
-do-compile-test-single
Not being able to find a definition of the property anywhere in the build file, I looked through the project’s project.properties file among the list of defined properties. The property j2ee.platform.classpath was not defined. Thus, I’m assuming this is passed into the build file dynamically by NetBeans?
In general I wouldn’t care, but when running the build file via Ant inside Hudson, the property j2ee.platform.classpath is never passed in. Hudson DOES allow you to pass properties and values to the build file, so I suppose I can specify the value manually, but I would like to keep the number of per project customizations to a minimum to maintain a low level of maintenance.
Unless this causes some problem with the project properties in the build system, I would suggest the following fix for anyone who is experiencing a similar issue. Open your project’s project.properties file. Navigate to the section that contains these properties:
j2ee.platform=1.4
j2ee.server.type=Tomcat55
Add a new line that specifies a blank j2ee.platform.classpath property such as this:
j2ee.platform=1.4
j2ee.platform.classpath=
j2ee.server.type=Tomcat55
Now, if the project.properties file is committed to CVS, a Hudson build can be triggered, and the FAIL check in the build-impl.xml file will pass. I ran some quick tests with the project, and everything with the project inside NetBeans still seems to work fine. I would propose to the NetBeans team to have the j2ee.platform.classpath property automatically added to the project.properties file.
3 Responses to “Exploring Ant Build File Changes for Java Web Projects in NetBeans 6.1”
Leave a Reply
You must be logged in to post a comment.
phejl on 27 Mar 2008 at 4:33 am #
Well, you are probably supplying the platform jars on javac classpath, I suppose (otherwise the project wouldn’t compile complaining about missing javax.servlet and similar).
j2ee.platform.properties is the value provided by the server, so it is placed in private.properties. It is bit dubious to place it to project.properties. You have several options.
1) When calling ant use ant -Dj2ee.platform.classpath=. This is much cleaner I would say.
2) You are using dedicated library folder
a) new project - just select “Use dedicated library for server JAR files” in second step
b) existing project - create server library and place your j2ee platform jars there, add the library to project (better than placing platform jars to javac classpath)
adam on 29 Mar 2008 at 8:09 am #
Well, if the j2ee.platform.properties property IS in private.properties, this still makes using NetBeans projects in a continuous integration server more difficult. From everything I understand, the files in the nbproject/private directory are never supposed to be checked into your source code repository. If you do a checkout of that code into a separate location or into a continuous integration server like Hudson, the j2ee.platform.classpath property is now “lost” because it was in private.properties.
I completely understand that I CAN pass it as argument to Ant in each project’s configuration in Hudson, but the question is WHY should I have to. If I have hundreds of Java projects configured in my build server, I then have to edit the configuration for each one and pass the property to ant statically. this can turn into a maintenance nightmare, especially if other required properties are added in later versions of NetBeans.
Would the solution here be to perhaps remove the FAIL check for the j2ee.platform.classpath property that was added in NetBeans 6.1 ? :
<fail unless=”j2ee.platform.classpath”> (where you put the property “j2ee.platform.classpath” in a .properties file) (where no properties file is used)
The Java EE server classpath is not correctly set up. Your active server type is ${j2ee.server.type}.
Either open the project in the IDE and assign the server or setup the server classpath manually.
For example like this:
ant -Duser.properties.file=
or ant -Dj2ee.platform.classpath=
</fail>
NetBeans 6.0 seemed to work fine without it. Just some thoughts.
phejl on 31 Mar 2008 at 5:02 am #
You are right about private.properties complications. But this is the exact reason why the server library was introduced.
Right now you are providing some j2ee jars on javac classpath - this is non-standard and you rely on implementation details of project infrastructure (What jars will be preferred for compilation in the IDE? Yours or jars provided by the registered server?). So now your project structure IS non-standard, adapted to continuous build system.
For new project you can check “Use dedicated library for server JAR files” in second step and this is exactly the thing you need. When this option is used, no change to project.properties and no special configuration of javac classpath is needed. It will work for cont. build system, in the command line and in the IDE as well.
If you have the existing project, just create new global library of “Server Library” type and put the j2ee jars there (jars you are now providing for continuous build, but which doesn’t make sense for IDE usage).
After this change it should work out-of-box.