Separation of Ant and NetBeans
I blogged the other day about the problems I encountered trying to put NetBeans project directories under version control. One problem was that NetBeans uses absolute paths to determine project dependencies and AccuRev, using exlusive locking, makes all files read only. I tried to solve these problems by setting up all project dependencies ahead of time. Apparently, NetBeans needs the ability to modify its project files, regardless of whether it actually modifies those files. So, back to square one.
In the end, the only solution was to completely separate out the Ant build scripts from the NetBeans project folders. This meant recreating build scripts across 7 projects. Fun stuff. Unfortunately, this lost me a day. In the end though the result was a much better project base from which to code and the complete separation of IDE from build script. This means that if developers want to use Eclipse, JEdit, IDEA, JBuilder, or NetBeans to work on the project, they can.
I definitely think this is the better way to go. I am not sure that I feel comfortable dictating what IDE developers should be using. I definitely think that the your build process should be completely independent of the app you use to create your software. This has other benefits as well. We also have build scripts that are now a lot easier to understand and a lot easier to modify and maintain. Yes, a lot of the magic that NetBeans provides is gone, but at least we understand every aspect of the build process and can modify or change any part of it. The NetBeans build scripts have to be among some of the most confusing scripts I have ever seen (although that may not be saying too much).
We also have a process now that is guaranteed to work outside of NetBeans. We can now take our code base and put it under continous integration using CruiseControl without any problems. And if something goes wrong, we can easily and quickly fix the problem.
In the end I agree with the statement that putting the NetBeans project folders under version control is a bad thing. Yes it takes a little longer to get a new developer up and running, but on the other hand the advantages out weigh that one negative.
I actually stumbled upon your previous entry as I was trying to solve this very problem myself. Being a newcomer to Netbeans, Ant, and Java Web Development (Coming from a PHP background) this was proving failry difficult.
We thankfully only have a small group of new developers working on this project, so I have no problem mandating Netbeans if nothing more than as a learning tool. In any event I found the easist solution in our case was to ensure the jars we needed were within the project. At that point the paths in the build scripts were relative to project root. Consequently, we’ve managed to build the site on another system without any modifications to the build scripts.
Perhaps at some point once we’re more comfortable with Ant we’ll be able to migrate over to the external build.xml, which arguably sounds liek a better solution.
So ultimately, just wanted to say it was good following along to see how someboddy else ultimately solved the problem…and to say that I’m surprised there’s no easily found “best practice guide” regarding such a seemingly unavoidable hurdle for newcomers and experienced developers alike.
I also include the jar files inside of the project directory. In my opinion, this is a best practice. Every Java project should contain a /lib directory that holds all the jar files for that project. I really don’t understand the reasoning behind setting up libraries in NetBeans for this or trying to get developers to add the necessary jars to some classpath environment variable.
What made my “project” more complex was that I was trying to orchestrate all of this across 7 projects. And most projects were dependent on at least one other project, sometime upwards of 3 projects.
I am glad to hear you liked the posts and found them helpful. I also enjoy finding a post somewhere where another developer is talking about a problem that I am struggling with. At the very least it afirms that you are not the only one.