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.
> 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?
> 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!
Lewis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
