Le sam. 17 nov. 2018 17:06, J. Lewis Muir <jlm...@imca-cat.org> a écrit :
> 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." > 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
