On Sat, Nov 17, 2018 at 11:32 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le sam. 17 nov. 2018 17:06, J. Lewis Muir <jlm...@imca-cat.org> a écrit : > > > 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.
Hmm, I can't get it to work. :-( I created my own lifecycle participant by extending AbstractMavenLifecycleParticipant and overrode afterProjectsRead, but the profile activation has already been evaluated by the time this method is called. That means I would have to trigger evaluation again after I changed the ActivationProperty to always evaluate to true or false to match the result of the MVEL expression evaluation. I could re-evaluate the profile activation with DefaultProfileSelector, but if something else is injecting a different ProfileSelector, then hard-coding DefaultProfileSelector would mess that up. Is there a way to instantiate the ProfileSelector that Maven would normally instantiate? And on top of that, I just tried a hack of manually adding the profile to the MavenProject's active-profiles list List<Profile> activeProfiles = project.getActiveProfiles(); activeProfiles.add(profileActivatedByMvel); project.setActiveProfiles(activeProfiles); and it seems to have no effect: running "mvn help:active-profiles validate" in a test project that uses the extension shows no active profiles. I also tried overriding AbstractMavenLifecycleParticipant.afterSessionStart, but this seems to be too early: the MavenSession doesn't have any projects. Thank you! Lewis --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
