You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by William Ferguson <wi...@xandar.com.au> on 2014/03/01 20:12:43 UTC
Re: Guice provision error with AbstractMavenLifecycleParticipant
Thanks for the exceptionally clear explanation Stuart.
I don't think we can just avoid the exception with stubbed implementations
of the Resolver because the the plugin doesn't use the Resolver directly.
It asks for an Aether RepositorySystem:
@Requirement
private RepositorySystem repoSystem;
which is what instantiates the VersionResolver.
I'll have another look at maven-dependency-tree but I didn't see a clear
path towards what we wanted.
Could you shed some more light on:
> Unfortunately adding a direct plugin dependency to the
maven-aether-provider from 3.1.1 won't help
> because Maven will filter out this dependency as being supplied from
Maven core
What's doing the filtering and why?
What would be need to make it not filter out a maven-core library that is a
different version of the running Maven instance?
William
On Fri, Feb 28, 2014 at 12:13 PM, Stuart McCulloch <mc...@gmail.com>wrote:
> On 28 Feb 2014, at 01:17, William Ferguson <wi...@xandar.com.au>
> wrote:
>
> > As part of the development of the android-maven-plugin we have need to
> add
> > in an AbstractMavenLifecycleParticipant so that we can modify the compile
> > classpath to add artefacts that are contained within a project's
> > dependencies. Igor provided a lot of the coaching on this.
> >
> > The build works fine. Does what is intended.
> >
> > But now, when you open a project in intelliJ13 that uses the
> > android-maven-plugin, IntelliJ declares a problem with the POM that
> > references our MavenLifecycleParticipant.
> >
> > What I'd like help with is:
> > 1) Is this a problem with the plugin itself. Ie have we defined something
> > incorrectly.
> > 2) Is it just a problem with how IntelliJ is parsing a POM that declares
> > the plugin.
> >
> > If it is (1), what do we need to do to fix it?
> >
> > However, I suspect it is (2) because similar error messages seem to occur
> > when plugins designed for Maven 3.1 (and the switch to Eclipse Aether
> from
> > Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that
> > maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and
> would
> > love some clarity from those who understand what is going on a bit
> better.
> > And if it is (2) is there anything we or IntelliJ can do to fix it?
> >
> > The plugin itself can be found at:
> > https://github.com/jayway/maven-android-plugin
> >
> > A project showing the failure can be found at:
> >
> https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app
> >
> > And the error message is (visible via flyover in the POM editor window or
> > in idea.log):
>
> I can recreate the same exception on the command-line using the plugin
> with Maven 3.0.5 (after I removed the 3.1.1 pre-req from the plugin's
> pom.xml)
>
> The issue is that the plugin expects Maven core to supply an
> implementation of org.eclipse.aether.impl.VersionResolver, namely
> DefaultVersionResolver from maven-aether-provider.
>
> However in Maven 3.0.x the maven-aether-provider module only supplies an
> implementation of org.sonatype.aether.impl.VersionResolver ... which is why
> you see that exception :/
>
> Unfortunately adding a direct plugin dependency to the
> maven-aether-provider from 3.1.1 won't help because Maven will filter out
> this dependency as being supplied from Maven core
>
> If you want the plugin to work on both Maven 3.0.x and 3.1.x then you'll
> either need to use an API common to both (like the shared
> maven-dependency-tree component) or write two versions of the code that
> talks to Aether and select the appropriate one at runtime using reflection.
> But if you just want to avoid the exception when Intellij processes the
> pom.xml then you could conceivably provide dummy/stubbed @Component
> implementations of the Eclipse/Aether resolver, with the role set to a
> non-default value such as "dummy" so that it doesn't interfere with the
> default implementation provided in Maven 3.1.1
>
> > java.lang.RuntimeException: com.google.inject.ProvisionException:
> > Guice provision errors:
> >
> > 1) No implementation for org.eclipse.aether.impl.VersionResolver was
> bound.
> > while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
> > at
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> > parent: sun.misc.Launcher$AppClassLoader@39172e08]
> > at
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> > parent: sun.misc.Launcher$AppClassLoader@39172e08]
> > while locating org.eclipse.aether.RepositorySystem
> > while locating
> >
> com.jayway.maven.plugins.android.phase_prebuild.AarMavenLifecycleParticipant
> > at
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> > parent: sun.misc.Launcher$AppClassLoader@39172e08]
> > at
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> > parent: sun.misc.Launcher$AppClassLoader@39172e08]
> > while locating org.apache.maven.AbstractMavenLifecycleParticipant
> > annotated with
> @com.google.inject.name.Named(value=AarMavenLifecycleListener)
> >
> >
> > We are tracking this at:
> > https://code.google.com/p/maven-android-plugin/issues/detail?id=449
> >
> >
> > Any help appreciated.
> >
> >
> > William
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Guice provision error with AbstractMavenLifecycleParticipant
Posted by William Ferguson <wi...@xandar.com.au>.
Just for anyone coming after me ..
Ended up rewriting everything that referenced Aether to use dependency-tree
instead. It was definitely the way to go. Made everything much cleaner and
simpler and firewalled up from directly using Maven 3.0 or 3.1 code.
Thanks for all your help Stuart. It was much appreciated.
William
On Sun, Mar 2, 2014 at 6:23 AM, Stuart McCulloch <mc...@gmail.com> wrote:
> On 1 Mar 2014, at 19:12, William Ferguson <wi...@xandar.com.au>
> wrote:
>
> > Thanks for the exceptionally clear explanation Stuart.
> >
> > I don't think we can just avoid the exception with stubbed
> implementations
> > of the Resolver because the the plugin doesn't use the Resolver directly.
> > It asks for an Aether RepositorySystem:
> > @Requirement
> > private RepositorySystem repoSystem;
> >
> > which is what instantiates the VersionResolver.
>
> I don't think this is an issue, just declaring a dummy component locally
> using @Component should satisfy the missing binding that leads to the
> original exception.
>
> In other words: at the moment you have a broken dependency chain that
> stops Guice from creating an instance of the repository system - if you
> provide a dummy link in the form of a local @Component(hint="dummy") that
> implements VersionResolver then the chain will be complete from the
> perspective of the current plugin and the repository system can be created.
> Of course you can't then do much with it because it would be using the
> dummy resolver, but it would avoid the original exception at creation time
> and allow the IntelliJ pom processing to continue. Note you may also need
> to stub out other resolver components required by the repository system.
>
> Of course as Manfred points out, if IntelliJ updated their bundled version
> of Maven to 3.1.x or later then that would also solve the problem and
> doesn't require any plugin changes.
>
> > I'll have another look at maven-dependency-tree but I didn't see a clear
> > path towards what we wanted.
> >
> > Could you shed some more light on:
> >> Unfortunately adding a direct plugin dependency to the
> > maven-aether-provider from 3.1.1 won't help
> >> because Maven will filter out this dependency as being supplied from
> > Maven core
> >
> > What's doing the filtering and why?
>
> IIRC this is done in DefaultClassRealmManager from maven-core... the reason
> it filters out dependencies/packages explicitly exported by core is to
> avoid class consistency issues, otherwise you could end up with the same
> class being defined twice, once by the core class loader and once by a
> plugin's class loader. Such classes would then be incompatible as they were
> defined by different class loaders and couldn't then be used for sharing
> data, such as sharing repository information between core and a plugin.
>
> > What would be need to make it not filter out a maven-core library that
> is a
> > different version of the running Maven instance?
>
> You can't without doing some complicated class loader hacks, this is a
> fundamental feature of Maven's plugin system.
>
> > William
> >
> > On Fri, Feb 28, 2014 at 12:13 PM, Stuart McCulloch <mcculls@gmail.com
> >wrote:
> >
> >> On 28 Feb 2014, at 01:17, William Ferguson <
> william.ferguson@xandar.com.au>
> >> wrote:
> >>
> >>> As part of the development of the android-maven-plugin we have need to
> >> add
> >>> in an AbstractMavenLifecycleParticipant so that we can modify the
> compile
> >>> classpath to add artefacts that are contained within a project's
> >>> dependencies. Igor provided a lot of the coaching on this.
> >>>
> >>> The build works fine. Does what is intended.
> >>>
> >>> But now, when you open a project in intelliJ13 that uses the
> >>> android-maven-plugin, IntelliJ declares a problem with the POM that
> >>> references our MavenLifecycleParticipant.
> >>>
> >>> What I'd like help with is:
> >>> 1) Is this a problem with the plugin itself. Ie have we defined
> something
> >>> incorrectly.
> >>> 2) Is it just a problem with how IntelliJ is parsing a POM that
> declares
> >>> the plugin.
> >>>
> >>> If it is (1), what do we need to do to fix it?
> >>>
> >>> However, I suspect it is (2) because similar error messages seem to
> occur
> >>> when plugins designed for Maven 3.1 (and the switch to Eclipse Aether
> >> from
> >>> Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that
> >>> maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and
> >> would
> >>> love some clarity from those who understand what is going on a bit
> >> better.
> >>> And if it is (2) is there anything we or IntelliJ can do to fix it?
> >>>
> >>> The plugin itself can be found at:
> >>> https://github.com/jayway/maven-android-plugin
> >>>
> >>> A project showing the failure can be found at:
> >>>
> >>
> https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app
> >>>
> >>> And the error message is (visible via flyover in the POM editor window
> or
> >>> in idea.log):
> >>
> >> I can recreate the same exception on the command-line using the plugin
> >> with Maven 3.0.5 (after I removed the 3.1.1 pre-req from the plugin's
> >> pom.xml)
> >>
> >> The issue is that the plugin expects Maven core to supply an
> >> implementation of org.eclipse.aether.impl.VersionResolver, namely
> >> DefaultVersionResolver from maven-aether-provider.
> >>
> >> However in Maven 3.0.x the maven-aether-provider module only supplies an
> >> implementation of org.sonatype.aether.impl.VersionResolver ... which is
> why
> >> you see that exception :/
> >>
> >> Unfortunately adding a direct plugin dependency to the
> >> maven-aether-provider from 3.1.1 won't help because Maven will filter
> out
> >> this dependency as being supplied from Maven core
> >>
> >> If you want the plugin to work on both Maven 3.0.x and 3.1.x then you'll
> >> either need to use an API common to both (like the shared
> >> maven-dependency-tree component) or write two versions of the code that
> >> talks to Aether and select the appropriate one at runtime using
> reflection.
> >> But if you just want to avoid the exception when Intellij processes the
> >> pom.xml then you could conceivably provide dummy/stubbed @Component
> >> implementations of the Eclipse/Aether resolver, with the role set to a
> >> non-default value such as "dummy" so that it doesn't interfere with the
> >> default implementation provided in Maven 3.1.1
> >>
> >>> java.lang.RuntimeException: com.google.inject.ProvisionException:
> >>> Guice provision errors:
> >>>
> >>> 1) No implementation for org.eclipse.aether.impl.VersionResolver was
> >> bound.
> >>> while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
> >>> at
> >>
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> >>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
> >>> at
> >>
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> >>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
> >>> while locating org.eclipse.aether.RepositorySystem
> >>> while locating
> >>>
> >>
> com.jayway.maven.plugins.android.phase_prebuild.AarMavenLifecycleParticipant
> >>> at
> >>
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> >>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
> >>> at
> >>
> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
> >>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
> >>> while locating org.apache.maven.AbstractMavenLifecycleParticipant
> >>> annotated with
> >> @com.google.inject.name.Named(value=AarMavenLifecycleListener)
> >>>
> >>>
> >>> We are tracking this at:
> >>> https://code.google.com/p/maven-android-plugin/issues/detail?id=449
> >>>
> >>>
> >>> Any help appreciated.
> >>>
> >>>
> >>> William
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Guice provision error with AbstractMavenLifecycleParticipant
Posted by Stuart McCulloch <mc...@gmail.com>.
On 1 Mar 2014, at 19:12, William Ferguson <wi...@xandar.com.au> wrote:
> Thanks for the exceptionally clear explanation Stuart.
>
> I don't think we can just avoid the exception with stubbed implementations
> of the Resolver because the the plugin doesn't use the Resolver directly.
> It asks for an Aether RepositorySystem:
> @Requirement
> private RepositorySystem repoSystem;
>
> which is what instantiates the VersionResolver.
I don’t think this is an issue, just declaring a dummy component locally using @Component should satisfy the missing binding that leads to the original exception.
In other words: at the moment you have a broken dependency chain that stops Guice from creating an instance of the repository system - if you provide a dummy link in the form of a local @Component(hint=“dummy") that implements VersionResolver then the chain will be complete from the perspective of the current plugin and the repository system can be created. Of course you can’t then do much with it because it would be using the dummy resolver, but it would avoid the original exception at creation time and allow the IntelliJ pom processing to continue. Note you may also need to stub out other resolver components required by the repository system.
Of course as Manfred points out, if IntelliJ updated their bundled version of Maven to 3.1.x or later then that would also solve the problem and doesn’t require any plugin changes.
> I'll have another look at maven-dependency-tree but I didn't see a clear
> path towards what we wanted.
>
> Could you shed some more light on:
>> Unfortunately adding a direct plugin dependency to the
> maven-aether-provider from 3.1.1 won't help
>> because Maven will filter out this dependency as being supplied from
> Maven core
>
> What's doing the filtering and why?
IIRC this is done in DefaultClassRealmManager from maven-core… the reason it filters out dependencies/packages explicitly exported by core is to avoid class consistency issues, otherwise you could end up with the same class being defined twice, once by the core class loader and once by a plugin’s class loader. Such classes would then be incompatible as they were defined by different class loaders and couldn’t then be used for sharing data, such as sharing repository information between core and a plugin.
> What would be need to make it not filter out a maven-core library that is a
> different version of the running Maven instance?
You can’t without doing some complicated class loader hacks, this is a fundamental feature of Maven’s plugin system.
> William
>
> On Fri, Feb 28, 2014 at 12:13 PM, Stuart McCulloch <mc...@gmail.com>wrote:
>
>> On 28 Feb 2014, at 01:17, William Ferguson <wi...@xandar.com.au>
>> wrote:
>>
>>> As part of the development of the android-maven-plugin we have need to
>> add
>>> in an AbstractMavenLifecycleParticipant so that we can modify the compile
>>> classpath to add artefacts that are contained within a project's
>>> dependencies. Igor provided a lot of the coaching on this.
>>>
>>> The build works fine. Does what is intended.
>>>
>>> But now, when you open a project in intelliJ13 that uses the
>>> android-maven-plugin, IntelliJ declares a problem with the POM that
>>> references our MavenLifecycleParticipant.
>>>
>>> What I'd like help with is:
>>> 1) Is this a problem with the plugin itself. Ie have we defined something
>>> incorrectly.
>>> 2) Is it just a problem with how IntelliJ is parsing a POM that declares
>>> the plugin.
>>>
>>> If it is (1), what do we need to do to fix it?
>>>
>>> However, I suspect it is (2) because similar error messages seem to occur
>>> when plugins designed for Maven 3.1 (and the switch to Eclipse Aether
>> from
>>> Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that
>>> maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and
>> would
>>> love some clarity from those who understand what is going on a bit
>> better.
>>> And if it is (2) is there anything we or IntelliJ can do to fix it?
>>>
>>> The plugin itself can be found at:
>>> https://github.com/jayway/maven-android-plugin
>>>
>>> A project showing the failure can be found at:
>>>
>> https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app
>>>
>>> And the error message is (visible via flyover in the POM editor window or
>>> in idea.log):
>>
>> I can recreate the same exception on the command-line using the plugin
>> with Maven 3.0.5 (after I removed the 3.1.1 pre-req from the plugin's
>> pom.xml)
>>
>> The issue is that the plugin expects Maven core to supply an
>> implementation of org.eclipse.aether.impl.VersionResolver, namely
>> DefaultVersionResolver from maven-aether-provider.
>>
>> However in Maven 3.0.x the maven-aether-provider module only supplies an
>> implementation of org.sonatype.aether.impl.VersionResolver ... which is why
>> you see that exception :/
>>
>> Unfortunately adding a direct plugin dependency to the
>> maven-aether-provider from 3.1.1 won't help because Maven will filter out
>> this dependency as being supplied from Maven core
>>
>> If you want the plugin to work on both Maven 3.0.x and 3.1.x then you'll
>> either need to use an API common to both (like the shared
>> maven-dependency-tree component) or write two versions of the code that
>> talks to Aether and select the appropriate one at runtime using reflection.
>> But if you just want to avoid the exception when Intellij processes the
>> pom.xml then you could conceivably provide dummy/stubbed @Component
>> implementations of the Eclipse/Aether resolver, with the role set to a
>> non-default value such as "dummy" so that it doesn't interfere with the
>> default implementation provided in Maven 3.1.1
>>
>>> java.lang.RuntimeException: com.google.inject.ProvisionException:
>>> Guice provision errors:
>>>
>>> 1) No implementation for org.eclipse.aether.impl.VersionResolver was
>> bound.
>>> while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
>>> at
>> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
>>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
>>> at
>> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
>>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
>>> while locating org.eclipse.aether.RepositorySystem
>>> while locating
>>>
>> com.jayway.maven.plugins.android.phase_prebuild.AarMavenLifecycleParticipant
>>> at
>> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
>>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
>>> at
>> ClassRealm[extension>com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1,
>>> parent: sun.misc.Launcher$AppClassLoader@39172e08]
>>> while locating org.apache.maven.AbstractMavenLifecycleParticipant
>>> annotated with
>> @com.google.inject.name.Named(value=AarMavenLifecycleListener)
>>>
>>>
>>> We are tracking this at:
>>> https://code.google.com/p/maven-android-plugin/issues/detail?id=449
>>>
>>>
>>> Any help appreciated.
>>>
>>>
>>> William
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org