maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: Extension does not work from .mvn/extensions.xml
Date Fri, 16 Nov 2018 21:35:18 GMT
Le ven. 16 nov. 2018 20:36, J. Lewis Muir <> a écrit :

> 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
> similar.

I didnt find in the code where the hint matches, just saw a chain so should
work if i didnt miss a later filtering. That said my naming advise was for
the pom content more than the code (to not interpret default property tag).

> > 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
>   MavenSession.getProjects()
>     MavenProject.getModel()
>       Model.getProfiles()
>         Profile.getActivation()
>           Activation.getProperty()
> 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?

You can mutate this model, this is all the trick ;)

> > 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.

Not instead but also. Instead of 3 impl you will get 4.

> Thank you!
> Lewis
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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