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.

Bug 157576 - copylibstask should be deleted and standard ant tasks used instead
Summary: copylibstask should be deleted and standard ant tasks used instead
Status: REOPENED
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 4 votes (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-28 20:34 UTC by pilbender
Modified: 2011-09-09 18:44 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pilbender 2009-01-28 20:34:56 UTC
In Netbeans 6.1 the IDE created ant build scripts were not only able to be used in other IDEs for the same project in 
version control (for example being able to issue an ant build from Eclipse), but also with external version control 
build tools like Hudson or Cruise Control.  The implementation of the copylibstask, which overrides something similar 
in standard ant, causes Netbeans produced builds to *not* work with other tools.

I consider this a major regression in functionality and I am unable to upgrade to Netbeans 6.5 until this is fixed.  
Netbeans needs to be able to play nicely with other tools and the simple operation of copying libraries does *not* need 
an incompatible task to complete this operation.  

Put it back the way it was, please!  I am a huge Netbeans advocate.  I love it.  But, I had egg on my face when I broke 
the build because of my upgrade to 6.5.  It was embarrassing and unnecessary.  Please don't do something fundamental 
like this again.  And, yes, I am aware of supplying the custom library to make it work.  The problem is, this extra 
step is unnecessary considering the task at hand (copying jars) and is *only* to accommodate Netbeans while 
inconveniencing everyone else.

One last point.  The task of building in Java projects has always been a difficult, painful operation.  Netbeans ant 
builds made this so much better.  The only other thing with that much automation is Maven and that's a pain to set up 
too.  I consider the ubiquitous Netbeans ant builds one of the shining things that this IDE does well and does right, 
until the 6.5 release of course.
Comment 1 Jesse Glick 2009-01-30 15:27:29 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'.
Comment 2 adam_myatt 2009-02-04 18:32:06 UTC
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?
Comment 3 wherisat 2009-02-10 19:07:41 UTC
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!).
Comment 4 pilbender 2009-02-28 06:47:48 UTC
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)
Comment 5 mzarathustra 2009-04-16 21:37:43 UTC
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.

  
Comment 6 David Strupl 2009-04-17 12:56:20 UTC
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.
Comment 7 ben_irwin 2011-09-09 18:08:38 UTC
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}"/>
Comment 8 Tomas Zezula 2011-09-09 18:44:41 UTC
>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.