Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 65729 - QA needs to disable major version checks
QA needs to disable major version checks
Product: platform
Classification: Unclassified
Component: Module System
All All
: P1 (vote)
: 5.x
Assigned To: Jaroslav Tulach
Depends on:
  Show dependency treegraph
Reported: 2005-10-03 15:49 UTC by Jaroslav Tulach
Modified: 2008-12-23 08:43 UTC (History)
3 users (show)

See Also:

The script to generate the dependencies (1.02 KB, text/plain)
2005-10-06 10:56 UTC, Jaroslav Tulach
Better version of the script to generate the deps (1.25 KB, text/plain)
2005-10-11 11:18 UTC, Jaroslav Tulach
The generated deps to be placed into nb5.0/config/ModuleAutoDeps (2.67 KB, text/xml)
2005-10-11 11:19 UTC, Jaroslav Tulach

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2005-10-03 15:49:53 UTC
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.
Comment 1 Jaroslav Tulach 2005-10-03 15:52:38 UTC
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. 
Comment 2 Jesse Glick 2005-10-03 21:33:12 UTC
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.
Comment 3 Jaroslav Tulach 2005-10-04 07:47:48 UTC
"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. 
Comment 4 Jesse Glick 2005-10-04 16:44:32 UTC
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).
Comment 5 Jan Chalupa 2005-10-04 17:09:28 UTC
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.
Comment 6 Jesse Glick 2005-10-04 17:45:48 UTC
"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

    <fileset dir="/opt/buzz">
        <include name="*/modules/*.jar"/>

As I said, my opinion is only -0.
Comment 7 Jaroslav Tulach 2005-10-05 09:17:15 UTC
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. 
Comment 8 Jesse Glick 2005-10-05 23:02:21 UTC
Re. ModuleAutoDeps: interesting idea. And you could mechanically generate this
file if it proved too much work to write manually.
Comment 9 Jaroslav Tulach 2005-10-06 10:56:30 UTC
Created attachment 25595 [details]
The script to generate the dependencies
Comment 10 Jaroslav Tulach 2005-10-06 11:00:36 UTC
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. 
Comment 11 Jesse Glick 2005-10-06 21:34:29 UTC
Don't know, I guess it's a module system bug if

      <trigger-dependency type='cancel'>
        <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

      <trigger-dependency type='cancel'>
        <module-dependency codenamebase='org.netbeans.modules.db' major='1' />
          <module-dependency codenamebase='org.netbeans.modules.db' major='0'/>


      <trigger-dependency type='cancel'>
        <module-dependency codenamebase='org.netbeans.modules.favorites'
major='1' />
          <module-dependency codenamebase='org.netbeans.modules.favorites'


      <trigger-dependency type='cancel'>
        <module-dependency codenamebase=''
major='-1' />
          <module-dependency codenamebase=''
Comment 12 Jaroslav Tulach 2005-10-11 11:18:42 UTC
Created attachment 25788 [details]
Better version of the script to generate the deps
Comment 13 Jaroslav Tulach 2005-10-11 11:19:40 UTC
Created attachment 25789 [details]
The generated deps to be placed into nb5.0/config/ModuleAutoDeps
Comment 14 Jaroslav Tulach 2005-10-11 11:22:07 UTC
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. 
Comment 15 Jesse Glick 2005-10-11 15:26:57 UTC
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.
Comment 16 Marian Mirilovic 2005-10-18 15:29:34 UTC
It looks like it works, thanks for your help.

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