maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@takari.io>
Subject Re: reactorProjects vs. session.getProjects() Was: Re: Adding a classpath element within a Mojo
Date Thu, 06 Feb 2014 02:59:04 GMT
Yes.

On Feb 5, 2014, at 4:05 PM, Mirko Friedenhagen <mfriedenhagen@gmail.com> wrote:

> Hello,
> 
> just for my understanding:
> - Does the property reactorProjects[0] hold the projects in reactor build order?
> 
> Regards Mirko
> [0] https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68
> 
> On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko <igor@ifedorenko.com> wrote:
>> Maven first calls #afterProjectsRead(MavenSession), then calculates
>> reactor build order. So session.getProjects() still returns unsorted
>> project list during afterProjectsRead, which most likely does not matter
>> in your case.
>> 
>> --
>> Regards,
>> Igor
>> 
>> 
>> On 2/4/2014, 17:47, William Ferguson wrote:
>>> 
>>> Can you explain the need to establish the reactor build order? I had
>>> expected session.getProjects() to have returned modules in the order they
>>> are defined. Are you saying that is not the case and that it would need to
>>> be configured by the LifeCycleParticipant?
>>> 
>>> I think I can make the hack work. So I'll go with that for now. But I'd
>>> like to be able to annotate that with an issue number if there are plans
>>> to
>>> enhance the API on this front so that we know what and when to replace.
>>> 
>>> I'd love to help enhance Maven (I have plenty to pay back for the hours it
>>> has saved me over the years) but I don't have the band width right now and
>>> I also don't feel like I have a good enough understanding of the Maven
>>> core. But as I said before if you think this is a worthwhile enterprise
>>> then help me create an issue that spells out what you think needs doing
>>> and
>>> I'll try to get back to it in a couple of months.
>>> 
>>> William
>>> 
>>> 
>>> 
>>> On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko <igor@ifedorenko.com>
>>> wrote:
>>> 
>>>> 
>>>> On 2/4/2014, 1:06, William Ferguson wrote:
>>>> 
>>>>> OK, I'm getting the dependencies to resolve and I can amend the
>>>>> classpath,
>>>>> but I think I've hit a road block for multi module builds.
>>>>> 
>>>>> LifeCycleParticipant is only ever called once at the root. This means
>>>>> that
>>>>> if I have a project with 2 modules where ModuleB depends on ModuleA then
>>>>> I'm not going to be able extract and add ModuleA and it's classes when
>>>>> the
>>>>> LifeCycleParticipant executes because ModuleA will not have been built
>>>>> yet.
>>>>> 
>>>>> Is there some way to get the LifeCycleParticipant called for every
>>>>> module
>>>>> of the build?
>>>>> 
>>>>> 
>>>> Looks like there are two related but distinct concerns there.
>>>> 
>>>> First, it is necessary to establish reactor build order. This must
>>>> happen before actual build starts and lifecycle participant provides a
>>>> way to do this.
>>>> 
>>>> Second, it is necessary to resolve dependencies among reactor modules.
>>>> This has to happen as part of the build itself and I don't think there
>>>> is an API for that yet.
>>>> 
>>>> One hack-ish way to workaround this is to resolve reactor dependencies
>>>> is to create empty directories from lifecycle participant,
>>>> ModuleA/target/something in your case, and make sure ModuleA's build
>>>> populates the directory with expected files.
>>>> 
>>>> Proper solution requires changes to maven core. I can provide some
>>>> pointers if you want to try this.
>>>> 
>>>> --
>>>> Regards,
>>>> Igor
>>>> 
>>>> 
>>>>  William
>>>>> 
>>>>> 
>>>>> William
>>>>> 
>>>>> 
>>>>> On Tue, Feb 4, 2014 at 12:46 PM, William Ferguson <
>>>>> william.ferguson@xandar.com.au> wrote:
>>>>> 
>>>>>  Igor,
>>>>>> 
>>>>>> 
>>>>>> I've worked out how to modify the project classpath (pretty trivial).
>>>>>> But
>>>>>> I'm struggling to get the project dependencies resolved during
>>>>>> LifeCycleParticipant#afterProjectsRead.
>>>>>> 
>>>>>> I tried using the TychoDependencyResolver to #setupProject and
>>>>>> #resolveProject but that isn't causing the projects dependencies
to get
>>>>>> resolved. I'm not sure what I'm missing.
>>>>>> 
>>>>>> I've created a cut down project dep-resolution-plugin at
>>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin.git
>>>>>> And a project that tests that plugin at
>>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin-test.git
>>>>>> If you could have a look and point out what it is I'm missing I'd
be
>>>>>> most
>>>>>> grateful.
>>>>>> 
>>>>>> William
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Sat, Jan 25, 2014 at 6:57 AM, William Ferguson <
>>>>>> william.ferguson@xandar.com.au> wrote:
>>>>>> 
>>>>>>  Maven 3.1.1 official, and all the plugin dependencies are 3.,1.1
too.
>>>>>>> 
>>>>>>> 
>>>>>>> I'll trying switching to the annotations. Javadoc annotations
were
>>>>>>> just
>>>>>>> for conformity with the rest of the project.
>>>>>>> 
>>>>>>> If that doesn't work, I'll put together a cut down example.
>>>>>>> 
>>>>>>> Thanks.
>>>>>>> 
>>>>>>> William
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Jan 23, 2014 at 9:43 PM, Igor Fedorenko <igor@ifedorenko.com
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>  No, no tricks, as far as I know Plexus (and now Sisu/Guice)
only
>>>>>>> inject
>>>>>>>> 
>>>>>>>> fully configured components. so the behaviour you describe
is rather
>>>>>>>> odd.
>>>>>>>> 
>>>>>>>> What version of Maven do you use? Is it official distribution
from
>>>>>>>> Apache or something you built locally?
>>>>>>>> 
>>>>>>>> Not likely related, but I haven't used javadoc plexus annotations
in
>>>>>>>> ages. Any particular reason you don't want to use java 5
@Component?
>>>>>>>> 
>>>>>>>> In any case, if you can provide small standalone example
that shows
>>>>>>>> the
>>>>>>>> problem, I can try to see what's going on there.
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Igor
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 1/23/2014, 0:54, William Ferguson wrote:
>>>>>>>> 
>>>>>>>>  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
>>>>>>>>> <igor@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 AbstractMavenLifecycleParticip
>>>>>>>>>>> ant#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
<
>>>>>>>>>>> igor@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-unsubscribe@maven.apache.org
>>>>>>>>>>>> 
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>    ------------------------------------------------------------
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> ---------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>  ------------------------------------------------------------
>>>>>>>> 
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

the course of true love never did run smooth ...

 -- Shakespeare










Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message