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 70330 - Module dependency sometimes cannot be removed
Summary: Module dependency sometimes cannot be removed
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Martin Krauskopf
: 70589 (view as bug list)
Depends on:
Reported: 2005-12-13 13:33 UTC by pzajac
Modified: 2006-01-06 08:09 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

release50-patch.diff (15.32 KB, patch)
2005-12-14 12:43 UTC, Martin Krauskopf
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description pzajac 2005-12-13 13:33:19 UTC
"I/O api" cannot be removed form NBCVS/ant module using project's customizer. I
 tried to copy the <modulesdependencies> xml tag project.xml to standalone
project configuration. It also doesn't work.
Comment 1 Martin Krauskopf 2005-12-13 14:07:14 UTC
There seems to be something terribly wrong. It works very strangely. Maybe P2...
Comment 2 Martin Krauskopf 2005-12-13 16:23:30 UTC
There is some mess in comparator vs. compareTo vs. equals vs. hashCode which
confuses SortedSets. Will have to be fixed also for 5.0.
Comment 3 Martin Krauskopf 2005-12-13 16:24:15 UTC
BTW quite good catch :)
Comment 4 Jesse Glick 2005-12-13 16:35:32 UTC
Oops, I made a really stupid typo in ModuleDependency...

  if (result != -1) {

should be

  if (result != 0) {

Same bug in PlatformComponentFactory and UIUtil.

Amazing that this code worked long enough to pass through all our unit tests...
I guess we were not testing sorting at all. Fix should include some new unit
tests, at least for ModuleDependency.
Comment 5 Martin Krauskopf 2005-12-13 16:45:58 UTC
Also we should override equals (+hashCode) in ModuleDependency when we
implemented Comparable.compareTo() (cf. compareTo's javadoc). And with it change
natural ordering of ModuleDependencies to CNB, not localized name. And provide
Comment 6 Jesse Glick 2005-12-13 17:41:28 UTC
All that makes sense for the trunk. For release50 we should probably limit
ourselves to undoing the damage done by my last patch, which should be
accomplished by changing -1 to 0, AFAIK.
Comment 7 Martin Krauskopf 2005-12-13 17:51:25 UTC
Ok. I'm afraid that there is also some other ordering problems, hopefully
without others impacts. I'll write tests and fix at least this. We will see....
Or feel free to retake if you want. I'm just going home, so I'll not definitely
fix it in next two hours :)
Comment 8 Martin Krauskopf 2005-12-14 08:31:47 UTC
Fixed (+ few sanity-check tests). I'll go through reviewers today and backport
into 5.0.

ui/; 1.20 -> 1.21;
ui/customizer/; 1.15 -> 1.16;
ui/platform/; 1.4 -> 1.5;
test/unit/; 1.5 -> 1.6;
test/unit/; 1.28 -> 1.29;
test/unit/ui/; 1.3 -> 1.4;
test/unit/ui/customizer/; 1.1
test/unit/ui/platform/; 1.1
Comment 9 Martin Krauskopf 2005-12-14 12:43:10 UTC
Created attachment 27835 [details]
Comment 10 Martin Krauskopf 2005-12-14 12:45:15 UTC
Attached fix against release50 branch. Jesse could you review it.
Comment 11 pzajac 2005-12-14 13:01:24 UTC
verified in trunk
Comment 12 Jesse Glick 2005-12-14 15:23:35 UTC
Looks fine to me; thanks for handling this.

For the trunk, UIUtilTest.testLayerItemPresenterCompareTo and
ModuleDependencyTest.testCompareTo could probably be made more robust by having
them operate on temporary external modules created by the test case with
controlled display names.
Comment 13 Martin Krauskopf 2005-12-14 15:30:28 UTC
Yes, also ModuleDependencyTest is little artifical (could use similar approach
with implementing ModuleEntry probably). I'll rewrite them together with a
polishing I mentioned above.
Comment 14 Martin Krauskopf 2005-12-16 10:37:02 UTC
Backported into release50 (the same diff)
Comment 15 Martin Krauskopf 2005-12-19 16:54:24 UTC
*** Issue 70589 has been marked as a duplicate of this issue. ***
Comment 16 pzajac 2006-01-06 08:09:23 UTC