maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. Lewis Muir" <>
Subject Re: Extension does not work from .mvn/extensions.xml
Date Sat, 17 Nov 2018 16:05:44 GMT
On Sat, Nov 17, 2018 at 1:53 AM Romain Manni-Bucau
<> wrote:
> > > 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

OK, I'm just trying to make sure I understanding that.  The default
activation impls are ActivationFile (file), ActivationOS (os),
ActivationProperty (property), and String (jdk).  The default
activator impls are FileProfileActivator,
OperatingSystemProfileActivator, PropertyProfileActivator, and
JdkVersionProfileActivator.  The idea would match true with these
default impls, right?  And the only way to make it match true with
these default impls would be to replace the ActivationProperty
instances in the model that need the special MVEL evaluation with new
ActivationProperty instances that will always evaluate to true or
false according to the pre-computed MVEL evaluation results, right?
In this approach, there would be no new impls (i.e., no
AdvancedActivationProperty and no AdvancedProfileActivator).

Another thought I had is that I could modify the active-profiles list
of the MavenProject instances (i.e., MavenProject.setActiveProfiles)
of the model to include or exclude the profiles with the special MVEL
activation based on the result of evaluating those MVEL expressions.
Then I wouldn't need to do the hack of changing the ActivationProperty
instances to always evaluate to true or false according to the
pre-computed result of the MVEL evaluation.  Wouldn't that work?
This, however, does not seem the same as your description of the idea
of setting an activation that would "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

Hmm, so to date I've been implementing this as a core extension, not
as a Plexus plugin (if I'm understanding terminology correctly).  Are
you suggesting it would be better to implement this as a Plexus

Also, based on your previous comments, I don't think you're suggesting
at all doing this thing of adding a new tag (e.g.,
since you said you were thinking of the separation logically, not
physically in the XML.

Thank you!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message