[modules-dev] Review request for 6605077, "jrepo dependencies"

Mandy Chung Mandy.Chung at Sun.COM
Fri Jul 11 16:56:13 PDT 2008


Hi Dave,

Looks good in general.  Here are my review comments:

sun/module/repository/URLModuleInfo.java
     line 61:  interesting to see "^" used here
     - this is not your change but do you mind fixing this to use "||" 
(OR sign) as part of your fix?

sun/module/tools/ImportTraverser.java
     line 120: prefer to see the OR sign instead of a bitwise XOR in an 
if-statement.
     line 102 & 126: would it be better to have this constructor 
requiring a non-null VersionConstraint?  The caller should supply 
VersionConstraint.DEFAULT instead of null.   Also, JRepo.java is passing 
the default version constraint instead of null.
     line 145: repo in the visit(Repository, Module) method is not 
used.  Look like better to rename visit(Repository, Module) method to a 
different method name e.g. traverse(Module m) to begin visiting the 
module and its imports.
     line 71-92: this method installing a module in a temporary 
repository is not used in your fix.   Under what circumstances do we 
need to use this method? I suggest to remove this method.

sun/module/tools/JRepo.java
   line 292: this line has extra whitespaces in front of "rc = ..."
   line 326: I think instead of checking "srcLoc == null" to determine a 
bootstrap repository, you should check md.getRepository() == 
Repository.getBootstrapRepository().
   line 378: IllegalArgumentException is an runtime exception which is 
not needed in the method signature.  Is this change for documentation 
purpose?  Can you add @throws in the comment instead?
   line 635-637: I think it's useful to add a method in the 
ImportTraverser class to determine if any module has been visited (e.g. 
int visitedModuleCount())
   line 694 & 710: should we check the name starting with "java.se" 
instead of equals?  We also have a "java.se.core" module, right?
   line 697 & 713: I suggest to define a string constant variable for 
"    " and then line 713 will use the length instead of hardcoding 4.
   line 673: should be "module archives in the repository" instead of 
"modules in the repository"

Mandy
  
Dave Bristor wrote:

>Hi folks,
>
>This work adds a "dependencies" command to jrepo, which will show, via 
>indentation, all the dependencies of a module.
>
>http://bugs.sun.com/view_bug.do?bug_id=6605077
>http://webrev.invokedynamic.info/bristor/6605077-01/
>
>For example, here's the output from one of the testcases:
>
>m1-1.1
>     java.se-1.7
>     m2-0.0-default
>         java.se-1.7
>         m4-1.6
>             java.se-1.7
>     m3-2.0
>         java.se-1.7
>         m4-1.6
>
>That is, m1-1.1 depends on java.se-1.7, m2-0.0-default, and m3-2.0.  Cycles 
>are handled.  The output does not include the imports of java.se; that is 
>possible if one uses the '-j' flag.  The '-v' flag causes the source location 
>of the containing repository to be printed.  With -j and -v, the above becomes:
>
>ependencies for m1-1.1:
>m1-1.1 
>file:/java/tl/libs/bristor/ws/jrepo/jdk/test/java/module/modinit/tmp_mtest/version/version3.mtest/
>     java.se-1.7 bootstrap
>         java.se.core-1.7 bootstrap
>         corba-3.0 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.xml-1.4 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.xml.bind-2.0 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.xml.ws-2.0 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.xml.soap-1.3 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.annotation-1.0 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.annotation.processing-1.0 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.script-1.0 bootstrap
>             java.se.core-1.7 bootstrap
>         javax.tools-1.0 bootstrap
>             java.se.core-1.7 bootstrap
>     m2-0.0-default 
>file:/java/tl/libs/bristor/ws/jrepo/jdk/test/java/module/modinit/tmp_mtest/version/version3.mtest/
>         java.se-1.7 bootstrap
>         m4-1.6 
>file:/java/tl/libs/bristor/ws/jrepo/jdk/test/java/module/modinit/tmp_mtest/version/version3.mtest/
>             java.se-1.7 bootstrap
>     m3-2.0 
>file:/java/tl/libs/bristor/ws/jrepo/jdk/test/java/module/modinit/tmp_mtest/version/version3.mtest/
>         java.se-1.7 bootstrap
>         m4-1.6 
>file:/java/tl/libs/bristor/ws/jrepo/jdk/test/java/module/modinit/tmp_mtest/version/version3.mtest/
>
>(That output might not paginate well in email; the source locations are on the 
>same lines as the module names.)
>
>The testing approach is to leverage RunMTest.  I've modified it to allow us to 
>specify exactly what it means to "run a test".  By default, it uses the 
>currently-checked-in behavior.  For testing "jrepo dependencies", it uses a 
>different behavior; see JRepoDependenciesTest.MyFactory and 
>JRepoDependenciesTest.MyTestDescription.
>
>The testing is fairly simple, just comparing known-good output with what is 
>generated on a test run.  I hope that one day SQE can do better ;-)
>
>Unrelated, but there's fix to a typo in sun/module/repository/URLModuleInfo.java.
>
>I have not yet integrated the latest API changes.  But neither have I seen a 
>JPRT run on that integration, nor on the ServiceLoader changes I pushed 
>yesterday.  Is our auto-JPRT script running?
>
>Thanks,
>	Dave
>_______________________________________________
>modules-dev mailing list
>modules-dev at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/modules-dev
>  
>




More information about the modules-dev mailing list