[ https://issues.apache.org/jira/browse/FELIX-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651042#comment-13651042 ]
Alexander Klimetschek commented on FELIX-2492: ---------------------------------------------- Got the same issue. Please note that I am using Java annotations. I could only fix it with the workaround mentioned above, adding "slf4j-simple" with scope=provided, which is not needed. scope=test did not work. AFAICS, the problem is the nasty slf4j binding trick that in org.slf4j.LoggerFactory the import of "org.slf4j.impl.StaticLoggerBinder" is unresolved in the api jar itself. Some possible solutions: * the scr plugin could just output a warning here in case this is a 3rd party jar (and not local source code) * that might break the desired validation of export/import/private package declarations or generation; so maybe one can configure classes to ignore in the pom (in this case "org.slf4j.LoggerFactory") > scr plugin: using src annotations causes NoClassDefFoundError and other errors > ------------------------------------------------------------------------------ > > Key: FELIX-2492 > URL: https://issues.apache.org/jira/browse/FELIX-2492 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin > Affects Versions: maven-scr-plugin-1.4.4 > Reporter: Michael Dürig > Assignee: Carsten Ziegeler > Fix For: maven-scr-plugin-1.7.2, scr ant task 1.1.2, scr > generator 1.1.2 > > > Using comment tags and having a dependency on slf4j-api causes the scr plugin > to throw a NoClassDefFoundError: > java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder > at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60) > at > com.day.crx.spi.sharepoint.resource.SharepointResourceProvider.<clinit>(SharepointResourceProvider.java:60) > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) > at > sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) > at java.lang.reflect.Field.getFieldAccessor(Field.java:899) > at java.lang.reflect.Field.get(Field.java:358) > at > org.apache.felix.scrplugin.tags.ClassUtil.getInitializationExpression(ClassUtil.java:41) > at > org.apache.felix.scrplugin.tags.qdox.QDoxJavaField.getInitializationExpression(QDoxJavaField.java:44) > at > org.apache.felix.scrplugin.helper.PropertyHandler.getPropertyName(PropertyHandler.java:239) > A workaround is to add a 'dummy' dependency to i.e. slf4j-simple. But then > [WARNING] Unused declared dependencies found: > [WARNING] org.slf4j:slf4j-simple:jar:1.5.0:provided > Furthermore when the 'dummy' dependency has the wrong version, the scr plugin > might throw other errors: > java.lang.NoSuchFieldError: name > at org.slf4j.impl.Log4jLoggerAdapter.<init>(Log4jLoggerAdapter.java:75) > at > org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:75) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:103) > at > com.day.crx.spi.sharepoint.resource.SharepointResourceProvider.<clinit>(SharepointResourceProvider.java:60) > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) > at > sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) > at java.lang.reflect.Field.getFieldAccessor(Field.java:899) > at java.lang.reflect.Field.get(Field.java:358) > at > org.apache.felix.scrplugin.tags.ClassUtil.getInitializationExpression(ClassUtil.java:41) > at > org.apache.felix.scrplugin.tags.qdox.QDoxJavaField.getInitializationExpression(QDoxJavaField.java:44) > at > org.apache.felix.scrplugin.helper.PropertyHandler.getPropertyName(PropertyHandler.java:238) > I think such errors should be handled more gracefully indicating the source > of the problem. Also it should not be necessary to have a 'dummy' > dependencies. This was not the case up to version 1.4.1. > If it is absolutely necessary to include such dummy dependencies, the plugin > should state so in its error message. Also the slf4j case is so common that > it might be worth to considering a specific solution/workaround for this in > the plugin. This is still much better than forcing all clients to analyze the > problem from the stacktrace and then implement workarounds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira