laeubi commented on pull request #665: URL: https://github.com/apache/maven/pull/665#issuecomment-1020793244
> I don't see the need for that since in the pom you can set in properties `<myextension.version>1.2.3</>` and override it with `-Dmyextension.version` in maven's spirit. Please take a look at the code and/or [referenced JIRA ](https://issues.apache.org/jira/browse/MNG-7395), at the time the extensions are fetched/created there is no properties, no session, even no "maven". If you still think it is possible a small example would be useful (disclaimer: I have already tried this out and got only an warning from maven where it complains that `${myextension.version}` could not be found as a version in any repository) you can use the one I have [attached here](https://issues.apache.org/jira/secure/attachment/13039302/testit.zip) as a starting point. > Anything else just creates something inconsistent without new real features so better to ensure the "on the fly plugin" is processed as any model instead of making it specific (and lacking env support for ex), no? Why do you think it is inconsistent? It is what most maven developers would expect and the first thing you have to learn when using core-extensions with `.mvn/extensions.xml` that they are simply dump and missing all features beside plain text parsing. So I'd like to have *at laest* support for java properties, if one feels env-variables are useful or whatever else that is avaiable at this very early stage, why not, but at the end of the day I'd better have support for "only" system properties instead of no support at all because there are so many other thing one *might* could need and essentially the feature never happens. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
