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.
The problem here is potentially serious. Let us say we start with this on Auto Update: jsp-syntax.jar spec=1.0 impl=Aug 10 dep: xml.text = Aug 10 xml-text.jar spec=1.0 impl=Aug 10 Fine. Now the maintainer of jsp-syntax.jar makes some important bugfix and bumps up the spec version. Daily NBM builder pushes it onto AU: jsp-syntax.jar spec=1.1 impl=Aug 15 dep: xml.text = Aug 15 xml-text.jar spec=1.0 impl=Aug 10 Won't work! The requested version of xml-text.jar may have been built internally somewhere, but is not published. A user downloading the new jsp-syntax.jar will find that it cannot be enabled. AU currently does not support backing out of a module upgrade, so the user will just be stuck unless he/she wipes out the NB installation and starts over. The problem is that ${buildnumber} = @BUILD_NUMBER_SUBST@ was never intended as a string you can rely on having a particular value; it can be changed with every build or even according to the whim of the developer running the build. It is purely informational, and not suitable for use in dependencies. If jsp-syntax.jar wishes to use the unstabilized APIs in xml-text.jar, it should not use specification versions because there is no guaranteed that backward compatibility will be retained. Instead, it needs to track development of xml-text.jar, so that each change in the XML Text code is tested to ensure the JSP editing code still works with it. One way to do this might be for there to be a file xml/impl-vers.properties which lists implementation versions for each XML submodule that someone might be using unofficially as an "API". For example: xml.text-edit.implementation.version=august-2002-refactoring-3 Note that these versions need not be numeric and are not considered orderable or comparable except by equality. Now web/jspsyntax/manifest.mf should declare a dep: org.netbeans.modules.xml.text/1 = august-2002-refactoring-3 I.e. known to work with this version of the module. When the JSP maintainer does some unrelated work, this dep should not be touched, and will still work. When the XML Text maintainer does something that affects the "API", he/she must change the impl version: xml.text-edit.implementation.version=aug02-fixed-typo-in-method-name If he/she does not touch web/jspsyntax/manifest.mf, the build will break. So the XML Text maintainer is reminded to check that JSP editing still works, in which case that can be upgraded to match: org.netbeans.modules.xml.text/1 = aug02-fixed-typo-in-method-name In such a case it is probably wise to increase the specification versions of both modules so the next daily alpha NBM push will get the matching versions of both modules together. Does this make sense?
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.