Not sure about the priority...
you cannot just use the dev version of the apisupport.project
module (containing the critical patch d9f95c89c573) on top of 6.0, since
the intervening ba9fd7dd4576 added shared lib support and requires use
of other dev modules. I expect the small required part of d9f95c89c573
could be backported to 6.0.1. If you care about this, please feel free
to file a bug in apisupport/project and mark it however it needs to be
marked to be considered a candidate for 6.0.1.
Background: NB 6.0's apisupport.project, not expecting the new Hg repo layout, dies when it fails to find a module
"core" where it expects to.
Well, it looks like it is probably too late for 6.0.1, but maybe for some update; I don't really know how this works.
You need to prepare the fix and then convince our QE to schedule it for some update. First scheduling of update of
6.0.1 is due end of January, next to follow in five week period.
If you prepare the patch, I will talk to our QE representative (e.g. Lukáš Hasík). I believe that ability to use
latest released version of NetBeans to work on current sources is important.
yes, QE agrees. We need the patch 6.0.
1, attach diff against release60 branch in CVS to this issue (to make life of sustaining easier ;)
2, provide jars/nbms for QE (offline) [yes. I'm lazy to build it from "old" cvs, I've deleted it already]
3, QE will test the 6.0.1 with these jars to make sure that the new apisupport.project works in 6.0.1. Of course, the
old one have to work as well
4, then we will pass the issue to sustaining. They will take care about the backport/build of the patch
5, if this issue won't be fixed till 1/31 then sustaining will ignore it (unfortunately)
Created attachment 55711 [details]
Patch against release60 incorporating parts of #5df9ed234973 and #d9f95c89c573
Created attachment 55712 [details]
NBM with patch
Well, certainly fixed for the trunk, just open for 6.0.1.
Not sure what is meant by "Of course, the old one have to work as well".
Testing should include use of the patched apisupport.project on both the old CVS repository and the new Hg repository.
*** Issue 126393 has been marked as a duplicate of this issue. ***
Build: NetBeans IDE 6.0 (Build 200711261600)
VM: Java HotSpot(TM) Client VM, 10.0-b19
OS: Windows XP, 5.1, x86
finally able to reproduce this problem restart of IDE helped to show the IOE
Created attachment 55847 [details]
using the org-netbeans-modules-apisupport-project.jar from the attached NBM helped to fixed the problem to me and jbecicka.
The issue wasn't 100% reproducible with NB6.0 and nb projects from Hg.
I can in NB6.0 with the patch
1, open projects from main Hg repository without exceptions
2, open project from nb_all
3, it checks project dir with module name
->marking as verified
PS: "Not sure what is meant by "Of course, the old one have to work as well"." -> old one == project from "old" cvs
*** Issue 126954 has been marked as a duplicate of this issue. ***
The fix has been ported into the release601_fixes branch.
Checking in src/org/netbeans/modules/apisupport/project/ui/wizard/BasicConfVisualPanel.java;
new revision: 184.108.40.206; previous revision: 1.37
Checking in src/org/netbeans/modules/apisupport/project/ui/wizard/Bundle.properties;
new revision: 220.127.116.11; previous revision: 1.35
Checking in src/org/netbeans/modules/apisupport/project/universe/ModuleList.java;
/cvs/apisupport/project/src/org/netbeans/modules/apisupport/project/universe/Attic/ModuleList.java,v <-- ModuleList.java
new revision: 18.104.22.168; previous revision: 1.36
Checking in src/org/netbeans/modules/apisupport/project/universe/TestEntry.java;
/cvs/apisupport/project/src/org/netbeans/modules/apisupport/project/universe/Attic/TestEntry.java,v <-- TestEntry.java
new revision: 22.214.171.124; previous revision: 1.7
Pity there is no "6.0.1" Target Milestone in Issuezilla - do you know why?
I think there are separate questions here:
1. When an issue is fixed in an update (to be released via the update center), should target milestone be changed?
The answer seems to be 'No', rightly so in my opinion, mainly because issuezilla is not meant to be
amulti-release-bug-tracking system. In other words, if a bug is fixed in both 6.1 (which at present is trunk) and in
6.0.1patch branch, what should the target milestone be? The general convention is that, issuezilla fields will, by
default, always refer to the trunk. The status of the same issue in other branches should be maintained via status
whiteboard values and comments.
In particular, the status field will always refer to the trunk or current-release version, so that development
dashboards will be accurate.
2. 6.0.1 in particular is a slightly different situation. 6.0.1 was meant only as a minor release with planned features
documented at http://wiki.netbeans.org/NB601Description . In particular, 6.0.1 release itself was not supposed to
contain any bugfixes and therefore there was no reason to create a target milestone value. Of course, now that 6.0.1 has
been released, this question is moot because no more bugs can be targeted for 6.0.1 release itself. (Of course, fixes
can be targeted for 6.0.1 patches, but these are covered by section (1) above).
Does that make sense?
*** Issue 127176 has been marked as a duplicate of this issue. ***