Obviously if it doesnt affect m2e (and this is known ?) its less of a problem.
In that case it means it'll just be a PITA for those 10-or so projects that use verifier here at asf and any others. I am no fan of releasing a version I wouldn't want to use myself, so I think this needs to be fixed - it's *our* time that will be wasted in the future if we let this through. So changing verifier to use a better approach may come, but I'm not sure it should come for /this/ reason? Is this for some reason a hard issue to fix ? Kristian 2012/12/4 Kristian Rosenvold <kristian.rosenv...@gmail.com>: > The severity of the issue is less > > 2012/12/4 Jason van Zyl <ja...@tesla.io>: >> Our build server appears out, and I wanted to get off my machine so I spun >> up an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears >> to be the problem. >> >> Obviously this affects people who embed, but won't affect CLI users. The >> major use case is m2e and it already uses SLF4J with logback so I don't see >> any issues there, but if others are concerned I'll track it down. >> >> On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold >> <kristian.rosenv...@gmail.com> wrote: >> >>> The core it's were running against 1.4-SNAPSHOT of the verifier and I >>> had introduced a minor compatibility problem when adding generics >>> which caused them to not compile. That is fixed on verifier trunk now. >>> >>> I just ran the following core it's, and they run lightning fast & razor >>> sharp: >>> >>> mvn304 -Pembedded,run-its clean install # success, 5min 11 sec >>> mvn31 -Pembedded,run-its clean install # At >>> 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were >>> fixed in later 3.1 versions - as expected) >>> mvn31 -Pembedded,run-its clean install # At >>> 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures >>> for instance mng4829 >>> >>> So the problem was introduced with slf4j; case closed. >>> >>> Kristian >>> >>> >>> >>> 2012/12/4 Jason van Zyl <ja...@tesla.io>: >>>> M >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder & CTO, Sonatype >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> believe nothing, no matter where you read it, >> or who has said it, >> not even if i have said it, >> unless it agrees with your own reason >> and your own common sense. >> >> -- Buddha >> >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
