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: | dev version of the apisupport.project cannot be used in NB 6.0 | ||
---|---|---|---|
Product: | apisupport | Reporter: | Tomas Mysik <tmysik> |
Component: | Project | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jbecicka, jtulach, juhrik, lhasik, mmirilovic, sustaining |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://statistics.netbeans.org/analytics/detail.do?id=3461 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Patch against release60 incorporating parts of #5df9ed234973 and #d9f95c89c573
NBM with patch stacktrace |
Description
Tomas Mysik
2008-01-28 17:40:20 UTC
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) thanks 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 User Comments: finally able to reproduce this problem restart of IDE helped to show the IOE Created attachment 55847 [details]
stacktrace
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; /cvs/apisupport/project/src/org/netbeans/modules/apisupport/project/ui/wizard/Attic/BasicConfVisualPanel.java,v <-- BasicConfVisualPanel.java new revision: 1.37.10.1; previous revision: 1.37 done Checking in src/org/netbeans/modules/apisupport/project/ui/wizard/Bundle.properties; /cvs/apisupport/project/src/org/netbeans/modules/apisupport/project/ui/wizard/Attic/Bundle.properties,v <-- Bundle.properties new revision: 1.35.10.1; previous revision: 1.35 done 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: 1.36.8.1; previous revision: 1.36 done 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: 1.7.8.1; previous revision: 1.7 done 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. *** |