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, ...
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
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
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
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
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
<module-dependency codenamebase='org.netbeans.core' major='1' />
<module-dependency codenamebase='org.netbeans.core' major='2'/>
does not work. Could probably be fixed without too much work. The script does
however generate some nonsense such as
<module-dependency codenamebase='org.netbeans.modules.db' major='1' />
<module-dependency codenamebase='org.netbeans.modules.db' major='0'/>
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.