maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
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 <jlmuir@imca-cat.org> a écrit :

> On Fri, Nov 16, 2018 at 12:02 AM Romain Manni-Bucau
> <rmannibucau@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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