maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: Extension does not work from .mvn/extensions.xml
Date Sat, 17 Nov 2018 17:32:36 GMT
Le sam. 17 nov. 2018 17:06, J. Lewis Muir <> a écrit :

> 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."

Here you change the activation to match a default logic evaluation or you
change profiles and model to be pre activated. Personally i prefer to keep
profile cause it eases debugging but both work.

> > > 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
> plugin?

This is not two things incompatible actually but yes. In short an extension
integrates with maven lifecycle and plexus with maven ioc (lower level).

> 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.,
> <activation><advancedProperty>...</advancedProperty></activation>),
> since you said you were thinking of the separation logically, not
> physically in the XML.

Would break several tooling to do that so likely not a good bet.

> Thank you!
> Lewis
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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