Re: [GUMP@vmgump]: Project fulcrum-quartz-test (in module turbine-fulcrum) failed
Hi General Gump, On 19.11.11 05:33, fulcrum-quartz development wrote: > The following work was performed: > http://vmgump.apache.org/gump/public/turbine-fulcrum/fulcrum-quartz-test/gump_work/build_turbine-fulcrum_fulcrum-quartz-test.html > Work Name: build_turbine-fulcrum_fulcrum-quartz-test (Type: Build) > Work ended in a state of : Failed > Elapsed: 6 secs > Command Line: /opt/maven2/bin/mvn --batch-mode --settings > /srv/gump/public/workspace/turbine-fulcrum/quartz/gump_mvn_settings.xml test > [Working Directory: /srv/gump/public/workspace/turbine-fulcrum/quartz] > M2_HOME: /opt/maven2 > - > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) > at org.apache.maven.surefire.Surefire.run(Surefire.java:177) > 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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) > Caused by: java.lang.IllegalStateException: org.slf4j.LoggerFactory could not > be successfully initialized. See also > http://www.slf4j.org/codes.html#unsuccessfulInit > at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:275) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241) > at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254) > at > org.quartz.impl.StdSchedulerFactory.(StdSchedulerFactory.java:274) > at > org.apache.fulcrum.quartz.impl.QuartzSchedulerImpl.initialize(QuartzSchedulerImpl.java:114) > at > org.apache.fulcrum.yaafi.framework.component.AvalonServiceComponentImpl.initialize(AvalonServiceComponentImpl.java:404) > at > org.apache.fulcrum.yaafi.framework.component.AvalonServiceComponentImpl.incarnateInstance(AvalonServiceComponentImpl.java:106) > at > org.apache.fulcrum.yaafi.framework.component.ServiceComponentImpl.getInstance(ServiceComponentImpl.java:139) > at > org.apache.fulcrum.yaafi.framework.component.ServiceComponentImpl.incarnate(ServiceComponentImpl.java:154) > ... 31 more > Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 0.636 sec <<< > FAILURE! Could some kind soul enlighten me, WTF is going on here again? Is this a topic we can fix? Bye, Thomas. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: [GUMP@vmgump]: Project fulcrum-quartz-test (in module turbine-fulcrum) failed
Hi Thomas, On 2011-11-19, Thomas Vandahl wrote: >> Caused by: java.lang.IllegalStateException: org.slf4j.LoggerFactory could >> not be successfully initialized. See also >> http://www.slf4j.org/codes.html#unsuccessfulInit >> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:275) >> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241) >> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254) >> at >> org.quartz.impl.StdSchedulerFactory.(StdSchedulerFactory.java:274) >> at >> org.apache.fulcrum.quartz.impl.QuartzSchedulerImpl.initialize(QuartzSchedulerImpl.java:114) >> at >> org.apache.fulcrum.yaafi.framework.component.AvalonServiceComponentImpl.initialize(AvalonServiceComponentImpl.java:404) >> at >> org.apache.fulcrum.yaafi.framework.component.AvalonServiceComponentImpl.incarnateInstance(AvalonServiceComponentImpl.java:106) >> at >> org.apache.fulcrum.yaafi.framework.component.ServiceComponentImpl.getInstance(ServiceComponentImpl.java:139) >> at >> org.apache.fulcrum.yaafi.framework.component.ServiceComponentImpl.incarnate(ServiceComponentImpl.java:154) >> ... 31 more > Could some kind soul enlighten me, WTF is going on here again? I'm not sure. The major difference between a local build and Gump is the version of dependencies you pull in. This means you likely get a more recent version of SLF4J or Quartz than you have asked for and maybe this newer version needs some additional configuration. Looking through http://www.slf4j.org/codes.html#unsuccessfulInit and looking at http://vmgump.apache.org/gump/public/turbine-fulcrum/fulcrum-quartz-test/gump_work/build_turbine-fulcrum_fulcrum-quartz-test.html which has a java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder pretty far at the top of the log it may be a case of a missing binding. fulcrum-quartz doesn't seem to specifiy a dependency on SLF4J at all, so you pull it in via a transitive dependency. You depend on Quartz 2.0.0 whose POM depends on SLF4J but only the api dependency is non-optional. I don't know for sure how transitive dependendcies work in Maven but guess you don't inherit the optional slf4j-log4j binding. If it works for a local build then the most likely reason is some sort of change in SLF4J that it now requires one of the bindings to be available and didn't require it in the version you get locally. > Is this a topic we can fix? Not sure, it depends on whether you want to take explicit control over logging (I think you should, but don't know enough about fulcrum or even fulcrum-quartz) and provide some sort of slf4j binding (as optional dependency, I guess). If you don't want to do that then I currently don't see what you could do. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: [GUMP@vmgump]: Project fulcrum-quartz-test (in module turbine-fulcrum) failed
Hi Stefan, On 20.11.11 06:59, Stefan Bodewig wrote: > If it works for a local build then the most likely reason is some sort > of change in SLF4J that it now requires one of the bindings to be > available and didn't require it in the version you get locally. Well the build works fine locally, including tests and such. After all, I made release based on this code level. > Not sure, it depends on whether you want to take explicit control over > logging (I think you should, but don't know enough about fulcrum or even > fulcrum-quartz) and provide some sort of slf4j binding (as optional > dependency, I guess). If you don't want to do that then I currently > don't see what you could do. I don't like meddling with transitive dependencies. Probably I'll disable the fulcrum-quartz-test project in Gump. Bye, Thomas. - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
