CDV ❯ Throw error on loading multiple versions of the "same" TIM
-
New Feature
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
-
-
nrana
-
Reporter: teck
-
August 10, 2009
-
0
-
Watchers: 0
-
September 16, 2009
-
September 03, 2009
Attachments
Description
This item is to impose a restriction where it is a hard error to load more than version of the “same” TIM
I’m mostly thinking of the situation Gary K got himself into the other day when testing a tc-config.xml with no versions strings. The net result of that was something like both tim-hibernate-concurrency-3.2-1.0.0-SNAPSHOT and tim-hibernate-concurrency-3.2-1.1.0-SNAPSHOT were to be loaded. That blew up because they both wanted to export the same class, but I think it should fail in a different and less cryptic way
Comments
Alex Miller 2009-08-10
Nitin Rana 2009-09-16
verified with ConflictingModuleTest.
Himadri Singh 2009-09-16
Will get following exception trace.
[INFO] ———————————————————————— [ERROR] FATAL ERROR [INFO] ———————————————————————— [INFO] Conflicting versions of org.terracotta.modules.modules-base required. Versions are [1.1.1] and [1.2.0.SNAPSHOT] [INFO] ———————————————————————— [INFO] Trace com.tc.bundles.ConflictingModuleException: Conflicting versions of org.terracotta.modules.modules-base required. Versions are [1.1.1] and [1.2.0.SNAPSHOT] at com.tc.bundles.Resolver.addToRegistry(Resolver.java:472) at com.tc.bundles.Resolver.ensureBundle(Resolver.java:459) at com.tc.bundles.Resolver.resolveDependencies(Resolver.java:435) at com.tc.bundles.Resolver.ensureBundle(Resolver.java:460) at com.tc.bundles.Resolver.resolveDependencies(Resolver.java:435) at com.tc.bundles.Resolver.ensureBundle(Resolver.java:460) at com.tc.bundles.Resolver.resolveDependencies(Resolver.java:435) at com.tc.bundles.Resolver.ensureBundle(Resolver.java:460) at com.tc.bundles.Resolver.resolveDependencies(Resolver.java:435) at com.tc.bundles.Resolver.resolve(Resolver.java:206) at com.tc.bundles.Resolver.resolve(Resolver.java:293) at org.terracotta.maven.plugins.tc.AbstractDsoMojo.resolveModuleArtifacts(AbstractDsoMojo.java:509) at org.terracotta.maven.plugins.tc.BootjarMojo.execute(BootjarMojo.java:62) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] ———————————————————————— [INFO] Total time: 54 seconds [INFO] Finished at: Wed Sep 16 16:10:09 IST 2009 [INFO] Final Memory: 20M/40M [INFO] ————————————————————————
Himadri Singh 2009-09-16
Got above trace on using attached pom.xml with h2lcperf.
This would indeed help detect and prevent some gnarly bugs