Re: Extension does not work from .mvn/extensions.xml
On Mon, Nov 19, 2018 at 4:16 PM Romain Manni-Bucau wrote: > Time to push your code and an example on github to encourage help/people to > run it ;) OK, here's how to get the extension with the proof of concept code and install it locally: === $ git clone https://github.com/imca-cat/profile-activation-advanced.git $ cd profile-activation-advanced $ git checkout lifecycle-participant-poc $ mvn clean install === The proof of concept extension just changes the value of any profile property activation with a name of "paa:mvel" to the string "!false". It does not evaluate any MVEL expression at the moment; it's just a proof of concept for changing the model. Since the system property "paa:mvel" is not defined, the altered property activation should evaluate to true, but I don't know how to get Maven to re-evaluate the property activations after I've changed them. And here's how to get and run a small test that uses the locally installed extension: === $ git clone https://github.com/jlmuir/profile-activation-advanced-test.git $ cd profile-activation-advanced-test $ mvn help:active-profiles validate === I'm expecting the "mvn help:active-profiles validate" command to show that the foo_env-development profile is active with output like === The following profiles are active: - foo_env-development (source: org.example.foo:foo:1.0.0) === but it does not. So, it seems the extension is not successfully changing the model (i.e., not successfully activating the foo_env-development profile). Thank you! Lewis - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Extension does not work from .mvn/extensions.xml
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 a écrit : > On Sat, Nov 17, 2018 at 11:32 AM Romain Manni-Bucau > wrote: > > Le sam. 17 nov. 2018 17:06, J. Lewis Muir 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 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 > >
Re: [VOTE] Release Apache Maven Shared Archiver version 3.3.0
+1 Regards, Hervé Le samedi 17 novembre 2018, 14:45:17 CET Karl Heinz Marbaise a écrit : > Hi, > > We solved 10 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922 > rsion=12341347 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20s > tatus%20%3D%20OPEN%20AND%20component%20%3D%20maven-archiver%20ORDER%20BY%20k > ey%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1469 > https://repository.apache.org/content/repositories/maven-1469/org/apache/mav > en/maven-archiver/3.3.0/maven-archiver-3.3.0-source-release.zip > > Source release checksum(s): > maven-archiver-3.3.0-source-release.zip sha512: > 288754b22c5a9500ffad069819296306bcef82d6cc63293399762116fa0b97b307d8199c98ed > 092fce7082f37ad23a8f2b248cd1c7b605bd66b4507f03841a9c > maven-archiver-3.3.0-source-release.zip sha1: > 9951a32333e76fcdb6e90da24a2f8d7b0654f964 > > Staging site: > https://maven.apache.org/shared-archives/maven-archiver-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Extension does not work from .mvn/extensions.xml
On Sat, Nov 17, 2018 at 11:32 AM Romain Manni-Bucau wrote: > Le sam. 17 nov. 2018 17:06, J. Lewis Muir 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 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
Re: [VOTE] Release Apache Maven Shared Archiver version 3.3.0
+1 On Sat, 17 Nov 2018 at 23:45, Karl Heinz Marbaise wrote: > Hi, > > We solved 10 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12341347 > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20OPEN%20AND%20component%20%3D%20maven-archiver%20ORDER%20BY%20key%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1469 > > https://repository.apache.org/content/repositories/maven-1469/org/apache/maven/maven-archiver/3.3.0/maven-archiver-3.3.0-source-release.zip > > Source release checksum(s): > maven-archiver-3.3.0-source-release.zip sha512: > > 288754b22c5a9500ffad069819296306bcef82d6cc63293399762116fa0b97b307d8199c98ed092fce7082f37ad23a8f2b248cd1c7b605bd66b4507f03841a9c > maven-archiver-3.3.0-source-release.zip sha1: > 9951a32333e76fcdb6e90da24a2f8d7b0654f964 > > Staging site: > https://maven.apache.org/shared-archives/maven-archiver-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
