You may also want to note as part of making plugins for Maven 3.x is that we should encourage people _not_ to inject SLF4J loggers. I'll send out another thread, but I'd like to update to the non-fork Guice 4.0 but there might be a couple instances of using injected SLF4J loggers in places. I honestly doubt many people are making JSR330 plugins yet anyway but I think it's good to note.
On May 14, 2015, at 3:52 PM, Robert Scholte <rfscho...@apache.org> wrote: > I've started this page based on my first experiences and things mentioned in > this mailthread: > > https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies > > Op Fri, 01 May 2015 23:02:39 +0200 schreef Dennis Lundberg > <denn...@apache.org>: > >> Not really deps related, but we should make sure that we use the >> correct package names when upgrading plugins to require Maven 3. Many >> plugins use org.apache.maven.plugin as the package name, but it should >> be org.apache.maven.plugins (with an s at the end) to match our >> groupId. >> >> On Thu, Apr 30, 2015 at 10:43 PM, Robert Scholte <rfscho...@apache.org> >> wrote: >>> Not that I'm aware of, but I can think of several steps: >>> - compile/runtime should not depend on maven-compat (the >>> plugin-testing-harness still requires it, so test-scope is still required, >>> though) >>> - consider testing with a Maven distribution without maven-compat >>> - use the major release to do housekeeping: remove deprecated parameters, >>> use direct M3 method calls instead of by reflection. >>> >>> I'm working on artifact/dependency related issues for the install, invoker >>> and deploy plugins. >>> I've created branches for these to give me enough time to fix this >>> correctly. >>> >>> thanks, >>> Robert >>> >>> Op Thu, 30 Apr 2015 22:29:18 +0200 schreef Kristian Rosenvold >>> <kristian.rosenv...@gmail.com>: >>> >>> >>>> Do we have any wiki page describing the migration steps that would be >>>> recommended to move a plugin from 2.2.1 deps to 3.x deps ? >>>> >>>> I'm thinking *both* in terms of avoiding deprecations and "other" troubles >>>> that may arise ? >>>> >>>> Kristian >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> > > --------------------------------------------------------------------- > 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, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org