[jira] [Created] (MRESOLVER-578) Incorrect qualifier handling in `GenericVersionScheme`
David M. Lloyd created MRESOLVER-578: Summary: Incorrect qualifier handling in `GenericVersionScheme` Key: MRESOLVER-578 URL: https://issues.apache.org/jira/browse/MRESOLVER-578 Project: Maven Resolver Issue Type: Bug Affects Versions: 2.0.0 Reporter: David M. Lloyd Starting with version 2.0.0, the resolver no longer considers the qualifier `ga` to be equal to `0` in some circumstances. In 1.9.6, we have this output: ``` $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme org.apache.maven.resolver:maven-resolver-util:1.9.6 0 ga Display parameters as parsed by Maven Resolver (in canonical form and as a list of tokens) and comparison result: 1. 0 -> 0; tokens: [0] 0 == ga 2. ga -> ga; tokens: [0] ``` Whereas in 2.0.0 we have this: ``` $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme org.apache.maven.resolver:maven-resolver-util:2.0.0 0 ga Display parameters as parsed by Maven Resolver 'generic' scheme (in canonical form and as a list of tokens) and comparison result: 1. 0 -> 0; tokens: [0] 0 > ga 2. ga -> ga; tokens: [0] ``` While this is a major version change, and incompatibilities are to be expected, I think this should be evaluated as a possible bug. In trailing context, a zero segment such as `ga` or `0` is considered equal to any other zero segment. When a series of tokens is given, such as `0.0.ga`, it's not entirely clear what is leading and what is trailing context. I think it is reasonable to expect that `0.0.ga` == `0` == `ga` == the empty string, and thus "trailing context" should in this case be defined to include any number of trailing zero segments, even if there are no nonzero leading segments. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806925#comment-17806925
]
David M. Lloyd commented on MRESOLVER-336:
--
There are many thousand artifacts already in the wild using qualifiers, both
standard and custom, so I think that ship has sailed. But in any event, the
version syntax must be well-defined for all allowed cases, otherwise it's not
really a syntax. The behavior should be completely predictable.
Many of these bug reports came from me trying to determine or establish the
"true" syntactic rules of Maven versions. The code disagrees with itself every
place it is implemented, and the developers also seem to disagree with one
another on what these rules should be. But based on feedback from developers on
this and other issues, I think the most generally-accepted rules when
considering spec intent, existing usage, and existing code are as follows:
* Versions should be compared by segment, from left to right, where each
segment is defined and ordered as follows (from earliest to latest):
** The qualifier "alpha" == "a" (but only when "a" is immediately followed by
a number)
** The qualifier "beta" == "b" (but only when "b" is immediately followed by a
number)
** The qualifier "milestone" = "m" (but only when "m" is immediately followed
by a number)
** The qualifier "rc" == "cr"
** The qualifier "snapshot"
** The empty string == the number zero == "ga" == "final" == "release" (I call
these "zero segments" down below)
** The qualifier "sp"
** Any "custom" qualifier (i.e. non-empty letter sequence) sorted
lexicographically per {{ROOT}} locale, ascending
** Any positive integer sorted numerically ascending
* Segments can be explicitly separated by a single {{.}} (dot) or {{-}}
(hyphen) (one proposal also included {{_}} (underscore) as a separator)
* All qualifiers (not just custom qualifiers) are interpreted as being
case-insensitive in terms of the {{ROOT}} locale (that is, "FINAL" is equal to
"final", not "fınal")
* A zero-width segment separator also exists between any two segments when one
of the two segments is a number of any kind (including 0) and the other is a
alphabetical qualifier of any kind (including special qualifiers)
* Finally, any version can be considered to have an infinite number of
invisible *trailing* "zero" segments, for the purposes of comparison (in other
words, "1" == "1.0.0.0.0.0.0.0.0")
According to the above rules, I think that the example version I gave above
"0.0.0.ga.ga.foo" should *not* be equal to "foo" exactly as "0.0.1" should not
be equal to "1". It *should* be equal to "0.0.0.0.0.foo". The issue itself is
due to the {{ga}} qualifier being equal to zero *sometimes* but not other
times. This inconsistency is the problem and should be fixed as described above.
I don't think it is realistic to get all or even most Java devs to agree on one
version {*}scheme{*}. However I do think it is not only realistic but
*critical* that we all agree on one version {*}syntax{*}. And, I think the
above is it, more or less, since it seems to eliminate most (maybe all) of the
problem cases that I could find in existing artifacts.
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doe
[jira] [Commented] (SUREFIRE-2210) Additional class path ordering broken since 3.2.0
[
https://issues.apache.org/jira/browse/SUREFIRE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788080#comment-17788080
]
David M. Lloyd commented on SUREFIRE-2210:
--
Is there any chance for a release containing this fix soon-ish? Thanks, and
thanks also for merging the fix promptly!
> Additional class path ordering broken since 3.2.0
> -
>
> Key: SUREFIRE-2210
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.2
>Reporter: David M. Lloyd
>Assignee: Konrad Windszus
>Priority: Critical
> Fix For: next-release
>
>
> Since commit
> [47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
> ([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179),
> the ordering of the {{additionalClasspathElements}} list configuration
> property is no longer preserved. This breaks testing of multi-release JARs,
> where the directories for newer JDKs *must* be strictly ordered *before* the
> directories for older JDKs.
> The problem is likely due to changing the additional class paths collection
> from a `List` to a `Set`, which does not preserve ordering.
> One simple fix could be to change the line {{Set
> additionalClasspathElements = new HashSet<>();}} to construct a
> {{LinkedHashSet}} instead.
> /cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2210) Additional class path ordering broken since 3.2.0
[
https://issues.apache.org/jira/browse/SUREFIRE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784968#comment-17784968
]
David M. Lloyd commented on SUREFIRE-2210:
--
[~kwin] not easily, unfortunately. At least not this week. I did empirically
verify that the fix does fix our MR JAR build tests, but crafting a test case
will require some thought (especially as I am unfamiliar with the test suite as
it is). Hopefully some existing test can be used as a basis.
> Additional class path ordering broken since 3.2.0
> -
>
> Key: SUREFIRE-2210
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.2.2
>Reporter: David M. Lloyd
>Priority: Critical
>
> Since commit
> [47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
> ([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179),
> the ordering of the {{additionalClasspathElements}} list configuration
> property is no longer preserved. This breaks testing of multi-release JARs,
> where the directories for newer JDKs *must* be strictly ordered *before* the
> directories for older JDKs.
> The problem is likely due to changing the additional class paths collection
> from a `List` to a `Set`, which does not preserve ordering.
> One simple fix could be to change the line {{Set
> additionalClasspathElements = new HashSet<>();}} to construct a
> {{LinkedHashSet}} instead.
> /cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2210) Additional class path ordering broken since 3.2.0
David M. Lloyd created SUREFIRE-2210:
Summary: Additional class path ordering broken since 3.2.0
Key: SUREFIRE-2210
URL: https://issues.apache.org/jira/browse/SUREFIRE-2210
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.2.2, 3.2.1
Reporter: David M. Lloyd
Since commit
[47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d|https://github.com/apache/maven-surefire/commit/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d]
([#667|https://github.com/apache/maven-surefire/pull/667], SUREFIRE-2179), the
ordering of the {{additionalClasspathElements}} list configuration property is
no longer preserved. This breaks testing of multi-release JARs, where the
directories for newer JDKs *must* be strictly ordered *before* the directories
for older JDKs.
The problem is likely due to changing the additional class paths collection
from a `List` to a `Set`, which does not preserve ordering.
One simple fix could be to change the line {{Set
additionalClasspathElements = new HashSet<>();}} to construct a
{{LinkedHashSet}} instead.
/cc [~kwin] who wrote the original patch back in June.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1618) Configure module path with additional modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784192#comment-17784192
]
David M. Lloyd commented on SUREFIRE-1618:
--
We've also hit this issue. [~marx.freedom], WDYT about opening a pull request
with the given patch at https://github.com/apache/maven-surefire ? It seems OK
to me.
> Configure module path with additional modules
> -
>
> Key: SUREFIRE-1618
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1618
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Sergey Gurev
>Priority: Major
> Attachments: additionalModules.patch
>
>
> When surefire-maven-plugin runs tests with the JPMS it constructs module path
> only from modules required by compiled module (reading its descriptor from
> file target/classes/module-info.class). Other jars will be used in class path
> even they are modular (with module-info.class).
> It seems that plugin should include all modular jars to module path or there
> should be an option to configure module path.
> For example:
>
> {code:java}
>
> net.bytebuddy
> net.bytebuddy.agent
>
> {code}
>
> Attached patch contains implementation of "additionalModules" configuration
> property.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1731) Unable to test Multi Release Jar with surefire or failsafe
[
https://issues.apache.org/jira/browse/SUREFIRE-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784190#comment-17784190
]
David M. Lloyd commented on SUREFIRE-1731:
--
Just bumping this issue. There is a workaround, which is really ugly but
*almost* does the job:
{code:xml}
java17-test
[18,)
java17.home
${basedir}/build-test-java17
org.apache.maven.plugins
maven-surefire-plugin
java17-test
test
test
${java17.home}/bin/java
${project.build.directory}/classes/META-INF/versions/17
${project.build.directory}/classes/META-INF/versions/16
${project.build.directory}/classes/META-INF/versions/15
${project.build.directory}/classes/META-INF/versions/14
${project.build.directory}/classes/META-INF/versions/13
${project.build.directory}/classes/META-INF/versions/12
${project.build.outputDirectory}
{code}
The relevant part of this snippet is where we set up the class path. We "trick"
surefire into prioritizing the highest layer by assigning it to the
`classesDirectory`. Then, we add the remaining layers, plus the *original*
project class path, as the final (lowest) layer.
This ugly trick works because the plugin just happens to support
`additionalClassPathElement`. But, it has a major drawback: when you do this,
the plugin can no longer find any `module-info.class` because it looks in the
`classesDirectory` for it! So, any thusly configured executions will never run
in module mode, making it impossible to test module mode execution and MR JAR
output at the same time.
Back when I proposed (in MCOMPILER-320) that the compiler plugin get
`additionalClassPathElements` support in order to support this use case, it was
determined that this was not desirable, and instead the `multiReleaseOutput`
switch was added to that plugin.
I propose that the solution to this issue is to add an analogous
`multiReleaseOutput` switch which tells the Surefire plugin to correctly
compose the class path and/or module path in such a way as to be multi-release
aware.
> Unable to test Multi Release Jar with surefire or failsafe
> --
>
> Key: SUREFIRE-1731
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1731
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Major
>
> I'm creating a Multi Release jar, containing base Java 1.8 and Java 11
> classes. But am not able to successful test the Java 11 part.
> In the following repo, I've got 3 tests.
> * 1 test needs to be executed using Java 1.8 that are under src/test/java.
> * 2 tests need to be executed using Java 11 that are under src/test/java11.
> If the src/test/java tests are executed using Java 11 I expect it to fail
> which is expected, because it would be picking up the classes under
> target/classes/META-INF/versions/11/ and not the Java 1.8 version under
> target/classes/. Because the tests have been written to prove the correct
> source file is used for execution so the Java 1.8 BaseClass returns a
> different string to the Java 11 BaseClass.
> [https://github.com/nhojpatrick/issue-maven-multi-release-jar-testing]
>
--
This message was sent by
[jira] [Commented] (MNG-7798) Maven model builder is incompatible with plexus-utils 4.0.0
[
https://issues.apache.org/jira/browse/MNG-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728425#comment-17728425
]
David M. Lloyd commented on MNG-7798:
-
I can confirm that this does seem to work. Thanks!
> Maven model builder is incompatible with plexus-utils 4.0.0
> ---
>
> Key: MNG-7798
> URL: https://issues.apache.org/jira/browse/MNG-7798
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-5
>Reporter: David M. Lloyd
>Assignee: Guillaume Nodet
>Priority: Major
>
> The {{maven-model-builder}} module has a binary dependency on
> `org.codehaus.plexus.util.xml.pull.XmlPullParserException` which was provided
> by `plexus-utils` 3.x but is no longer provided by 4.x. This causes
> dependabot updates for `plexus-utils` 4.0.0 to fail if they rely on the Maven
> model builder.
> See [DefaultModelReader on
> GitHub|https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelReader.java].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7798) Maven model builder is incompatible with plexus-utils 4.0.0
David M. Lloyd created MNG-7798:
---
Summary: Maven model builder is incompatible with plexus-utils
4.0.0
Key: MNG-7798
URL: https://issues.apache.org/jira/browse/MNG-7798
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 4.0.0-alpha-5
Reporter: David M. Lloyd
The {{maven-model-builder}} module has a binary dependency on
`org.codehaus.plexus.util.xml.pull.XmlPullParserException` which was provided
by `plexus-utils` 3.x but is no longer provided by 4.x. This causes dependabot
updates for `plexus-utils` 4.0.0 to fail if they rely on the Maven model
builder.
See [DefaultModelReader on
GitHub|https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/io/DefaultModelReader.java].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694645#comment-17694645
]
David M. Lloyd commented on MRESOLVER-336:
--
Another symptom of what might be the same problem:
{code}
1. 0.foo.1.2.3 -> 0.foo.1.2.3; tokens: [0, foo, 1, 2, 3]
0.foo.1.2.3 > foo.1.2.3
2. foo.1.2.3 -> foo.1.2.3; tokens: [foo, 1, 2, 3]
{code}
{code}
1. 0.foo -> 0.foo; tokens: [0, foo]
0.foo == foo
2. foo -> foo; tokens: [foo]
{code}
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
David M. Lloyd created MRESOLVER-336:
Summary: Unexpected handling of qualifiers in GenericVersionScheme
Key: MRESOLVER-336
URL: https://issues.apache.org/jira/browse/MRESOLVER-336
Project: Maven Resolver
Issue Type: Bug
Affects Versions: 1.9.5
Reporter: David M. Lloyd
Given the following:
{code}
$ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
Display parameters as parsed by Maven Resolver (in canonical form and as a list
of tokens) and comparison result:
1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
0.0.0.ga.ga.foo == foo
2. foo -> foo; tokens: [foo]
{code}
This is expected iff zero-prefixed qualifiers are considered equal to the bare
qualifier, which does seem to be the case *mostly*. However, we also have this:
{code}
$ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
Display parameters as parsed by Maven Resolver (in canonical form and as a list
of tokens) and comparison result:
1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
ga.ga.foo < foo
2. foo -> foo; tokens: [foo]
{code}
In this case we have "zero"-valued qualifiers but no leading numerical segment,
which unexpectedly changes the parsing rules. I would expect {{ga.ga.foo ==
foo}} as above. Is this a bug? Is there an explanation for this behavior? The
spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MRESOLVER-334:
-
Description:
The [specification for version
resolution|https://maven.apache.org/pom.html#version-order-specification]
indicates these facts which disagree with the implementation in
{{{}GenericVersionScheme{}}}:
* "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'), hyphens
('{{{}-{}}}') and transitions between digits and characters." - in
{{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
separator.
* In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
"{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
{{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
addition to being untrue in the actual implementation, this relation is clearly
nonsensical because it would place {{sp}} before {{{}ga{}}}, which would have a
tremendous negative impact on the existing artifact ecosystem if it were
carried out in the implementation.
* Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
{{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
"{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
In my opinion all of these things are spec errors so I'd be happy to see the
spec page be updated and this bug consequently closed as "out of date",
especially since the implementation behavior has been in the wild for some time.
was:
The [specification for version
resolution|https://maven.apache.org/pom.html#version-order-specification]
indicates these two facts which disagree with the implementation in
{{GenericVersionScheme}}:
* "The Maven coordinate is split in tokens between dots ('{{.}}'), hyphens
('{{-}}') and transitions between digits and characters." - in
{{GenericVersion}}, the underscore ('{{_}}') is also treated as a separator.
* In the examples area, it says that while "{{1-sp.1}}" {{>}} "{{1-ga.1}}", at
the same time "{{1-sp-1}}" {{<}} "{{1-ga-1}}" {{=}} "{{1-1}}" due to "trailing
'null' values at each hyphen". But in addition to being untrue in the actual
implementation, this relation is clearly nonsensical because it would place
{{sp}} before {{ga}}, which would have a tremendous negative impact on the
existing artifact ecosystem if it were carried out in the implementation.
* Also in the example area, we have "{{1.foo}}" {{=}} "{{1-foo}}" {{<}}
"{{1-1}}" {{<}} "{{1.1}}", whereas in practice it is (rightly) "{{1.foo}}"
{{=}} "{{1-foo}}" {{<}} "{{1-1}}" {{=}} "{{1.1}}".
In my opinion all of these things are spec errors so I'd be happy to see the
spec page be updated and this bug consequently closed as "out of date",
especially since the implementation behavior has been in the wild for some time.
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694616#comment-17694616
]
David M. Lloyd commented on MRESOLVER-334:
--
Additionally, there is a provision in the specification which says that "if the
prefix is the same '{{.qualifier}}' {{=}} '{{-qualifier}}' {{<}}
'{{-number}}' {{<}} '{{.number}}'". However, I was not able to produce an
example that showed the ordering "{{-number}}" {{<}} "{{.number}}".
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these two facts which disagree with the implementation in
> {{GenericVersionScheme}}:
> * "The Maven coordinate is split in tokens between dots ('{{.}}'), hyphens
> ('{{-}}') and transitions between digits and characters." - in
> {{GenericVersion}}, the underscore ('{{_}}') is also treated as a separator.
> * In the examples area, it says that while "{{1-sp.1}}" {{>}} "{{1-ga.1}}",
> at the same time "{{1-sp-1}}" {{<}} "{{1-ga-1}}" {{=}} "{{1-1}}" due to
> "trailing 'null' values at each hyphen". But in addition to being untrue in
> the actual implementation, this relation is clearly nonsensical because it
> would place {{sp}} before {{ga}}, which would have a tremendous negative
> impact on the existing artifact ecosystem if it were carried out in the
> implementation.
> * Also in the example area, we have "{{1.foo}}" {{=}} "{{1-foo}}" {{<}}
> "{{1-1}}" {{<}} "{{1.1}}", whereas in practice it is (rightly) "{{1.foo}}"
> {{=}} "{{1-foo}}" {{<}} "{{1-1}}" {{=}} "{{1.1}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
David M. Lloyd created MRESOLVER-334:
Summary: Maven Resolver's GenericVersionScheme diverges from the
spec
Key: MRESOLVER-334
URL: https://issues.apache.org/jira/browse/MRESOLVER-334
Project: Maven Resolver
Issue Type: Bug
Components: Resolver
Affects Versions: 1.9.5
Reporter: David M. Lloyd
The [specification for version
resolution|https://maven.apache.org/pom.html#version-order-specification]
indicates these two facts which disagree with the implementation in
{{GenericVersionScheme}}:
* "The Maven coordinate is split in tokens between dots ('{{.}}'), hyphens
('{{-}}') and transitions between digits and characters." - in
{{GenericVersion}}, the underscore ('{{_}}') is also treated as a separator.
* In the examples area, it says that while "{{1-sp.1}}" {{>}} "{{1-ga.1}}", at
the same time "{{1-sp-1}}" {{<}} "{{1-ga-1}}" {{=}} "{{1-1}}" due to "trailing
'null' values at each hyphen". But in addition to being untrue in the actual
implementation, this relation is clearly nonsensical because it would place
{{sp}} before {{ga}}, which would have a tremendous negative impact on the
existing artifact ecosystem if it were carried out in the implementation.
* Also in the example area, we have "{{1.foo}}" {{=}} "{{1-foo}}" {{<}}
"{{1-1}}" {{<}} "{{1.1}}", whereas in practice it is (rightly) "{{1.foo}}"
{{=}} "{{1-foo}}" {{<}} "{{1-1}}" {{=}} "{{1.1}}".
In my opinion all of these things are spec errors so I'd be happy to see the
spec page be updated and this bug consequently closed as "out of date",
especially since the implementation behavior has been in the wild for some time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694276#comment-17694276
]
David M. Lloyd commented on MNG-7701:
-
Also, closing the issue is not called for as the resolution is clearly
contested.
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694269#comment-17694269
]
David M. Lloyd commented on MNG-7701:
-
It is easy to demonstrate that this is *not* fixed and also *not* in line with
the spec, with just this one important example (yes this does break for us):
{code}
$ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
[1
{code}
versus
{code}
$ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, [1]
{code}
As you can see, our `sp` release is now ordered *after* our `final` release
despite this clear text in the "spec":
bq. Non-numeric tokens ("qualifiers") have the alphabetical order, except for
the following tokens which come first in this order: "alpha" < "beta" <
"milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
It's clear that this tokenization isn't really correct by any reasonable
measurement, and breaking large amounts of (our) existing artifacts in the wild
is definitely not OK.
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690635#comment-17690635
]
David M. Lloyd commented on MNG-7701:
-
Assuming this is intentional, I don't think it is appropriate to change this
behavior in a micro version. It's nearly impossible to accurately describe the
Maven version scheme thanks to MNG-6964 and now MNG-7644. Also, I'm thinking
about this comment:
https://github.com/apache/maven/pull/930#issuecomment-1363838716
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MNG-7700:
Description:
The canonicalization logic for versions is incorrect.
Using the method {{ComparableVersion#getCanonical}} as in {{new
ComparableVersion(input).getCanonical()}}, the following results can be
observed:
||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
|{{1}}|{{1}}|yes|{{1}}|yes|
|{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
|{{0-1}}|{{1}}|no|{{1}}|no|
|{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
|{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
|{{0.x}}|{{0.x}}|yes|{{x}}|no|
|{{0-x}}|{{x}}|no|{{x}}|no|
|{{x}}|{{x}}|yes|{{x}}|yes|
|{{0.rc}}|{{0.rc}}|yes|{{rc}}|no|
The "OK?" columns indicate whether parsing the canonical version string will
yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
from the original input, i.e. it's internally consistent.
The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
intentional or not, but it is definitely a change.
These canonicalizations seem to have gotten less consistent in the move to
3.9.0.
was:
The canonicalization logic for versions is incorrect.
Using the method {{ComparableVersion#getCanonical}} as in {{new
ComparableVersion(input).getCanonical()}}, the following results can be
observed:
||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
|{{1}}|{{1}}|yes|{{1}}|yes|
|{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
|{{0-1}}|{{1}}|no|{{1}}|no|
|{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
|{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
|{{0.x}}|{{0.x}}|yes|{{x}}|no|
|{{0-x}}|{{x}}|no|{{x}}|no|
|{{x}}|{{x}}|yes|{{x}}|yes|
The "OK?" columns indicate whether parsing the canonical version string will
yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
from the original input, i.e. it's internally consistent.
The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
intentional or not, but it is definitely a change.
These canonicalizations seem to have gotten less consistent in the move to
3.9.0.
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> |{{0.rc}}|{{0.rc}}|yes|{{rc}}|no|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690628#comment-17690628
]
David M. Lloyd commented on MNG-7700:
-
I don't think MNG-7644 covers this one; this is about canonical form. If `0-1`
is canonically `1`, then `0-1` should equal `1`, but it does not.
The test is like this:
{code:java}
ComparableVersion parsed = new ComparableVersion(str);
ComparableVersion canon = new ComparableVersion(parsed.getCanonical());
boolean ok = parsed.equals(canon) && parsed.compareTo(canon) == 0 &&
canon.compareTo(parsed) == 0;
{code}
For the versions listed with "No" under "OK?", this test does not pass.
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690617#comment-17690617
]
David M. Lloyd commented on MNG-7700:
-
This is easy to test by hand using [JBang|https://www.jbang.dev/]:
{code}
$ jbang org.apache.maven:maven-artifact:3.8.6 1.x
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.x -> 1.x; tokens: [1, x]
{code}
{code}
$ jbang org.apache.maven:maven-artifact:3.8.7 1.x
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.x -> 1-x; tokens: [1, [x]]
{code}
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690615#comment-17690615
]
David M. Lloyd commented on MNG-7701:
-
This is easy to test by hand using [JBang|https://www.jbang.dev/]:
{code}
$ jbang org.apache.maven:maven-artifact:3.8.6 1.alpha 1-alpha
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.alpha -> 1.alpha; tokens: [1, alpha]
1.alpha < 1-alpha
2. 1-alpha -> 1-alpha; tokens: [1, [alpha]]
{code}
{code}
$ jbang org.apache.maven:maven-artifact:3.8.7 1.alpha 1-alpha
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.alpha -> 1-alpha; tokens: [1, [alpha]]
1.alpha == 1-alpha
2. 1-alpha -> 1-alpha; tokens: [1, [alpha]]
{code}
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690611#comment-17690611
]
David M. Lloyd commented on MNG-7700:
-
The behavior changed between 3.8.6 and 3.8.7 (which behaves the same as 3.9.0).
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.6, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MNG-7700:
Affects Version/s: 3.8.7
(was: 3.8.6)
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7701) Incompatible version sorting changes
David M. Lloyd created MNG-7701:
---
Summary: Incompatible version sorting changes
Key: MNG-7701
URL: https://issues.apache.org/jira/browse/MNG-7701
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 3.9.0, 3.8.7
Reporter: David M. Lloyd
Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
changed. This table captures the observed relations:
||Input 1||3.8.6||3.8.7||Input 2||
|{{0.x}}|{{>}}|{{==}}|{{0-x}}|
|{{1.x}}|{{<}}|{{==}}|{{1-x}}|
|{{1.x}}|{{<}}|{{>}}|{{1_y}}|
|{{1.y}}|{{<}}|{{>}}|{{1_x}}|
|{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MNG-7700:
Affects Version/s: 3.8.6
(was: 3.8.7)
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.6, 3.9.0
>Reporter: David M. Lloyd
>Priority: Major
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7700) Improper canonicalization of versions
David M. Lloyd created MNG-7700:
---
Summary: Improper canonicalization of versions
Key: MNG-7700
URL: https://issues.apache.org/jira/browse/MNG-7700
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 3.9.0, 3.8.7
Reporter: David M. Lloyd
The canonicalization logic for versions is incorrect.
Using the method {{ComparableVersion#getCanonical}} as in {{new
ComparableVersion(input).getCanonical()}}, the following results can be
observed:
||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
|{{1}}|{{1}}|yes|{{1}}|yes|
|{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
|{{0-1}}|{{1}}|no|{{1}}|no|
|{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
|{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
|{{0.x}}|{{0.x}}|yes|{{x}}|no|
|{{0-x}}|{{x}}|no|{{x}}|no|
|{{x}}|{{x}}|yes|{{x}}|yes|
The "OK?" columns indicate whether parsing the canonical version string will
yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
from the original input, i.e. it's internally consistent.
The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
intentional or not, but it is definitely a change.
These canonicalizations seem to have gotten less consistent in the move to
3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-494) Add `useModulePath` to TestCompilerMojo
David M. Lloyd created MCOMPILER-494:
Summary: Add `useModulePath` to TestCompilerMojo
Key: MCOMPILER-494
URL: https://issues.apache.org/jira/browse/MCOMPILER-494
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: David M. Lloyd
Sometimes it is necessary to compile tests which do not include all of the
{{requires static}} dependencies of the main module or would have other errors
when compiled in module mode. The compile mojos will always use module path
mode whenever a release of 9 or later is detected and there is no way to
disable this behavior.
Add a {{useModulePath}} switch which is similar to the one found in
{{maven-surefire-plugin}} to allow test classes to be compiled in classpath
mode always.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MCOMPILER-493) Add `useModulePath` to TestCompilerMojo
David M. Lloyd created MCOMPILER-493:
Summary: Add `useModulePath` to TestCompilerMojo
Key: MCOMPILER-493
URL: https://issues.apache.org/jira/browse/MCOMPILER-493
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: David M. Lloyd
Sometimes it is necessary to compile tests which do not include all of the
{{requires static}} dependencies of the main module or would have other errors
when compiled in module mode. The compile mojos will always use module path
mode whenever a release of 9 or later is detected and there is no way to
disable this behavior.
Add a {{useModulePath}} switch which is similar to the one found in
{{maven-surefire-plugin}} to allow test classes to be compiled in classpath
mode always.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162013#comment-17162013
]
David M. Lloyd commented on MNG-6964:
-
I don't understand what you're trying to explain to me. Yes, there are version
numbers that have a valid total order. But I opened this bug because there are
also version numbers that do *not* have a valid total order. The _social_
question of whether one uses semver or not is completely irrelevant to the
problem. The version comparison is _objectively incorrect_ for the cases I've
given above. That's the beginning, middle, and end of the problem. I didn't
file a bug asking for help, I filed a bug because _there is a bug in the code_.
I hope you can appreciate the difference.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161996#comment-17161996
]
David M. Lloyd edited comment on MNG-6964 at 7/21/20, 12:23 PM:
That was just a typo. You can see that the result is as I've said up above.
Also it should be highly evident that I understand how version sorting is
intended to work. But I'll fix the typo just to be clear.
was (Author: dmlloyd):
That was just a typo. You can see that the result is as I've said up above.
But I'll fix the typo just to be clear.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161996#comment-17161996
]
David M. Lloyd edited comment on MNG-6964 at 7/21/20, 12:22 PM:
That was just a typo. You can see that the result is as I've said up above.
But I'll fix the typo just to be clear.
was (Author: dmlloyd):
That was just a typo. You can see that the result is as I've said up above.
But I'll fix the typo just to be clear.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MNG-6964:
Description:
There's a bug where version sorting is inconsistent. This manifests like this:
{code:java}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.alpha == 1-0.alpha
1-0.alpha == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1-0.alpha
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta > 1-0.alpha
2. 1-0.alpha == 1-0.alpha
{code}
Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though both
{{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
I think this is likely due to a logical bug where any dot-separated segments
following a zero or release ({{ga}} or {{final}}) is simply truncated in
certain circumstances:
{code:java}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x == 1-0.x
1-0.x == 1-0
2. 1-0 == 1
{code}
but
{code:java}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x-1 == 1-0.x-1
1-0.x-1 > 1-0-1
2. 1-0-1 == 1-1
{code}
was:
There's a bug where version sorting is inconsistent. This manifests like this:
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.alpha == 1-0.alpha
1-0.alpha == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1-0.alpha
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta > 1-0.alpha
2. 1-0.alpha == 1-0.alpha
{code}
Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though both
{{1-0.beta}} and {{1.0.alpha}} are equal to {{1}}.
I think this is likely due to a logical bug where any dot-separated segments
following a zero or release ({{ga}} or {{final}}) is simply truncated in
certain circumstances:
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x == 1-0.x
1-0.x == 1-0
2. 1-0 == 1
{code}
but
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x-1 == 1-0.x-1
1-0.x-1 > 1-0-1
2. 1-0-1 == 1-1
{code}
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ j
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161996#comment-17161996
]
David M. Lloyd commented on MNG-6964:
-
That was just a typo. You can see that the result is as I've said up above.
But I'll fix the typo just to be clear.
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Priority: Major
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1.0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6964) Maven version sorting is internally inconsistent
David M. Lloyd created MNG-6964:
---
Summary: Maven version sorting is internally inconsistent
Key: MNG-6964
URL: https://issues.apache.org/jira/browse/MNG-6964
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.6.3
Reporter: David M. Lloyd
There's a bug where version sorting is inconsistent. This manifests like this:
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.alpha == 1-0.alpha
1-0.alpha == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta == 1
2. 1 == 1
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1-0.alpha
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.beta == 1-0.beta
1-0.beta > 1-0.alpha
2. 1-0.alpha == 1-0.alpha
{code}
Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though both
{{1-0.beta}} and {{1.0.alpha}} are equal to {{1}}.
I think this is likely due to a logical bug where any dot-separated segments
following a zero or release ({{ga}} or {{final}}) is simply truncated in
certain circumstances:
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x == 1-0.x
1-0.x == 1-0
2. 1-0 == 1
{code}
but
{code}
$ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0.x-1 == 1-0.x-1
1-0.x-1 > 1-0-1
2. 1-0-1 == 1-1
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966676#comment-16966676
]
David M. Lloyd commented on MCOMPILER-320:
--
> Everything on the classpath should be managed as a dependency in the pom.
That means every intermediate build step - every stub class - every layer -
needs a separate Maven submodule and artifact. For what reason? Because of an
unreasonable ideology. I feel like those who cling to this point of view have
never done anything nontrivial with Maven. Not even considering the pointless
performance penalties of doing so, it vastly complicates otherwise far simpler
builds for absolutely no valid reason.
I'm sorry to see that you're so very blinded by this naive notion. I think to
be safe you'd better disable multiple executions of plugins like the compiler
plugin just to make sure that people don't operate under the illusion that
Maven has the capability that it actually does have (but make sure you don't
think too much about why that capability exists). If you cripple it enough,
perhaps your illusory ideology will become real.
In the meantime we'll have to continue maintaining our fork, which, with one
simple change, dramatically simplifies layered compilation, and allows us to
exercise a much more sane design principle: one module per artifact, rather
than N modules per artifact plus extra scaffolding to prevent the pointless
intermediate modules from being deployed.
> Only this way Maven can ensure complete classpath resolution (including
> transitive dependencies).
This is patently false. This has nothing to do with dependency resolution and
everything to do with layered compilation.
> To me it is still an edge case and AFAIK only Redhat needs to trick the
> compiler
This is false also. Only Red Hat *has* gone so far as to do this because most
"regular" users would see it's not possible and try a different (worse)
approach, or just give up. That in no way means this approach isn't better, or
cleaner, or more logical. Must users simply don't know how to ask for what
they need. It's not unusual within one of my many active projects for just one
user to ask for something (maybe after months or years of project maturity)
which later goes on to be a popular feature. So this logic is clearly flawed.
> I've tried to find the problem with Quarkus, but it is simply too big.
I guess you'll have to take my word then. This is a very useful feature - one
entirely consistent with the design of the Java compiler - and you're
needlessly limiting Maven's capabilities by excluding it. Do you _really_
believe that users will see this feature and run amok with it? I don't.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893862#comment-16893862
]
David M. Lloyd edited comment on MCOMPILER-320 at 7/26/19 2:37 PM:
---
Here's one example:
https://github.com/dmlloyd/quarkus/blob/e164c4e554192a0b44ec3a7dc6eb2075b58ccaee/core/runtime/pom.xml#L100-L149
In this example the stub classes are not included in the final artifact. The
user will use our plugin to generate the class.
was (Author: dmlloyd):
Here's one example:
https://github.com/dmlloyd/quarkus/blob/e164c4e554192a0b44ec3a7dc6eb2075b58ccaee/core/runtime/pom.xml#L100-L149
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893862#comment-16893862
]
David M. Lloyd commented on MCOMPILER-320:
--
Here's one example:
https://github.com/dmlloyd/quarkus/blob/e164c4e554192a0b44ec3a7dc6eb2075b58ccaee/core/runtime/pom.xml#L100-L149
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887236#comment-16887236
]
David M. Lloyd commented on MCOMPILER-320:
--
Any updates?
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882227#comment-16882227
]
David M. Lloyd commented on MCOMPILER-320:
--
Another use case I've hit is when we're generating part of a module's code in
Quarkus. What I do is I divide the module into multiple source paths, some of
which are stubs. The stubs are compiled to enable some other parts to compile,
but then the stubs are thrown away in favor of generated code. This cannot be
done without classpath control. We do *not* want to publish multiple modules
in this case.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16847095#comment-16847095
]
David M. Lloyd commented on MCOMPILER-320:
--
So... how was Kiev? :)
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825424#comment-16825424
]
David M. Lloyd commented on MCOMPILER-320:
--
Is it possible that your integration test does not cover the cases I care
about? Is it possible that there is no practical integration test that can do
so? Is it possible that the barriers you are imposing for a small, cheap,
harmless patch are unreasonably high?
I believe it is actually cheaper for me to maintain our fork of the compiler
plugin forever than to try to invent a convoluted test (of all things) that
proves I need what I say I need. That's not a healthy situation for any
project (believe me I know, I have and continue to maintain many open source
projects over these past many years). I can write a test that proves that the
change works, but it is really not possible to write a test that proves a
change is useful: that should be self-evident, and in fact does not take a
great deal of imagination in this case because it's a very straightforward
change.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825389#comment-16825389
]
David M. Lloyd commented on MCOMPILER-320:
--
Overall I'm quite baffled by the amount of resistance this patch has gotten.
It very clearly solves a problem (multiple problems in fact) for me, the
submitter. It adds flexibility and capability, costs almost nothing to
implement (myself having done this work already) or to maintain, and nobody
would be forced to use it who does not want to. It seems that the main problem
is that you do not think I should be doing the things that I think I should be
doing. Am I wrong?
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825368#comment-16825368
]
David M. Lloyd commented on MCOMPILER-320:
--
The usefulness of the ability to perform multiple compilation executions is
greatly hampered if none of the executions can "see" any of the others.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825367#comment-16825367
]
David M. Lloyd commented on MCOMPILER-320:
--
What then is the recommendation if I need to do multiple compilation stages
that are layered? For example say I want to compile some classes against one
API variation and some against another, and then include them in the same final
artifact? I can do this easily with multiple compilation executions, provided
that I can add the class paths of the lower layers in at compile time. If I
had to publish intermediate artifacts for everything, it would get extremely
complex.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824076#comment-16824076
]
David M. Lloyd commented on MCOMPILER-320:
--
I don't have the bandwidth at present to provide a test, but it would merely
have to illustrate that classes from the {{additionalClassPathElements}} are
visible to {{javac}}.
[~rfscholte], making the dependency {{optional}} means that the dependency is
still in the model, which we do not want. Adding dependencies such as the
stubbed {{jdk-misc}} would result in execution errors in _any_ circumstances,
therefore it is not "optional" (more like "forbidden"). But if I haven't
explained it sufficiently to you by now, then I imagine there's nothing more I
can say to help you understand the need for this.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16794998#comment-16794998
]
David M. Lloyd commented on MCOMPILER-320:
--
Still missing is the ability to provide a dependency that only applies to one
compiler execution and is not a part of the standard dependency set. This is
required (for example) when building Java 8 sources using the {{--release}}
switch, which must nevertheless use APIs that are not part of the base set for
Java 8 shipped with later JDKs. Adding the APIs as a regular dependency is
impossible because any other phase or plugin will fail when using stubbed
classes.
If a new dependency scope were added - one which *only* applies during
compilation and is completely invisible to all other phases, and only applies
to certain plugin executions - then the problem will disappear. However, this
seems very unlikely due to complexity, compatibility impacts, and other
potential problems.
Thus it still makes sense (to me at least) to include
{{additionalClassPathElements}} (which I will remind you is also a part of
other standard plugins, just not this one) as a useful "escape hatch" to solve
problems that cannot be easily solved any other way.
An alternative would be to add a variation which accepts GAV instead of
filesystem locations. While less flexible, this would also solve the use cases
I know about.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16536908#comment-16536908
]
David M. Lloyd commented on MCOMPILER-320:
--
How do we then include classes that must not be part of the dependency set
(e.g. boot class path supplements necessary for compiling to release 8)?
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 3.7.1
>
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341025#comment-16341025
]
David M. Lloyd commented on MCOMPILER-320:
--
Thanks, Robert.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339294#comment-16339294
]
David M. Lloyd commented on MCOMPILER-320:
--
Any further thoughts on this? My schedule is such that I will likely have to
create a fork release of maven-compiler-plugin, but it would be good to have
some assurance that I won't have to go back and redo all these projects again
if more changes are needed.
Thanks.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332977#comment-16332977
]
David M. Lloyd commented on MCOMPILER-320:
--
I see that {{maven-surefire-plugin}} has a {{additionalClasspathElements}}
element which does the same thing. I think I should rename the new
{{maven-compiler-plugin}} attribute to have the same name; I'll update the PR
accordingly.
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332430#comment-16332430
]
David M. Lloyd commented on MCOMPILER-320:
--
https://github.com/apache/maven-compiler-plugin/pull/2 should illustrate the
problem. You need Java 10 to do it "right", otherwise just change the
"release" to "9" in the java 10 part and it's close enough to show the
problems. Here's the first one:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.1-SNAPSHOT:compile
(compile-java10) on project mcompiler320: Compilation failure
[ERROR]
/home/david/src/java/maven-compiler-plugin/src/it/MCOMPILER-320_mrjar/lib/src/main/java10/asset/MyClass3.java:[29,16]
cannot find symbol
[ERROR] symbol: method exampleMethod()
[ERROR] location: class asset.MyClass
{noformat}
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332339#comment-16332339
]
David M. Lloyd commented on MCOMPILER-320:
--
Your example won't quite work:
* The supplementary classes must not be on the compile path for Java 9 or later
as they may cause split package errors when compiling with modules - or worse
yet, they may overlap a Java 9 API which is used by the Java 9 code overlay
* The Java 9 layer does not seem to include the classes from the Java 8 layer;
in your example this may work because the Java 9 layer doesn't use any code
from the Java 8 layer but in our code, we only provide Java 9 (or 10 or 11)
classes when we actually need to use a newer API or something that is specific
to that version; otherwise we inherit the earlier layer
* If you add more layers to your example, they in turn must depend on the
classes output of each prior layer in order
* The dependency infects all other executions of all other mojos - which we
definitely do not want. It's better to include it in the one place we need it
then deal with the heisenbug situation of excluding it from every other plugin
everywhere
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329558#comment-16329558
]
David M. Lloyd commented on MCOMPILER-320:
--
Thanks for the feedback. A new "compile-only" scope would definitely be good
but it would not solve either of my two present immediate use cases.
Case 1 is that if you build a project in Java 9, and use {{--release=8}} (i.e.
{{8}}) then the sun.misc and sun.reflect packages are not
included in the class path. They must be stubbed, however you absolutely do
_not_ want to have the stubs appear in _any_ context other than the exact
compilation, otherwise severe problems will occur: the JVM could even crash. A
new scope _almost_ solves this, but not quite, because you might only want to
include the stub in one execution. What if you have more than one? Which
brings us to case 2.
Case 2 is that currently the best way of building an MR JAR can be done by way
of multiple executions. But in order to do this, the overlay executions must
include, on the class path, each earlier execution's output classes.
Here's an example of both cases being done at once; this is using a version of
the plugin which contains my proposed patch:
{code:xml}
maven-compiler-plugin
3.7.1-SNAPSHOT
default-compile
none
compile-java8
compile
compile
8
${project.build.directory}
${project.compileSourceRoots}
${project.build.outputDirectory}
${project.build.directory}/sun-misc.jar
compile-java9
compile
compile
9
${project.build.directory}
${project.basedir}/src/main/java9
${project.build.directory}/classes/META-INF/versions/9
${project.build.outputDirectory}
maven-dependency-plugin
fetch-misc
generate-sources
get
copy
org.jboss:sun-misc:1.Final-SNAPSHOT
${project.build.directory}
true
{code}
This makes use of several basic defining features of Maven: the ability to have
multiple executions, the usage of maven-dependency-plugin to fetch dependencies
by way of specific goals, etc.
The only missing piece is the ability to add class path entries.
I am enormously skeptical that a practical high-level solution to MR JARs will
appear in Maven _ever_. Even if I was wrong and it would happen, I am
extremely confident that it would be inadequate for any non-trivial case, and
furthermore, as a maintainer of many frameworks, I contend that most any case
where a framework _would_ require MR JARs would be a non-trivial case. This is
due to the fact that some of the key APIs that are motivating factors in
producing MR JARs - namely sun.misc.Unsafe and sun.reflect.ReflectionFactory -
have to be specially handled in the way that I have done above. It is unlikely
that a single compiler plugin pass, no matter how enhanced, would be able to
cope with this situation, nor would it be able to cope with any other situation
where different layers of the JAR would require different compiler parameters -
a situation that seems inevitable to me. I don't think there is a better
solution to MR JAR than the one I've worked up in this example.
We could maintain our own fork of this plugin, but that would be a bit
ridiculous: nothing in this proposed change opposes what I would call a
rational interpretation of the spirit of Maven's design, or of the design of
javac.
> Allow additional class
[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation
[
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329124#comment-16329124
]
David M. Lloyd commented on MCOMPILER-320:
--
https://github.com/apache/maven-compiler-plugin/pull/1
> Allow additional class path items to be given during compilation
>
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>Priority: Major
>
> At present it is very difficult to include additional class path items during
> compilation that are not dependencies. But this is a very useful capability,
> especially when doing partial builds, MR JARs, JDK API stubbing, including
> dependency items that cannot be included in any other build phase or
> execution, etc.
> This enhancement and pull request are to request the addition of a
> {{additionalCompilePathItems}} property in CompilerMojo or
> AbstractCompilerMojo which includes additional filesystem paths in the
> compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCOMPILER-320) Allow additional class path items to be given during compilation
David M. Lloyd created MCOMPILER-320:
Summary: Allow additional class path items to be given during
compilation
Key: MCOMPILER-320
URL: https://issues.apache.org/jira/browse/MCOMPILER-320
Project: Maven Compiler Plugin
Issue Type: New Feature
Reporter: David M. Lloyd
At present it is very difficult to include additional class path items during
compilation that are not dependencies. But this is a very useful capability,
especially when doing partial builds, MR JARs, JDK API stubbing, including
dependency items that cannot be included in any other build phase or execution,
etc.
This enhancement and pull request are to request the addition of a
{{additionalCompilePathItems}} property in CompilerMojo or AbstractCompilerMojo
which includes additional filesystem paths in the compilation class path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-285) Support test-compile for JDK 9 build b148+
[
https://issues.apache.org/jira/browse/MCOMPILER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007193#comment-16007193
]
David M. Lloyd commented on MCOMPILER-285:
--
Looks like {{-Xmodule}} has gone away as of April 19 (8178012). Builds of
OpenJDK after this time fail in maven-compiler-plugin for test sources:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.0:testCompile
(default-testCompile) on project jboss-modules: Fatal error compiling: invalid
flag: -Xmodule:null -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.0:testCompile
(default-testCompile) on project jboss-modules: Fatal error compiling
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal error compiling
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:954)
at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:164)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: org.codehaus.plexus.compiler.CompilerException: invalid flag:
-Xmodule:null
at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:173)
at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:943)
... 23 more
Caused by: java.lang.IllegalArgumentException: invalid flag: -Xmodule:null
at
jdk.compiler/com.sun.tools.javac.main.Arguments.error(Arguments.java:911)
at
jdk.compiler/com.sun.tools.javac.main.Arguments.doProcessArgs(Arguments.java:409)
at
jdk.compiler/com.sun.tools.javac.main.Arguments.processArgs(Arguments.java:361)
at
jdk.compiler/com.sun.tools.javac.main.Arguments.init(Arguments.java:246)
at
jdk.compiler/com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:185)
at
jdk.compiler/com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:119)
at
jdk.compiler/com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:68)
at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
... 25 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}
> Support test-compile for JDK 9 build b148+
> --
>
> Key: MCOMPILER-285
> URL: https://issues.apache.org/jira
[jira] [Updated] (MCOMPILER-264) Allow isolation of annotation processors from one another
[
https://issues.apache.org/jira/browse/MCOMPILER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MCOMPILER-264:
-
Description:
The MCOMPILER-203 issue went part of the way to solve this problem, however it
does not help in the case where annotation processors have conflicting
dependencies. Given that this is very easy to solve on the Java end, and seems
possible to solve on the Maven end, I would very much like to see this come to
pass.
Here's some relevant info from that issue:
{quote}
An important note here would be that the processors should have their own
dependency resolution and class loading scope, so that the versions of
dependencies of the annotation processor do not have an impact on the versions
used to compile the project itself (or other annotation processors).
They should have their own and and so on.
{quote}
{quote}
All you have to do with the API is call
javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can be
instantiated from an isolated class loader according to any rules or strategy
that you like. To specify isolated options, you can simply wrap each Processor
with one that provides the specific arguments that were configured to the
delegate processor on init().
{quote}
{quote}
Without isolation this is just one step removed from having your processors on
the class path. The difference is that processors are generally more likely to
have dependencies that conflict with other processors than to have dependencies
that conflict with the class path.
{quote}
I imagine it should even be possible to hook into an external javac task by
providing it with a proxy JAR from which annotation processor proxies (which
instantiate isolated class loaders and return proxied processors from them).
But I'd also be OK with just having this feature be unsupported for forked
javac.
was:
The MCOMPILER-203 issue went part of the way to solve this problem, however it
does not help in the case where annotation processors have conflicting
dependencies. Given that this is very easy to solve on the Java end, and seems
possible to solve on the Maven end, I would very much like to see this come to
pass.
Here's some relevant info from that issue:
{blockquote}
An important note here would be that the processors should have their own
dependency resolution and class loading scope, so that the versions of
dependencies of the annotation processor do not have an impact on the versions
used to compile the project itself (or other annotation processors).
They should have their own and and so on.
{blockquote}
{blockquote}
All you have to do with the API is call
javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can be
instantiated from an isolated class loader according to any rules or strategy
that you like. To specify isolated options, you can simply wrap each Processor
with one that provides the specific arguments that were configured to the
delegate processor on init().
{blockquote}
{blockquote}
Without isolation this is just one step removed from having your processors on
the class path. The difference is that processors are generally more likely to
have dependencies that conflict with other processors than to have dependencies
that conflict with the class path.
{blockquote}
I imagine it should even be possible to hook into an external javac task by
providing it with a proxy JAR from which annotation processor proxies (which
instantiate isolated class loaders and return proxied processors from them).
But I'd also be OK with just having this feature be unsupported for forked
javac.
> Allow isolation of annotation processors from one another
> -
>
> Key: MCOMPILER-264
> URL: https://issues.apache.org/jira/browse/MCOMPILER-264
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: David M. Lloyd
>
> The MCOMPILER-203 issue went part of the way to solve this problem, however
> it does not help in the case where annotation processors have conflicting
> dependencies. Given that this is very easy to solve on the Java end, and
> seems possible to solve on the Maven end, I would very much like to see this
> come to pass.
> Here's some relevant info from that issue:
> {quote}
> An important note here would be that the processors should have their own
> dependency resolution and class loading scope, so that the versions of
> dependencies of the annotation processor do not have an impact on the
> versions used to compile the project itself (or other annotation processors).
> They should have their own and and so on.
> {quote}
> {quote}
> All you have to do with the API is call
> javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can
> be instantiated from an isolate
[jira] [Created] (MCOMPILER-264) Allow isolation of annotation processors from one another
David M. Lloyd created MCOMPILER-264:
Summary: Allow isolation of annotation processors from one another
Key: MCOMPILER-264
URL: https://issues.apache.org/jira/browse/MCOMPILER-264
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: David M. Lloyd
The MCOMPILER-203 issue went part of the way to solve this problem, however it
does not help in the case where annotation processors have conflicting
dependencies. Given that this is very easy to solve on the Java end, and seems
possible to solve on the Maven end, I would very much like to see this come to
pass.
Here's some relevant info from that issue:
{blockquote}
An important note here would be that the processors should have their own
dependency resolution and class loading scope, so that the versions of
dependencies of the annotation processor do not have an impact on the versions
used to compile the project itself (or other annotation processors).
They should have their own and and so on.
{blockquote}
{blockquote}
All you have to do with the API is call
javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can be
instantiated from an isolated class loader according to any rules or strategy
that you like. To specify isolated options, you can simply wrap each Processor
with one that provides the specific arguments that were configured to the
delegate processor on init().
{blockquote}
{blockquote}
Without isolation this is just one step removed from having your processors on
the class path. The difference is that processors are generally more likely to
have dependencies that conflict with other processors than to have dependencies
that conflict with the class path.
{blockquote}
I imagine it should even be possible to hook into an external javac task by
providing it with a proxy JAR from which annotation processor proxies (which
instantiate isolated class loaders and return proxied processors from them).
But I'd also be OK with just having this feature be unsupported for forked
javac.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094986#comment-15094986
]
David M. Lloyd commented on MCOMPILER-203:
--
I guess I'll have to figure out some kind of workaround, yeah.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091843#comment-15091843
]
David M. Lloyd commented on MCOMPILER-203:
--
Pity. This feature isn't even useful to me without isolation - we may soon
rely on having multiple, non-conflicting annotation processors in various of
our projects. Without isolation this is just one step removed from having your
processors on the class path. The difference is that processors are generally
more likely to have dependencies that conflict with other processors than to
have dependencies that conflict with the class path.
Thanks for looking at this, in any event. My own effort stalled as I did not
know how to use the internal Maven APIs to set up isolated class loaders anyway.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090068#comment-15090068
]
David M. Lloyd commented on MCOMPILER-203:
--
All you have to do with the API is call
javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can
be instantiated from an isolated class loader according to any rules or
strategy that you like. To specify isolated options, you can simply wrap each
Processor with one that provides the specific arguments that were configured to
the delegate processor on init().
I'm not aware of a use case that external javac solves which cannot be solved
with the javax.tools API, given how old that API is now.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1509#comment-1509
]
David M. Lloyd commented on MCOMPILER-203:
--
The idea is to not use javac anymore, or at most, do not support processor
specification for javac, which I believe is consistent with the current design
climate (in fact I'm not even sure that the latest version supports using javac
anymore, does it?). Instead the javax.tools API should be used, as it is not
only far more flexible but also solves a number of other unrelated bugs
relating to output parsing, error reporting, etc.
Using this API, it is trivial to specify isolated processors.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089964#comment-15089964
]
David M. Lloyd commented on MCOMPILER-203:
--
Does the proposed solution isolate the processor paths from each other?
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089965#comment-15089965
]
David M. Lloyd commented on MCOMPILER-203:
--
Also, is there a way to override or exclude transitive dependencies of the
processor path entries?
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=364910#comment-364910
]
David M. Lloyd commented on MCOMPILER-203:
--
Also if no {{}} are given, then the default argument
mechanism (inheriting from javac) should be used. If it is given though, then
a simple wrapping Processor would be used which provides the given arguments to
the delegate.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=364873#comment-364873
]
David M. Lloyd commented on MCOMPILER-203:
--
Example configuration:
{code:xml}
maven-compiler-plugin
org.blah.processing
blah-processor
1.5.3
true
{code}
If no {{}} element is given, then discovery should behave as it
does today; if a {{}} element is present but empty then no
annotation processors should be discovered.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MCOMPILER-203:
-
Affects Version/s: 3.1
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353714#comment-353714 ] David M. Lloyd commented on MCOMPILER-224: -- Thanks John! > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd >Assignee: John Casey > Fix For: 3.2 > > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353634#comment-353634 ] David M. Lloyd commented on MCOMPILER-224: -- OK cool, just ping me if you need anything more. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd >Assignee: John Casey > Fix For: 3.2 > > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353631#comment-353631 ] David M. Lloyd commented on MCOMPILER-224: -- I haven't provided any patch to fix the JDK 6 test problem, but I can, if you would like. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd >Assignee: John Casey > Fix For: 3.2 > > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-231) Make compiler output paths relative to the project or module root
[
https://jira.codehaus.org/browse/MCOMPILER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352304#comment-352304
]
David M. Lloyd commented on MCOMPILER-231:
--
Sure, for example:
{noformat}
[ERROR]
/home/david/src/java/jboss-mgmt/tool/src/main/java/org/wildfly/core/management/processor/model/value/MapAttributeValueTypeDescription.java:[31,12]
org.wildfly.core.management.processor.model.value.MapAttributeValueTypeDescription.Builder
is not abstract and does not override abstract method getName() in
org.wildfly.core.management.processor.model.value.AttributeValueTypeDescription.Builder
{noformat}
Could automatically be rewritten as:
{noformat}
[ERROR]
tool/src/main/java/org/wildfly/core/management/processor/model/value/MapAttributeValueTypeDescription.java:[31,12]
org.wildfly.core.management.processor.model.value.MapAttributeValueTypeDescription.Builder
is not abstract and does not override abstract method getName() in
org.wildfly.core.management.processor.model.value.AttributeValueTypeDescription.Builder
{noformat}
or even:
{noformat}
[ERROR]
src/main/java/org/wildfly/core/management/processor/model/value/MapAttributeValueTypeDescription.java:[31,12]
org.wildfly.core.management.processor.model.value.MapAttributeValueTypeDescription.Builder
is not abstract and does not override abstract method getName() in
org.wildfly.core.management.processor.model.value.AttributeValueTypeDescription.Builder
{noformat}
> Make compiler output paths relative to the project or module root
> -
>
> Key: MCOMPILER-231
> URL: https://jira.codehaus.org/browse/MCOMPILER-231
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: David M. Lloyd
>Priority: Minor
>
> Using the latest 3.2-SNAPSHOT as of the time of this report, all compiler
> messages which start with a file name are printing the absolute file name.
> There should be a filter step which checks a message to see if it starts with
> the project or module path, and if so, makes the path relative, to reduce
> screen real-estate consumption.
> It seems to me that the compiler plugin had this capability at some point in
> the past (though maybe I've just dreamed it)? I suppose it's even possible
> that if it did regress, that it was one of my patches that did it (though I
> don't recall seeing this kind of code anywhere).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352025#comment-352025
]
David M. Lloyd commented on MCOMPILER-203:
--
An important note here would be that the processors should have their own
dependency resolution and class loading scope, so that the versions of
dependencies of the annotation processor do not have an impact on the versions
used to compile the project itself (or other annotation processors).
They should have their own {{}} and {{}} and so on.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-231) Make compiler output paths relative to the project or module root
David M. Lloyd created MCOMPILER-231: Summary: Make compiler output paths relative to the project or module root Key: MCOMPILER-231 URL: https://jira.codehaus.org/browse/MCOMPILER-231 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: David M. Lloyd Priority: Minor Using the latest 3.2-SNAPSHOT as of the time of this report, all compiler messages which start with a file name are printing the absolute file name. There should be a filter step which checks a message to see if it starts with the project or module path, and if so, makes the path relative, to reduce screen real-estate consumption. It seems to me that the compiler plugin had this capability at some point in the past (though maybe I've just dreamed it)? I suppose it's even possible that if it did regress, that it was one of my patches that did it (though I don't recall seeing this kind of code anywhere). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350048#comment-350048 ] David M. Lloyd commented on MCOMPILER-224: -- I think it'd just have to be a string transformation, special-cased for that JDK... > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd >Assignee: John Casey > Fix For: 3.2 > > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-66) Compiler swallows messages from annotation processors
[ https://jira.codehaus.org/browse/MCOMPILER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347228#comment-347228 ] David M. Lloyd commented on MCOMPILER-66: - This issue should be closed because MCOMPILER-224 supersedes it and that issue has been fixed. > Compiler swallows messages from annotation processors > - > > Key: MCOMPILER-66 > URL: https://jira.codehaus.org/browse/MCOMPILER-66 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2, 2.1 >Reporter: Evan Cowden > Attachments: AnnotationProcessorMessagerBug.zip > > > When using the annotation processor API to print messages through the > javax.annotation.processing.Messager object, only messagesspecified by levels > javax.tools.Diagnostic.Kind.ERROR and > javax.tools.Diagnostic.Kind.MANDATORY_WARNING are displayed (and cause the > build to fail). All other messages are swallowed. > Note that while the attached JUnit test case is necessary to help expose the > problem, passing it will not imply that the bug is fixed. The only way to > confirm the fix (that I know of) is to examine console output. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346734#comment-346734 ] David M. Lloyd commented on MCOMPILER-224: -- Actually it seems to just be a basic behavior of the compiler itself. So you have to have that option to see warning (and info) output. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346733#comment-346733
]
David M. Lloyd commented on MCOMPILER-224:
--
If you add this line to the pom:
{code:xml}
org.apache.maven.plugins
maven-compiler-plugin
3.2-SNAPSHOT
true
{code}
Then it works. I think it has to do with the way plexus-compiler forwards
output... I can look into that separately.
> Maven compiler plugin does not properly consume plexus compiler output
> --
>
> Key: MCOMPILER-224
> URL: https://jira.codehaus.org/browse/MCOMPILER-224
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0, 3.1
>Reporter: David M. Lloyd
> Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip
>
>
> Maven compiler plugin does not properly read the output from the plexus
> compiler. All CompilerMessages are logged at warning or error level, even if
> they are not warnings or errors.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346730#comment-346730 ] David M. Lloyd commented on MCOMPILER-224: -- I ask because it doesn't sound like it's using the embedded javac. The interface to the external compiler doesn't support gathering other levels. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346716#comment-346716 ] David M. Lloyd commented on MCOMPILER-224: -- What version of plexus-compiler are you using? > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345094#comment-345094 ] David M. Lloyd commented on MCOMPILER-224: -- Looking for any update here. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344103#comment-344103 ] David M. Lloyd commented on MCOMPILER-224: -- FYI [~jdcasey] is currently reviewing this. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-144) Using compiler API instead of tools.jar
[ https://jira.codehaus.org/browse/MCOMPILER-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343954#comment-343954 ] David M. Lloyd commented on MCOMPILER-144: -- I think this is probably fixed by now? > Using compiler API instead of tools.jar > --- > > Key: MCOMPILER-144 > URL: https://jira.codehaus.org/browse/MCOMPILER-144 > Project: Maven Compiler Plugin > Issue Type: New Feature >Reporter: Markus KARG >Priority: Minor > > Currently (MVN 3.0) java compilation needs tools.jar provided by the Sun JDK: > [ERROR] Unable to locate the Javac Compiler in: > [ERROR] C:\Program Files\Java\jre6\..\lib\tools.jar > [ERROR] Please ensure you are using JDK 1.4 or above and > [ERROR] not a JRE (the com.sun.tools.javac.Main class is required). > [ERROR] In most cases you can change the location of your Java > [ERROR] installation by setting the JAVA_HOME environment variable. > In fact, this is bad because (a) it assumes that a full JDK is installed just > for this sole tool where a JRE would be sufficient, (b) tools.jar is not > contained in any standards documents and such possibly is not existing on > future or non-sun JDK. > Since JRE 6 (i. e. for many years) the JRE (not JDK!) comes with a > standardized (!) API for compilation: The Java Compiler API. It would make > sense to use that standardized API instead of forcing the user to have Sun > JDK installed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343953#comment-343953 ] David M. Lloyd commented on MCOMPILER-224: -- I think MCOMPILER-66 is probably out of date, as processor output isn't necessarily being swallowed right now, except maybe in error cases (however it is being logged wrong). > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David M. Lloyd updated MCOMPILER-224: - Attachment: (was: MCOMPILER-222.patch) > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David M. Lloyd updated MCOMPILER-224: - Attachment: MCOMPILER-224.patch > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
David M. Lloyd created MCOMPILER-224: Summary: Maven compiler plugin does not properly consume plexus compiler output Key: MCOMPILER-224 URL: https://jira.codehaus.org/browse/MCOMPILER-224 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.1, 3.0 Reporter: David M. Lloyd Attachments: MCOMPILER-224.patch Maven compiler plugin does not properly read the output from the plexus compiler. All CompilerMessages are logged at warning or error level, even if they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output
[ https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David M. Lloyd updated MCOMPILER-224: - Attachment: MCOMPILER-222.patch Uploaded patch. > Maven compiler plugin does not properly consume plexus compiler output > -- > > Key: MCOMPILER-224 > URL: https://jira.codehaus.org/browse/MCOMPILER-224 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: David M. Lloyd > Attachments: MCOMPILER-224.patch > > > Maven compiler plugin does not properly read the output from the plexus > compiler. All CompilerMessages are logged at warning or error level, even if > they are not warnings or errors. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326725#comment-326725
]
David M. Lloyd commented on MCOMPILER-203:
--
My other personality filed this (probably more verbose and useful) summary on a
duplicate bug just today:
{quote}
Currently, the compiler plugin searches for annotation processors on the
compile class path using the default search algorithm. This can be problematic
when having annotation processor JARs or their dependencies on the compile
classpath adversely affects compilation behavior, sometimes even making
compilation impossible.
It should be possible to alternatively explicitly give a list of artifacts to
pass in to the compiler as the annotation processor path. This would correspond
to the standard "-processorpath" option. When given in this way, these
artifacts (and their transitive dependencies) would have an isolated class
loader which could "see" classes on the compile class path but not be "seen" by
classes on the compile class path.
This list would be defined in the compiler plugin configuration section as a
list of artifacts with optional nested exclusions and that sort of thing (no
scope though, as annotation processing is only applicable to compilation). I
imagine that these artifacts would behave largely similarly to normal
dependencies (i.e. subject to sections), and any
dependencies which are already on the compile class path would be chosen from
the compile class loader rather than being duplicated in the processor class
loader.
{quote}
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-207) Support separate GAV list for annotation processors
[
https://jira.codehaus.org/browse/MCOMPILER-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd closed MCOMPILER-207.
Resolution: Duplicate
Oops, just noticed I had already opened a bug for this. Derp
> Support separate GAV list for annotation processors
> ---
>
> Key: MCOMPILER-207
> URL: https://jira.codehaus.org/browse/MCOMPILER-207
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Reporter: David M. Lloyd
>
> Currently, the compiler plugin searches for annotation processors on the
> compile class path using the default search algorithm. This can be
> problematic when having annotation processor JARs or their dependencies on
> the compile classpath adversely affects compilation behavior, sometimes even
> making compilation impossible.
> It should be possible to alternatively explicitly give a list of artifacts to
> pass in to the compiler as the annotation processor path. This would
> correspond to the standard "-processorpath" option. When given in this way,
> these artifacts (and their transitive dependencies) would have an isolated
> class loader which could "see" classes on the compile class path but not *be*
> "seen" by classes on the compile class path.
> This list would be defined in the compiler plugin configuration section as a
> list of artifacts with optional nested exclusions and that sort of thing (no
> scope though, as annotation processing is only applicable to compilation). I
> imagine that these artifacts would behave largely similarly to normal
> dependencies (i.e. subject to {{}} sections), and any
> dependencies which are already on the compile class path would be chosen from
> the compile class loader rather than being duplicated in the processor class
> loader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-207) Support separate GAV list for annotation processors
David M. Lloyd created MCOMPILER-207:
Summary: Support separate GAV list for annotation processors
Key: MCOMPILER-207
URL: https://jira.codehaus.org/browse/MCOMPILER-207
Project: Maven 2.x Compiler Plugin
Issue Type: New Feature
Reporter: David M. Lloyd
Currently, the compiler plugin searches for annotation processors on the
compile class path using the default search algorithm. This can be problematic
when having annotation processor JARs or their dependencies on the compile
classpath adversely affects compilation behavior, sometimes even making
compilation impossible.
It should be possible to alternatively explicitly give a list of artifacts to
pass in to the compiler as the annotation processor path. This would
correspond to the standard "-processorpath" option. When given in this way,
these artifacts (and their transitive dependencies) would have an isolated
class loader which could "see" classes on the compile class path but not *be*
"seen" by classes on the compile class path.
This list would be defined in the compiler plugin configuration section as a
list of artifacts with optional nested exclusions and that sort of thing (no
scope though, as annotation processing is only applicable to compilation). I
imagine that these artifacts would behave largely similarly to normal
dependencies (i.e. subject to {{}} sections), and any
dependencies which are already on the compile class path would be chosen from
the compile class loader rather than being duplicated in the processor class
loader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-204) Add a switch to disable unwanted annotation processors
David M. Lloyd created MCOMPILER-204: Summary: Add a switch to disable unwanted annotation processors Key: MCOMPILER-204 URL: https://jira.codehaus.org/browse/MCOMPILER-204 Project: Maven 2.x Compiler Plugin Issue Type: New Feature Affects Versions: 2.3.2 Environment: Java 6+ Reporter: David M. Lloyd Right now you can turn annotation processing on and off globally. However, you cannot turn on annotation processing such that only processor artifacts are considered for processing. This in particular makes it very hard to build artifacts which include an annotation processor but also *use* annotation processors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
David M. Lloyd created MCOMPILER-203:
Summary: Allow compiler-plugin to specify annotation processor
dependencies
Key: MCOMPILER-203
URL: https://jira.codehaus.org/browse/MCOMPILER-203
Project: Maven 2.x Compiler Plugin
Issue Type: New Feature
Affects Versions: 2.3.2
Environment: Java 6+
Reporter: David M. Lloyd
Right now the status quo for annotation processor artifacts requires one of two
actions:
# Use an external plugin for annotation processing
# Put the annotation processor in as a dependency with {{provided}} scope
The former is suboptimal because the external plugins are clunky and
ill-supported, and inflexible/hard to use. The latter is suboptimal because it
is often the case that you do not want to leak annotation processor classes on
to the application class path.
It should be possible to add annotation processor dependency artifacts to the
compiler plugin configuration such that they are recognized by the annotation
processing search algorithm of the compiler, but they do not actually appear on
the compilation class path. Ideally they would also be isolated from one
another (dependency graphs and all), but that's more of a "nice to have".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-144) Using compiler API instead of tools.jar
[ https://jira.codehaus.org/browse/MCOMPILER-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=309809#comment-309809 ] David M. Lloyd commented on MCOMPILER-144: -- https://github.com/sonatype/plexus-compiler/pull/6 (PLXCOMP-1) is relevant here. > Using compiler API instead of tools.jar > --- > > Key: MCOMPILER-144 > URL: https://jira.codehaus.org/browse/MCOMPILER-144 > Project: Maven 2.x Compiler Plugin > Issue Type: New Feature >Reporter: Markus KARG >Priority: Minor > > Currently (MVN 3.0) java compilation needs tools.jar provided by the Sun JDK: > [ERROR] Unable to locate the Javac Compiler in: > [ERROR] C:\Program Files\Java\jre6\..\lib\tools.jar > [ERROR] Please ensure you are using JDK 1.4 or above and > [ERROR] not a JRE (the com.sun.tools.javac.Main class is required). > [ERROR] In most cases you can change the location of your Java > [ERROR] installation by setting the JAVA_HOME environment variable. > In fact, this is bad because (a) it assumes that a full JDK is installed just > for this sole tool where a JRE would be sufficient, (b) tools.jar is not > contained in any standards documents and such possibly is not existing on > future or non-sun JDK. > Since JRE 6 (i. e. for many years) the JRE (not JDK!) comes with a > standardized (!) API for compilation: The Java Compiler API. It would make > sense to use that standardized API instead of forcing the user to have Sun > JDK installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-785) Lots of newlines being strewn about in test output
[ https://jira.codehaus.org/browse/SUREFIRE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283411#comment-283411 ] David M. Lloyd commented on SUREFIRE-785: - Thanks! > Lots of newlines being strewn about in test output > -- > > Key: SUREFIRE-785 > URL: https://jira.codehaus.org/browse/SUREFIRE-785 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.10 > Environment: Linux 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 > UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_25" > Java(TM) SE Runtime Environment (build 1.6.0_25-b06) > Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode) > Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600) > Maven home: /home/david/local/apache-maven > Java version: 1.6.0_25, vendor: Sun Microsystems Inc. > Java home: /home/david/local/jdk/sun-jdk-1.6.0_25-x86_64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.40.4-5.fc15.x86_64", arch: "amd64", family: > "unix" >Reporter: David M. Lloyd >Assignee: Kristian Rosenvold > Fix For: 2.11 > > > Since 2.10, surefire has been emitting lots of superfluous newlines. I was > looking at commit 81694ee84e5155d402ea8564196e8aaf34ec7cec as a potential > culprit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-785) Lots of newlines being strewn about in test output
Lots of newlines being strewn about in test output -- Key: SUREFIRE-785 URL: https://jira.codehaus.org/browse/SUREFIRE-785 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.10 Environment: Linux 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux java version "1.6.0_25" Java(TM) SE Runtime Environment (build 1.6.0_25-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode) Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600) Maven home: /home/david/local/apache-maven Java version: 1.6.0_25, vendor: Sun Microsystems Inc. Java home: /home/david/local/jdk/sun-jdk-1.6.0_25-x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "2.6.40.4-5.fc15.x86_64", arch: "amd64", family: "unix" Reporter: David M. Lloyd Since 2.10, surefire has been emitting lots of superfluous newlines. I was looking at commit 81694ee84e5155d402ea8564196e8aaf34ec7cec as a potential culprit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
