[jira] [Created] (MARTIFACT-58) display origin of local repository artifact when comparing
Herve Boutemy created MARTIFACT-58: -- Summary: display origin of local repository artifact when comparing Key: MARTIFACT-58 URL: https://issues.apache.org/jira/browse/MARTIFACT-58 Project: Maven Artifact Plugin Issue Type: Wish Components: artifact:compare Affects Versions: 3.5.0 Reporter: Herve Boutemy artifact:compare compares output from current build (available in target/) to content from local repository what is not easy to detect is if content from local repository comes from a previous local "mvn install" (done recently or a long time ago) or if it was downloaded from a remote repository perhaps the artifact:compare can detect and display the info -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-462) 3.5.1 not compatible with 3.4.1: The version cannot be empty
[
https://issues.apache.org/jira/browse/MSHADE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803387#comment-17803387
]
ASF GitHub Bot commented on MSHADE-462:
---
CrazyHZM opened a new pull request, #208:
URL: https://github.com/apache/maven-shade-plugin/pull/208
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MSHADE) 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.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MSHADE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MSHADE-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.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] 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.
- [ ] 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)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> 3.5.1 not compatible with 3.4.1: The version cannot be empty
>
>
> Key: MSHADE-462
> URL: https://issues.apache.org/jira/browse/MSHADE-462
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Maven home: /usr/share/apache-maven-3.8.8
> Java version: 17.0.9, vendor: Eclipse Adoptium, runtime:
> /usr/lib/jvm/temurin-17-jdk-amd64
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "6.2.0-1018-azure", arch: "amd64", family: "unix"
>Reporter: Gary D. Gregory
>Priority: Major
>
> When updating Apache Juneau git master from 3.4.1 to 3.5.1, we get:
> {noformat}
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.5.1:shade (source-jar) on
> project juneau-all: Execution source-jar of goal
> org.apache.maven.plugins:maven-shade-plugin:3.5.1:shade failed: For artifact
> {org.apache.juneau:juneau-marshall:null:jar}: The version cannot be empty. ->
> [Help 1]
> {noformat}
> See the build failure in the PR https://github.com/apache/juneau/pull/125
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MSHADE-462] 3.5.1 not compatible with 3.4.1: The version cannot be empty [maven-shade-plugin]
CrazyHZM opened a new pull request, #208: URL: https://github.com/apache/maven-shade-plugin/pull/208 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSHADE) 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. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MSHADE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHADE-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. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] 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. - [ ] 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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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
[jira] [Commented] (SUREFIRE-2231) JaCoCo 0.8.11 fails with old TestNG releases on Java 17+
[
https://issues.apache.org/jira/browse/SUREFIRE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803369#comment-17803369
]
ASF GitHub Bot commented on SUREFIRE-2231:
--
slachiewicz commented on PR #710:
URL: https://github.com/apache/maven-surefire/pull/710#issuecomment-1877964618
Nice spot
> JaCoCo 0.8.11 fails with old TestNG releases on Java 17+
>
>
> Key: SUREFIRE-2231
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2231
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Michael Osipov
>Priority: Major
>
> Upgrade JaCoCo to 0.8.11 and watch many TestNGs ITs fail. A lot still use
> TestNG 5.7 which seems to be broken with Java 17+. We either need to remove
> them or upgrade the entire test setup to 6+ which should work on Java 17+ as
> well:
> {noformat}
> $ grep -r '"testNgVersion"' surefire-its/src/test/ --color
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgBeforeMethodFailureIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgBeforeMethodIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgExecuteErrorIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgGroupThreadParallelIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgListenerReporterIT.java:
> unpack("testng-listener-reporter", "_" +
> version).sysProp("testNgVersion", version);
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgPathWithSpacesIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgReportTestIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgReportTestIT.java:
> .sysProp("testNgVersion", "5.10")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgReportTestIT.java:
> .sysProp("testNgVersion", "5.10")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgSuiteXmlIT.java:
> return unpack("testng-suite-xml").sysProp("testNgVersion",
> "5.7").sysProp("testNgClassifier", "jdk15");
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgSuiteXmlSingleIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgVersionsIT.java:
> final SurefireLauncher launcher =
> unpack("testng-simple").sysProp("testNgVersion", version);
> surefire-its/src/test/java/org/apache/maven/surefire/its/TestMethodPatternIT.java:
> props.put("testNgVersion", "5.7");
> surefire-its/src/test/java/org/apache/maven/surefire/its/TestMethodPatternIT.java:
> props.put("testNgVersion", "5.7");
> surefire-its/src/test/java/org/apache/maven/surefire/its/TestMethodPatternIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/TestNgSuccessPercentageIT.java:
> .sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/TestSingleMethodIT.java:
> props.put("testNgVersion", "5.7");
> surefire-its/src/test/java/org/apache/maven/surefire/its/TestSingleMethodIT.java:
> props.put("testNgVersion", "5.7");
> surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
>.sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
>.sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
>.sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
>.sysProp("testNgVersion", "5.7")
> surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1135ImproveIgnoreMessageForTestNGIT.java:
> SurefireLauncher launcher = unpack(resource).sysProp("testNgVersion",
> version);
> surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1967CheckTestNgMethodParallelOrderingIT.java:
> .sysProp("testNgVersion", "7.3.0")
> surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1967CheckTestNgMethodParallelOrderingIT.java:
> .sysProp("testNgVersion", "6.10")
> surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1967CheckTestNgMethodParallelOrderingIT.java:
>
Re: [PR] [SUREFIRE-2231] JaCoCo 0.8.11 fails with old TestNG releases on Java 17+ [maven-surefire]
slachiewicz commented on PR #710: URL: https://github.com/apache/maven-surefire/pull/710#issuecomment-1877964618 Nice spot -- 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
[jira] [Updated] (MPIR-455) dependencies goal: add support for multi-release jar
[ https://issues.apache.org/jira/browse/MPIR-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Belingueres updated MPIR-455: - Description: dependencies goal reports dependencies with multi-release support with the highest version supported in the jar file, instead of the base version. Example: plexus-utils 4.0.0 is reported as a Java 11 dependency, but their base version is 1.8. !image-2024-01-04-21-12-54-861.png! Because of this the lower "Total" rows report a wrong java version too. This depends on https://issues.apache.org/jira/browse/MSHARED-1256. was: dependencies goal reports dependencies with multi-release support with the hieghest version supported in the jar file, instead of the base version. Example: plexus-utils 4.0.0 is reported as a Java 11 dependency, but their base version is 1.8. !image-2024-01-04-21-12-54-861.png! Because of this the lower "Total" rows report a wrong java version too. This depends on https://issues.apache.org/jira/browse/MSHARED-1256. > dependencies goal: add support for multi-release jar > > > Key: MPIR-455 > URL: https://issues.apache.org/jira/browse/MPIR-455 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 3.4.5, 3.5.0 >Reporter: Gabriel Belingueres >Priority: Major > Attachments: image-2024-01-04-21-12-54-861.png > > > dependencies goal reports dependencies with multi-release support with the > highest version supported in the jar file, instead of the base version. > Example: plexus-utils 4.0.0 is reported as a Java 11 dependency, but their > base version is 1.8. > !image-2024-01-04-21-12-54-861.png! > Because of this the lower "Total" rows report a wrong java version too. > > This depends on https://issues.apache.org/jira/browse/MSHARED-1256. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPIR-455) dependencies goal: add support for multi-release jar
Gabriel Belingueres created MPIR-455: Summary: dependencies goal: add support for multi-release jar Key: MPIR-455 URL: https://issues.apache.org/jira/browse/MPIR-455 Project: Maven Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 3.5.0, 3.4.5 Reporter: Gabriel Belingueres Attachments: image-2024-01-04-21-12-54-861.png dependencies goal reports dependencies with multi-release support with the hieghest version supported in the jar file, instead of the base version. Example: plexus-utils 4.0.0 is reported as a Java 11 dependency, but their base version is 1.8. !image-2024-01-04-21-12-54-861.png! Because of this the lower "Total" rows report a wrong java version too. This depends on https://issues.apache.org/jira/browse/MSHARED-1256. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.maven.plugins:maven-docck-plugin from 1.1 to 1.2 [maven-surefire]
michael-o commented on PR #713: URL: https://github.com/apache/maven-surefire/pull/713#issuecomment-1877782610 @dependabot rebase -- 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
Re: [PR] Bump net.java.dev.javacc:javacc from 7.0.12 to 7.0.13 [maven-surefire]
michael-o commented on PR #711: URL: https://github.com/apache/maven-surefire/pull/711#issuecomment-1877782543 @dependabot rebase -- 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
Re: [PR] Bump commons-io:commons-io from 2.15.0 to 2.15.1 [maven-surefire]
michael-o commented on PR #712: URL: https://github.com/apache/maven-surefire/pull/712#issuecomment-1877782446 @dependabot rebase -- 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
Re: [PR] Drop old TestNG, test with more recent ones [maven-surefire]
michael-o commented on PR #710: URL: https://github.com/apache/maven-surefire/pull/710#issuecomment-1877706149 @slachiewicz I am an idiot, created too much noise. I logged the JaCoCo and TestNG issue: https://issues.apache.org/jira/browse/SUREFIRE-2231 -- 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
[jira] [Created] (SUREFIRE-2231) JaCoCo 0.8.11 fails with old TestNG releases on Java 17+
Michael Osipov created SUREFIRE-2231:
Summary: JaCoCo 0.8.11 fails with old TestNG releases on Java 17+
Key: SUREFIRE-2231
URL: https://issues.apache.org/jira/browse/SUREFIRE-2231
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Michael Osipov
Upgrade JaCoCo to 0.8.11 and watch many TestNGs ITs fail. A lot still use
TestNG 5.7 which seems to be broken with Java 17+. We either need to remove
them or upgrade the entire test setup to 6+ which should work on Java 17+ as
well:
{noformat}
$ grep -r '"testNgVersion"' surefire-its/src/test/ --color
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgBeforeMethodFailureIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgBeforeMethodIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgExecuteErrorIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgGroupThreadParallelIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgListenerReporterIT.java:
unpack("testng-listener-reporter", "_" +
version).sysProp("testNgVersion", version);
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgPathWithSpacesIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgReportTestIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgReportTestIT.java:
.sysProp("testNgVersion", "5.10")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgReportTestIT.java:
.sysProp("testNgVersion", "5.10")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgSuiteXmlIT.java:
return unpack("testng-suite-xml").sysProp("testNgVersion",
"5.7").sysProp("testNgClassifier", "jdk15");
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgSuiteXmlSingleIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/CheckTestNgVersionsIT.java:
final SurefireLauncher launcher =
unpack("testng-simple").sysProp("testNgVersion", version);
surefire-its/src/test/java/org/apache/maven/surefire/its/TestMethodPatternIT.java:
props.put("testNgVersion", "5.7");
surefire-its/src/test/java/org/apache/maven/surefire/its/TestMethodPatternIT.java:
props.put("testNgVersion", "5.7");
surefire-its/src/test/java/org/apache/maven/surefire/its/TestMethodPatternIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/TestNgSuccessPercentageIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/TestSingleMethodIT.java:
props.put("testNgVersion", "5.7");
surefire-its/src/test/java/org/apache/maven/surefire/its/TestSingleMethodIT.java:
props.put("testNgVersion", "5.7");
surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/TwoTestCasesIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1135ImproveIgnoreMessageForTestNGIT.java:
SurefireLauncher launcher = unpack(resource).sysProp("testNgVersion",
version);
surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1967CheckTestNgMethodParallelOrderingIT.java:
.sysProp("testNgVersion", "7.3.0")
surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1967CheckTestNgMethodParallelOrderingIT.java:
.sysProp("testNgVersion", "6.10")
surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1967CheckTestNgMethodParallelOrderingIT.java:
.sysProp("testNgVersion", "6.2.1")
surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire376TestNgAfterSuiteFailureIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire377TestNgAndJUnitTogetherIT.java:
.sysProp("testNgVersion", "5.7")
surefire-its/src/test/java/org/apache/maven/surefire/its/jiras/Surefire377TestNgAndJUnitTogetherIT.java:
.sysProp("testNgVersion", "5.7")
{noformat}
[jira] [Commented] (MNG-6776) Inconsistent list of parameters in MojoDescriptor
[ https://issues.apache.org/jira/browse/MNG-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803307#comment-17803307 ] ASF GitHub Bot commented on MNG-6776: - michael-o commented on PR #1361: URL: https://github.com/apache/maven/pull/1361#issuecomment-1877694981 @cstamas Any objections before I backport this one? > Inconsistent list of parameters in MojoDescriptor > - > > Key: MNG-6776 > URL: https://issues.apache.org/jira/browse/MNG-6776 > Project: Maven > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.6.2 >Reporter: Sylwester Lachiewicz >Assignee: Tamas Cservenak >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > While working with maven-plugin-tools I discovered inconsistent results > returned from MojoDescriptor getParameters() and getParametersMap(). > In > [AntMojoDescriptorExtractor.java#L101|https://github.com/apache/maven-plugin-tools/blob/master/maven-script/maven-plugin-tools-ant/src/main/java/org/apache/maven/tools/plugin/extractor/ant/AntMojoDescriptorExtractor.java#L101] > If first I call MojoDescriptor.getParameterMap() and then later add parameter > via MojoDescriptor.addParameter - MojoDescriptor.getParameterMap() will still > return map with old (cached) list with parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-6776] Inconsistent list of parameters for MojoDescriptor (#584) [maven]
michael-o commented on PR #1361: URL: https://github.com/apache/maven/pull/1361#issuecomment-1877694981 @cstamas Any objections before I backport this one? -- 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
[jira] [Commented] (MNG-6776) Inconsistent list of parameters in MojoDescriptor
[ https://issues.apache.org/jira/browse/MNG-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803306#comment-17803306 ] ASF GitHub Bot commented on MNG-6776: - michael-o commented on PR #1361: URL: https://github.com/apache/maven/pull/1361#issuecomment-1877694799 > good, maybe it's also worth to backport to 3.8.x? I was thinking about the same. Will prepare after this one. > Inconsistent list of parameters in MojoDescriptor > - > > Key: MNG-6776 > URL: https://issues.apache.org/jira/browse/MNG-6776 > Project: Maven > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.6.2 >Reporter: Sylwester Lachiewicz >Assignee: Tamas Cservenak >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > While working with maven-plugin-tools I discovered inconsistent results > returned from MojoDescriptor getParameters() and getParametersMap(). > In > [AntMojoDescriptorExtractor.java#L101|https://github.com/apache/maven-plugin-tools/blob/master/maven-script/maven-plugin-tools-ant/src/main/java/org/apache/maven/tools/plugin/extractor/ant/AntMojoDescriptorExtractor.java#L101] > If first I call MojoDescriptor.getParameterMap() and then later add parameter > via MojoDescriptor.addParameter - MojoDescriptor.getParameterMap() will still > return map with old (cached) list with parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-6776] Inconsistent list of parameters for MojoDescriptor (#584) [maven]
michael-o commented on PR #1361: URL: https://github.com/apache/maven/pull/1361#issuecomment-1877694799 > good, maybe it's also worth to backport to 3.8.x? I was thinking about the same. Will prepare after this one. -- 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
Re: [PR] [MPOM-451] Remove repository elements from Apache Parent [maven-apache-parent]
ctubbsii commented on PR #183: URL: https://github.com/apache/maven-apache-parent/pull/183#issuecomment-1877686303 > > A lot of projects rely on this being already set up > > Understandable, but since these upgrades don't happen automatically and "fail fast", I don't see this as a big issue. I don't see this as "fail fast"... bumping the parent version is trivial, but the requirement that every user on a project set up a repository in their local workspace or in each project and in any automated builder environment, like Jenkins, can happen later, when a non-reactor snapshot is added (typically done while testing a bugfix in a dependency prior to that dependency's release, or when co-releasing projects at the same time). After reading all the arguments listed in favor of this, I think it boils down to: 1. Weird behavior with dependabot that seems to only affect a few people, for which there is a workaround, and 2. General advice against doing it because it could be slow... but this argument falls flat when the suggestion is that everybody still needs to set it up locally, and this doesn't come in at all for releases, which don't depend on snapshots. I'm just not convinced by the arguments in favor of doing this, and worry about the impact. It's been this way for so long, without any problems whatsoever. -- 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
[PR] Bump org.apache.maven.plugins:maven-docck-plugin from 1.1 to 1.2 [maven-surefire]
dependabot[bot] opened a new pull request, #713: URL: https://github.com/apache/maven-surefire/pull/713 Bumps [org.apache.maven.plugins:maven-docck-plugin](https://github.com/apache/maven-docck-plugin) from 1.1 to 1.2. Commits https://github.com/apache/maven-docck-plugin/commit/a47e98c1fcabbfe9422621c1a2d2abe56e43d1e1";>a47e98c [maven-release-plugin] prepare release maven-docck-plugin-1.2 https://github.com/apache/maven-docck-plugin/commit/00c05e46fad519c4b377e9041176dce69e44e04b";>00c05e4 [MDOCCK-39] Prepare documentation for retired https://github.com/apache/maven-docck-plugin/commit/4663f8de97ae72a6132b0ea03069c29260c46ffb";>4663f8d [MNG-6829] Replace StringUtils#isEmpty(String) & #isNotEmpty(String) (https://redirect.github.com/apache/maven-docck-plugin/issues/3";>#3) https://github.com/apache/maven-docck-plugin/commit/4f66af7c9f8cf65e127378094f458b24ef6e6097";>4f66af7 Auto-link MDOCCK Jira https://github.com/apache/maven-docck-plugin/commit/9a51d8217df4cc44a7535f82e723d70bb972da6b";>9a51d82 Use shared GitHub Actions https://github.com/apache/maven-docck-plugin/commit/3a0d4c7388ef8af9675b696c5e6efc3ac348e38b";>3a0d4c7 Fix project name in readme https://github.com/apache/maven-docck-plugin/commit/08fe1a8c8c4cfaafae6c6d51bc1109c570a59a78";>08fe1a8 Fix JavaDoc https://github.com/apache/maven-docck-plugin/commit/1e0896228aebefab6c2b4750e9cc8002e0dd8ed7";>1e08962 update CI url https://github.com/apache/maven-docck-plugin/commit/ab5588ce05b89d434980ff07c3e1bcd66468d967";>ab5588c Made use of Java 8 code for creating a singletonList https://github.com/apache/maven-docck-plugin/commit/27483cd1d58d5e2d82d14ad45460b1a109e4887c";>27483cd [MDOCCK-35] - Upgrade Http Client Additional commits viewable in https://github.com/apache/maven-docck-plugin/compare/maven-docck-plugin-1.1...maven-docck-plugin-1.2";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[PR] Bump commons-io:commons-io from 2.15.0 to 2.15.1 [maven-surefire]
dependabot[bot] opened a new pull request, #712: URL: https://github.com/apache/maven-surefire/pull/712 Bumps commons-io:commons-io from 2.15.0 to 2.15.1. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[PR] Bump net.java.dev.javacc:javacc from 7.0.12 to 7.0.13 [maven-surefire]
dependabot[bot] opened a new pull request, #711:
URL: https://github.com/apache/maven-surefire/pull/711
Bumps [net.java.dev.javacc:javacc](https://github.com/javacc/javacc) from
7.0.12 to 7.0.13.
Changelog
Sourced from https://github.com/javacc/javacc/blob/master/docs/release-notes.md";>net.java.dev.javacc:javacc's
changelog.
Modifications in JavaCC 7.0.13
https://redirect.github.com/javacc/javacc/issues/267";>#267
: Resolve merge conflicts from https://redirect.github.com/javacc/javacc/issues/245";>#245
https://redirect.github.com/javacc/javacc/issues/245";>#245
: Fix issue https://redirect.github.com/javacc/javacc/issues/243";>#243 (Character
code is returned instead of the symbol in the message)
https://redirect.github.com/javacc/javacc/issues/232";>#232
: Revert "Try to fix {} issue in GitHub Pages"
https://redirect.github.com/javacc/javacc/issues/231";>#231
: Try to fix {} issue in GitHub Pages
Commits
https://github.com/javacc/javacc/commit/e64881dcd7175db6150d70bfc9c8cad86ccee9b0";>e64881d
[maven-release-plugin] prepare release javacc-7.0.13
https://github.com/javacc/javacc/commit/46bf1031490637f2cf287ae08f5e503acac0ee16";>46bf103
Updates for release 7.0.13. Signed
https://github.com/javacc/javacc/commit/e8bf2428b9bb40b17064f437298e0e10e4dcb5f5";>e8bf242
Bump to 7.0.13
https://github.com/javacc/javacc/commit/f9e8c42366953b94b16b679407efc4761a0e3e35";>f9e8c42
Revert "Bump to version 7.0.13"
https://github.com/javacc/javacc/commit/6bfdaa57dcd47279514c9343790f95f518acfa61";>6bfdaa5
Bump to version 7.0.13
https://github.com/javacc/javacc/commit/38cfc5df09316b8f70045e3a935bb6b6398c070c";>38cfc5d
Merge pull request https://redirect.github.com/javacc/javacc/issues/267";>#267 from
zbynek/resolve-conflict
https://github.com/javacc/javacc/commit/dfba32b4b2b58c6e798b1adc79ed079db7b0098c";>dfba32b
More missing bits from 7.0.12 version bump
https://github.com/javacc/javacc/commit/670551be1e6e587b797b524b88efe865056cd9fd";>670551b
Bump to 7.0.12
https://github.com/javacc/javacc/commit/e501ff610b2bef8c9545ea61c4f353c50ab9bc0c";>e501ff6
Update index.md
https://github.com/javacc/javacc/commit/66924ba38147690dedd566bb7f6e69bbe9e3649d";>66924ba
Production part in javacc_input cannot be omitted
Additional commits viewable in https://github.com/javacc/javacc/compare/javacc-7.0.12...javacc-7.0.13";>compare
view
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that
have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI
passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and
block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it.
You can achieve the same result by closing it manually
- `@dependabot show ignore conditions` will show all of
the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen the PR
or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen the PR
or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the PR or
upgrade to it yourself)
--
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
[jira] [Commented] (DOXIASITETOOLS-324) Allow configuration of parser (per markup source path pattern)
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803295#comment-17803295
]
ASF GitHub Bot commented on DOXIASITETOOLS-324:
---
kwin commented on code in PR #126:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/126#discussion_r1442152573
##
doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java:
##
@@ -320,9 +337,13 @@ public void renderDocument(
String resource = doc.getAbsolutePath();
Parser parser = doxia.getParser(docRenderingContext.getParserId());
-// DOXIASITETOOLS-146 don't render comments from source markup
-parser.setEmitComments(false);
-
+ParserConfiguration parserConfiguration =
docRenderingContext.getParserConfiguration();
+if (parserConfiguration != null) {
+parserConfiguration.accept(parser);
+} else {
+// DOXIASITETOOLS-146 don't render comments from source markup
+parser.setEmitComments(false);
Review Comment:
TODO: once https://github.com/apache/maven-doxia/pull/180 is merged, the
default for emitting anchors should be changed as well.
> Allow configuration of parser (per markup source path pattern)
> --
>
> Key: DOXIASITETOOLS-324
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-324
> Project: Maven Doxia Sitetools
> Issue Type: New Feature
> Components: Site renderer
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M17
>
>
> Currently the Doxia parsers being used for the Doxia markup sources have a
> fix configuration
> (https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L324).
> It would be beneficial to allow to dynamically configure the parsers (based
> on a matching markup source path pattern)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIASITETOOLS-324] Allow configuration of Doxia parser [maven-doxia-sitetools]
kwin commented on code in PR #126:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/126#discussion_r1442152573
##
doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java:
##
@@ -320,9 +337,13 @@ public void renderDocument(
String resource = doc.getAbsolutePath();
Parser parser = doxia.getParser(docRenderingContext.getParserId());
-// DOXIASITETOOLS-146 don't render comments from source markup
-parser.setEmitComments(false);
-
+ParserConfiguration parserConfiguration =
docRenderingContext.getParserConfiguration();
+if (parserConfiguration != null) {
+parserConfiguration.accept(parser);
+} else {
+// DOXIASITETOOLS-146 don't render comments from source markup
+parser.setEmitComments(false);
Review Comment:
TODO: once https://github.com/apache/maven-doxia/pull/180 is merged, the
default for emitting anchors should be changed as well.
--
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
[jira] [Comment Edited] (MPOM-449) Remove the leading "1." from source/target properties
[
https://issues.apache.org/jira/browse/MPOM-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803264#comment-17803264
]
Herve Boutemy edited comment on MPOM-449 at 1/4/24 6:15 PM:
very good idea: this is supported since Java 5, we can forget about this "1."
that was necessary only until Java 1.4...
https://docs.oracle.com/javase/6/docs/technotes/tools/solaris/javac.html
was (Author: hboutemy):
very good idea: this is supported since Java 5, we can forget about this "1."
that was necessary only until Java 1.4...
> Remove the leading "1." from source/target properties
> -
>
> Key: MPOM-449
> URL: https://issues.apache.org/jira/browse/MPOM-449
> Project: Maven POMs
> Issue Type: Bug
> Components: maven
>Affects Versions: MAVEN-41
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: MAVEN-42
>
>
> The parent 41 has these lines:
> {noformat}
> 1.${javaVersion}
> 1.${javaVersion} {noformat}
> This makes any Java above 9 defunct (and we do not go below 8, so it works
> for only two versions). If you try to use 11, 17 or oh my god 21, you end up
> with "1.11", "1.17" and "1.21" subsequently. While for javac this is not a
> biggie (it will ignore this if release set, and hopefully is), but
> reporting/site/whatever craps out badly on this.
> Remove the prefix "1.", and let those on 8 use 1.8 instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPOM-449) Remove the leading "1." from source/target properties
[
https://issues.apache.org/jira/browse/MPOM-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803264#comment-17803264
]
Herve Boutemy commented on MPOM-449:
very good idea: this is supported since Java 5, we can forget about this "1."
that was necessary only until Java 1.4...
> Remove the leading "1." from source/target properties
> -
>
> Key: MPOM-449
> URL: https://issues.apache.org/jira/browse/MPOM-449
> Project: Maven POMs
> Issue Type: Bug
> Components: maven
>Affects Versions: MAVEN-41
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: MAVEN-42
>
>
> The parent 41 has these lines:
> {noformat}
> 1.${javaVersion}
> 1.${javaVersion} {noformat}
> This makes any Java above 9 defunct (and we do not go below 8, so it works
> for only two versions). If you try to use 11, 17 or oh my god 21, you end up
> with "1.11", "1.17" and "1.21" subsequently. While for javac this is not a
> biggie (it will ignore this if release set, and hopefully is), but
> reporting/site/whatever craps out badly on this.
> Remove the prefix "1.", and let those on 8 use 1.8 instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-324) Allow configuration of parser (per markup source path pattern)
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIASITETOOLS-324: --- Fix Version/s: 2.0.0-M17 > Allow configuration of parser (per markup source path pattern) > -- > > Key: DOXIASITETOOLS-324 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-324 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M17 > > > Currently the Doxia parsers being used for the Doxia markup sources have a > fix configuration > (https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L324). > It would be beneficial to allow to dynamically configure the parsers (based > on a matching markup source path pattern) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7991) refactor "aggregator" goal feature
[ https://issues.apache.org/jira/browse/MNG-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7991: --- Summary: refactor "aggregator" goal feature (was: refactor aggregator goal) > refactor "aggregator" goal feature > -- > > Key: MNG-7991 > URL: https://issues.apache.org/jira/browse/MNG-7991 > Project: Maven > Issue Type: Wish > Components: Plugin API, Plugins and Lifecycle, Reactor and Workspace >Affects Versions: 4.x / Backlog >Reporter: Herve Boutemy >Priority: Major > > aggregation was added in early Maven 2 stages with MNG-250, not really > documented AFAIK > there are multiple shortcomings found over time: > * discrepancy between CLI and lifecycle use: CLI skips execution in > sub-modules, but not lifecycle > * forked lifecycle execution vs second execution in modules > * sometimes, instead of executing aggregate goal *before* building modules, > it would be useful to execute aggregate *after* building modules (to > aggregate some results built in each module) > notice that this looks also like the need for "execute at end" as found in > install/deploy > we probably need to better document what aggregate currently does and define > what should be the target: perhaps refactoring will require new mechanisms > that we won't call aggregator, like MNG-5665... > edge case: aggregating reports for maven-site-plugin (launched by > maven-reporting-exec, hence quite independent from associated reporting goals > even if we expect some consistency between site reports and reporting goals) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-722) Optionally create anchors for index entries server-side (used in TOCs)
[ https://issues.apache.org/jira/browse/DOXIA-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIA-722: -- Description: The links for the TOC macro are created server-side by Doxia while the only referenceable anchors or ids are created currently client side by the skin. As the latter uses a different format than the former the TOC links are broken (except with APT where they can be created manually with markup). Therefore there should be an option to enable anchor creation for all index entries (used by the TOC macro). (was: The links for the TOC macro are created server-side by Doxia while the only local anchors are created currently client side by the skin. As the latter uses a different format than the former the TOC links are broken (except with APT where they can be created manually with markup). Therefore there should be an option to enable anchor creation for all index entries (used by the TOC macro).) > Optionally create anchors for index entries server-side (used in TOCs) > -- > > Key: DOXIA-722 > URL: https://issues.apache.org/jira/browse/DOXIA-722 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0, 2.0.0-M9 > > > The links for the TOC macro are created server-side by Doxia while the only > referenceable anchors or ids are created currently client side by the skin. > As the latter uses a different format than the former the TOC links are > broken (except with APT where they can be created manually with markup). > Therefore there should be an option to enable anchor creation for all index > entries (used by the TOC macro). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-722) Optionally create anchors for index entries server-side (used in TOCs)
[ https://issues.apache.org/jira/browse/DOXIA-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIA-722: -- Fix Version/s: 2.0.0 > Optionally create anchors for index entries server-side (used in TOCs) > -- > > Key: DOXIA-722 > URL: https://issues.apache.org/jira/browse/DOXIA-722 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0, 2.0.0-M9 > > > The links for the TOC macro are created server-side by Doxia while the only > local anchors are created currently client side by the skin. As the latter > uses a different format than the former the TOC links are broken (except with > APT where they can be created manually with markup). Therefore there should > be an option to enable anchor creation for all index entries (used by the TOC > macro). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (DOXIA-710) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIA-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned DOXIA-710:
-
Assignee: (was: Konrad Windszus)
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIA-710
> URL: https://issues.apache.org/jira/browse/DOXIA-710
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-722) Optionally create anchors for index entries server-side (used in TOCs)
[ https://issues.apache.org/jira/browse/DOXIA-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803241#comment-17803241 ] ASF GitHub Bot commented on DOXIA-722: -- kwin commented on PR #180: URL: https://github.com/apache/maven-doxia/pull/180#issuecomment-1877409083 > The the actual change is perfectly fine, this needs a new JIRA issue because it does not really solve [DOXIA-710](https://issues.apache.org/jira/browse/DOXIA-710) because we cannot solve the problem within the skin. Please create a new issue and change the commit message. It can only solve external linking and interplay between TOC macro and the content itself. Done in https://github.com/apache/maven-doxia/pull/180/commits/4518d58bd45591164b3043a46ad3db4356a48c85 associated with new JIRA issue [DOXIA-722](https://issues.apache.org/jira/browse/DOXIA-722) > Optionally create anchors for index entries server-side (used in TOCs) > -- > > Key: DOXIA-722 > URL: https://issues.apache.org/jira/browse/DOXIA-722 > Project: Maven Doxia > Issue Type: New Feature > Components: Core >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M9 > > > The links for the TOC macro are created server-side by Doxia while the only > local anchors are created currently client side by the skin. As the latter > uses a different format than the former the TOC links are broken (except with > APT where they can be created manually with markup). Therefore there should > be an option to enable anchor creation for all index entries (used by the TOC > macro). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIA-722] Optionally generate anchors for TOC entries [maven-doxia]
kwin commented on PR #180: URL: https://github.com/apache/maven-doxia/pull/180#issuecomment-1877409083 > The the actual change is perfectly fine, this needs a new JIRA issue because it does not really solve [DOXIA-710](https://issues.apache.org/jira/browse/DOXIA-710) because we cannot solve the problem within the skin. Please create a new issue and change the commit message. It can only solve external linking and interplay between TOC macro and the content itself. Done in https://github.com/apache/maven-doxia/pull/180/commits/4518d58bd45591164b3043a46ad3db4356a48c85 associated with new JIRA issue [DOXIA-722](https://issues.apache.org/jira/browse/DOXIA-722) -- 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
[jira] [Updated] (MSITE-1000) Allow parametrisation of Doxia parser per file
[
https://issues.apache.org/jira/browse/MSITE-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MSITE-1000:
---
Description:
Currently only the attributes used for rendering the site can be parameterized
in
https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#attributes.
There is no possibility to configure the parser in
https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L322
per document.
This would be nice in the context of
https://issues.apache.org/jira/browse/DOXIA-722 where generation of anchors
should be switched on/off for certain documents. Also generation of comments
may be desirable for certain documents.
I propose the following additional plugin goal parameter:
{code}
**/apt/**
false
true
{code}
where {{parserConfigurations}} is an array of a complex type with (include)
patterns on the source path (String array) and boolean methods for features.
was:
Currently only the attributes used for rendering the site can be parameterized
in
https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#attributes.
There is no possibility to configure the parser in
https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L322
per document.
This would be nice in the context of
https://issues.apache.org/jira/browse/DOXIA-710 where generation of anchors
should be switched on/off for certain documents. Also generation of comments
may be desirable for certain documents.
I propose the following additional plugin goal parameter:
{code}
**/apt/**
false
true
{code}
where {{parserConfigurations}} is an array of a complex type with (include)
patterns on the source path (String array) and boolean methods for features.
> Allow parametrisation of Doxia parser per file
> --
>
> Key: MSITE-1000
> URL: https://issues.apache.org/jira/browse/MSITE-1000
> Project: Maven Site Plugin
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently only the attributes used for rendering the site can be
> parameterized in
> https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#attributes.
> There is no possibility to configure the parser in
> https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L322
> per document.
> This would be nice in the context of
> https://issues.apache.org/jira/browse/DOXIA-722 where generation of anchors
> should be switched on/off for certain documents. Also generation of comments
> may be desirable for certain documents.
> I propose the following additional plugin goal parameter:
> {code}
>
>
>
> **/apt/**
>
> false
> true
>
>
> {code}
> where {{parserConfigurations}} is an array of a complex type with (include)
> patterns on the source path (String array) and boolean methods for features.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-710) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/DOXIA-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803240#comment-17803240
]
Konrad Windszus commented on DOXIA-710:
---
As requested by [~michael-o] the workaround for this issue is now tracked in
DOXIA-722.
> Inconsistent anchors between toc macro and headers
> --
>
> Key: DOXIA-710
> URL: https://issues.apache.org/jira/browse/DOXIA-710
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Konrad Windszus
>Priority: Critical
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-722) Optionally create anchors for index entries server-side (used in TOCs)
Konrad Windszus created DOXIA-722: - Summary: Optionally create anchors for index entries server-side (used in TOCs) Key: DOXIA-722 URL: https://issues.apache.org/jira/browse/DOXIA-722 Project: Maven Doxia Issue Type: New Feature Components: Core Reporter: Konrad Windszus Assignee: Konrad Windszus Fix For: 2.0.0-M9 The links for the TOC macro are created server-side by Doxia while the only local anchors are created currently client side by the skin. As the latter uses a different format than the former the TOC links are broken (except with APT where they can be created manually with markup). Therefore there should be an option to enable anchor creation for all index entries (used by the TOC macro). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803228#comment-17803228 ] ASF GitHub Bot commented on MCOMPILER-391: -- psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1877354179 Ah, I see. In that case you are right, the relocation message should be there. I'll see if I can find some time to take a look at this. > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1877354179 Ah, I see. In that case you are right, the relocation message should be there. I'll see if I can find some time to take a look at this. -- 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
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803209#comment-17803209 ] ASF GitHub Bot commented on MCOMPILER-391: -- famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1877280262 > I think the missing relocation warning has the same cause - the plugin (or more precisely the dependency resolution mechanism the plugin uses) simply does not know that the artifact was relocated, because without version, it cannot fetch the relocation config. > > I believe the relocation warning gets printed in case you depend on the old artifact, but the version must be known, explicitly or via depMgmt: e.g: > > ``` > > org.hibernate > hibernate-jpamodelgen > 6.0.0 > ``` > > In that case, the POM is fetched, relocation config found and the warning can be printed. I guess I should have been more precise: I had exactly that (only a version property instead of the version literal, but that shouldn't make any difference) and still no warning. Maven 3.9.6, btw. > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1877280262 > I think the missing relocation warning has the same cause - the plugin (or more precisely the dependency resolution mechanism the plugin uses) simply does not know that the artifact was relocated, because without version, it cannot fetch the relocation config. > > I believe the relocation warning gets printed in case you depend on the old artifact, but the version must be known, explicitly or via depMgmt: e.g: > > ``` > > org.hibernate > hibernate-jpamodelgen > 6.0.0 > ``` > > In that case, the POM is fetched, relocation config found and the warning can be printed. I guess I should have been more precise: I had exactly that (only a version property instead of the version literal, but that shouldn't make any difference) and still no warning. Maven 3.9.6, btw. -- 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
[jira] [Updated] (MNG-7993) New or existing service improvement: "resolve in the context of project"
[ https://issues.apache.org/jira/browse/MNG-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7993: - Description: See for example MCOMPILER-391. Today all the burden is on plugin to reimplement all the logic whether to apply or not the depMgt. Instead, there should be a service that does "resolve in the context of project" (obeying all the depMgt), so a plugin that has GAV artifact dependency can just pass it to API and API resolves with while obeying existing depMgt entries present in project. was: See for example MCOMPILER-391. Instead as today, all the burden is on plugin (to reimplement all the logic), there should be a service that does "resolve in the context of project" (obeying all the depMgt), so a plugin that has GAV artifact dependency can just pass it to API and API resolves with while obeying existing depMgt entries present in project. > New or existing service improvement: "resolve in the context of project" > > > Key: MNG-7993 > URL: https://issues.apache.org/jira/browse/MNG-7993 > Project: Maven > Issue Type: Improvement > Components: API >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.x-candidate, 4.0.0 > > > See for example MCOMPILER-391. > Today all the burden is on plugin to reimplement all the logic whether to > apply or not the depMgt. Instead, there should be a service that does > "resolve in the context of project" (obeying all the depMgt), so a plugin > that has GAV artifact dependency can just pass it to API and API resolves > with while obeying existing depMgt entries present in project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7993) New or existing service improvement: "resolve in the context of project"
Tamas Cservenak created MNG-7993: Summary: New or existing service improvement: "resolve in the context of project" Key: MNG-7993 URL: https://issues.apache.org/jira/browse/MNG-7993 Project: Maven Issue Type: Improvement Components: API Reporter: Tamas Cservenak Fix For: 4.0.x-candidate, 4.0.0 See for example MCOMPILER-391. Instead as today, all the burden is on plugin (to reimplement all the logic), there should be a service that does "resolve in the context of project" (obeying all the depMgt), so a plugin that has GAV artifact dependency can just pass it to API and API resolves with while obeying existing depMgt entries present in project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803199#comment-17803199 ] ASF GitHub Bot commented on MCOMPILER-391: -- psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-187725 Yeah, there could possibly be some sort of heuristics to try to detect these relocations. Not sure if this would be something that should be done directly in the plugin or rather left to the dependency resolver. I think the missing relocation warning has the same cause - the plugin (or more precisely the dependency resolution mechanism the plugin uses) simply does not know that the artifact was relocated, because without version, it cannot fetch the relocation config. I believe the relocation warning gets printed in case you depend on the old artifact, but the version must be known, explicitly or via depMgmt: e.g: ``` org.hibernate hibernate-jpamodelgen 6.0.0 ``` In that case, the POM is fetched, relocation config found and the warning can be printed. > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-187725 Yeah, there could possibly be some sort of heuristics to try to detect these relocations. Not sure if this would be something that should be done directly in the plugin or rather left to the dependency resolver. I think the missing relocation warning has the same cause - the plugin (or more precisely the dependency resolution mechanism the plugin uses) simply does not know that the artifact was relocated, because without version, it cannot fetch the relocation config. I believe the relocation warning gets printed in case you depend on the old artifact, but the version must be known, explicitly or via depMgmt: e.g: ``` org.hibernate hibernate-jpamodelgen 6.0.0 ``` In that case, the POM is fetched, relocation config found and the warning can be printed. -- 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
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803175#comment-17803175 ] ASF GitHub Bot commented on MCOMPILER-391: -- famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1877127524 @psiroky Yeah, I think you have a very valid point: There is no explicit version for that old groupId and so there is no precise way to find the exact pom with the relocation info (=> new groupId). As a human you could just check the latest version for the old groupId and get the relocation info from that but I doubt there is a nice way of finding the latest version via Maven builtin features (?). Not worth the hassle. For extra user-friendliness this plugin could check (if no version is found) for _similar_ deps, e.g. same artifactId but differen groupId and print put all those candidates, but relocations are not limited to groupIds (AFAIK), so... It probably boils down to the question why there are/were no relocations warnings like you get for "normal" dependencies. For general plugin dependencies that's clearly something that Maven should cover. `annotationProcessorPaths` is probably a different story. > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1877127524 @psiroky Yeah, I think you have a very valid point: There is no explicit version for that old groupId and so there is no precise way to find the exact pom with the relocation info (=> new groupId). As a human you could just check the latest version for the old groupId and get the relocation info from that but I doubt there is a nice way of finding the latest version via Maven builtin features (?). Not worth the hassle. For extra user-friendliness this plugin could check (if no version is found) for _similar_ deps, e.g. same artifactId but differen groupId and print put all those candidates, but relocations are not limited to groupIds (AFAIK), so... It probably boils down to the question why there are/were no relocations warnings like you get for "normal" dependencies. For general plugin dependencies that's clearly something that Maven should cover. `annotationProcessorPaths` is probably a different story. -- 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
Re: [PR] subject verb agreement [maven-compiler-plugin]
elharo merged PR #221: URL: https://github.com/apache/maven-compiler-plugin/pull/221 -- 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
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876984635 @famod thanks. In this case, I am not quite sure this is supported from Maven itself. I assume there is no version anywhere in the project depMgmt for `org.hibernate:hibernate-jpamodelgen` and so there is also no information which could map it to the new artifact `org.hibernate.orm:hibernate-jpamodelgen`. That mapping information is part of the old / original POM, but since the plugin does not have the version for this old artifact, it cannot lookup the POM with the relocation config. Does that make sense? Or am I overlooking something in the setup? Or this perhaps something that is working for you outside of the compiler plugin configuration with standard project dependencies? -- 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
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803039#comment-17803039 ] ASF GitHub Bot commented on MCOMPILER-391: -- psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876984635 @famod thanks. In this case, I am not quite sure this is supported from Maven itself. I assume there is no version anywhere in the project depMgmt for `org.hibernate:hibernate-jpamodelgen` and so there is also no information which could map it to the new artifact `org.hibernate.orm:hibernate-jpamodelgen`. That mapping information is part of the old / original POM, but since the plugin does not have the version for this old artifact, it cannot lookup the POM with the relocation config. Does that make sense? Or am I overlooking something in the setup? Or this perhaps something that is working for you outside of the compiler plugin configuration with standard project dependencies? > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump jacocoVersion from 0.8.8 to 0.8.11 [maven-surefire]
dependabot[bot] commented on PR #683: URL: https://github.com/apache/maven-surefire/pull/683#issuecomment-1876953440 OK, I won't notify you again about this release, but will get in touch when a new version is available. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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
Re: [PR] Bump jacocoVersion from 0.8.8 to 0.8.11 [maven-surefire]
michael-o closed pull request #683: Bump jacocoVersion from 0.8.8 to 0.8.11 URL: https://github.com/apache/maven-surefire/pull/683 -- 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
Re: [PR] Bump jacocoVersion from 0.8.8 to 0.8.11 [maven-surefire]
michael-o commented on PR #683: URL: https://github.com/apache/maven-surefire/pull/683#issuecomment-1876953392 Merged. -- 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
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802972#comment-17802972 ] ASF GitHub Bot commented on MCOMPILER-391: -- famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876946809 @psiroky sure: > Are you relying on the new dependency management Yes, that's what I tried and this doesn't work (old groupId): ```xml org.hibernate hibernate-jpamodelgen ``` but this does work (new, relocated groupId): ``` ``` org.hibernate.orm hibernate-jpamodelgen ``` The Quarkus BOM I'm importing has this entry (new groupId only!): https://github.com/quarkusio/quarkus/blob/3.6.4/bom/application/pom.xml#L5012-L5014 > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876946809 @psiroky sure: > Are you relying on the new dependency management Yes, that's what I tried and this doesn't work (old groupId): ```xml org.hibernate hibernate-jpamodelgen ``` but this does work (new, relocated groupId): ``` ``` org.hibernate.orm hibernate-jpamodelgen ``` The Quarkus BOM I'm importing has this entry (new groupId only!): https://github.com/quarkusio/quarkus/blob/3.6.4/bom/application/pom.xml#L5012-L5014 -- 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
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802947#comment-17802947 ] ASF GitHub Bot commented on MCOMPILER-391: -- psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876936773 @famod could you please provide a bit more details, maybe with an example configuration of the plugin? Are you relying on the new dependency management, or specifying the version manually as before? > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
psiroky commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876936773 @famod could you please provide a bit more details, maybe with an example configuration of the plugin? Are you relying on the new dependency management, or specifying the version manually as before? -- 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
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802911#comment-17802911 ] ASF GitHub Bot commented on MCOMPILER-391: -- famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876921475 Just a heads up: This implementation does not seem to respect relocations, e.g. I was still using https://mvnrepository.com/artifact/org.hibernate/hibernate-jpamodelgen in my plugin config but the Quarkus BOM contains (only) the new and proper group id `org.hibernate.orm` and not the old one ``org.hibernate.` and so the annotation processor path version lookup logic didn't find it. Took me a while to figure out. > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-391] Use dep mgmt when resolving annotation processors and their deps [maven-compiler-plugin]
famod commented on PR #180: URL: https://github.com/apache/maven-compiler-plugin/pull/180#issuecomment-1876921475 Just a heads up: This implementation does not seem to respect relocations, e.g. I was still using https://mvnrepository.com/artifact/org.hibernate/hibernate-jpamodelgen in my plugin config but the Quarkus BOM contains (only) the new and proper group id `org.hibernate.orm` and not the old one ``org.hibernate.` and so the annotation processor path version lookup logic didn't find it. Took me a while to figure out. -- 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
[jira] [Commented] (DOXIASITETOOLS-324) Allow configuration of parser (per markup source path pattern)
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802900#comment-17802900 ] ASF GitHub Bot commented on DOXIASITETOOLS-324: --- kwin opened a new pull request, #126: URL: https://github.com/apache/maven-doxia-sitetools/pull/126 (no comment) > Allow configuration of parser (per markup source path pattern) > -- > > Key: DOXIASITETOOLS-324 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-324 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the Doxia parsers being used for the Doxia markup sources have a > fix configuration > (https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L324). > It would be beneficial to allow to dynamically configure the parsers (based > on a matching markup source path pattern) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [DOXIASITETOOLS-324] Allow configuration of Doxia parser [maven-doxia-sitetools]
kwin opened a new pull request, #126: URL: https://github.com/apache/maven-doxia-sitetools/pull/126 (no comment) -- 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
[jira] [Created] (DOXIASITETOOLS-324) Allow configuration of parser (per markup source path pattern)
Konrad Windszus created DOXIASITETOOLS-324: -- Summary: Allow configuration of parser (per markup source path pattern) Key: DOXIASITETOOLS-324 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-324 Project: Maven Doxia Sitetools Issue Type: New Feature Components: Site renderer Reporter: Konrad Windszus Assignee: Konrad Windszus Currently the Doxia parsers being used for the Doxia markup sources have a fix configuration (https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L324). It would be beneficial to allow to dynamically configure the parsers (based on a matching markup source path pattern) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Drop old TestNG, test with more recent ones [maven-surefire]
michael-o opened a new pull request, #710: URL: https://github.com/apache/maven-surefire/pull/710 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) 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. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-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. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). 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. - [ ] 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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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
Re: [PR] Bump org.testng:testng from 5.10 to 5.11 [maven-surefire]
dependabot[bot] commented on PR #677: URL: https://github.com/apache/maven-surefire/pull/677#issuecomment-1876707564 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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
Re: [PR] Bump org.testng:testng from 5.10 to 5.11 [maven-surefire]
michael-o closed pull request #677: Bump org.testng:testng from 5.10 to 5.11 URL: https://github.com/apache/maven-surefire/pull/677 -- 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
Re: [PR] Bump org.testng:testng from 5.10 to 5.11 [maven-surefire]
michael-o commented on PR #677: URL: https://github.com/apache/maven-surefire/pull/677#issuecomment-1876707374 @slachiewicz Merged this to use a property. The rest requires more work. -- 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
Re: [PR] Bump org.testng:testng from 5.10 to 5.11 [maven-surefire]
michael-o commented on PR #677: URL: https://github.com/apache/maven-surefire/pull/677#issuecomment-1876705583 > This is a very old dependency also with classifier java5 Should the classifier dropped or does it require more work? -- 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
Re: [PR] Bump org.testng:testng from 5.10 to 5.11 [maven-surefire]
slachiewicz commented on PR #677: URL: https://github.com/apache/maven-surefire/pull/677#issuecomment-1876696214 This is a very old dependency also with classifier java5 -- 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
Re: [PR] Bump org.testng:testng from 5.10 to 5.11 [maven-surefire]
michael-o commented on PR #677: URL: https://github.com/apache/maven-surefire/pull/677#issuecomment-1876686868 @dependabot rebase -- 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
Re: [PR] Bump org.htmlunit:htmlunit from 3.8.0 to 3.9.0 in /maven-failsafe-plugin/src/it/jetty-war-test-passing [maven-surefire]
michael-o merged PR #693: URL: https://github.com/apache/maven-surefire/pull/693 -- 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
Re: [PR] Bump org.htmlunit:htmlunit from 3.8.0 to 3.9.0 in /maven-failsafe-plugin/src/it/jetty-war-test-passing [maven-surefire]
michael-o commented on PR #693: URL: https://github.com/apache/maven-surefire/pull/693#issuecomment-1876685643 @dependabot rebase -- 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
Re: [PR] Bump org.htmlunit:htmlunit from 3.8.0 to 3.9.0 in /maven-failsafe-plugin/src/it/jetty-war-test-failing [maven-surefire]
michael-o merged PR #694: URL: https://github.com/apache/maven-surefire/pull/694 -- 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
[jira] [Closed] (SUREFIRE-2229) [REGRESSION] SUREFIRE-2224 causes stack trace to be omitted for errors and failures
[
https://issues.apache.org/jira/browse/SUREFIRE-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SUREFIRE-2229.
Resolution: Fixed
Fixed with
[e7507601f4f6b10d82518fa5f3d32aab17e26d11|https://gitbox.apache.org/repos/asf?p=maven-surefire.git&a=commit&h=e7507601f4f6b10d82518fa5f3d32aab17e26d11].
> [REGRESSION] SUREFIRE-2224 causes stack trace to be omitted for errors and
> failures
> ---
>
> Key: SUREFIRE-2229
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2229
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.5
>
>
> As reported by [~marcphilipp]
> [here|https://github.com/apache/maven-surefire/pull/702#discussion_r1439664959]
> the stack traces of {{failure}} and {{error}} are omitted due to bad XML
> schema design. Restore the ability to record the stack trace and log an
> improvement request to the XML schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump org.htmlunit:htmlunit from 3.8.0 to 3.9.0 in /maven-failsafe-plugin/src/it/jetty-war-test-failing [maven-surefire]
michael-o commented on PR #694: URL: https://github.com/apache/maven-surefire/pull/694#issuecomment-1876684845 @dependabot rebase -- 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
[jira] [Commented] (SUREFIRE-2229) [REGRESSION] SUREFIRE-2224 causes stack trace to be omitted for errors and failures
[
https://issues.apache.org/jira/browse/SUREFIRE-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802630#comment-17802630
]
ASF GitHub Bot commented on SUREFIRE-2229:
--
michael-o closed pull request #709: [SUREFIRE-2229] [REGRESSION] SUREFIRE-2224
causes stack trace to be o…
URL: https://github.com/apache/maven-surefire/pull/709
> [REGRESSION] SUREFIRE-2224 causes stack trace to be omitted for errors and
> failures
> ---
>
> Key: SUREFIRE-2229
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2229
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.5
>
>
> As reported by [~marcphilipp]
> [here|https://github.com/apache/maven-surefire/pull/702#discussion_r1439664959]
> the stack traces of {{failure}} and {{error}} are omitted due to bad XML
> schema design. Restore the ability to record the stack trace and log an
> improvement request to the XML schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2229] [REGRESSION] SUREFIRE-2224 causes stack trace to be o… [maven-surefire]
michael-o closed pull request #709: [SUREFIRE-2229] [REGRESSION] SUREFIRE-2224 causes stack trace to be o… URL: https://github.com/apache/maven-surefire/pull/709 -- 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
