Igor,

I'm having some difficulty getting the LifecycleParticipant to resolve
Maven components.

In particular, the org.apache.maven.project.ProjectDependenciesResolver.
While it gets resolved, none of it's internal attributes get resolved. So
calls to projectDependenciesResolver.resolve crash with NPEs because
DefaultProjectDependenciesResolver#logger or #repoSystem is not initialised.

    /**
     * @component
     * @readonly
     * @required
     */
    protected ProjectDependenciesResolver projectDependenciesResolver;

Is there some special trick to getting components fully initialised in a
LifecycleParticipant?

William


On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko <i...@ifedorenko.com>wrote:

> Here is Tycho lifecycle participant [1] and here is the code that
> injects new dependencies in MavenProject instances [2].
>
>
> [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
> TychoMavenLifecycleParticipant.java?h=tycho-0.19.x
> [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
> MavenDependencyInjector.java?h=tycho-0.19.x
>
> --
> Regards,
> Igor
>
>
> On 1/20/2014, 8:21, William Ferguson wrote:
>
>> Thanks Igor,
>>
>> could you give me a link to an example or some code that
>>
>>     - Utilises AbstractMavenLifecycleParticipant#afterProjectsRead
>>     - How to manipulate the project <dependencies> from there.
>>
>>
>> I found an example example by Brett Porter, but the doco is pretty thin
>> and
>> I can't see how I would go about inject extra elements into the classpath
>> from there.
>>
>> William
>>
>>
>> On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko <i...@ifedorenko.com
>> >wrote:
>>
>>  There is probably more ways to do this, but you can implement
>>> AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate
>>> project <dependencies>. This is what we do in Tycho, where we resolve
>>> project OSGi dependencies in AbstractMavenLifecycleParticipant and then
>>> inject that into Maven project model as system scoped maven dependencies.
>>>
>>> I also think your usecase highlights general deficiency with current
>>> dependency model. Since you have to add classpath elements dynamically,
>>> these elements are not visible to maven-based tools like m2e without
>>> additional effort on the tools part. I think it will be useful to extend
>>> <dependency> element syntax to allow references for nested
>>> archive entries, i.e. "dependency on classes jar nested within this AAR
>>> archive".
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>> On 1/20/2014, 7:00, William Ferguson wrote:
>>>
>>>  Hi,
>>>>
>>>> I realise this question isn't exactly related to dev within the Maven
>>>> components, but it is about developing a Mojo using components that have
>>>> to
>>>> be pretty central and don't appear to be obviously documented anywhere.
>>>> And
>>>> I ahve asked on maven-users without much luck.
>>>>
>>>> As part of the android-maven-plugin we have a Mojo which needs to add an
>>>> element to the compile time classpath for future Mojos (specifically the
>>>> maven-compiler-plugin).
>>>>
>>>> Project has dependencies on artifacts of type AAR (Android archive - an
>>>> archive that contains several sub-artifacts including a classes jar).
>>>>
>>>> Our Mojo unpacks the AAR artifacts and makes the sub-artifacts available
>>>> to
>>>> other build components.
>>>>
>>>> One of those build components is the maven-compiler-plugin. We want to
>>>> add
>>>> the classes contained in the AAR dependencies to the compile classpath
>>>> so
>>>> that the maven-compiler-plugin can compile our classes against the
>>>> classes
>>>> from the AARs.
>>>>
>>>> How do we do that?
>>>>
>>>>
>>>> William
>>>>
>>>>
>>>>  ---------------------------------------------------------------------
>>> 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
>
>

Reply via email to