Time to push your code and an example on github to encourage help/people to run it ;)
Le lun. 19 nov. 2018 22:28, J. Lewis Muir <jlm...@imca-cat.org> a écrit : > 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 > >
