Comments on: Exploring Ant Build File Changes for Java Web Projects in NetBeans 6.1

By: phejl

phejl — Mon, 31 Mar 2008 10:02:04 +0000

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.

By: adam

adam — Sat, 29 Mar 2008 13:09:29 +0000

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 ? :

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= (where you put the property “j2ee.platform.classpath” in a .properties file)
or ant -Dj2ee.platform.classpath= (where no properties file is used)

NetBeans 6.0 seemed to work fine without it. Just some thoughts.

By: phejl

phejl — Thu, 27 Mar 2008 09:33:37 +0000

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)