On Sat, Nov 17, 2018 at 1:53 AM Romain Manni-Bucau <rmannibu...@gmail.com> 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 plugin? 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. Thank you! Lewis --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
