Bug 126135 - dev version of the apisupport.project cannot be used in NB 6.0
dev version of the apisupport.project cannot be used in NB 6.0
Status: VERIFIED FIXED
Product: apisupport
Classification: Unclassified
Component: Project
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Jesse Glick
issues@apisupport
http://statistics.netbeans.org/analyt...
release601_fixes_candidate1 release60...
:
: 126393 126954 127176 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-28 17:40 UTC by Tomas Mysik
Modified: 2008-02-20 18:17 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Patch against release60 incorporating parts of #5df9ed234973 and #d9f95c89c573 (6.39 KB, patch)
2008-01-29 18:18 UTC, Jesse Glick
Details | Diff
NBM with patch (968.49 KB, application/octet-stream)
2008-01-29 18:20 UTC, Jesse Glick
Details
stacktrace (3.20 KB, text/plain)
2008-01-31 15:48 UTC, Lukas Hasik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Mysik 2008-01-28 17:40:20 UTC
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.
Comment 1 Jesse Glick 2008-01-28 17:53:22 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.
Comment 2 Jesse Glick 2008-01-28 17:55:12 UTC
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.
Comment 3 Jaroslav Tulach 2008-01-29 06:51:38 UTC
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.
Comment 4 Lukas Hasik 2008-01-29 09:30:50 UTC
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
Comment 5 Jesse Glick 2008-01-29 18:18:18 UTC
Created attachment 55711 [details]
Patch against release60 incorporating parts of #5df9ed234973 and #d9f95c89c573
Comment 6 Jesse Glick 2008-01-29 18:20:43 UTC
Created attachment 55712 [details]
NBM with patch
Comment 7 Jesse Glick 2008-01-29 18:22:19 UTC
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.
Comment 8 Lukas Hasik 2008-01-31 15:46:28 UTC
*** Issue 126393 has been marked as a duplicate of this issue. ***
Comment 9 Lukas Hasik 2008-01-31 15:48:56 UTC
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
Comment 10 Lukas Hasik 2008-01-31 15:48:59 UTC
Created attachment 55847 [details]
stacktrace
Comment 11 Lukas Hasik 2008-01-31 17:03:57 UTC
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
Comment 12 Jesse Glick 2008-02-08 00:38:06 UTC
*** Issue 126954 has been marked as a duplicate of this issue. ***
Comment 13 Karthikeyan Rajeswaran 2008-02-11 21:00:44 UTC
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
Comment 14 Jesse Glick 2008-02-12 19:06:31 UTC
Pity there is no "6.0.1" Target Milestone in Issuezilla - do you know why?
Comment 15 Karthikeyan Rajeswaran 2008-02-13 00:14:05 UTC
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?
Comment 16 Lukas Hasik 2008-02-13 10:56:07 UTC
*** Issue 127176 has been marked as a duplicate of this issue. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo