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

Reply via email to