[GitHub] [maven-surefire] slawekjaranowski commented on pull request #579: [SUREFIRE-2129] Upgrade Maven Reporting API to 3.1.1/Maven Reporting …
slawekjaranowski commented on PR #579: URL: https://github.com/apache/maven-surefire/pull/579#issuecomment-1360991079 @michael-o looks like this merge break a build on master 😄 -- 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-7645) Implement some #toString() methods
[
https://issues.apache.org/jira/browse/MNG-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7645:
Summary: Implement some #toString() methods (was: Implement some toStrings)
> Implement some #toString() methods
> --
>
> Key: MNG-7645
> URL: https://issues.apache.org/jira/browse/MNG-7645
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.6
>Reporter: Piotr Zygielo
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> If something decides to dump some build/session details, like
> `maven-bundle-plugin` with `--debug` does, currently it produces:
> {noformat}
> [DEBUG] BND Instructions:
> project.build.mailingLists=[org.apache.maven.model.MailingList@16e91d6f,
> org.apache.maven.model.MailingList@57104caa]
> project.licenses=[org.apache.maven.model.License@416855dc,
> org.apache.maven.model.License@1f342afb]
> project.build.scm=org.apache.maven.model.Scm@5d4369c5{noformat}
> I propose to change that to something more friendly by overriding toString.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] michael-o commented on pull request #579: [SUREFIRE-2129] Upgrade Maven Reporting API to 3.1.1/Maven Reporting …
michael-o commented on PR #579: URL: https://github.com/apache/maven-surefire/pull/579#issuecomment-1361000424 > @michael-o looks like this merge break a build on master 😄 Already noticed. Will take a look. Surefire is getting bigger and bigger :-( -- 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
[GitHub] [maven] asfgit closed pull request #933: [MNG-7645] Implement `toString`s in model
asfgit closed pull request #933: [MNG-7645] Implement `toString`s in model URL: https://github.com/apache/maven/pull/933 -- 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] (MNG-7645) Implement some #toString() methods
[
https://issues.apache.org/jira/browse/MNG-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7645.
---
Resolution: Fixed
Fixed with
[880b00133ee2d2db68350a3b01d7f9834efc|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=880b00133ee2d2db68350a3b01d7f9834efc],
with
[4adaf2abca4e3018b92c0c03e07c50a6b1a8ddab|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=4adaf2abca4e3018b92c0c03e07c50a6b1a8ddab]
for maven-3.9.x branch, with
[6c53b28ecc84f0f90d5417f199d99b20334f26d7|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=6c53b28ecc84f0f90d5417f199d99b20334f26d7]
for maven-3.8.x branch.
> Implement some #toString() methods
> --
>
> Key: MNG-7645
> URL: https://issues.apache.org/jira/browse/MNG-7645
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.6
>Reporter: Piotr Zygielo
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> If something decides to dump some build/session details, like
> `maven-bundle-plugin` with `--debug` does, currently it produces:
> {noformat}
> [DEBUG] BND Instructions:
> project.build.mailingLists=[org.apache.maven.model.MailingList@16e91d6f,
> org.apache.maven.model.MailingList@57104caa]
> project.licenses=[org.apache.maven.model.License@416855dc,
> org.apache.maven.model.License@1f342afb]
> project.build.scm=org.apache.maven.model.Scm@5d4369c5{noformat}
> I propose to change that to something more friendly by overriding toString.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7645) Implement some #toString() methods
[
https://issues.apache.org/jira/browse/MNG-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650316#comment-17650316
]
ASF GitHub Bot commented on MNG-7645:
-
asfgit closed pull request #933: [MNG-7645] Implement `toString`s in model
URL: https://github.com/apache/maven/pull/933
> Implement some #toString() methods
> --
>
> Key: MNG-7645
> URL: https://issues.apache.org/jira/browse/MNG-7645
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.6
>Reporter: Piotr Zygielo
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> If something decides to dump some build/session details, like
> `maven-bundle-plugin` with `--debug` does, currently it produces:
> {noformat}
> [DEBUG] BND Instructions:
> project.build.mailingLists=[org.apache.maven.model.MailingList@16e91d6f,
> org.apache.maven.model.MailingList@57104caa]
> project.licenses=[org.apache.maven.model.License@416855dc,
> org.apache.maven.model.License@1f342afb]
> project.build.scm=org.apache.maven.model.Scm@5d4369c5{noformat}
> I propose to change that to something more friendly by overriding toString.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7644) Fix version comparison ( .RC1 < -RC2 )
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwénaël Ruelland updated MNG-7644: -- Description: The current version parser does not treat .RC and -RC correctly: actual : 1.0.0.RC1 > 1.0.0-RC2 expected : 1.0.0.RC1 < 1.0.0-RC2 because RC1 < RC2 how to fix : place a list item before qualifier the intention is to have this same result with all qualifier x: actual : 1.0.0.X1 > 1.0.0-X2 actual : 1.0.X < 1.0.0.X expected : 1.0.0.X1 < 1.0.0-X2 expected : 1.0.X == 1-X == 1.0.0.X was: The current version parser does not treat .RC and -RC correctly: actual: 1.0.0.RC1 > 1.0.0-RC2 expected: 1.0.0.RC1 < 1.0.0-RC2 because RC1 < RC2 how to fix: place a list item before qualifier > Fix version comparison ( .RC1 < -RC2 ) > -- > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7644) Fix version comparison ( .X1 < -X2 for any qualifier X )
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwénaël Ruelland updated MNG-7644: -- Summary: Fix version comparison ( .X1 < -X2 for any qualifier X ) (was: Fix version comparison ( .RC1 < -RC2 )) > Fix version comparison ( .X1 < -X2 for any qualifier X ) > > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X )
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwénaël Ruelland updated MNG-7644: -- Summary: Fix version comparison ( .X1 < -X2 for any string qualifier X ) (was: Fix version comparison ( .X1 < -X2 for any qualifier X )) > Fix version comparison ( .X1 < -X2 for any string qualifier X ) > --- > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7644: Summary: Fix version comparison ( .X1 < -X2 for any string qualifier X) (was: Fix version comparison ( .X1 < -X2 for any string qualifier X )) > Fix version comparison ( .X1 < -X2 for any string qualifier X) > -- > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7644: Fix Version/s: 3.8.x-candidate 3.9.0-candidate 4.0.x-candidate > Fix version comparison ( .X1 < -X2 for any string qualifier X) > -- > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] sultan commented on pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
sultan commented on PR #930:
URL: https://github.com/apache/maven/pull/930#issuecomment-1361083577
> > > Does this really only apply to RC or anything else which has the
pattern `dot/hyphen{item}{digit/number}`?
> >
> >
> > it is intended to apply to all string qualifiers: dot/hyphen{string item}
>
> Then please generalize the issue summary as well as the description and
add more tests which depict that is general and not specific. Let's make this
complete for master first and then I consent, then you can back port and save
time.
it's fair @michael-o, i updated the Jira and PRs/commits.
i hope its all ok now.
thank you very much for your time!
--
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-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[
https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650625#comment-17650625
]
ASF GitHub Bot commented on MNG-7644:
-
sultan commented on PR #930:
URL: https://github.com/apache/maven/pull/930#issuecomment-1361083577
> > > Does this really only apply to RC or anything else which has the
pattern `dot/hyphen{item}{digit/number}`?
> >
> >
> > it is intended to apply to all string qualifiers: dot/hyphen{string item}
>
> Then please generalize the issue summary as well as the description and
add more tests which depict that is general and not specific. Let's make this
complete for master first and then I consent, then you can back port and save
time.
it's fair @michael-o, i updated the Jira and PRs/commits.
i hope its all ok now.
thank you very much for your time!
> Fix version comparison ( .X1 < -X2 for any string qualifier X)
> --
>
> Key: MNG-7644
> URL: https://issues.apache.org/jira/browse/MNG-7644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Gwénaël Ruelland
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate
>
>
> The current version parser does not treat .RC and -RC correctly:
> actual : 1.0.0.RC1 > 1.0.0-RC2
> expected : 1.0.0.RC1 < 1.0.0-RC2
> because RC1 < RC2
> how to fix : place a list item before qualifier
> the intention is to have this same result with all qualifier x:
> actual : 1.0.0.X1 > 1.0.0-X2
> actual : 1.0.X < 1.0.0.X
> expected : 1.0.0.X1 < 1.0.0-X2
> expected : 1.0.X == 1-X == 1.0.0.X
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on a diff in pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
sultan commented on code in PR #929: URL: https://github.com/apache/maven/pull/929#discussion_r1054189508 ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -40,22 +41,39 @@ * 1.0alpha1 => [1, 0, alpha, 1] * unlimited number of version components, * version components in the text can be digits or strings, - * strings are checked for well-known qualifiers and the qualifier ordering is used for version ordering. - * Well-known qualifiers (case insensitive) are: - * alpha or a - * beta or b - * milestone or m - * rc or cr - * snapshot - * (the empty string) or ga or final - * sp - * - * Unknown qualifiers are considered after known qualifiers, with lexical order (always case insensitive), - * - * a hyphen usually precedes a qualifier, and is always less important than something preceded with a dot. + * + * String qualifiers are ordered lexically (case insensitive), with the following exceptions: + * + * 'snapshot' < '' < 'sp' Review Comment: > The cleanup you mean? i think Andrzej meant a vote for Maven 4 to be semver compatible or at least move towards it step by step (PR by PR) -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650674#comment-17650674
]
ASF GitHub Bot commented on MNG-7559:
-
sultan commented on code in PR #929:
URL: https://github.com/apache/maven/pull/929#discussion_r1054189508
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -40,22 +41,39 @@
* 1.0alpha1 => [1, 0, alpha, 1]
* unlimited number of version components,
* version components in the text can be digits or strings,
- * strings are checked for well-known qualifiers and the qualifier
ordering is used for version ordering.
- * Well-known qualifiers (case insensitive) are:
- * alpha or a
- * beta or b
- * milestone or m
- * rc or cr
- * snapshot
- * (the empty string) or ga or
final
- * sp
- *
- * Unknown qualifiers are considered after known qualifiers, with lexical
order (always case insensitive),
- *
- * a hyphen usually precedes a qualifier, and is always less important
than something preceded with a dot.
+ *
+ * String qualifiers are ordered lexically (case insensitive), with the
following exceptions:
+ *
+ * 'snapshot' < '' < 'sp'
Review Comment:
> The cleanup you mean?
i think Andrzej meant a vote for Maven 4 to be semver compatible or at least
move towards it step by step (PR by PR)
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
michael-o commented on code in PR #930:
URL: https://github.com/apache/maven/pull/930#discussion_r1054191144
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
+ */
+public void testMng7644()
+{
+for ( String x : new String[]{ "alpha", "a", "beta", "b", "milestone",
"m", "RC" } ) {
Review Comment:
You should add at least two arbitrary one as well.
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -53,7 +53,8 @@
*
* Unknown qualifiers are considered after known qualifiers, with lexical
order (always case insensitive),
*
- * a hyphen usually precedes a qualifier, and is always less important
than something preceded with a dot.
+ * a hyphen usually precedes a qualifier, and is always less important
than digits/number, for example
+ * 1.0.RC2 < 1.0-RC3 < 1.0.1 ; but prefer '1.0.0-RC1' over '1.0.0.RC1'
Review Comment:
This needs to be generalized as well.
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
Review Comment:
This needs to be generalized 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] [Commented] (MNG-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[
https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650687#comment-17650687
]
ASF GitHub Bot commented on MNG-7644:
-
michael-o commented on code in PR #930:
URL: https://github.com/apache/maven/pull/930#discussion_r1054191144
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
+ */
+public void testMng7644()
+{
+for ( String x : new String[]{ "alpha", "a", "beta", "b", "milestone",
"m", "RC" } ) {
Review Comment:
You should add at least two arbitrary one as well.
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -53,7 +53,8 @@
*
* Unknown qualifiers are considered after known qualifiers, with lexical
order (always case insensitive),
*
- * a hyphen usually precedes a qualifier, and is always less important
than something preceded with a dot.
+ * a hyphen usually precedes a qualifier, and is always less important
than digits/number, for example
+ * 1.0.RC2 < 1.0-RC3 < 1.0.1 ; but prefer '1.0.0-RC1' over '1.0.0.RC1'
Review Comment:
This needs to be generalized as well.
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
Review Comment:
This needs to be generalized as well.
> Fix version comparison ( .X1 < -X2 for any string qualifier X)
> --
>
> Key: MNG-7644
> URL: https://issues.apache.org/jira/browse/MNG-7644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Gwénaël Ruelland
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate
>
>
> The current version parser does not treat .RC and -RC correctly:
> actual : 1.0.0.RC1 > 1.0.0-RC2
> expected : 1.0.0.RC1 < 1.0.0-RC2
> because RC1 < RC2
> how to fix : place a list item before qualifier
> the intention is to have this same result with all qualifier x:
> actual : 1.0.0.X1 > 1.0.0-X2
> actual : 1.0.X < 1.0.0.X
> expected : 1.0.0.X1 < 1.0.0-X2
> expected : 1.0.X == 1-X == 1.0.0.X
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on pull request #929: [MNG-7559] Fix version comparison (master 4.0.x branch)
sultan commented on PR #929: URL: https://github.com/apache/maven/pull/929#issuecomment-1361095442 > What I now understand is that arbitrary qualifiers are not considered _after_ `GA`. Following example: I need to fork commons-io 2.12.0 for the company and it will be named `2.12.0-company-1` through `2.12.0-company-5`. I would expect that those come _after_ the GA because I had to apply custom patches. > > I do this at work for various reasons and if you check libs bundled with Nexus they have `SONATYPE` qualifier. you need to use the + instead of - as in: 2.12.0+company-1 -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650693#comment-17650693
]
ASF GitHub Bot commented on MNG-7559:
-
sultan commented on PR #929:
URL: https://github.com/apache/maven/pull/929#issuecomment-1361095442
> What I now understand is that arbitrary qualifiers are not considered
_after_ `GA`. Following example: I need to fork commons-io 2.12.0 for the
company and it will be named `2.12.0-company-1` through `2.12.0-company-5`. I
would expect that those come _after_ the GA because I had to apply custom
patches.
>
> I do this at work for various reasons and if you check libs bundled with
Nexus they have `SONATYPE` qualifier.
you need to use the + instead of - as in:
2.12.0+company-1
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3,
> 4.0.0-alpha-4
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on a diff in pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
sultan commented on code in PR #930: URL: https://github.com/apache/maven/pull/930#discussion_r1054197217 ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -53,7 +53,8 @@ * * Unknown qualifiers are considered after known qualifiers, with lexical order (always case insensitive), * - * a hyphen usually precedes a qualifier, and is always less important than something preceded with a dot. + * a hyphen usually precedes a qualifier, and is always less important than digits/number, for example + * 1.0.RC2 < 1.0-RC3 < 1.0.1 ; but prefer '1.0.0-RC1' over '1.0.0.RC1' Review Comment: yes -- 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-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650716#comment-17650716 ] ASF GitHub Bot commented on MNG-7644: - sultan commented on code in PR #930: URL: https://github.com/apache/maven/pull/930#discussion_r1054197217 ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -53,7 +53,8 @@ * * Unknown qualifiers are considered after known qualifiers, with lexical order (always case insensitive), * - * a hyphen usually precedes a qualifier, and is always less important than something preceded with a dot. + * a hyphen usually precedes a qualifier, and is always less important than digits/number, for example + * 1.0.RC2 < 1.0-RC3 < 1.0.1 ; but prefer '1.0.0-RC1' over '1.0.0.RC1' Review Comment: yes > Fix version comparison ( .X1 < -X2 for any string qualifier X) > -- > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-431) Skip specific rules
[
https://issues.apache.org/jira/browse/MENFORCER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650795#comment-17650795
]
Petr Široký commented on MENFORCER-431:
---
Since this is {{up-for-grabs}} I will take a look and see if I can add a new
config option to skip just specific rules.
> Skip specific rules
> ---
>
> Key: MENFORCER-431
> URL: https://issues.apache.org/jira/browse/MENFORCER-431
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 3.1.0
>Reporter: Delany
>Priority: Minor
> Labels: up-for-grabs
>
> I can select rules like
> {code:java}
> mvn verify -Drules=alwaysPass,alwaysFail {code}
> or skip all rules with
> {code:java}
> mvn verify -Denforcer.skip
> {code}
> But what if I want to skip a single rule?
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies{code}
> Or multiple
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies,NoPackageCyclesRule{code}
> Vulnerabilities could be discovered and published at any time. This would be
> a useful to quickly allow my builds to continue, since I can't always upgrade
> dependencies as they appear.
> I don't want to turn off ALL my enforcer checks and I also dont want to list
> all the checks in the build command.
> Skipping a rule is an exceptional circumstance so I don't want to commit it
> to the pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on a diff in pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
sultan commented on code in PR #930:
URL: https://github.com/apache/maven/pull/930#discussion_r1054206213
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
+ */
+public void testMng7644()
+{
+for ( String x : new String[]{ "alpha", "a", "beta", "b", "milestone",
"m", "RC" } ) {
Review Comment:
i suppose you mean like abc and def. will do
--
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-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[
https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650796#comment-17650796
]
ASF GitHub Bot commented on MNG-7644:
-
sultan commented on code in PR #930:
URL: https://github.com/apache/maven/pull/930#discussion_r1054206213
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
+ */
+public void testMng7644()
+{
+for ( String x : new String[]{ "alpha", "a", "beta", "b", "milestone",
"m", "RC" } ) {
Review Comment:
i suppose you mean like abc and def. will do
> Fix version comparison ( .X1 < -X2 for any string qualifier X)
> --
>
> Key: MNG-7644
> URL: https://issues.apache.org/jira/browse/MNG-7644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Gwénaël Ruelland
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate
>
>
> The current version parser does not treat .RC and -RC correctly:
> actual : 1.0.0.RC1 > 1.0.0-RC2
> expected : 1.0.0.RC1 < 1.0.0-RC2
> because RC1 < RC2
> how to fix : place a list item before qualifier
> the intention is to have this same result with all qualifier x:
> actual : 1.0.0.X1 > 1.0.0-X2
> actual : 1.0.X < 1.0.0.X
> expected : 1.0.0.X1 < 1.0.0-X2
> expected : 1.0.X == 1-X == 1.0.0.X
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650801#comment-17650801
]
Bertrand Martin commented on DOXIA-617:
---
Thank you [~hboutemy], this clarifies the workflow, which has an extra step for
Markdown, since it goes through the *XhtmlParser*, that's what I meant (as
documented in your beautiful diagram ;-) )
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650801#comment-17650801
]
Bertrand Martin edited comment on DOXIA-617 at 12/21/22 10:15 AM:
--
Thank you [~hboutemy], this clarifies the workflow, which has an extra step for
Markdown, since it goes through the _XhtmlParser_, that's what I meant (as
documented in your beautiful diagram ;-) )
was (Author: bertrandmartin):
Thank you [~hboutemy], this clarifies the workflow, which has an extra step for
Markdown, since it goes through the *XhtmlParser*, that's what I meant (as
documented in your beautiful diagram ;-) )
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on a diff in pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
sultan commented on code in PR #930:
URL: https://github.com/apache/maven/pull/930#discussion_r1054215083
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -53,7 +53,8 @@
*
* Unknown qualifiers are considered after known qualifiers, with lexical
order (always case insensitive),
*
- * a hyphen usually precedes a qualifier, and is always less important
than something preceded with a dot.
+ * a hyphen usually precedes a qualifier, and is always less important
than digits/number, for example
+ * 1.0.RC2 < 1.0-RC3 < 1.0.1 ; but prefer '1.0.0-RC1' over '1.0.0.RC1'
Review Comment:
done
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
+ */
+public void testMng7644()
+{
+for ( String x : new String[]{ "alpha", "a", "beta", "b", "milestone",
"m", "RC" } ) {
Review Comment:
done
--
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-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[
https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650802#comment-17650802
]
ASF GitHub Bot commented on MNG-7644:
-
sultan commented on code in PR #930:
URL: https://github.com/apache/maven/pull/930#discussion_r1054215083
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -53,7 +53,8 @@
*
* Unknown qualifiers are considered after known qualifiers, with lexical
order (always case insensitive),
*
- * a hyphen usually precedes a qualifier, and is always less important
than something preceded with a dot.
+ * a hyphen usually precedes a qualifier, and is always less important
than digits/number, for example
+ * 1.0.RC2 < 1.0-RC3 < 1.0.1 ; but prefer '1.0.0-RC1' over '1.0.0.RC1'
Review Comment:
done
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -337,4 +337,20 @@ public void testReuse()
assertEquals( "reused instance should be equivalent to new instance",
c1, c2 );
}
+
+/**
+ * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases
+ * 1.0.0.RC1 < 1.0.0-RC2
+ */
+public void testMng7644()
+{
+for ( String x : new String[]{ "alpha", "a", "beta", "b", "milestone",
"m", "RC" } ) {
Review Comment:
done
> Fix version comparison ( .X1 < -X2 for any string qualifier X)
> --
>
> Key: MNG-7644
> URL: https://issues.apache.org/jira/browse/MNG-7644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Gwénaël Ruelland
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate
>
>
> The current version parser does not treat .RC and -RC correctly:
> actual : 1.0.0.RC1 > 1.0.0-RC2
> expected : 1.0.0.RC1 < 1.0.0-RC2
> because RC1 < RC2
> how to fix : place a list item before qualifier
> the intention is to have this same result with all qualifier x:
> actual : 1.0.0.X1 > 1.0.0-X2
> actual : 1.0.X < 1.0.0.X
> expected : 1.0.0.X1 < 1.0.0-X2
> expected : 1.0.X == 1-X == 1.0.0.X
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7629) Improve resolution of modules within a multi-module build
[ https://issues.apache.org/jira/browse/MNG-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7629: - Summary: Improve resolution of modules within a multi-module build (was: Revert MNG-6118 and provide a better solution for it) > Improve resolution of modules within a multi-module build > - > > Key: MNG-7629 > URL: https://issues.apache.org/jira/browse/MNG-7629 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] sultan commented on a diff in pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
sultan commented on code in PR #930: URL: https://github.com/apache/maven/pull/930#discussion_r1054215565 ## maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java: ## @@ -337,4 +337,20 @@ public void testReuse() assertEquals( "reused instance should be equivalent to new instance", c1, c2 ); } + +/** + * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases + * 1.0.0.RC1 < 1.0.0-RC2 Review Comment: done -- 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-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650803#comment-17650803 ] ASF GitHub Bot commented on MNG-7644: - sultan commented on code in PR #930: URL: https://github.com/apache/maven/pull/930#discussion_r1054215565 ## maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java: ## @@ -337,4 +337,20 @@ public void testReuse() assertEquals( "reused instance should be equivalent to new instance", c1, c2 ); } + +/** + * Test https://issues.apache.org/jira/browse/MNG-7644";>MNG-7644 edge cases + * 1.0.0.RC1 < 1.0.0-RC2 Review Comment: done > Fix version comparison ( .X1 < -X2 for any string qualifier X) > -- > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7646) Do not parse all projects in the reactor
[ https://issues.apache.org/jira/browse/MNG-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7646: - Summary: Do not parse all projects in the reactor (was: Do not parse the whole reactor) > Do not parse all projects in the reactor > > > Key: MNG-7646 > URL: https://issues.apache.org/jira/browse/MNG-7646 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7646) Do not parse the whole reactor
Guillaume Nodet created MNG-7646: Summary: Do not parse the whole reactor Key: MNG-7646 URL: https://issues.apache.org/jira/browse/MNG-7646 Project: Maven Issue Type: Task Affects Versions: 4.0.0-alpha-3 Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #912: [MNG-7629] Improve resolution of modules within a multi-module build
gnodet commented on PR #912:
URL: https://github.com/apache/maven/pull/912#issuecomment-1361132977
I'm going to split the two issues as they can be handled separately:
* [MNG-7629](https://issues.apache.org/jira/browse/MNG-7629): cache all
built artifacts in a per-multi-project repository so that they can be reused in
later builds, do not point to {{target/classes}} to ensure correct build
* [MNG-7646](https://issues.apache.org/jira/browse/MNG-7646): do not parse
all poms in the reactor when building a subtree
--
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-7629) Improve resolution of modules within a multi-module build
[
https://issues.apache.org/jira/browse/MNG-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650812#comment-17650812
]
ASF GitHub Bot commented on MNG-7629:
-
gnodet commented on PR #912:
URL: https://github.com/apache/maven/pull/912#issuecomment-1361132977
I'm going to split the two issues as they can be handled separately:
* [MNG-7629](https://issues.apache.org/jira/browse/MNG-7629): cache all
built artifacts in a per-multi-project repository so that they can be reused in
later builds, do not point to {{target/classes}} to ensure correct build
* [MNG-7646](https://issues.apache.org/jira/browse/MNG-7646): do not parse
all poms in the reactor when building a subtree
> Improve resolution of modules within a multi-module build
> -
>
> Key: MNG-7629
> URL: https://issues.apache.org/jira/browse/MNG-7629
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-4
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7646) Do not parse all projects in the reactor when building a subtree
[ https://issues.apache.org/jira/browse/MNG-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-7646: - Summary: Do not parse all projects in the reactor when building a subtree (was: Do not parse all projects in the reactor) > Do not parse all projects in the reactor when building a subtree > > > Key: MNG-7646 > URL: https://issues.apache.org/jira/browse/MNG-7646 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7646) Do not parse all projects in the reactor when building a subtree
[ https://issues.apache.org/jira/browse/MNG-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650822#comment-17650822 ] Maarten Mulders commented on MNG-7646: -- I am still very much in doubt about this topic. >From a user point-of-view, I would expect Maven to "understand" that the >subtree is part of a bigger project, and be able to at least resolve >dependencies that live inside the same project tree. The idea to resolve that >over a project-local repository (MNG-7629) sounds promising, but will that >still work if Maven only parses a selection of the root project? > Do not parse all projects in the reactor when building a subtree > > > Key: MNG-7646 > URL: https://issues.apache.org/jira/browse/MNG-7646 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-965) Symbolic links get copied with absolute path
[
https://issues.apache.org/jira/browse/MASSEMBLY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650840#comment-17650840
]
Stefan Seifert commented on MASSEMBLY-965:
--
PR that should solve the root cause is present, but not yet merged:
https://github.com/codehaus-plexus/plexus-io/pull/90
> Symbolic links get copied with absolute path
>
>
> Key: MASSEMBLY-965
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-965
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Marc Guillemot
>Assignee: Guillaume Nodet
>Priority: Major
>
> Copied symbolic links in a `` have an absolute path as target and
> not the one of the original resource.
> Example:
> Source: {{foo -> ../my-file1}}
> Assembly: {{foo ->/home/marc/projects/demo/src/somestuff/myfile1}}
> This is a regression compared to 3.3.0. According to git bisect, the problem
> has been introduced with commit
> [https://github.com/apache/maven-assembly-plugin/commit/937750250bfe06333f92351fa1a19a9cd5e59d28]
> Pull Request with failing integration test follows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7646) Do not parse all projects in the reactor when building a subtree
[ https://issues.apache.org/jira/browse/MNG-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650841#comment-17650841 ] Guillaume Nodet commented on MNG-7646: -- We'll see :-) My point is that I want to focus on MNG-7629 first, and then see what can be done for this one. My main problem with the current state is the processing time when you want to build a single module in a big reactor. If MNG-7629 is solved, I don't have any other technical issues with parsing the whole reactor. > Do not parse all projects in the reactor when building a subtree > > > Key: MNG-7646 > URL: https://issues.apache.org/jira/browse/MNG-7646 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650904#comment-17650904
]
Tamas Cservenak commented on MRESOLVER-308:
---
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:23
{noformat}
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649777#comment-17649777
]
Tamas Cservenak edited comment on MRESOLVER-308 at 12/21/22 3:23 PM:
-
Plan: create -{color:#FF}multi release{color}- JAR for
maven-resolver-transport-java11, that is:
* on Java8 is doermant
* on Java11+ becomes default (instead of "native")
It works without multi release jar, as it raises module release to Java11, and
on Java8 SISU will (silently) skip components from this JAR, so basically this
happens: if on Java8, components are not discovered, nothing changes, while on
Java11 components are discovered and takes over.
*Update:* This is *DONE* on branch: just build it (skip tests for now, some red
herrings still not ironed out), and you will end up with java11 transport JAR
that can be thrown into lib or lib/ext (does not matter). And from that moment
on, if Maven used on Java8, everything is as today, but if on Java11+ the new
transport becomes default.
was (Author: cstamas):
Plan: create multi release JAR for maven-resolver-transport-java11, that is:
* on Java8 is doermant
* on Java11+ becomes default (instead of "native")
*Update:* This is *DONE* on branch: just build it (skip tests for now, some red
herrings still not ironed out), and you will end up with java11 transport JAR
that can be thrown into lib or lib/ext (does not matter). And from that moment
on, if Maven used on Java8, everything is as today, but if on Java11+ the new
transport becomes default.
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650904#comment-17650904
]
Tamas Cservenak edited comment on MRESOLVER-308 at 12/21/22 3:24 PM:
-
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:23{noformat}
was (Author: cstamas):
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:23
{noformat}
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650904#comment-17650904
]
Tamas Cservenak edited comment on MRESOLVER-308 at 12/21/22 3:25 PM:
-
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:23{noformat}
Yes, you did read it well: wagon vs java11 is almost a minute.
was (Author: cstamas):
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:23{noformat}
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-445) Include Java Home in Message for Java Rule Failures
Robert Krajewski created MENFORCER-445: -- Summary: Include Java Home in Message for Java Rule Failures Key: MENFORCER-445 URL: https://issues.apache.org/jira/browse/MENFORCER-445 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Documentation, Standard Rules Affects Versions: 3.1.0 Environment: Maven 3.8.5 Reporter: Robert Krajewski When Java rules fail, for example, when JDK version or vendor fails, knowing exactly which Java implementation caused the problem would be handy, especially when it happens in a CI system that might be setting up Java to be used in a roundabout way. Including the Java home in the message should be enough. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650904#comment-17650904
]
Tamas Cservenak edited comment on MRESOLVER-308 at 12/21/22 3:44 PM:
-
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:51{noformat}
Yes, you did read it well: wagon vs java11 is almost a minute.
was (Author: cstamas):
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:23{noformat}
Yes, you did read it well: wagon vs java11 is almost a minute.
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-308) HTTP transport showdown
[
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650904#comment-17650904
]
Tamas Cservenak edited comment on MRESOLVER-308 at 12/21/22 3:45 PM:
-
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:52
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:51{noformat}
was (Author: cstamas):
Today progress, where modern clients and HTTP/2 does show difference (java11,
jetty rewrote, okhttp pending):
{noformat}
Test buiding resolver against central
wagon 01:22
native 00:52
jetty 00:27
okhttp -- (did not rewrite since last time, unfair to measure)
java11 00:51{noformat}
Yes, you did read it well: wagon vs java11 is almost a minute.
> HTTP transport showdown
> ---
>
> Key: MRESOLVER-308
> URL: https://issues.apache.org/jira/browse/MRESOLVER-308
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
> * transport-wagon that uses Maven 2.x Wagon, that among other protocols
> supports HTTP/1.1 as well
> * transport-http that uses directly Apache HttpClient 4.x supporting
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
> * Maven Central supports HTTP/1.1 but also HTTP/2
> * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
> * Jetty Client
> * OkHTTP
> * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be
> transparently supported (Jetty 12 works on that). We could then simply
> compare these implementations, count in pros and cons, and decide where we
> want to go,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-445) Include Java Home in Message for Java Rule Failures
[ https://issues.apache.org/jira/browse/MENFORCER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Krajewski updated MENFORCER-445: --- Description: When Java rules fail, for example, when JDK version or vendor fails, knowing exactly which Java implementation caused the problem would be handy, especially when it happens in a CI system that might be setting up the Java to be used in a roundabout way. Including the Java home in the message should be enough. was: When Java rules fail, for example, when JDK version or vendor fails, knowing exactly which Java implementation caused the problem would be handy, especially when it happens in a CI system that might be setting up Java to be used in a roundabout way. Including the Java home in the message should be enough. > Include Java Home in Message for Java Rule Failures > --- > > Key: MENFORCER-445 > URL: https://issues.apache.org/jira/browse/MENFORCER-445 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 3.1.0 > Environment: Maven 3.8.5 >Reporter: Robert Krajewski >Priority: Major > Labels: enforcer, messages, usability > > When Java rules fail, for example, when JDK version or vendor fails, knowing > exactly which Java implementation caused the problem would be handy, > especially when it happens in a CI system that might be setting up the Java > to be used in a roundabout way. Including the Java home in the message should > be enough. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-surefire] michael-o opened a new pull request, #586: Fix report tests
michael-o opened a new pull request, #586: URL: https://github.com/apache/maven-surefire/pull/586 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
[GitHub] [maven-jar-plugin] jorsol opened a new pull request, #57: [MJAR-292] - Detect MRJAR and add Multi-Release manifest entry
jorsol opened a new pull request, #57: URL: https://github.com/apache/maven-jar-plugin/pull/57 https://issues.apache.org/jira/browse/MJAR-292 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAR) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MJAR-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAR-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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
[GitHub] [maven-surefire] asfgit closed pull request #586: Fix report tests
asfgit closed pull request #586: Fix report tests URL: https://github.com/apache/maven-surefire/pull/586 -- 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
[GitHub] [maven-surefire] michael-o commented on pull request #586: Fix report tests
michael-o commented on PR #586: URL: https://github.com/apache/maven-surefire/pull/586#issuecomment-1362022811 @slawekjaranowski Tests are passing again. I must have had a blackout not testing properly. -- 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-2129) Upgrade Maven Reporting API to 3.1.1/Maven Reporting Impl to 3.2.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650983#comment-17650983 ] Michael Osipov commented on SUREFIRE-2129: -- Post fixed tests with [1218cf82d206d7644f2fd010ec8a045e0f6abaf8|https://gitbox.apache.org/repos/asf?p=maven-surefire.git&a=commit&h=1218cf82d206d7644f2fd010ec8a045e0f6abaf8]. > Upgrade Maven Reporting API to 3.1.1/Maven Reporting Impl to 3.2.0 > -- > > Key: SUREFIRE-2129 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2129 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Surefire Report Plugin >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.0.0-M8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] ppalaga opened a new issue, #758: 1.0.0-m1 slower than 0.8.2
ppalaga opened a new issue, #758: URL: https://github.com/apache/maven-mvnd/issues/758 When building Camel Quarkus with these changes https://github.com/apache/camel-quarkus/pull/4355 in place using ``` mvnd clean install -Dquickly ``` 1.0.0-m1 is slower than 0.8.2 by more than 10 seconds. At the first sight the initial scanning of Maven modules takes much longer. It is ~9 seconds with 0.8.2, but ~19 sec with 1.0.0-m1. Is this expected, @gnodet ? -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga commented on issue #758: 1.0.0-m1 slower than 0.8.2
ppalaga commented on issue #758: URL: https://github.com/apache/maven-mvnd/issues/758#issuecomment-1362053109 Scanning for projects... takes ~10 seconds even when I am in a directory where there is just a single project. -- 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
[GitHub] [maven-mvnd] gnodet commented on issue #758: 1.0.0-m1 slower than 0.8.2
gnodet commented on issue #758: URL: https://github.com/apache/maven-mvnd/issues/758#issuecomment-1362054400 > Scanning for projects... takes ~10 seconds even when I am in a directory where there is just a single project. That's https://issues.apache.org/jira/browse/MNG-7646 -- 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] (MNG-7647) The initial parsing of projects can be very slow
Guillaume Nodet created MNG-7647:
Summary: The initial parsing of projects can be very slow
Key: MNG-7647
URL: https://issues.apache.org/jira/browse/MNG-7647
Project: Maven
Issue Type: Task
Affects Versions: 4.0.0-alpha-3
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
It can take up to 19 seconds on big projects such as {{camel-quarkus}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] gnodet commented on issue #758: 1.0.0-m1 slower than 0.8.2
gnodet commented on issue #758: URL: https://github.com/apache/maven-mvnd/issues/758#issuecomment-1362056650 > When building Camel Quarkus with these changes [apache/camel-quarkus#4355](https://github.com/apache/camel-quarkus/pull/4355) in place using > > ``` > mvnd clean install -Dquickly > ``` > > 1.0.0-m1 is slower than 0.8.2 by more than 10 seconds. > > At the first sight the initial scanning of Maven modules takes much longer. It is ~9 seconds with 0.8.2, but ~19 sec with 1.0.0-m1. > > Is this expected, @gnodet ? I'm aware of the problem, and no this is not really acceptable imho. I raised [MNG-7647](https://issues.apache.org/jira/browse/MNG-7647). -- 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-7647) The initial parsing of projects can be very slow
[
https://issues.apache.org/jira/browse/MNG-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7647:
-
Description:
It can take up to 19 seconds on big projects such as {{camel-quarkus}}.
See https://github.com/apache/maven-mvnd/issues/758
was:It can take up to 19 seconds on big projects such as {{camel-quarkus}}.
> The initial parsing of projects can be very slow
>
>
> Key: MNG-7647
> URL: https://issues.apache.org/jira/browse/MNG-7647
> Project: Maven
> Issue Type: Task
>Affects Versions: 4.0.0-alpha-3
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> It can take up to 19 seconds on big projects such as {{camel-quarkus}}.
> See https://github.com/apache/maven-mvnd/issues/758
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7646) Do not parse all projects in the reactor when building a subtree
[ https://issues.apache.org/jira/browse/MNG-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650841#comment-17650841 ] Guillaume Nodet edited comment on MNG-7646 at 12/21/22 8:29 PM: We'll see :-) My point is that I want to focus on MNG-7629 first, and then see what can be done for this one. My main problem with the current state is the processing time when you want to build a single module in a big reactor. If MNG-7629 is solved, I don't have any other technical issues with parsing the whole reactor, so I would focus this issue on the processing time. was (Author: gnt): We'll see :-) My point is that I want to focus on MNG-7629 first, and then see what can be done for this one. My main problem with the current state is the processing time when you want to build a single module in a big reactor. If MNG-7629 is solved, I don't have any other technical issues with parsing the whole reactor. > Do not parse all projects in the reactor when building a subtree > > > Key: MNG-7646 > URL: https://issues.apache.org/jira/browse/MNG-7646 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-513) Error cross-compiling (JDK 18+ to release 17-) source with lint warnings
[
https://issues.apache.org/jira/browse/MCOMPILER-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650988#comment-17650988
]
Piotr Zygielo commented on MCOMPILER-513:
-
May I ask to have it assigned to release (probably
[https://issues.apache.org/jira/projects/MCOMPILER/versions/12351444)] and
closed, please?
> Error cross-compiling (JDK 18+ to release 17-) source with lint warnings
>
>
> Key: MCOMPILER-513
> URL: https://issues.apache.org/jira/browse/MCOMPILER-513
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.1
>Reporter: Piotr Zygielo
>Priority: Major
>
> {code:java}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.865 s
> [INFO] Finished at: 2022-11-30T16:32:53Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile
> (default-compile) on project mcp-OOS-bad-class: Fatal error compiling: bad
> class file: /BCDEFGH/java.base/java/io/ObjectOutputStream.sig
> Error: unable to access file: java.nio.file.ClosedFileSystemException
> {code}
> This sounds a bit like MCOMPILER-450 (for the
> {{{}ClosedFileSystemException{}}}), but there is no reproducer there so it's
> hard to tell. The comment suggests to me that it's not related, b/c the bug
> described here needs no modules.
> Reproducer for the case: [https://github.com/pzrep/mcp-OOS-bad-class]
> The key change, that _fixes_ this is
> [https://github.com/codehaus-plexus/plexus-compiler/pull/204].
> PC in MCOMPILER was updated in
> - [https://github.com/apache/maven-compiler-plugin/pull/122]
> - [https://github.com/apache/maven-compiler-plugin/pull/139]
> but with no JIRA reference. PR 122 can be selected as _fixed in_ then.
> Yes, it's fixed already, but I'm reporting this for inclusion in RN.
> Workaround until new MCOMPILER release: override plexus-compiler dependencies
> to at least 2.12.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #932: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 4.0.x branch
michael-o commented on PR #932: URL: https://github.com/apache/maven/pull/932#issuecomment-1362065831 @sultan Running tests now. I have applied small improvements to Javadoc. Kindly replicate to other PRs 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] [Commented] (MNG-7644) Fix version comparison ( .X1 < -X2 for any string qualifier X)
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650991#comment-17650991 ] ASF GitHub Bot commented on MNG-7644: - michael-o commented on PR #932: URL: https://github.com/apache/maven/pull/932#issuecomment-1362065831 @sultan Running tests now. I have applied small improvements to Javadoc. Kindly replicate to other PRs as well. > Fix version comparison ( .X1 < -X2 for any string qualifier X) > -- > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] mthmulders commented on issue #758: 1.0.0-m1 slower than 0.8.2
mthmulders commented on issue #758: URL: https://github.com/apache/maven-mvnd/issues/758#issuecomment-1362072139 > even when I am in a directory where there is just a single project. Do you mean a directory that is part of a multi-module project, but has no child modules? Or do you mean a directory that has a single project, i.e. not part of multi-module project? -- 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-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7644: Summary: Fix version comparison where .X1 < -X2 for any string qualifier X (was: Fix version comparison ( .X1 < -X2 for any string qualifier X)) > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] sultan commented on pull request #932: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 4.0.x branch
sultan commented on PR #932: URL: https://github.com/apache/maven/pull/932#issuecomment-1362108274 > @sultan Running tests now. I have applied small improvements to Javadoc. Kindly replicate to other PRs as well. neat! -- 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-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651005#comment-17651005 ] ASF GitHub Bot commented on MNG-7644: - sultan commented on PR #932: URL: https://github.com/apache/maven/pull/932#issuecomment-1362108274 > @sultan Running tests now. I have applied small improvements to Javadoc. Kindly replicate to other PRs as well. neat! > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-invoker-plugin] olamy merged pull request #161: build with jdk19
olamy merged PR #161: URL: https://github.com/apache/maven-invoker-plugin/pull/161 -- 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] (MCOMPILER-513) Error cross-compiling (JDK 18+ to release 17-) source with lint warnings
[
https://issues.apache.org/jira/browse/MCOMPILER-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MCOMPILER-513.
-
Fix Version/s: 3.11.0
Resolution: Fixed
> Error cross-compiling (JDK 18+ to release 17-) source with lint warnings
>
>
> Key: MCOMPILER-513
> URL: https://issues.apache.org/jira/browse/MCOMPILER-513
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.1
>Reporter: Piotr Zygielo
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.11.0
>
>
> {code:java}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.865 s
> [INFO] Finished at: 2022-11-30T16:32:53Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile
> (default-compile) on project mcp-OOS-bad-class: Fatal error compiling: bad
> class file: /BCDEFGH/java.base/java/io/ObjectOutputStream.sig
> Error: unable to access file: java.nio.file.ClosedFileSystemException
> {code}
> This sounds a bit like MCOMPILER-450 (for the
> {{{}ClosedFileSystemException{}}}), but there is no reproducer there so it's
> hard to tell. The comment suggests to me that it's not related, b/c the bug
> described here needs no modules.
> Reproducer for the case: [https://github.com/pzrep/mcp-OOS-bad-class]
> The key change, that _fixes_ this is
> [https://github.com/codehaus-plexus/plexus-compiler/pull/204].
> PC in MCOMPILER was updated in
> - [https://github.com/apache/maven-compiler-plugin/pull/122]
> - [https://github.com/apache/maven-compiler-plugin/pull/139]
> but with no JIRA reference. PR 122 can be selected as _fixed in_ then.
> Yes, it's fixed already, but I'm reporting this for inclusion in RN.
> Workaround until new MCOMPILER release: override plexus-compiler dependencies
> to at least 2.12.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MCOMPILER-513) Error cross-compiling (JDK 18+ to release 17-) source with lint warnings
[
https://issues.apache.org/jira/browse/MCOMPILER-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MCOMPILER-513:
-
Assignee: Slawomir Jaranowski
> Error cross-compiling (JDK 18+ to release 17-) source with lint warnings
>
>
> Key: MCOMPILER-513
> URL: https://issues.apache.org/jira/browse/MCOMPILER-513
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.1
>Reporter: Piotr Zygielo
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> {code:java}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.865 s
> [INFO] Finished at: 2022-11-30T16:32:53Z
> [INFO]
>
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile
> (default-compile) on project mcp-OOS-bad-class: Fatal error compiling: bad
> class file: /BCDEFGH/java.base/java/io/ObjectOutputStream.sig
> Error: unable to access file: java.nio.file.ClosedFileSystemException
> {code}
> This sounds a bit like MCOMPILER-450 (for the
> {{{}ClosedFileSystemException{}}}), but there is no reproducer there so it's
> hard to tell. The comment suggests to me that it's not related, b/c the bug
> described here needs no modules.
> Reproducer for the case: [https://github.com/pzrep/mcp-OOS-bad-class]
> The key change, that _fixes_ this is
> [https://github.com/codehaus-plexus/plexus-compiler/pull/204].
> PC in MCOMPILER was updated in
> - [https://github.com/apache/maven-compiler-plugin/pull/122]
> - [https://github.com/apache/maven-compiler-plugin/pull/139]
> but with no JIRA reference. PR 122 can be selected as _fixed in_ then.
> Yes, it's fixed already, but I'm reporting this for inclusion in RN.
> Workaround until new MCOMPILER release: override plexus-compiler dependencies
> to at least 2.12.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-wrapper] bmarwell merged pull request #73: [MWRAPPER-77] update to plexus archiver 4.6.0
bmarwell merged PR #73: URL: https://github.com/apache/maven-wrapper/pull/73 -- 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] (MWRAPPER-77) wrapper:wrapper does not update scripts
[
https://issues.apache.org/jira/browse/MWRAPPER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651008#comment-17651008
]
ASF GitHub Bot commented on MWRAPPER-77:
bmarwell merged PR #73:
URL: https://github.com/apache/maven-wrapper/pull/73
> wrapper:wrapper does not update scripts
> ---
>
> Key: MWRAPPER-77
> URL: https://issues.apache.org/jira/browse/MWRAPPER-77
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.1.1
>Reporter: Tamas Cservenak
>Priority: Major
>
> On my ancient project seems that scripts (mvnw and mvnw.cmd) were not updated
> after I ran {{wrapper:wrapper}} while the rest was okay.
> To test my assumption, moved them to mvnw.old and mvnw.cmd.old and re-run
> {{{}wrapper:wrapper{}}}. This time the scripts were written out just fine.
> But, they were totally different. This also means that scrpts, once written
> out, will never we updated?
> End result I had:
> {noformat}
> -rwxr-xr-x. 1 cstamas cstamas 9781 máj 8 09.15 mvnw
> -rw-r--r--. 1 cstamas cstamas 6889 máj 8 09.15 mvnw.cmd
> -rw-r--r--. 1 cstamas cstamas 6607 szept 1 15.55 mvnw.cmd.old
> -rwxr-xr-x. 1 cstamas cstamas 10069 szept 1 15.55 mvnw.old {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MWRAPPER-77) wrapper:wrapper does not update scripts
[
https://issues.apache.org/jira/browse/MWRAPPER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MWRAPPER-77.
--
Assignee: Benjamin Marwell
Resolution: Fixed
Updated plexus-archiver
> wrapper:wrapper does not update scripts
> ---
>
> Key: MWRAPPER-77
> URL: https://issues.apache.org/jira/browse/MWRAPPER-77
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.1.1
>Reporter: Tamas Cservenak
>Assignee: Benjamin Marwell
>Priority: Major
>
> On my ancient project seems that scripts (mvnw and mvnw.cmd) were not updated
> after I ran {{wrapper:wrapper}} while the rest was okay.
> To test my assumption, moved them to mvnw.old and mvnw.cmd.old and re-run
> {{{}wrapper:wrapper{}}}. This time the scripts were written out just fine.
> But, they were totally different. This also means that scrpts, once written
> out, will never we updated?
> End result I had:
> {noformat}
> -rwxr-xr-x. 1 cstamas cstamas 9781 máj 8 09.15 mvnw
> -rw-r--r--. 1 cstamas cstamas 6889 máj 8 09.15 mvnw.cmd
> -rw-r--r--. 1 cstamas cstamas 6607 szept 1 15.55 mvnw.cmd.old
> -rwxr-xr-x. 1 cstamas cstamas 10069 szept 1 15.55 mvnw.old {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-77) wrapper:wrapper does not update scripts
[
https://issues.apache.org/jira/browse/MWRAPPER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MWRAPPER-77:
-
Fix Version/s: 3.2.0
> wrapper:wrapper does not update scripts
> ---
>
> Key: MWRAPPER-77
> URL: https://issues.apache.org/jira/browse/MWRAPPER-77
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.1.1
>Reporter: Tamas Cservenak
>Assignee: Benjamin Marwell
>Priority: Major
> Fix For: 3.2.0
>
>
> On my ancient project seems that scripts (mvnw and mvnw.cmd) were not updated
> after I ran {{wrapper:wrapper}} while the rest was okay.
> To test my assumption, moved them to mvnw.old and mvnw.cmd.old and re-run
> {{{}wrapper:wrapper{}}}. This time the scripts were written out just fine.
> But, they were totally different. This also means that scrpts, once written
> out, will never we updated?
> End result I had:
> {noformat}
> -rwxr-xr-x. 1 cstamas cstamas 9781 máj 8 09.15 mvnw
> -rw-r--r--. 1 cstamas cstamas 6889 máj 8 09.15 mvnw.cmd
> -rw-r--r--. 1 cstamas cstamas 6607 szept 1 15.55 mvnw.cmd.old
> -rwxr-xr-x. 1 cstamas cstamas 10069 szept 1 15.55 mvnw.old {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] asfgit merged pull request #932: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 4.0.x branch
asfgit merged PR #932: URL: https://github.com/apache/maven/pull/932 -- 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-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651014#comment-17651014 ] ASF GitHub Bot commented on MNG-7644: - asfgit merged PR #932: URL: https://github.com/apache/maven/pull/932 > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
michael-o commented on PR #930: URL: https://github.com/apache/maven/pull/930#issuecomment-1362187894 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
[GitHub] [maven] michael-o closed pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch
michael-o closed pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch URL: https://github.com/apache/maven/pull/930 -- 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-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651018#comment-17651018 ] ASF GitHub Bot commented on MNG-7644: - michael-o commented on PR #931: URL: https://github.com/apache/maven/pull/931#issuecomment-1362187969 Merged. > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7 > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7644. --- Fix Version/s: 3.9.0 4.0.0 4.0.0-alpha-4 3.8.7 (was: 4.0.x-candidate) (was: 3.8.x-candidate) (was: 3.9.0-candidate) Resolution: Fixed Fixed with [35c81bedde7290710208a8912170638bac76ee6f|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=35c81bedde7290710208a8912170638bac76ee6f], with [6de6877c2fe772c6d0a19cf518a3fd806b8a0afb|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=6de6877c2fe772c6d0a19cf518a3fd806b8a0afb] for maven-3.9.x branch, with [da4246ad2677f3a91353b6f3024832e4a5aff7b4|https://gitbox.apache.org/repos/asf?p=maven.git&a=commit&h=da4246ad2677f3a91353b6f3024832e4a5aff7b4] for maven-3.8.x branch. > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7 > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651019#comment-17651019 ] ASF GitHub Bot commented on MNG-7644: - michael-o closed pull request #931: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.9.x branch URL: https://github.com/apache/maven/pull/931 > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7 > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o closed pull request #931: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.9.x branch
michael-o closed pull request #931: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.9.x branch URL: https://github.com/apache/maven/pull/931 -- 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-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651016#comment-17651016 ] ASF GitHub Bot commented on MNG-7644: - michael-o commented on PR #930: URL: https://github.com/apache/maven/pull/930#issuecomment-1362187894 Merged. > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7 > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7644) Fix version comparison where .X1 < -X2 for any string qualifier X
[ https://issues.apache.org/jira/browse/MNG-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651017#comment-17651017 ] ASF GitHub Bot commented on MNG-7644: - michael-o closed pull request #930: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.8.x branch URL: https://github.com/apache/maven/pull/930 > Fix version comparison where .X1 < -X2 for any string qualifier X > - > > Key: MNG-7644 > URL: https://issues.apache.org/jira/browse/MNG-7644 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.6, 4.0.0-alpha-3 >Reporter: Gwénaël Ruelland >Assignee: Michael Osipov >Priority: Major > Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7 > > > The current version parser does not treat .RC and -RC correctly: > actual : 1.0.0.RC1 > 1.0.0-RC2 > expected : 1.0.0.RC1 < 1.0.0-RC2 > because RC1 < RC2 > how to fix : place a list item before qualifier > the intention is to have this same result with all qualifier x: > actual : 1.0.0.X1 > 1.0.0-X2 > actual : 1.0.X < 1.0.0.X > expected : 1.0.0.X1 < 1.0.0-X2 > expected : 1.0.X == 1-X == 1.0.0.X -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #931: [MNG-7644] Fix version comparison ( .X1 < -X2 for any string qualifier x ), 3.9.x branch
michael-o commented on PR #931: URL: https://github.com/apache/maven/pull/931#issuecomment-1362187969 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] [Created] (MCOMPILER-517) store compilation time of modules to avoid not needed compile when using install
Olivier Lamy created MCOMPILER-517: -- Summary: store compilation time of modules to avoid not needed compile when using install Key: MCOMPILER-517 URL: https://issues.apache.org/jira/browse/MCOMPILER-517 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: Olivier Lamy Assignee: Olivier Lamy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-517) store compilation time of modules to avoid not needed compile when using install
[ https://issues.apache.org/jira/browse/MCOMPILER-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCOMPILER-517: --- Description: when using `install` m-compiler-p detects artifacts of the reactor as new and so re compile everything whereas it is not needed. the solution is to store on disk the last compilation time of a module and use this value rather than the installed artifact timestamp > store compilation time of modules to avoid not needed compile when using > install > > > Key: MCOMPILER-517 > URL: https://issues.apache.org/jira/browse/MCOMPILER-517 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > > when using `install` m-compiler-p detects artifacts of the reactor as new and > so re compile everything whereas it is not needed. > the solution is to store on disk the last compilation time of a module and > use this value rather than the installed artifact timestamp -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] ppalaga commented on issue #758: 1.0.0-m1 slower than 0.8.2
ppalaga commented on issue #758: URL: https://github.com/apache/maven-mvnd/issues/758#issuecomment-1362232284 > > even when I am in a directory where there is just a single project. > > Do you mean a directory that is part of a multi-module project, but has no child modules? Yes, exactly 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] (SUREFIRE-2118) surefire-report xml format not compliant with xsi for test failing in all of the re-runs
[
https://issues.apache.org/jira/browse/SUREFIRE-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651072#comment-17651072
]
Ruslan Sibgatullin commented on SUREFIRE-2118:
--
Just to confirm that you are not alone, we are experiencing the same issue.
> surefire-report xml format not compliant with xsi for test failing in all of
> the re-runs
>
>
> Key: SUREFIRE-2118
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2118
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin,
> xml generation
>Affects Versions: 3.0.0-M7
>Reporter: Yamini
>Priority: Major
>
> We expect the format of surefire .xml report for test failing in all rerun to
> be as mentioned in
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html#:~:text=2)-,The%20test%20fails%20in%20all%20of%20the%20re%2Druns%3A,-failure%20and%20error]
>
> But, I can see the following format for my run
> rerunFailingTestsCount = 2
> {code:java}
>
> first failure stack trace
>
> rerun failure stack trace
>
>
> rerun failure stack trace
> rerun failure
>
> {code}
> we have only one in last rerunFailure. is missing
> under and first
>
> surefire-plugin
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M7
>
>
> org.apache.maven.surefire
> surefire-junit47
> 3.0.0-M7
>
>
>
>
>
> true
>
> all
> 4
> 1C
> ${tests.groups}
> 2
>
> {code}
>
> Why is it not compliant? Can the issue be fixed?
> Please let me know if you need any more information.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia] hboutemy opened a new pull request, #132: [DOXIA-617] support yaml metadata
hboutemy opened a new pull request, #132: URL: https://github.com/apache/maven-doxia/pull/132 https://issues.apache.org/jira/browse/DOXIA-617 given the way metadata header are reworked during parsing by Doxia to detect title, I did not use Flexmark Yaml extension but coded detection and removal of the `---` enclosing yaml metadata unit tests show that "it works! (TM)" -- 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] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651108#comment-17651108
]
ASF GitHub Bot commented on DOXIA-617:
--
hboutemy opened a new pull request, #132:
URL: https://github.com/apache/maven-doxia/pull/132
https://issues.apache.org/jira/browse/DOXIA-617
given the way metadata header are reworked during parsing by Doxia to detect
title, I did not use Flexmark Yaml extension but coded detection and removal of
the `---` enclosing yaml metadata
unit tests show that "it works! (TM)"
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-617) doxia-module-markdown: Add support for --- header section marks
[
https://issues.apache.org/jira/browse/DOXIA-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651109#comment-17651109
]
Herve Boutemy commented on DOXIA-617:
-
now that I understand many aspects, I was able to code the feature
[https://github.com/apache/maven-doxia/pull/132]
as you can see, implementation is not as we expected: given the way metadata
header are reworked during parsing by Doxia to detect title, I did not use
Flexmark Yaml extension but coded detection and removal of the {{---}}
enclosing yaml metadata
unit tests show that "it works! (TM)"
> doxia-module-markdown: Add support for --- header section marks
> ---
>
> Key: DOXIA-617
> URL: https://issues.apache.org/jira/browse/DOXIA-617
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> It is "generally" accepted that document header metadata in Markdown (like
> _title_, _author_, etc.) must be specified inside a header section, delimited
> with 3 hypens:
> {noformat}
> ---
> title: My Doc Title
> author: Myself
> keywords: great,doc
> ---
> # Introduction
> ...
> {noformat}
> See:
> * https://bookdown.org/yihui/rmarkdown/html-document.html
> * https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
> * https://github.com/vsch/flexmark-java/wiki/Extensions#yaml-front-matter
> Currently, the only supported syntax for document header metadata is the very
> same as above, but *without* the 3 hypens marking the header section:
> {noformat}
> title: My Doc Title
> author: Myself
> keywords: great,doc
> # Introduction
> ...
> {noformat}
> h1. Specification
> Enable the YAML Front Matter Extension of Flexmark so that such header is
> processed automatically (nothing to code here!)
> Keep the default behavior (we want backward compatibility) with the parsing
> of metadatas (which won't be affected by the YAML Front Matter parsing).
> h1. Doc
> Update the documentation on how to use Markdown in Doxia. This feature
> (document metadata) is currently not documented.
> We should have a small guide on how to use Markdown in Doxia, and its
> specific features (metadatas, macros, etc.)
> h1. Test
> Add corresponding unit tests and integration tests (for both old and new
> syntaxes)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
