[jira] [Commented] (MCOMPILER-550) Make 'outputDirectory' writeable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778421#comment-17778421
]
ASF GitHub Bot commented on MCOMPILER-550:
--
bmarwell commented on PR #202:
URL:
https://github.com/apache/maven-compiler-plugin/pull/202#issuecomment-1774132830
> I think the same change should apply to the test compile mono. @bmarwell
Can do, just left it out because I couldn't think of a use case I could have
added to the documentation.
> Make 'outputDirectory' writeable
>
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writeable, i.e. not meant to
> be modified.
> However, making it writeable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not just deprecated, it is deprecated for
> removal. The moment we know which Java version it is, we can create a MR-Jar
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writeable as suggested in Slack.
> PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-550) Make 'outputDirectory' writeable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778410#comment-17778410
]
ASF GitHub Bot commented on MCOMPILER-550:
--
gnodet commented on PR #202:
URL:
https://github.com/apache/maven-compiler-plugin/pull/202#issuecomment-1774114724
I think the same change should Apple to the test compile mono.
@bmarwell
> Make 'outputDirectory' writeable
>
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.12.0
>
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writeable, i.e. not meant to
> be modified.
> However, making it writeable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not just deprecated, it is deprecated for
> removal. The moment we know which Java version it is, we can create a MR-Jar
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writeable as suggested in Slack.
> PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-550) Make 'outputDirectory' writeable
[
https://issues.apache.org/jira/browse/MCOMPILER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778055#comment-17778055
]
ASF GitHub Bot commented on MCOMPILER-550:
--
bmarwell opened a new pull request, #202:
URL: https://github.com/apache/maven-compiler-plugin/pull/202
- add more documentation when and how to use it (and when to not use it)
- fixes MCOMPILER-550
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MCOMPILER-550) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line
and body.
- [X] Format the pull request title like `[MCOMPILER-550] - Fixes bug in
ApproximateQuantiles`,
where you replace `MCOMPILER-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [X] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> Make 'outputDirectory' writeable
>
>
> Key: MCOMPILER-550
> URL: https://issues.apache.org/jira/browse/MCOMPILER-550
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
>
> h2. Description of Improvement
> Currently, the property 'outputDirectory' is not writeable, i.e. not meant to
> be modified.
> However, making it writeable has at least two major advantages.
> h2. Use case one -- variable is already used
> Some Tutorials (e.g. https://www.baeldung.com/maven-multi-release-jars)
> already make use of rewriting the variable.
> h2. Use case two: MR-Jars with different bytecode level.
> Another use case is Multi-Release-Jars. Currently, they can officially only
> be controlled by setting the {{release}} property. That will not only require
> a suitable JDK or Toolchain-JDK, it will also require the bytecode for that
> version to be the bytecode of that version.
> E.g. using {{release}} and {{multiReleaseOutput}}, the bytecode in
> {{META-INF/version/java9}} MUST be exactly Java 9 bytecode.
> However, the JDK does not know of such restrictions.
> Using {{outputDirectory}}, you can now create Java 8 bytecode to run in e.g.
> Java 24. Here is an example use case:
> https://github.com/groovy/GMavenPlus/pull/287
> Granted, this could also be done differently, but this way it seems a little
> more elegant.
> The actual advantage is, that some developers can now plan ahead. For
> example, the SecurityManager is not just deprecated, it is deprecated for
> removal. The moment we know which Java version it is, we can create a MR-Jar
> for e.g. Java 30, even though Java 30 SDKs are not available then (currently
> we have Java 21 GA).
> h2. Proposed solution
> Make variable writeable as suggested in Slack.
> PR available locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
