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.
See URL. You seem to have four JARs duplicated in the ruby cluster for no obvious reason.
The reason for this is that there are two Ruby installations: - A full JRuby installation (which is optional, and users can choose not to install it if they intend to use for example a native Ruby interpreter). This is installed into ruby1/jruby-1.0.1/ - A small part of JRuby used for in-IDE processing and parsing of code. This part is not optional. It's installed into ruby1/modules/ and the extra jars it depends on are in ruby1/modules/ext/. I don't want to try to make the IDE-JRuby-module find these jars out of the JRuby 1.0.1 tree, since that part is optional. And I don't want to make the JRuby 1.0.1 setup try to find its bits in the ruby1 cluster, since these can evolve independently. In particular, I might upgrade the IDE-JRuby module to a trunk build or something to pick up parsing fixes, but leave JRuby 1.0.1 (which runs user programs) at the stable release. Does this explain the problem adequately? Do you have better suggestions for how this should be solved?
If the duplication is intentional and you plan to keep it this way for 6.0, I can create an ignore list for this test - just assign to jglick in nbbuild if so (keep issues@ruby or tor on CC).
Yes, this is intentional and won't change for 6.0.
Checking in ignored-binary-overlaps; /shared/data/ccvs/repository/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/ignored-binary-overlaps,v <-- ignored-binary-overlaps initial revision: 1.1 done Checking in CreateLicenseSummary.java; /shared/data/ccvs/repository/nbbuild/antsrc/org/netbeans/nbbuild/extlibs/CreateLicenseSummary.java,v <-- CreateLicenseSummary.java new revision: 1.10; previous revision: 1.9 done