Re: Extension does not work from .mvn/extensions.xml
On Fri, Nov 16, 2018 at 12:02 AM Romain Manni-Bucau
<[hidden email]> 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
> If your activator is registered it is injected and then used in the
> isActive loop if it returns true for presentInConfig call (check
> 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.
To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email]
> On Fri, Nov 16, 2018 at 3:35 PM Romain Manni-Bucau
> <[hidden email]> wrote:
> > I didnt find in the code where the hint matches, just saw a chain so
> > work if i didnt miss a later filtering.
> Where in the code is that?
The profile selector impl
> > That said my naming advise was for
> > the pom content more than the code (to not interpret default property
> I see. But if I add a new tag, then the POM wouldn't validate against
> the DTD, right? That seems like an undesirable path to take, no?
Idea is just to split them logically, property.name=yourprefix:xxxx not
> And even if I did change the POM content to have, let's say, an
> advancedProperty element under the XPath
> /project/profiles/profile/activation, what object in the model would
> be created when Maven reads the POM? It seems to me that it won't
> know how to create an object for this part of the POM in
> MavenXpp3Reader, so I don't understand how it would work. I would
> need it to be able to create an AdvancedActivationProperty, but I
> don't see a way to make it able to do that.
> > > Am I anywhere near understanding what you're suggesting?
> > You can mutate this model, this is all the trick ;)
> So, the hack I outlined is what you were thinking? I don't see how to
> do it any other way.
> > > 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.
> I see. I guess I don't know where to hook into the model, then. I
> can't find anything in the model that implements the is-active
> computation for a Profile or Activation, so I don't see how to hook
> into it other than mutating the model with the hack I previously
> proposed which was to evaluate the MVEL expression and replace the
> ActivationProperty with one with a specially constructed name and
> value that would always evaluate to the just computed result of the
> MVEL expression.
Idea was to set an activation which will match true with default impls
> So, in the approach where I have 4 implementations, how do I get Maven
> to use my AdvancedProfileActivator? I assumed this was done based on
> the Component annotation hint element, and I thought the hint had to
> match the element under the activation element in the POM (e.g.,
> <activation><property>...</property></activation> means the hint for
> Maven's PropertyProfileActivator must be "property", which it is).
> So, for <activation><advancedProperty>...</advancedProperty></activation>,
> the hint for my AdvancedProfileActivator must be "advancedProperty".
> If that's right, then that makes sense to me. But I still don't know
> how to get Maven to create an instance of AdvancedActivationProperty
> in the model when it reads the POM.
If you have plexus plugin it will do
> Sorry to not be understanding things. Thanks for your help! I really
> appreciate it!
> To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] >