[jira] [Commented] (GERONIMO-6301) Can't Build Geronimo server trunk after upgrading to ASM 4.0

[Ulrich Romahn (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230697#comment-13230697
 ] 

Ulrich Romahn commented on GERONIMO-6301:
-

I have started investigating the issue and it appears that Apache Karaf 
3.0-SNAPSHOT is using ASM 4.0, while many other components in Geronimo is still 
depending on ASM 3.x.

It should be possible to have both versions co-exist at runtime and hence 
satisfy the different dependencies.

I have already tried to update the version of ASM to 4.0 in the master pom but 
the build is still broken with the same error message since Karaf 3.0-SNAPSHOT 
has only the ASM 4.0 bundle loaded.
It should be possible to fix this by modifying Karaf 3.0-SNAPSHOT to also 
include the ASM 3.x bundle.
This may actually be a Karaf bug, instead of a Geronimo bug, but since is 
happened here, I created the bug here.

> Can't Build Geronimo server trunk after upgrading to ASM 4.0
> 
>
> Key: GERONIMO-6301
> URL: https://issues.apache.org/jira/browse/GERONIMO-6301
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: buildsystem, core
>Affects Versions: 3.0
> Environment: Any build environment.
> My build environment: CentOS 6.2-64bit, OpenJDK 1.6-64bit, Maven 3.0.4
>Reporter: Ulrich Romahn
>Priority: Blocker
>
> Some component (most likely Apache Karaf 3.0-SNAPSHOT) upgraded the ASM 
> library from 3.x to 4.0. This upgrade breaks the build.
> The build "hangs" at the following step: Building Geronimo Plugins, System 
> Database :: System Database 3.0-SNAPSHOT
> Which is producing the following exception:
> [INFO]   
> org.apache.geronimo.configs/j2ee-deployer/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-deployer/3.0-SNAPSHOT/car,j2eeType=ModuleBuilder,name=GBeanRefBuilder
>  
> [INFO] Exception, use console to investigate 
> java.lang.reflect.InvocationTargetException 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:616) 
> at 
> org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:456)
>  
> at 
> org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:311)
>  
> at 
> org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:214)
>  
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>  
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>  
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>  
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) 
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) 
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) 
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) 
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:616) 
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>  
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) 
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>  
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) 
> Caused by: java.lang.NoClassDefFoundError: 
> org/objectweb/asm/commons/EmptyVisitor 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defi

[jira] [Commented] (GERONIMO-6227) Version numbers not resolved in resulting karaf-framework-3.0-beta-1-features.xml

[Ulrich Romahn (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164011#comment-13164011
 ] 

Ulrich Romahn commented on GERONIMO-6227:
-

UPDATE:
I think I figured out what the issue is here. The pom.xml of the 
karaf-framework artifact is "importing" the main pom of karaf assuming it would 
also get all the properties defined therein. However, this is not what 
importing the pom does - it only imports the dependencies defined in this pom, 
but not the properties. In order to fix the issue, I had to manually copy all 
the missing properties from the karaf main pom into the pom of the Geronimo 
karaf-framework. This is not perfect but at least a stop-gap.

> Version numbers not resolved in resulting 
> karaf-framework-3.0-beta-1-features.xml
> -
>
> Key: GERONIMO-6227
> URL: https://issues.apache.org/jira/browse/GERONIMO-6227
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: osgi-bundles
>Affects Versions: 3.0-M1
> Environment: All
>Reporter: Ulrich Romahn
>  Labels: build
>
> The build process is supposed to replace all version numbers contained in the 
> source file features.xml inside 
> framework/configs/karaf-framework/src/main/filtered-resources with the 
> corresponding values defined somewhere.
> Example: 
>   the line 
> 
> mvn:org.apache.geronimo.specs/geronimo-servlet_2.5_spec/${geronimo.servlet.version}
>   should be expanded to something like
> 
> mvn:org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1.2
> in the resulting file.
> However, those environment variables are not defined anywhere and hence they 
> are not resolved during build time.
> This is causing error messages while trying to install an OSGI feature, such 
> as the webconsole or other OSGI features that depend on such bundles/features.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira