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.
QA needs to test compatibility of nb4.1 and nb5.0. It does that by taking an existing application written for nb4.1 and running it in nb5.0. Unfortunatelly, the application does not even start as there were incompatible changes in some module APIs (debuggerjpda, j2eeserver, javamodel, etc.) and the major version of these modules was increased. Althrough the fix is easy (e.g. change the dependency to use range version like 2-3), there is no easy way for QA to verify this. As a result there is a request for simulating the state after the module dependencies upgrade without actually modifying the modules.
I propose to introduce property "org.netbeans.modules.upgrademajorversion" which, if provided will ignore all the major versions in module dependencies and install the modules anyway. Moreover it will print a warning describing which modules will need to be upgraded when switching to new version. Imho this is simple to do and use and understand.
Suggest "org.netbeans.modules.upgradeMajorVersion" for readability. Could we get a little more background on this? You say the dep upgrade is easy, yet it is not easy for QA to validate it. How can these both be true? If it is easy to upgrade the app to use version ranges, then it cannot be so hard to (1) do so, (2) try it.
"You say the dep upgrade is easy, yet it is not easy for QA to validate it. How can these both be true?" I am sure both can be true pretty easily: Our QA is going to test buzz produced by group of people Idonotknowfromwhere. QA does not know how to build buzz. QA does not have much time. Communicating with the buzz people would likely require more time then creating the support in our module system, which is likely to be useful anyway.
You don't have to build Buzz from sources to change OpenIDE-Module-Module-Dependencies: org.netbeans.modules.debuggerjpda/1, ... to OpenIDE-Module-Module-Dependencies: org.netbeans.modules.debuggerjpda/1-2, ... in META-INF/MANIFEST.MF. Can be done e.g. in Emacs in about fifteen seconds. If you needed to upgrade deps to a lot of APIs in a lot of client modules, e.g. more than fifty or a hundred such deps, and you wanted to save some typing, you could write a very simple Ant task or other script to do this for you automatically - I would estimate 100-200 LOC using Ant APIs. No need to patch the NB module system and no need to communicate with the original authors of the application; this would just be opening some JARs, tweaking the manifests, and writing them back. I don't think the new property would be harmful, just a bit of extra complexity to document and test, and I don't really see the point. So -0 from me, I guess (not a blocker).
Re: "You don't have to build Buzz from sources to change" Sure you don't, but you do have to unpack jars, update module dependencies in the manifests and pack the jars again. It certainly can be automated, but you still need to know what dependencies should be upgraded and to what versions. In general, the person tasked to perform *functional compatibility testing* cannot be expected to have such knowledge and shouldn't need to rebuild the modules under the test.
"It certainly can be automated, but you still need to know what dependencies should be upgraded and to what versions." - usually this is a small list (three or four modules), but if not, that can be automated too. Just take as input to the script not just the application but also the target platform (if these are separated), and scan for any deps on an older version of a major release version than is currently satisfiable. All of the information you need is mechanically discoverable. <upgradedeps> <fileset dir="/opt/buzz"> <include name="*/modules/*.jar"/> </> </> As I said, my opinion is only -0.
Well, seeing the discussion I think now is the right time to offer another solution. I can write ModuleAutoDeps/41-50.xml which will automatically upgrade the dependencies. I can attach the XML file here and let the person who wishes to do the testing to put it into nb5.0/config/ModuleAutoDeps/41-50.xml. Possible problem is that I may make a mistake and not include all the deps that need to be upgraded. However the file format is semi human readable, so Marian could modify it if needed. If you do not disagree I can prepare this solution.
Re. ModuleAutoDeps: interesting idea. And you could mechanically generate this file if it proved too much work to write manually.
Created attachment 25595 [details] The script to generate the dependencies
Use cd ide/golden cvs diff -r release41 modules.txt | awk -f transform.awk >41-50.xml to generate the dependencies upgrade file. Place it to nb5.0/config/ModuleAutoDeps/41-50.xml and currently you will get [WARNING] Warning - had to upgrade dependencies for module org.netbeans.modules.autoupdate: added = [] removed = [module org.netbeans.core/2 > 3.0]; details: [Automatic update of dependencies for test purposes.] etc. So something is wrong right now. Jesse as you invented the format can you review the output of the script and suggest what is wrong or what shall be changed? I suspect the module system ignores major version in the dependency and still tries to upgrade it even it is in fact different dependency.
Don't know, I guess it's a module system bug if <transformation> <trigger-dependency type='cancel'> <module-dependency codenamebase='org.netbeans.core' major='1' /> </trigger-dependency> <implies> <result> <module-dependency codenamebase='org.netbeans.core' major='2'/> </result> </implies> </transformation> does not work. Could probably be fixed without too much work. The script does however generate some nonsense such as <transformation> <trigger-dependency type='cancel'> <module-dependency codenamebase='org.netbeans.modules.db' major='1' /> </trigger-dependency> <implies> <result> <module-dependency codenamebase='org.netbeans.modules.db' major='0'/> </result> </implies> </transformation> and <transformation> <trigger-dependency type='cancel'> <module-dependency codenamebase='org.netbeans.modules.favorites' major='1' /> </trigger-dependency> <implies> <result> <module-dependency codenamebase='org.netbeans.modules.favorites' major='1'/> </result> </implies> </transformation> and <transformation> <trigger-dependency type='cancel'> <module-dependency codenamebase='org.netbeans.modules.java.freeform' major='-1' /> </trigger-dependency> <implies> <result> <module-dependency codenamebase='org.netbeans.modules.java.freeform' major='1'/> </result> </implies> </transformation>
Created attachment 25788 [details] Better version of the script to generate the deps
Created attachment 25789 [details] The generated deps to be placed into nb5.0/config/ModuleAutoDeps
I checked the tests for autodeps and based on their content I've generated the new autodeps file. When used on plain 5.0 it does not get triggered at all. On older modules it should upgrade the deps. Marian, I guess now it is your turn. Try it and if there are problems, either edit the 41-50.xml by hand or let me know we can investigate what is wrong.
Shouldn't the result dep be e.g. spec="999999" rather than spec="0.1"? E.g. if the new module is foo/3 2.6 and the old dep was foo/2 1.1, giving a result dep of foo/3 0.1 should still fail.
It looks like it works, thanks for your help.