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: | web/jspsyntax/manifest.mf depends on ${buildnumber} used for xml/text-edit/manifest.mf | ||
---|---|---|---|
Product: | javaee | Reporter: | Jesse Glick <jglick> |
Component: | JSP | Assignee: | _ rkubacki <rkubacki> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | akemr, issues, jtulach, mmetelka |
Priority: | P2 | Keywords: | ARCH |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 22922 |
Description
Jesse Glick
2002-08-02 20:31:44 UTC
I agree that it is better to set some constant string as implementation version rather then dynamic ${buildnumber}. At XML side, if I change the implementation version I have to change it also in all dependent modules, what is really bad for as. I will probably publish org.netbeans.modules.xml.text.syntax package the jspsyntax module depend on. It is the simpliest solution now. And when we will provide API about it I will "close" this package again. :-( I agree that it is probably the easiest way now to publich the package temporarily. According to our earlier discussion with Mila it looks that better solution would be to create some FilterKit that could be obtained using MIME type without need to directly depend on some existing implementation. This will alow us to extend XML tokens without explicit dependency on their module. I think it makes sence: the dependency on implementation version signals that those two modules must be updated at the same time. This will work better in Jesse's example when the implementation version is not build number, but it should work relatively fine even with the build numbers, I guess. What I think we have to do is to improve autoupdate to check for correct implementation dependencies and if there is a new jsp-syntax.jar and no xml-text.jar with the proper implementation version then refuse/warn during the update. Autoupdate checks dependencies on implementation version and displays warning if it's not satisfied. Package org.netbeans.modules.xml.text.syntax is temporarily (waiting for API) published now. Mentioned FilterKit is right way. It should solve this issue. I am marking as fixed and will create new issue to track implementation of FilterKit. "Autoupdate checks dependencies on implementation version and displays warning if it's not satisfied.": true, will at least help the user from shooting him/herself in the foot in my original example. However if you reverse it, there is still a problem: jsp-syntax.jar spec=1.0 impl=Aug 10 dep: xml.text = Aug 10 xml-text.jar spec=1.0 impl=Aug 10 Fix in xml-test.jar, push new version: jsp-syntax.jar spec=1.0 impl=Aug 10 dep: xml.text = Aug 10 xml-text.jar spec=1.1 impl=Aug 15 Now AU will helpfully offer to download the new xml-text.nbm. The user accepts, NB restarts, and then jsp-syntax.jar is disabled with a mysterious error. There is no way to turn it back on unless you either wait for a new jsp-syntax.nbm to be published, or figure out how to manually revert to the older xml-text.nbm. Unless AU also checks before downloading a new NBM that *other* modules will not be broken by the upgrade - does it? You are right - AU doesn't do it.. But it should check it IMO - I filed #26373 Verified in NetBeans dev build 200302220100. |