Le ven. 16 nov. 2018 20:36, J. Lewis Muir <jlm...@imca-cat.org> a écrit :
> On Fri, Nov 16, 2018 at 12:02 AM Romain Manni-Bucau
> <rmannibu...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
