maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: Guice provision error with AbstractMavenLifecycleParticipant
Date Sat, 01 Mar 2014 20:23:13 GMT
On 1 Mar 2014, at 19:12, William Ferguson <william.ferguson@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


Mime
View raw message