maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. Lewis Muir" <>
Subject Re: Extension does not work from .mvn/extensions.xml
Date Fri, 16 Nov 2018 19:36:09 GMT
On Fri, Nov 16, 2018 at 12:02 AM Romain Manni-Bucau
<> wrote:
> For the marker i was thinking about "property" so your activation would be
> "el:name" or anything else - idea just being not intrusive and impacting
> for actual property activation.

I see.  I thought that, in order for the hijack to work, it needed to
use the same role hint; no?  I'll change the hint element to
"paa:property" (for Profile Activation Advanced property) or something

> Did you try to use an extension rewritting the model after it is read and
> before it is executed with a lifecycle participant? Sounds easier to
> implement since you just convert it to an active or not activation of a
> built in type.

No, I didn't try that.  That's an interesting idea!  The lifecycle
participant would give me a MavenSession object.  I can get to
ActivationProperty objects via


but this is just the model, not how the model is interpreted (i.e.,
how the profile is determined to be active or not).  I could examine
the ActivationProperty objects, and if they are the special ones I
want to handle (i.e., name is "mvel" or "mvel("
<properties-map-identifier> ")"), then I could evaluate the MVEL
expression and replace the ActivationProperty objects with ones that
would evaluate to true or false always (e.g., a property name I know
does not exist and using the negation operator or not to artificially
cause it to always evaluate to true or false).  That seems like a
hack, but maybe it's OK. (?)

And I wouldn't have the ProfileActivationContext object that I would
have in the ProfileActivator.isActive method.  But I guess I could
work around that by getting the things I need directly from the
MavenSession object (i.e., MavenSession.getSystemProperties() and
MavenSession.getUserProperties()), but would that be considered
correct, or would that likely break stuff?

Am I anywhere near understanding what you're suggesting?

> The IoC uses guice so it is notr trivial to use @priority but there are
> ways to do so, that said i dont think you need checking the profile logic.

OK, I'll put this approach on the back burner and only come back to it
if I can't get the lifecycle participant approach to work.

> The default model builder is used when there is no IoC so shouldn't be used
> here.

OK, great.

> If your activator is registered it is injected and then used in the
> isActive loop if it returns true for presentInConfig call (check
> DefaultProfileSelector).
> This is likely where you will have to debug.

But my problem is getting my activator to be injected instead of the
regular one.  I think that's where the @Priority annotation comes in.
But I think you're suggesting the lifecycle participant approach would
be easier, so I'm trying that now.

Thank you!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message