This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | copylibstask should be deleted and standard ant tasks used instead | ||
---|---|---|---|
Product: | java | Reporter: | pilbender <pilbender> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | REOPENED --- | ||
Severity: | blocker | CC: | dstrupl, mmirilovic, pjiricka |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
pilbender
2009-01-28 20:34:56 UTC
For use in Hudson etc., you should go to the Libraries panel of the Properties dialog and click the button the make the project sharable. This ensures that all libraries are physically contained in the project. Unfortunately the custom task is necessary (as far as we know) for the particular kind of copying which is done, because Ant "scripting" is not expressive enough. (Obviously a hand-written script can use a series of <copy> statements, but an IDE-maintained script must work with whatever classpath has been set up in project.properties using a predetermined script fragment.) I have not looked at this recently so there might now be sufficiently powerful changes to standard tasks in Ant 1.7.1 to get the same effect, probably making heavy use of <pathconvert> and resource collection tricks. Writing the logic in Java is certainly much easier. (Ant does have <script> but does not guarantee that any particular scripting engine will actually be available, so this is useless for our purposes.) BTW from looking at the build script, it seems that if libs.CopyLibs.classpath is not set, this extra functionality will be skipped anyway. Try -v and grep for the property 'manifest.available+main.class+mkdist.available'. It's a shame this has been marked Resolved Invalid. I also fae this problem and don't like many of the different hacks suggested. This issue is especially annoying to those of us to used NetBeans 6.1 + Ant + Hudson for a large number of projects. Any hope this can be addressed in a NB 6.5 patch or NB 7? I have to agree, it's definitely a shame that this has been marked RESOLVED INVALID. This is a thorn in netbean's side (and mine!). I was asked by a Netbeans developer to articulate my expectations for the Ant build scripts produced by Netbeans. I haven't posted another comment because I've had to go through some extreme efforts to work around the change from Netbeans 6.1 to 6.5. Since this is marked invalid now and I am the lead developer and architect on our product, I had to do the responsible thing and move on to a less coupled tool, namely Maven 2. I hate writing Ant build scripts because it's labor intensive on a fast moving project. The Netbeans produced Ant build script was a great thing because it enabled us to get more done with almost no build maintenance. But with the change regarding the copylibstask, I decided to return to Maven 2. I used it in the past when it was new. I have also used Maven 1 and both seemed to give me more headaches than help at that time. This was 2 or 3 years ago. The landscape as changed. Maven 2 is a really nice tool now and Netbeans 6.5 has pretty good integration with it. It also has even better integration with Eclipse and some developers on our team prefer development on Eclipse. I still prefer Netbeans. The fact that builds and tests can be run from the command line or within any IDE in the same way was a real tipping point for me deciding to switch to it. I don't wish to force my tool preferences on my team. I've never operated that way. I prefer Netbeans on Linux, others prefer Eclipse on Windows. There were other features in Maven 2 such as transitive dependencies and reporting that made some other aspects of build and project management very simple. We also have the requirement of having to support slightly differnt builds for differnt platforms. Maven handles this nicely. In the end, I wanted something that made my life and my teams' life easier because we want to spend our time building a product, not baby sitting build managment. So those are my expectations and Maven 2 meets those. I would advise anyone with similar circumstances to buy a good book on Maven 2 such as "Maven, The Definitive Guide" from O'Reilly and study Maven until it's easy to deal with. In 2 weeks to a month you can pretty much learn and exploit anything you'd ever want to do with Maven. And for those who might be wondering, Maven 2 can pull from Subversion on it's own and run a build. It works in Cruise Control, Hudson, anything you can think of. Netbeans also supports deployment to Glassfish right within the IDE. I don't believe there has been any loss in functionality or convenience by switching to Maven. I can hit the same IDE buttons and menu options and I still get the same great functionality I had using Netbeans generated Ant builds. Richard Scott Smith (pilbender) I agree: this is a serious problem with Netbeans, it was wrong to mark this bug as "invalid." The whole way this task was implemented has always made it painful to deal with for outside builds. It's opaque and tricky. Digging through the ant build to figure out where it all gets defined is painful. Removing the task is not easy, and looks like it will create a mess no matter how it's done. The "value" of this task is dubious in the first place. I'd rather use a command-line script that sets the classpath in the first place. Being able to say "java -jar" is cute, but in the end, not that useful to me. This one "feature" is wasting hours of my time, because I need to generate a build that will work on another system. The failure to provide a way to remove this task so I can do that is a show stopper, and may well force me to stop using netbeans, unfortunately. Making this an ENH (and changed the description). A very good suggestion was already posted here: give Maven projects a try. In NetBeans 6.7 the support for Maven 2 is very solid and part of the standard distribution. I wanted to pipe in that this is definitely an issue. We have people who are going to pull our project out of source control and build it, without necessarily opening Netbeans first. This means the private properties file that points to CopyLibs may not have been created. This is especially a problem on machines where Netbeans is not installed at all. It's also extremely confusing to team members, when the build behaves differently depending on which arbitrary steps they've taken (opening the project in Netbeans). Worse of all, CopyLibs is entirely unnecessary. Here's some example ant that leverages the javac.classpath variable to copy the libraries using no Netbeans unique ant tasks. <mkdir dir="${basedir}/dist/lib"/> <property name="src.jars.filename" value="build/jars.txt"/> <echo message="${javac.classpath}" file="${src.jars.filename}"/> <replace file="${src.jars.filename}" token=":" value="${line.separator}"/> <copy todir="${basedir}/dist/lib" flatten="true" overwrite="true"> <resourcelist> <file file="${src.jars.filename}"/> </resourcelist> </copy> <delete file="${src.jars.filename}"/> >Worse of all, CopyLibs is entirely unnecessary.
Unfortunately the CopyLibs is a bit more complicated. It does more things like removing Class-Path from copied jars.
|