.... will not be reported.
Loading modules:
Start loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse_1.0.0.20070118' at 21:12:51...
Finished loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse_1.0.0.20070118' at 21:12:51, duration is 0 s.
Start loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.typed_1.0.0.20070110' at 21:12:51...
Finished loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.typed_1.0.0.20070110' at 21:12:51, duration is 0 s.
Start loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.dgm_1.0.0.20070110' at 21:12:51...
Finished loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.dgm_1.0.0.20070110' at 21:12:51, duration is 0 s.
Start loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codebrowsing_1.0.0.20070110.jar' at 21:12:51...
Finished loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codebrowsing_1.0.0.20070110.jar' at 21:12:51, duration is 0 s.
Start loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.hippie_1.0.0.20070110' at 21:12:51...
Finished loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist.hippie_1.0.0.20070110' at 21:12:51, duration is 0 s.
Start loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.astviews_1.0.0.20070110' at 21:12:51...
Finished loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.astviews_1.0.0.20070110' at 21:12:51, duration is 0 s.
Start loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist_1.0.0.20070110' at 21:12:51...
Finished loading types from module '/Users/michael/eclipse-plugin-groovy/eclipse/plugins/org.codehaus.groovy.eclipse.codeassist_1.0.0.20070110' at 21:12:51, duration is 0 s.
Start loading details from types at 21:12:51...
Collecting types lasts 0 ms.
org.jmove.core.JmoveException: Method reverse(java.lang.String) already defined
at org.jmove.java.model.Type.defineMethod(Type.java:124)
at org.jmove.java.loader.typeanalyzer.bytecode.asm.AsmTypeLoader.visitMethod(AsmTypeLoader.java:168)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.jmove.java.loader.typeanalyzer.bytecode.asm.AsmLoadStrategy.processBytecode(AsmLoadStrategy.java:41)
at org.jmove.java.loader.typeanalyzer.bytecode.BytecodeLoadStrategy.processBytecode(BytecodeLoadStrategy.java:151)
at org.jmove.java.loader.typeanalyzer.bytecode.BytecodeLoadStrategy.processTask(BytecodeLoadStrategy.java:140)
at org.jmove.java.loader.LoadDetailsFromTypes.processStack(LoadDetailsFromTypes.java:156)
at org.jmove.java.loader.LoadDetailsFromTypes.importTypeSet(LoadDetailsFromTypes.java:188)
at org.jmove.java.loader.LoadDetailsFromTypes.perform(LoadDetailsFromTypes.java:141)
at org.jmove.zui.actions.ModuleLoader$LoadModulesThread.loadDetailsFromModuleTypes(ModuleLoader.java:223)
at org.jmove.zui.actions.ModuleLoader$LoadModulesThread.run(ModuleLoader.java:202)
causes an empty model in jmover. The user will not be informed about the error.
Logged In: YES
user_id=516787
Originator: NO
The error occures when there are duplicates of class within the same module. This is true for the groovy-eclipse plugin.
The problem is the following:
1. The byte code loader assumes that the root package is the jar root. this is not true for OSGI Bundles (jars and directories) as they are used for Eclipse plugins. These Bundles may specify a Bundle-Classpath in the manifest file.
2. When scanning the module content the class files are located but there is no preparsing to determine the real class name. So the false class name derived from the file path is assumed.
3. When analyzing the types the the real class name is read from the class file and the right type is created in the model. But due to the duplicate existence of the class and the fact that it is assumed that the files belong to different types the type is analyzed a second (or third...) time. During this repetition it comes to an error when defining the methd.
4. An extra effect is that there may be up to three types defined for a duplicate type.
We have to do two things:
- first make method definitions more tolerant for failures
- second don't trust the file path....
- third support OSGI bundles in the future...
Logged In: YES
user_id=552723
Originator: YES
A similar error occurs on source code analyzer for hibernate sources. At first I avoid the NPE with a lookup before defining the method.
I think the throwing of JMoveException in defineMethod should be removed.