[jira] [Created] (MRELEASE-1143) MRELEASE should be able to recognise and update project.build.outputTimestamp in a profile
Thorsten Glaser created MRELEASE-1143:
-
Summary: MRELEASE should be able to recognise and update
project.build.outputTimestamp in a profile
Key: MRELEASE-1143
URL: https://issues.apache.org/jira/browse/MRELEASE-1143
Project: Maven Release Plugin
Issue Type: Improvement
Reporter: Thorsten Glaser
Follow-up for: MRELEASE-1029
I have pretty much the same problem as the ASF has in MPOM-255 and MPOM-265: I
build a parent POM in a project, and I want that project's output to be
reproducible, but if I set `project.build.outputTimestamp` in the parent POM
itself's ``, all users inherit it. This is suboptimal (even if not
harmful), especially as users' `mvn artifact:check-buildplan` will now succeed
with merely...
{noformat}
[WARNING] property is inherited, it should be
defined in pom.xml{noformat}
... instead of erroring out when a user does _not_ define it.
In my parent POM, I have already defined a profile `build-mvnparent` which I
enable when releasing the parent POM project itself, which defines a couple of
properties such as the copyright years which I also don't want users to inherit
by accident.
However, when I put the `project.build.outputTimestamp` property in there, not
only do I get `mvn artifact:check-buildplan` warnings about the property being
inherited when it's not (just pulled from a profile), but also does the
maven-release-plugin not update it when releasing.
I would request that this be fixed, so then the ASF and I could use the profile
method of defining this in the parent POM without all users of the
parent-POM-once-installed inheriting that value (while all other modules in the
same project that _installs_ the parent POM _do_ get it), and once it's fixed,
the `artifact:check-buildplan` be updated to recognise this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-951) Better handling of file.encoding system property
[
https://issues.apache.org/jira/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843385#comment-17843385
]
Thorsten Glaser commented on SUREFIRE-951:
--
This breaks JaCoCo. You need:
{code:java}
org.apache.maven.plugins
maven-surefire-plugin
${argLine}
-Dfile.encoding=${project.build.sourceEncoding}
{code}
> Better handling of file.encoding system property
>
>
> Key: SUREFIRE-951
> URL: https://issues.apache.org/jira/browse/SUREFIRE-951
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.13
> Environment: Any environment in which the file encoding is distinct
> from ${project.build.sourceEncoding}.
>Reporter: Stephan Schroevers
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.15
>
> Attachments: file-encoding-example.tbz
>
>
> It appears that Surefire doesn't (correctly) set
> {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} prior to running the
> tests. As a result the JVM will derive {{file.encoding}} from the
> environment's file encoding. This affects the return value of
> {{java.nio.charset.Charset#defaultCharset()}}, which reads the
> {{file.encoding}} system property exactly once, and is invoked very early on.
> Concretely this means that the unit tests are unnecessarily platform
> dependent.
> Thus I have two requests:
> # Make {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} the default.
> That is, the following configuration setting should be implied:
> {noformat}
> -Dfile.encoding=${project.build.sourceEncoding}
> {noformat}
> # Extend the method
> {{org.apache.maven.plugin.surefire.SurefireProperties#verifyLegalSystemProperties(org.apache.maven.plugin.logging.Log)}}
> such that is warns about users attempting to set the {{file.encoding}}
> property through the {{systemPropertyVariables}} configuration setting. Like
> with {{java.library.path}}, this does _not_ work.
> I have [attached|^file-encoding-example.tbz] a sample project that
> demonstrates the issue (simply run {{`mvn test`}}). Please have a look at the
> comments I added to the POM. I have tested this sample project only on Linux,
> but a colleague has confirmed that an instance of this issue can also be
> recreated on Windows.
> TIA for looking into this!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725918#comment-17725918
]
Thorsten Glaser edited comment on MRESOURCES-237 at 5/24/23 6:37 PM:
-
Yes, so far [my comment from
2022-01-07|https://issues.apache.org/jira/browse/MRESOURCES-237?focusedCommentId=17470929=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17470929]
has been ignored, and this issue is still keeping me on MRESOURCE 2.x in all
Java™ projects.
was (Author: mirabilos):
Yes, so far my comment from 2022-01-07 has been ignored, and this issue is
still keeping me on MRESOURCE 2.x in all Java™ projects.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725918#comment-17725918
]
Thorsten Glaser commented on MRESOURCES-237:
Yes, so far my comment from 2022-01-07 has been ignored, and this issue is
still keeping me on MRESOURCE 2.x in all Java™ projects.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6058) Test dependencies should override application dependencies only during testing
[
https://issues.apache.org/jira/browse/MNG-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17497807#comment-17497807
]
Thorsten Glaser commented on MNG-6058:
--
You don’t see me disagreeing there. However:
* that should probably be done in Maven 4 as it’s a backwards-incompatible
change
* independent of where it’s done, we *really* _need_ a fixed current version
of {{maven-dependency-plugin}} now, for compatibility with contemporary
versions of the JDK
* newer versions of the {{maven-dependency-plugin}} can and will be run on
current-and-older versions of Maven for a *long* time, so independent of when
and where the change is introduced, {{maven-dependency-plugin}} *must* stay
aware of Maven versions not having this change being in productive use and work
well with them
> Test dependencies should override application dependencies only during testing
> --
>
> Key: MNG-6058
> URL: https://issues.apache.org/jira/browse/MNG-6058
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6058.zip
>
>
> The following graph
> {code}
> POM
> |->a 2.0 compile
> |-->b 2.0 compile
> |->b 1.0 test
> {code}
> will be mediated to
> {code}
> POM
> |->a 2.0 compile
> |->b 1.0 test
> {code}
> The test dependency on b will make the transitive application dependency on b
> disappear. Maven should understand that the application dependency on b in
> version 2.0 is part of the application classpath and that the test
> dependency on b in version 1.0 is part of the test classpath only (overriding
> the application classpath). If someone adds a dependency on a project like
> that, the test dependency will disappear because the test scope is not
> transitive so that a "consuming" project gets a different application
> classpath than the project itself.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-6058) Test dependencies should override application dependencies only during testing
[
https://issues.apache.org/jira/browse/MNG-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495231#comment-17495231
]
Thorsten Glaser commented on MNG-6058:
--
Referenced in https://issues.apache.org/jira/browse/MDEP-791
But if so, we’re going to have a way to override a dependency multiple times,
for different scopes.
> Test dependencies should override application dependencies only during testing
> --
>
> Key: MNG-6058
> URL: https://issues.apache.org/jira/browse/MNG-6058
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Major
> Attachments: MNG-6058.zip
>
>
> The following graph
> {code}
> POM
> |->a 2.0 compile
> |-->b 2.0 compile
> |->b 1.0 test
> {code}
> will be mediated to
> {code}
> POM
> |->a 2.0 compile
> |->b 1.0 test
> {code}
> The test dependency on b will make the transitive application dependency on b
> disappear. Maven should understand that the application dependency on b in
> version 2.0 is part of the application classpath and that the test
> dependency on b in version 1.0 is part of the test classpath only (overriding
> the application classpath). If someone adds a dependency on a project like
> that, the test dependency will disappear because the test scope is not
> transitive so that a "consuming" project gets a different application
> classpath than the project itself.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494817#comment-17494817
]
Thorsten Glaser commented on MDEP-791:
--
I don’t really disagree, but my understanding of the current Maven model means
I cannot fully agree either.
You say “Saying that the top-level project depends on an artifact with test
scope”, but this is not what we say (at least not in
{{{}{}}}). Rather, we say “the artefact FOO is available
in the following scopes: test”.
I actually rely on the ability to override things from external dependencies
_quite_ a lot. Hmm, perhaps {{}} would suffice… but, hm, no. I can
mentally construct something where I would want an implicit (or explicit)
dependency available at test time but not at compile or runtime; for example,
consider you use some kind of framework that normally pulls in its own logging,
and that’s okay to test my (jar) module, but otherwise (at least at runtime) I
provide the necessary things on my own (or don’t even need to because it uses
reflection so just removing the default dependency will change the features but
still work).
Perhaps we need a way to specify scopes as either “add to” or “set to”. (A more
flexible scope specification would also make it possible, for example, to set
something to compile+test but not runtime, or the other way around. Currently
we’re limited to a set of choices that set the module-in-scope bitmask to
certain values, which is less flexible.)
Additionally, I’d argue (and I’m sure people like [~chonton] would do that even
more vegemently) that changing anything in the way Maven resolution works is
something for a 4.x and you should try to work within the 3.x model in updates
of this plugin, *especially* considering the last _working_ version of MDEP
does not work with contemporary supported JDK versions and so people _direly_
need an updated _working_ version.
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494068#comment-17494068
]
Thorsten Glaser commented on MDEP-791:
--
[~elharo] there was much discussion about this in
https://issues.apache.org/jira/browse/MDEP-753
The problem here is:
* jackson-databind *does* declare a dependency on jackson-core
* src/main/ directly uses classes from jackson-databind, but none from
jackson-core
** these classes *derive from* classes in jackson-core
* src/test/ directly uses classes from jackson-core
With direct dependencies on jackson-databind and jackson-core, MDEP says
test-only dependency jackson-core (because src/main/ does not use it). But
there’s no fix that can be used with the current model because:
* adding {{test}} to jackson-core removes it from the
transitive compile dependencies, making compile fail
* removing jackson-core from direct dependencies (rightfully) gives an MDEP
warning because src/test/ directly uses it
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[ https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491735#comment-17491735 ] Thorsten Glaser commented on MDEP-753: -- You seem to be confusing me with the developers and ignoring the proposed solution. Separating the new checks into a new configuration option also sounds like a sensible thing to do but is orthogonal to that. (I even agree with that doing it as new, not yet enabled-by-default, option is the way to go for minor releases; unfortunately, Maven plugins seem to occasionally break things even in minor releases so I was not daring voicing it, plus it doesn’t fix the actual problems with this.) > Non-test dependency reported as Non-test scoped test only dependency > > > Key: MDEP-753 > URL: https://issues.apache.org/jira/browse/MDEP-753 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 3.2.0 >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Critical > Fix For: 3.3.0 > > Attachments: chas.zip, tj.zip > > > Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the > plugin. I'm not immediately sure whether this is a regression: > [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @ > google-http-client --- > Warning: Non-test scoped test only dependencies found: > Warning: com.google.guava:guava:jar:30.1.1-android:compile > Warning: io.opencensus:opencensus-api:jar:0.28.0:compile > Changing Guava to scope test breaks the build, which is expected based on the > code. The warning seems incorrect. > https://github.com/googleapis/google-http-java-client/pull/1396 > https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491731#comment-17491731
]
Thorsten Glaser commented on MDEP-753:
--
{quote}Flagging transitive compile dependencies as "non-test scoped test-only
dependency" is incorrect, because these dependencies are *not* test-only.
{quote}
This is not correct.
{quote}They are required by the compiler to compile the code.
{quote}
This is correct. But that doesn’t mean they are not test-only: only the tests
*directly* use it.
As far as I can tell, maven-dependency-plugin here attempts to do something
that is not currently possible with Maven. OpenBSD’s change to binutils (hide
transitive dependencies in the {{ld(1)}} linker if they are not also explicitly
depended on) is something I have long wished for, but it doesn’t work with the
contemporary Java™ model of just throwing all dependencies into “the” classpath.
Rather, the compiler would need to see *only* the explicitly depended-on
modules (so that using a symbol from e.g. spring-core in {{src/main/}} when not
explicitly depended on would be a compiler failure!), and only for looking
_into_ +these+ it would even consider _their_ transitive _direct_ dependencies…
and for those, theirs, etc.
I’m all for minimising the direct dependencies, of course.
In my last comment I suggested the plugin recognise the very situation in your
example and suggest proper ignore XML. Another option would be to just skip the
warnings in that case (direct dependency only in {{src/test/}} but indirect
dependency in {{compile}} scope from a module that’s directly depended on (this
part is important)). It’d be a realistic compromise.
One of the developers said the test-only analysis only looks at bytecode. But I
believe this can be done in a kind of postprocessing step. When we have a list
of test-only direct dependencies, and we can obtain a list of both direct and
transitive dependencies in nōn-test scope, and if a test-only dependency shows
up in the latter list, the warning is skipped. (Maybe it’s not that easy. Also,
to get the scopes right, there’s more than two, might be tricky. But it’d be
worthwhile.)
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
> Fix For: 3.3.0
>
> Attachments: chas.zip, tj.zip
>
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491725#comment-17491725
]
Thorsten Glaser commented on MDEP-753:
--
Thanks [~hgschmie], this is ridiculous but I *think* I understand the bug now.
Trying to build as-is will fil with one “non-test scoped test only” (and this
is probably missing a few hyphens) warning, because…
{noformat}
$ git grep -F org.springframework.core
spring5/src/test/java/org/jdbi/v3/spring5/TestVersion.java:import
org.springframework.core.SpringVersion;{noformat}
… only the test ever imports *directly* from {{{}spring-core{}}}. However, you
*cannot* switch the dependency to {{test}} scope because it’s needed as parent
class:
{noformat}
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/tmp/jdbi/spring5/src/main/java/org/jdbi/v3/spring5/JdbiUtil.java:[65,20]
cannot access org.springframework.core.Ordered
class file for org.springframework.core.Ordered not found
[INFO] 1 error
[INFO] - {noformat}
Line 65 is:
{noformat}
$ sed -n 65p /tmp/jdbi/spring5/src/main/java/org/jdbi/v3/spring5/JdbiUtil.java
private static class Adapter extends TransactionSynchronizationAdapter {
{noformat}
So it’s probably a parent class of {{TransactionSynchronizationAdapter}} that
cannot be found.
But you cannot just remove the dependency (and rely on the implicit
dependencies from the other Spring Maven modules) either:
{noformat}
[INFO] --- maven-dependency-plugin:3.3.0-SNAPSHOT:analyze-only
(basepom.default) @ jdbi3-spring5 ---
[WARNING] Used undeclared dependencies found:
[WARNING] org.springframework:spring-core:jar:5.3.12:compile
[WARNING] Non-test scoped test only dependencies found:
[WARNING] org.springframework:spring-core:jar:5.3.12:compile {noformat}
The “used undeclared” is right here because the test *directly* uses it.
Yet, I think the behaviour of the 3.3.0-SNAPSHOT version of the
maven-dependency-plugin is correct here, you’ve just reached a corner case that
cannot be modelled properly within the bounds of the Maven model. In this case,
I believe an {{ignoredNonTestScopedDependencies}} entry to override is the
proper solution.
The thing here is that maven-dependency-plugin has two conflicting goals. One
is that only modules that are directly used are listed as dependencies;
recursive dependencies should take care of the rest. The other is that all
classes that are directly used *are* indeed listed as dependencies. But while
you can add a module in two different scopes as dependency (e.g. {{test}} and
{{{}provided{}}}) you cannot add it to {{test}} scope explicitly but rely on
implicit inclusion into {{compile}} scope.
It might be possible to extend the maven-dependency-plugin to somehow handle
this case in a more user-friendly way, but this is literally a situation that
_cannot_ be properly modelled in the project itself, so I’d think papering over
this, while reducing angry users’ outcry, will do a disservice in the long run.
Maybe the new “non-test-scoped test-only dependencies” check should be a
nōnfatal warning for a release or two? So projects continue to build, and
people can add {{ignoredNonTestScopedDependencies}} entries at their leisure.
Maybe the plugin or the analyser can recognise this situation (specifically 「a
Maven module is used (in {{compile}} scope) indirectly by other modules
depending on it by means of inheritance, and at least one of these other
modules (e.g. {{{}spring-beans{}}}) is indeed directly used by {{main}}
classes, but the module is *directly* used by {{test}} classes」, this is what I
believe to be the problem spec) and recommend adding
{{ignoredNonTestScopedDependencies}} entries (it could provide them as
copy/paste templates, even!) documenting this as a modelling problem.
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
> Fix For: 3.3.0
>
> Attachments: chas.zip, tj.zip
>
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning:
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491664#comment-17491664
]
Thorsten Glaser commented on MDEP-753:
--
This is a little tricky.
Some of the other checks also check if the code *directly* uses the Maven
module, and if not (if only subclasses that are in other modules are used),
there normally needs to be no direct dependency from your project to the module
with the parent classes that are not used.
That being said, you say “with test scope, compile fails”. Well, it does not,
for me:
{noformat}
$ mvn clean test
[INFO] Scanning for projects...
[INFO]
[INFO] < mdep753:tstp >
[INFO] Building tstp 0.1-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ tstp ---
[INFO] Deleting /home/tglase/tjc/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ tstp ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/tglase/tjc/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ tstp ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to /home/tglase/tjc/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
tstp ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/tglase/tjc/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ tstp
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to /home/tglase/tjc/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ tstp ---
[INFO] Surefire report directory: /home/tglase/tjc/target/surefire-reports
---
T E S T S
---
Running tstp.TestMDEP753
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.512 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.025 s
[INFO] Finished at: 2022-02-13T19:49:03+01:00
[INFO]
{noformat}
This is with {{chas.zip}} with only the following change:
{noformat}
--- tj/pom.xml
+++ tjc/pom.xml
@@ -45,8 +45,8 @@
com.fasterxml.jackson.core
jackson-core
${jackson.version}
-
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
> Fix For: 3.3.0
>
> Attachments: chas.zip, tj.zip
>
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-787) [regression] 3.2.0/3.3.0-SNAPSHOT need way to override false “non-test-scoped dependency” warning
[
https://issues.apache.org/jira/browse/MDEP-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491661#comment-17491661
]
Thorsten Glaser commented on MDEP-787:
--
Thanks, confirmed, both options work.
> [regression] 3.2.0/3.3.0-SNAPSHOT need way to override false “non-test-scoped
> dependency” warning
> -
>
> Key: MDEP-787
> URL: https://issues.apache.org/jira/browse/MDEP-787
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Thorsten Glaser
>Assignee: Slawomir Jaranowski
>Priority: Blocker
> Fix For: 3.3.0
>
>
> This was found due to testing whether 3.3.0-SNAPSHOT fixes the regressions of
> 3.2.0 against 3.1.2 (it doesn’t, yet).
> After finding
> [https://maven.apache.org/guides/development/guide-testing-development-plugins.html]
> I was able to test the snapshot on the
> [https://github.com/tarent/extract-tool/tree/mdep753-snapshot] branch as well.
> This problem shows up:
> {quote}{{$ mvn dependency:analyze-only@analyse-dependency-usage}}
> {{[…]}}
> {{[WARNING] Non-test scoped test only dependencies found:}}
> {{[WARNING]
> com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.13.1:compile}}
> {quote}
> This is “correct”: {{com.fasterxml.jackson.dataformat.yaml.YAMLFactory}} is
> {{{}import{}}}ed in the tests but only used via reflection in prod because
> it’s an optional (but not marked as optional so it’s included by default, but
> users can {{}} it and that’s supported and documented) dependency.
> This means it’s a false positive that cannot be expected to be handled by the
> test correctly and must be overridden in the POM.
> However, adding it as {{}} does not work ☹
> it’s probably the wrong overriding element, but
> [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html]
> does not have anything on how to override this particular warning.
> This is a *must-have* for, I hope, obvious reasons…
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491368#comment-17491368
]
Thorsten Glaser commented on MDEP-753:
--
[~chonton] hmm, but scoping it to test here will not cause the build to fail.
Can you extend this minimal example until it does? I think this is because
{{jackson-databind-2.13.1.pom}} has an explicit dependency on core… why does
that not work in your case?
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
> Fix For: 3.3.0
>
> Attachments: tj.zip
>
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[ https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491366#comment-17491366 ] Thorsten Glaser commented on MDEP-753: -- [~sbrunov] how did you create the box for the preformatted output? Mine ↑ here looks awful ☹ > Non-test dependency reported as Non-test scoped test only dependency > > > Key: MDEP-753 > URL: https://issues.apache.org/jira/browse/MDEP-753 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 3.2.0 >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Critical > Fix For: 3.3.0 > > Attachments: tj.zip > > > Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the > plugin. I'm not immediately sure whether this is a regression: > [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @ > google-http-client --- > Warning: Non-test scoped test only dependencies found: > Warning: com.google.guava:guava:jar:30.1.1-android:compile > Warning: io.opencensus:opencensus-api:jar:0.28.0:compile > Changing Guava to scope test breaks the build, which is expected based on the > code. The warning seems incorrect. > https://github.com/googleapis/google-http-java-client/pull/1396 > https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491365#comment-17491365
]
Thorsten Glaser commented on MDEP-753:
--
I’ve isolated the problem with Jackson reported by [~chonton] in an MWE:
[^tj.zip]
{quote}{{$ mvn dependency:analyze-only}}
{{[INFO] Scanning for projects...}}
{{[INFO] }}
{{[INFO] < mdep753:tstp
>}}
{{[INFO] Building tstp 0.1-SNAPSHOT}}
{{[INFO] [ jar
]-}}
{{[INFO] }}
{{[INFO] --- maven-dependency-plugin:3.3.0-SNAPSHOT:analyze-only (default-cli)
@ tstp ---}}
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING] com.fasterxml.jackson.core:jackson-core:jar:2.13.1:compile}}
{{[INFO]
}}
{{[INFO] BUILD SUCCESS}}
{{[INFO]
}}
{{[INFO] Total time: 3.260 s}}
{{[INFO] Finished at: 2022-02-12T16:16:52+01:00}}
{{[INFO]
}}
{quote}
Running just {{mvn clean test}} will work. It does indeed seem like the “is
this used outside of tests?” check does not take inheritance across Maven
modules into account.
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
> Fix For: 3.3.0
>
> Attachments: tj.zip
>
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[ https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thorsten Glaser updated MDEP-753: - Attachment: tj.zip > Non-test dependency reported as Non-test scoped test only dependency > > > Key: MDEP-753 > URL: https://issues.apache.org/jira/browse/MDEP-753 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 3.2.0 >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Critical > Fix For: 3.3.0 > > Attachments: tj.zip > > > Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the > plugin. I'm not immediately sure whether this is a regression: > [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @ > google-http-client --- > Warning: Non-test scoped test only dependencies found: > Warning: com.google.guava:guava:jar:30.1.1-android:compile > Warning: io.opencensus:opencensus-api:jar:0.28.0:compile > Changing Guava to scope test breaks the build, which is expected based on the > code. The warning seems incorrect. > https://github.com/googleapis/google-http-java-client/pull/1396 > https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MDEP-787) [regression] 3.2.0/3.3.0-SNAPSHOT need way to override false “non-test-scoped dependency” warning
[
https://issues.apache.org/jira/browse/MDEP-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491361#comment-17491361
]
Thorsten Glaser commented on MDEP-787:
--
Hmm, doesn’t work though:
[https://github.com/tarent/extract-tool/commit/83aa157c14155f0f0a318d9afcfa1cb3969b44b4]
I’d prefer a separate override instead of a “catch-all” though. Thank you for
considering to add it as well.
> [regression] 3.2.0/3.3.0-SNAPSHOT need way to override false “non-test-scoped
> dependency” warning
> -
>
> Key: MDEP-787
> URL: https://issues.apache.org/jira/browse/MDEP-787
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Thorsten Glaser
>Assignee: Slawomir Jaranowski
>Priority: Blocker
>
> This was found due to testing whether 3.3.0-SNAPSHOT fixes the regressions of
> 3.2.0 against 3.1.2 (it doesn’t, yet).
> After finding
> [https://maven.apache.org/guides/development/guide-testing-development-plugins.html]
> I was able to test the snapshot on the
> [https://github.com/tarent/extract-tool/tree/mdep753-snapshot] branch as well.
> This problem shows up:
> {quote}{{$ mvn dependency:analyze-only@analyse-dependency-usage}}
> {{[…]}}
> {{[WARNING] Non-test scoped test only dependencies found:}}
> {{[WARNING]
> com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.13.1:compile}}
> {quote}
> This is “correct”: {{com.fasterxml.jackson.dataformat.yaml.YAMLFactory}} is
> {{{}import{}}}ed in the tests but only used via reflection in prod because
> it’s an optional (but not marked as optional so it’s included by default, but
> users can {{}} it and that’s supported and documented) dependency.
> This means it’s a false positive that cannot be expected to be handled by the
> test correctly and must be overridden in the POM.
> However, adding it as {{}} does not work ☹
> it’s probably the wrong overriding element, but
> [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html]
> does not have anything on how to override this particular warning.
> This is a *must-have* for, I hope, obvious reasons…
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-787) [regression] 3.2.0/3.3.0-SNAPSHOT need way to override false “non-test-scoped dependency” warning
[
https://issues.apache.org/jira/browse/MDEP-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491359#comment-17491359
]
Thorsten Glaser commented on MDEP-787:
--
So, like this?
https://github.com/tarent/extract-tool/commit/2e83e94482e4406bb013785281456c7d46358ac1
> [regression] 3.2.0/3.3.0-SNAPSHOT need way to override false “non-test-scoped
> dependency” warning
> -
>
> Key: MDEP-787
> URL: https://issues.apache.org/jira/browse/MDEP-787
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Thorsten Glaser
>Assignee: Slawomir Jaranowski
>Priority: Blocker
>
> This was found due to testing whether 3.3.0-SNAPSHOT fixes the regressions of
> 3.2.0 against 3.1.2 (it doesn’t, yet).
> After finding
> [https://maven.apache.org/guides/development/guide-testing-development-plugins.html]
> I was able to test the snapshot on the
> [https://github.com/tarent/extract-tool/tree/mdep753-snapshot] branch as well.
> This problem shows up:
> {quote}{{$ mvn dependency:analyze-only@analyse-dependency-usage}}
> {{[…]}}
> {{[WARNING] Non-test scoped test only dependencies found:}}
> {{[WARNING]
> com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.13.1:compile}}
> {quote}
> This is “correct”: {{com.fasterxml.jackson.dataformat.yaml.YAMLFactory}} is
> {{{}import{}}}ed in the tests but only used via reflection in prod because
> it’s an optional (but not marked as optional so it’s included by default, but
> users can {{}} it and that’s supported and documented) dependency.
> This means it’s a false positive that cannot be expected to be handled by the
> test correctly and must be overridden in the POM.
> However, adding it as {{}} does not work ☹
> it’s probably the wrong overriding element, but
> [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html]
> does not have anything on how to override this particular warning.
> This is a *must-have* for, I hope, obvious reasons…
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490969#comment-17490969
]
Thorsten Glaser edited comment on MDEP-753 at 2/11/22, 5:46 PM:
After finding
[https://maven.apache.org/guides/development/guide-testing-development-plugins.html]
I was able to test the snapshot on the
[https://github.com/tarent/extract-tool/tree/mdep753-snapshot] branch as well.
The initial problem…
{quote}{{$ mvn -Dmaven.dependency.version=3.2.0
dependency:analyze-only@analyse-dependency-usage}}
{{[…]}}
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING] org.springframework:spring-jdbc:jar:4.3.30.RELEASE:compile}}
{quote}
… is gone.
A new issue (another +must-fix+ regression against 3.1.2) shows up in
https://issues.apache.org/jira/browse/MDEP-787 in that it’s not possible to
override “{{{}Non-test scoped test only dependencies{}}}” false-positives.
was (Author: mirabilos):
After finding
[https://maven.apache.org/guides/development/guide-testing-development-plugins.html]
I was able to test the snapshot on the
[https://github.com/tarent/extract-tool/tree/mdep753-snapshot] branch as well.
The initial problem…
{quote}{{$ mvn -Dmaven.dependency.version=3.2.0
dependency:analyze-only@analyse-dependency-usage}}
{{[…]}}
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING] org.springframework:spring-jdbc:jar:4.3.30.RELEASE:compile}}
{quote}
… is gone, but I have a new problem:
{quote}{{$ mvn dependency:analyze-only@analyse-dependency-usage}}
{{[…]}}
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING]
com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.13.1:compile}}
{quote}
This is “correct”: {{com.fasterxml.jackson.dataformat.yaml.YAMLFactory}} is
{{{}import{}}}ed in the tests but only used via reflection in prod because it’s
an optional (but not marked as optional so it’s included by default, but users
can {{}} it and that’s supported and documented) dependency.
However, adding it as {{}} does not work ☹ and
[https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html]
does not have anything on how to override this particular warning.
This is a *must-have* for, I hope, obvious reasons…
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
> Fix For: 3.3.0
>
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MDEP-787) [regression] 3.2.0/3.3.0-SNAPSHOT need way to override false “non-test-scoped dependency” warning
Thorsten Glaser created MDEP-787:
Summary: [regression] 3.2.0/3.3.0-SNAPSHOT need way to override
false “non-test-scoped dependency” warning
Key: MDEP-787
URL: https://issues.apache.org/jira/browse/MDEP-787
Project: Maven Dependency Plugin
Issue Type: Bug
Affects Versions: 3.2.0, 3.3.0
Reporter: Thorsten Glaser
This was found due to testing whether 3.3.0-SNAPSHOT fixes the regressions of
3.2.0 against 3.1.2 (it doesn’t, yet).
After finding
[https://maven.apache.org/guides/development/guide-testing-development-plugins.html]
I was able to test the snapshot on the
[https://github.com/tarent/extract-tool/tree/mdep753-snapshot] branch as well.
This problem shows up:
{quote}{{$ mvn dependency:analyze-only@analyse-dependency-usage}}
{{[…]}}
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING]
com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.13.1:compile}}
{quote}
This is “correct”: {{com.fasterxml.jackson.dataformat.yaml.YAMLFactory}} is
{{{}import{}}}ed in the tests but only used via reflection in prod because it’s
an optional (but not marked as optional so it’s included by default, but users
can {{}} it and that’s supported and documented) dependency. This
means it’s a false positive that cannot be expected to be handled by the test
correctly and must be overridden in the POM.
However, adding it as {{}} does not work ☹
it’s probably the wrong overriding element, but
[https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html]
does not have anything on how to override this particular warning.
This is a *must-have* for, I hope, obvious reasons…
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490969#comment-17490969
]
Thorsten Glaser commented on MDEP-753:
--
After finding
[https://maven.apache.org/guides/development/guide-testing-development-plugins.html]
I was able to test the snapshot on the
[https://github.com/tarent/extract-tool/tree/mdep753-snapshot] branch as well.
The initial problem…
{quote}{{$ mvn -Dmaven.dependency.version=3.2.0
dependency:analyze-only@analyse-dependency-usage}}
{{[…]}}
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING] org.springframework:spring-jdbc:jar:4.3.30.RELEASE:compile}}
{quote}
… is gone, but I have a new problem:
{quote}{{$ mvn dependency:analyze-only@analyse-dependency-usage}}
{{[…]}}
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING]
com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.13.1:compile}}
{quote}
This is “correct”: {{com.fasterxml.jackson.dataformat.yaml.YAMLFactory}} is
{{{}import{}}}ed in the tests but only used via reflection in prod because it’s
an optional (but not marked as optional so it’s included by default, but users
can {{}} it and that’s supported and documented) dependency.
However, adding it as {{}} does not work ☹ and
[https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html]
does not have anything on how to override this particular warning.
This is a *must-have* for, I hope, obvious reasons…
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
> Fix For: 3.3.0
>
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-703) maven-javadoc-plugin > 3.0.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MJAVADOC-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488311#comment-17488311
]
Thorsten Glaser commented on MJAVADOC-703:
--
Interestingly enough, the problem went away when fixing a property that caused
a similar issue in the maven-compiler-plugin:
https://issues.apache.org/jira/browse/MCOMPILER-477
Feel free to close this as resolved.
> maven-javadoc-plugin > 3.0.1 fail on JDK 8
> --
>
> Key: MJAVADOC-703
> URL: https://issues.apache.org/jira/browse/MJAVADOC-703
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.3.1
>Reporter: Thorsten Glaser
>Priority: Major
> Attachments: verbose1.txt
>
>
> Trying to use 3.1.0 or 3.3.1 with JDK 8 results in {{--release}} being passed
> to the {{javadoc}} command, which does not know it in JDK 8:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project maven-parent-lib: MavenReportException: Error while generating
> Javadoc: }}
> {{[ERROR] Exit code: 1 - javadoc: error - invalid flag: --release}}
> {{[ERROR]}}
> {{[ERROR] Command line was:
> /usr/lib/jvm/java-8-openjdk-i386/jre/../bin/javadoc @options @packages}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCOMPILER-477) maven-compiler-plugin > 3.5.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MCOMPILER-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488310#comment-17488310
]
Thorsten Glaser commented on MCOMPILER-477:
---
Huh, that was it. With
https://github.com/tarent/maven-parent/commit/8259d9ffdd3e7d6078359b26cc7dc3730fe0aa02
the problems, both this and the mjavadoc one(!), went away.
Feel free to close this as resolved, and thanks for the help!
> maven-compiler-plugin > 3.5.1 fail on JDK 8
> ---
>
> Key: MCOMPILER-477
> URL: https://issues.apache.org/jira/browse/MCOMPILER-477
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Thorsten Glaser
>Priority: Major
> Labels: need-more-info
> Fix For: waiting-for-feedback
>
>
> Trying to use 3.8.1 (or select older versions) with JDK 8 result in
> {{--release}} being passed to {{{}javac{}}}, which does not like that.
> {quote}{{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project maven-parent-lib: Fatal error compiling: invalid
> flag: --release -> [Help 1]}}
> {quote}
> Might be related to https://issues.apache.org/jira/browse/MJAVADOC-703 which
> is pretty much the same but for the maven-javadoc-plugin starting past a
> certain version. I tested them independently of each other, though.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[ https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488150#comment-17488150 ] Thorsten Glaser commented on MDEP-753: -- It says fixed in version 3.3.0 but there is no version 3.3.0‽ > Non-test dependency reported as Non-test scoped test only dependency > > > Key: MDEP-753 > URL: https://issues.apache.org/jira/browse/MDEP-753 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 3.2.0 >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Critical > Fix For: 3.3.0 > > > Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the > plugin. I'm not immediately sure whether this is a regression: > [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @ > google-http-client --- > Warning: Non-test scoped test only dependencies found: > Warning: com.google.guava:guava:jar:30.1.1-android:compile > Warning: io.opencensus:opencensus-api:jar:0.28.0:compile > Changing Guava to scope test breaks the build, which is expected based on the > code. The warning seems incorrect. > https://github.com/googleapis/google-http-java-client/pull/1396 > https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCOMPILER-477) maven-compiler-plugin > 3.5.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MCOMPILER-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486416#comment-17486416
]
Thorsten Glaser commented on MCOMPILER-477:
---
Hmm, no, but:
{{
${javaRelease}}}
Would that do it?
I’d have expected the plugin to only pass options known for a certain version
to tools of that version. I’ll try reshuffling that…
Setup is the same as in the other ticket:
[https://github.com/tarent/maven-parent] commit
01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a with [line 152 (not 154 here) in
{{parent/pom.xml}}|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L152]
commented out
> maven-compiler-plugin > 3.5.1 fail on JDK 8
> ---
>
> Key: MCOMPILER-477
> URL: https://issues.apache.org/jira/browse/MCOMPILER-477
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Thorsten Glaser
>Priority: Major
> Labels: need-more-info
> Fix For: waiting-for-feedback
>
>
> Trying to use 3.8.1 (or select older versions) with JDK 8 result in
> {{--release}} being passed to {{{}javac{}}}, which does not like that.
> {quote}{{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project maven-parent-lib: Fatal error compiling: invalid
> flag: --release -> [Help 1]}}
> {quote}
> Might be related to https://issues.apache.org/jira/browse/MJAVADOC-703 which
> is pretty much the same but for the maven-javadoc-plugin starting past a
> certain version. I tested them independently of each other, though.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7383) Cannot combine project.build.resources
[
https://issues.apache.org/jira/browse/MNG-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470961#comment-17470961
]
Thorsten Glaser commented on MNG-7383:
--
Ah, damn. That would have been very useful.
To symlinks (and sticking with maven-resources-plugin 2.x for much longer) then…
> Cannot combine project.build.resources
> --
>
> Key: MNG-7383
> URL: https://issues.apache.org/jira/browse/MNG-7383
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.6.3
>Reporter: Thorsten Glaser
>Priority: Minor
>
> I’m trying to add resources to a project but preserve the resources that the
> parent POM adds. This fails, though:
> {quote}{{}}
> {{ }}
> {{ }}
> {{ ${project.basedir}}}
> {{ }}
> {{ README}}
> {{ }}
> {{ false}}
> {{ }}
> {{ }}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7383) Cannot combine project.build.resources
[
https://issues.apache.org/jira/browse/MNG-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470942#comment-17470942
]
Thorsten Glaser commented on MNG-7383:
--
[~michael-o] reproducer: [https://github.com/tarent/rfc822/tree/MNG-7383]
{{$ mvn -B help:effective-pom | sed -n '//,/<\/resources>/p'}}
Compare with doing that on the parent commit ({{{}git checkout HEAD^{}}}). The
output should have been the superset of the two.
I’m kinda bound to the versions Debian ships. If the reproducer works for you,
you can test that much more quickly ☻
> Cannot combine project.build.resources
> --
>
> Key: MNG-7383
> URL: https://issues.apache.org/jira/browse/MNG-7383
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.6.3
>Reporter: Thorsten Glaser
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I’m trying to add resources to a project but preserve the resources that the
> parent POM adds. This fails, though:
> {quote}{{}}
> {{ }}
> {{ }}
> {{ ${project.basedir}}}
> {{ }}
> {{ README}}
> {{ }}
> {{ false}}
> {{ }}
> {{ }}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MDEP-780) “Non-test scoped test only dependencies found” false-positive in 3.2.0/1.11.2
[
https://issues.apache.org/jira/browse/MDEP-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470937#comment-17470937
]
Thorsten Glaser edited comment on MDEP-780 at 1/7/22, 11:03 PM:
Thanks [~mttjj] it is… WTF‽ This bug is {*}critical{*}, known for {*}seven
months{*}, has had an MWE for an it {+}five days later{+}, has had an
{+}apparent *fix another two days later* (seven _days_ after the report){+},
has *several dozen* votes and even more watchers, and is still unfixed‽
was (Author: mirabilos):
Thanks [~mttjj] it is… WTF‽ This bug is {*}critical{*}, known for {*}seven
months{*}, has had an MWE for an it {+}five days later{+}, has had an
{+}apparent *fix another two days later* (seven _days_ after the report){+},
and is still unfixed‽
> “Non-test scoped test only dependencies found” false-positive in 3.2.0/1.11.2
> -
>
> Key: MDEP-780
> URL: https://issues.apache.org/jira/browse/MDEP-780
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Critical
>
> After upgrading maven-dependency-plugin 3.1.2 → 3.2.0 I get the following
> false positives in [a
> project|https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/extract-tool.git]:
> {{[WARNING] Non-test scoped test only dependencies found:}}
> {{[WARNING] org.springframework:spring-jdbc:jar:4.3.30.RELEASE:compile}}
> This isn’t right, and with spring-jdbc scoped to test, the project doesn’t
> even compile.
> This also applies if I dowgrade the Maven dependency analyser to 1.11.2 [as
> in this
> commit|https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/extract-tool.git;a=commitdiff;h=d2b923304b6d2dfd2f52186d17843c492e4f5957];
> I cannot test with 1.11.1 (same version maven-dependency-plugin 3.1.2 used)
> because that’s incompatible with 3.2.0 so I cannot say for sure which of the
> two introduced this bug. If this is a bug in the shared component, please
> reassign appropriately.
> I’m setting the severity as it is because this effectively prevents me from
> upgrading past 3.1.2 in my projects.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470939#comment-17470939
]
Thorsten Glaser commented on MDEP-753:
--
https://issues.apache.org/jira/browse/MDEP-780 is another occurrence of this
bug, with Spring JDBC. In my case, however, both classes from the relevant
package used in {{src/test/}} are also used in {{{}src/main/{}}}… so I’m not
sure if the supposed fix is a proper fix, and apparently, seven months later we
still cannot even try‽
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Critical
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-780) “Non-test scoped test only dependencies found” false-positive in 3.2.0/1.11.2
[
https://issues.apache.org/jira/browse/MDEP-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470937#comment-17470937
]
Thorsten Glaser commented on MDEP-780:
--
Thanks [~mttjj] it is… WTF‽ This bug is {*}critical{*}, known for {*}seven
months{*}, has had an MWE for an it {+}five days later{+}, has had an
{+}apparent *fix another two days later* (seven _days_ after the report){+},
and is still unfixed‽
> “Non-test scoped test only dependencies found” false-positive in 3.2.0/1.11.2
> -
>
> Key: MDEP-780
> URL: https://issues.apache.org/jira/browse/MDEP-780
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Critical
>
> After upgrading maven-dependency-plugin 3.1.2 → 3.2.0 I get the following
> false positives in [a
> project|https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/extract-tool.git]:
> {{[WARNING] Non-test scoped test only dependencies found:}}
> {{[WARNING] org.springframework:spring-jdbc:jar:4.3.30.RELEASE:compile}}
> This isn’t right, and with spring-jdbc scoped to test, the project doesn’t
> even compile.
> This also applies if I dowgrade the Maven dependency analyser to 1.11.2 [as
> in this
> commit|https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/extract-tool.git;a=commitdiff;h=d2b923304b6d2dfd2f52186d17843c492e4f5957];
> I cannot test with 1.11.1 (same version maven-dependency-plugin 3.1.2 used)
> because that’s incompatible with 3.2.0 so I cannot say for sure which of the
> two introduced this bug. If this is a bug in the shared component, please
> reassign appropriately.
> I’m setting the severity as it is because this effectively prevents me from
> upgrading past 3.1.2 in my projects.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHARED-1004) Two (2) issues with symbolic links
[
https://issues.apache.org/jira/browse/MSHARED-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470931#comment-17470931
]
Thorsten Glaser commented on MSHARED-1004:
--
First, making a distinction between what the symlink points to (at copy time)
is really useless: it may be dangling in the source but correct in the copied
location (I have repositories like that!), and IMHO (see also below), you
either follow symlinks encountered in the source directory or you don’t
(whether you then also follow symlinks enocountered in the pointed-to directory
is another matter, but for consistency with filtering (see below) I think that
Maven needs to either follow all symlinks recursively or not touch them at all).
Turns out that there are +*three*+ distinct cases, to apply for each
{{}} directory:
* {{true}} — here, the symlinks are always followed
because the files themselves are possibly manipulated
* {{false}} with symlinks followed by default (m-r-p
2.x behaviour)
* {{false}} with symlinks copied as-is (m-r-p 3.0/3.1
behaviour)
And it also turns out I need to be able to mix them in a project, so I’m now
even stronger in favour of an option per resource directory (or otherwise
configured).
> Two (2) issues with symbolic links
> --
>
> Key: MSHARED-1004
> URL: https://issues.apache.org/jira/browse/MSHARED-1004
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.0
>Reporter: Jimisola Laursen
>Priority: Major
> Attachments: my-app-wo-symlinks.tar.gz, my-app.tar.gz
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Two issues with (relative) symbolic links as resources (use attached file for
> reference and MWE:
>
> {noformat}
> user@earhart:~/dev/test/my-app$ tree
> .
> ├── pom.xml
> ├── src
> │ ├── main
> │ │ ├── java
> │ │ │ └── com
> │ │ │ └── mycompany
> │ │ │ └── app
> │ │ │ └── App.java
> │ │ └── resources
> │ │ ├── B -> ../../../to_be_symlinked/B
> │ │ └── folder -> ../../../to_be_symlinked/folder
> │ └── test
> │ └── java
> │ └── com
> │ └── mycompany
> │ └── app
> │ └── AppTest.java
> └── to_be_symlinked
> ├── B
> └── folder
> └── A{noformat}
>
>
>
> * Symlinks for directories copies the actual directory (folder/A) whereas
> symlinks for files copies the symlink (B). Note the difference between file A
> and B. B is pointing incorrectly since it is relative.
> {noformat}
> user@earhart:~/dev/test/my-app/target/classes$ ls -l
> total 8
> lrwxrwxrwx 1 user user 26 dec 10 10:19 B -> ../../../to_be_symlinked/B
> drwxrwxr-x 3 user user 4096 dec 10 10:19 com
> drwxrwxr-x 2 user user 4096 dec 10 10:19 folder
> user@earhart:~/dev/test/my-app/target/classes$ ls -l folder/
> total 0
> -rw-rw-r-- 1 user user 0 dec 10 10:19 A{noformat}
> * Resources are not overwritten (java.nio.file.FileAlreadyExistsException).
> To reproduce run "mvn compile" two (2x) times:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources
> (default-resources) on project my-app: copying
> /home/user/dev/test/my-app/src/main/resources/folder/A to
> /home/user/dev/test/my-app/target/classes/folder/A failed with
> FileAlreadyExistsException:
> /home/user/dev/test/my-app/target/classes/folder/A -{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470929#comment-17470929
]
Thorsten Glaser commented on MRESOURCES-237:
Turns out that there are +*three*+ distinct cases, to apply for each
{{}} directory:
* {{true}} — here, the symlinks are always followed
because the files themselves are possibly manipulated
* {{false}} with symlinks followed by default (m-r-p
2.x behaviour)
* {{false}} with symlinks copied as-is (m-r-p 3.0/3.1
behaviour)
And it also turns out I need to be able to mix them in a project, so I’m now
even stronger in favour of an option per resource directory (or otherwise
configured).
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458306#comment-17458306
]
Thorsten Glaser edited comment on MRESOURCES-237 at 1/7/22, 10:37 PM:
--
I assume you’ve added a configuration item (or, perhaps ideally, a
per-resource-directory setting, just like {{false}} vs.
{{{}false{}}}) which we can use to configure this?
Because there are totally opposite requirements: some *must* have the symbolic
links copied *as-is* while others need to have the *content* of the symbolic
link *targets* copied.
I could not find a release announcement for either maven-resources of
maven-filtering 3.3.0 on
[https://www.mail-archive.com/announce@maven.apache.org/] so I’ve got no idea
how we can even test both behaviours.
{quote}There seems to be inconsistency since another symbolic link that points
to a directory has all its content (5-6 files) copied to target/classes.
That is, actual directory structure is copied if sym link but just sym link if
it is a file. Is this correct or have I missed something?
{quote}
This would also be really bad. In the “do not follow symlinks” case, I
*require* that symbolic links be copied as symlinks, no matter whether they
point to a file, directory, or are even dangling in the source repository. (I
have a project in which the symlink under {{src/main/resources/}} is
deliberately “broken” so that, when it is copied to {{target/something/}} it
will be correct. In another, the symlinks are only correct in the source
directory; this is actually my use case, and one which works with the 2.x
series of Maven’s relevant plugins.)
was (Author: mirabilos):
I assume you’ve added a configuration item (or, perhaps ideally, a
per-resource-directory setting, just like {{false}} vs.
{{{}false{}}}) which we can use to configure this?
Because [~lfvjimisola] and I have totally opposite requirements: I *must* have
the symbolic links copied *as-is* while [~lfvjimisola] needs to have the
*content* of the symbolic link *targets* copied.
I could not find a release announcement for either maven-resources of
maven-filtering 3.3.0 on
[https://www.mail-archive.com/announce@maven.apache.org/] so I’ve got no idea
how we can even test both behaviours.
{quote}There seems to be inconsistency since another symbolic link that points
to a directory has all its content (5-6 files) copied to target/classes.
That is, actual directory structure is copied if sym link but just sym link if
it is a file. Is this correct or have I missed something?
{quote}
This would also be really bad. I *require* that symbolic links be copied as
symlinks, no matter whether they point to a file, directory, or are even
dangling in the source repository. (I have a project in which the symlink under
{{src/main/resources/}} is deliberately “broken” so that, when it is copied to
{{target/something/}} it will be correct. This is actually my use case, and one
which works with the 2.x series of Maven’s relevant plugins.)
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink
[jira] [Created] (MNG-7383) Cannot combine project.build.resources
Thorsten Glaser created MNG-7383:
Summary: Cannot combine project.build.resources
Key: MNG-7383
URL: https://issues.apache.org/jira/browse/MNG-7383
Project: Maven
Issue Type: Bug
Components: POM
Affects Versions: 3.6.3
Reporter: Thorsten Glaser
I’m trying to add resources to a project but preserve the resources that the
parent POM adds. This fails, though:
{quote}{{}}
{{ }}
{{ }}
{{ ${project.basedir}}}
{{ }}
{{ README}}
{{ }}
{{ false}}
{{ }}
{{ }}
{quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[
https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461944#comment-17461944
]
Thorsten Glaser commented on MDEP-714:
--
[~lars-sh] good point!
I guess we cannot “simply” add a new scope to Maven, nor annotate the
{{dependency}} tags themselves. So adding a documented one-liner override like
[here|https://github.com/tarent/rfc822/blob/db4b50e7ac16619ef75779b6489cddf9b410d2b6/pom.xml#L226-L227]
seems like the best solution for this kind of {{testRuntime}} dependency.
In old projects, with many reported unused dependencies once this plugin is
turned on, it can be challenging to figure out which is which, though… but
that’s neither here nor there.
It *might* make sense for MDEP to add a hardcoded list of a couple of overrides
(specifically, test-scoped {{testRuntime}} dependencies). But once this is
added, everyone will add bugreports asking why the thing _they_ use isn’t on
the list, so it might be wise to not do it, from a maintenance PoV.
> Add analyze parameter "ignoreUnusedRuntime"
> ---
>
> Key: MDEP-714
> URL: https://issues.apache.org/jira/browse/MDEP-714
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.0
>
>
> Typical output when analyzing the maven-archetype-plugin:
> [WARNING] Unused declared dependencies found:
> [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime
> However since this is needed at runtime, possibly via reflection, it seems
> likely that it is used but the dependency analyzer can't figure this out.
> Confirm and consider whether the plugin should simply never report runtime
> dependencies as unused.
> This is tricky because it's certainly possible that a runtime dependency is
> unused, but in practice it seems more likely than not to be a false positive.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MJAVADOC-703) maven-javadoc-plugin > 3.0.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MJAVADOC-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461642#comment-17461642
]
Thorsten Glaser edited comment on MJAVADOC-703 at 12/17/21, 8:05 PM:
-
[~michael-o] [https://github.com/tarent/maven-parent] commit
01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a with [line 154 in
{{parent/pom.xml}}|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L154]
commented out (which forces 3.0.1 for JDK < 9), then a simple {{mvn clean
install}} shows this within under a minute.
(Uhm. But you need to {{git commit -a -m tmp}} (or something) before building,
or remove the {{mksrc-run}} from the top-level POM {{exec-maven-plugin}} or put
an {{exit 0}} on top of {{src/main/ancillary/mksrc.sh}} because it
(deliberately) breaks the build if there are uncommitted changes. Sorry about
that.)
I’m not sure what you mean with “verbose mode”. Setting {{-Dverbose}} or so on
the command line does not change the output? [^verbose1.txt]
PS: Might be related to https://issues.apache.org/jira/browse/MCOMPILER-477
which is pretty much the same but for the maven-compiler-plugin starting past a
certain version. I tested them independently of each other, though.
PPS: A bit more context: the parent POM adds two profiles, one for JDK 8 or
older (testing with 8), one for JDK 9 or newer (testing with 11), which help in
building with old/new JDK targetting old/new JRE (currently supporting/testing
8→8, 11→8, 11→11). Lines 165ff. of {{parent/pom.xml}} add the {{}}
(mjavadoc) or {{}} (mcompiler) configuration item to the plugins only
for 9+, but this does not currently work, which is why we have lines 149ff.
lower the versions of these plugins for 8-. The “to be targetted” JRE version
(by default 8) is set in [line
45|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L45]
as user-defined property {{{}$\{javaRelease{. We then insert this into
various plugins’ configuration blocks further below. {{lib/pom.xml}} is a
(very) tiny library shipped with the “our parent POM” project, and it quickly
exhibits issues with these plugins. The build and runtime environments are
Debian, so the JDK is used from {{/usr/bin/}} via the alternatives subsystem of
Debian, and {{JAVA_HOME}} is not set (which is why [we set
{{javadocExecutable}}
sometimes|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L183-L201]).
was (Author: mirabilos):
[~michael-o] [https://github.com/tarent/maven-parent] commit
01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a with [line 154 in
{{parent/pom.xml}}|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L154]
commented out (which forces 3.0.1 for JDK < 9), then a simple {{mvn clean
install}} shows this within under a minute.
(Uhm. But you need to {{git commit -a -m tmp}} (or something) before building,
or remove the {{mksrc-run}} from the top-level POM {{exec-maven-plugin}} or put
an {{exit 0}} on top of {{src/main/ancillary/mksrc.sh}} because it
(deliberately) breaks the build if there are uncommitted changes. Sorry about
that.)
I’m not sure what you mean with “verbose mode”. Setting {{-Dverbose}} or so on
the command line does not change the output? [^verbose1.txt]
PS: Might be related to https://issues.apache.org/jira/browse/MCOMPILER-477
which is pretty much the same but for the maven-compiler-plugin starting past a
certain version. I tested them independently of each other, though.
> maven-javadoc-plugin > 3.0.1 fail on JDK 8
> --
>
> Key: MJAVADOC-703
> URL: https://issues.apache.org/jira/browse/MJAVADOC-703
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.3.1
>Reporter: Thorsten Glaser
>Priority: Major
> Attachments: verbose1.txt
>
>
> Trying to use 3.1.0 or 3.3.1 with JDK 8 results in {{--release}} being passed
> to the {{javadoc}} command, which does not know it in JDK 8:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project maven-parent-lib: MavenReportException: Error while generating
> Javadoc: }}
> {{[ERROR] Exit code: 1 - javadoc: error - invalid flag: --release}}
> {{[ERROR]}}
> {{[ERROR] Command line was:
> /usr/lib/jvm/java-8-openjdk-i386/jre/../bin/javadoc @options @packages}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MCOMPILER-477) maven-compiler-plugin > 3.5.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MCOMPILER-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Glaser updated MCOMPILER-477:
--
Description:
Trying to use 3.8.1 (or select older versions) with JDK 8 result in
{{--release}} being passed to {{{}javac{}}}, which does not like that.
{quote}{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project maven-parent-lib: Fatal error compiling: invalid flag: --release ->
[Help 1]}}
{quote}
Might be related to https://issues.apache.org/jira/browse/MJAVADOC-703 which is
pretty much the same but for the maven-javadoc-plugin starting past a certain
version. I tested them independently of each other, though.
was:
Trying to use 3.8.1 (or select older versions) with JDK 8 result in
{{--release}} being passed to {{{}javac{}}}, which does not like that.
{quote}{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project maven-parent-lib: Fatal error compiling: invalid flag: --release ->
[Help 1]}}
{quote}
> maven-compiler-plugin > 3.5.1 fail on JDK 8
> ---
>
> Key: MCOMPILER-477
> URL: https://issues.apache.org/jira/browse/MCOMPILER-477
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Thorsten Glaser
>Priority: Major
>
> Trying to use 3.8.1 (or select older versions) with JDK 8 result in
> {{--release}} being passed to {{{}javac{}}}, which does not like that.
> {quote}{{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project maven-parent-lib: Fatal error compiling: invalid
> flag: --release -> [Help 1]}}
> {quote}
> Might be related to https://issues.apache.org/jira/browse/MJAVADOC-703 which
> is pretty much the same but for the maven-javadoc-plugin starting past a
> certain version. I tested them independently of each other, though.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MJAVADOC-703) maven-javadoc-plugin > 3.0.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MJAVADOC-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461642#comment-17461642
]
Thorsten Glaser edited comment on MJAVADOC-703 at 12/17/21, 7:57 PM:
-
[~michael-o] [https://github.com/tarent/maven-parent] commit
01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a with [line 154 in
{{parent/pom.xml}}|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L154]
commented out (which forces 3.0.1 for JDK < 9), then a simple {{mvn clean
install}} shows this within under a minute.
(Uhm. But you need to {{git commit -a -m tmp}} (or something) before building,
or remove the {{mksrc-run}} from the top-level POM {{exec-maven-plugin}} or put
an {{exit 0}} on top of {{src/main/ancillary/mksrc.sh}} because it
(deliberately) breaks the build if there are uncommitted changes. Sorry about
that.)
I’m not sure what you mean with “verbose mode”. Setting {{-Dverbose}} or so on
the command line does not change the output? [^verbose1.txt]
PS: Might be related to https://issues.apache.org/jira/browse/MCOMPILER-477
which is pretty much the same but for the maven-compiler-plugin starting past a
certain version. I tested them independently of each other, though.
was (Author: mirabilos):
[~michael-o] [https://github.com/tarent/maven-parent] commit
01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a with [line 154 in
{{parent/pom.xml}}|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L154]
commented out (which forces 3.0.1 for JDK < 9), then a simple {{mvn clean
install}} shows this within under a minute.
(Uhm. But you need to {{git commit -a -m tmp}} (or something) before building,
or remove the {{mksrc-run}} from the top-level POM {{exec-maven-plugin}} or put
an {{exit 0}} on top of {{src/main/ancillary/mksrc.sh}} because it
(deliberately) breaks the build if there are uncommitted changes. Sorry about
that.)
I’m not sure what you mean with “verbose mode”. Setting {{-Dverbose}} or so on
the command line does not change the output? [^verbose1.txt]
> maven-javadoc-plugin > 3.0.1 fail on JDK 8
> --
>
> Key: MJAVADOC-703
> URL: https://issues.apache.org/jira/browse/MJAVADOC-703
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.3.1
>Reporter: Thorsten Glaser
>Priority: Major
> Attachments: verbose1.txt
>
>
> Trying to use 3.1.0 or 3.3.1 with JDK 8 results in {{--release}} being passed
> to the {{javadoc}} command, which does not know it in JDK 8:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project maven-parent-lib: MavenReportException: Error while generating
> Javadoc: }}
> {{[ERROR] Exit code: 1 - javadoc: error - invalid flag: --release}}
> {{[ERROR]}}
> {{[ERROR] Command line was:
> /usr/lib/jvm/java-8-openjdk-i386/jre/../bin/javadoc @options @packages}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-703) maven-javadoc-plugin > 3.0.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MJAVADOC-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461642#comment-17461642
]
Thorsten Glaser commented on MJAVADOC-703:
--
[~michael-o] [https://github.com/tarent/maven-parent] commit
01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a with [line 154 in
{{parent/pom.xml}}|https://github.com/tarent/maven-parent/blob/01e7a681ad6f3b90f08eb436fe9dd4ad3a391f0a/parent/pom.xml#L154]
commented out (which forces 3.0.1 for JDK < 9), then a simple {{mvn clean
install}} shows this within under a minute.
(Uhm. But you need to {{git commit -a -m tmp}} (or something) before building,
or remove the {{mksrc-run}} from the top-level POM {{exec-maven-plugin}} or put
an {{exit 0}} on top of {{src/main/ancillary/mksrc.sh}} because it
(deliberately) breaks the build if there are uncommitted changes. Sorry about
that.)
I’m not sure what you mean with “verbose mode”. Setting {{-Dverbose}} or so on
the command line does not change the output? [^verbose1.txt]
> maven-javadoc-plugin > 3.0.1 fail on JDK 8
> --
>
> Key: MJAVADOC-703
> URL: https://issues.apache.org/jira/browse/MJAVADOC-703
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.3.1
>Reporter: Thorsten Glaser
>Priority: Major
> Attachments: verbose1.txt
>
>
> Trying to use 3.1.0 or 3.3.1 with JDK 8 results in {{--release}} being passed
> to the {{javadoc}} command, which does not know it in JDK 8:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project maven-parent-lib: MavenReportException: Error while generating
> Javadoc: }}
> {{[ERROR] Exit code: 1 - javadoc: error - invalid flag: --release}}
> {{[ERROR]}}
> {{[ERROR] Command line was:
> /usr/lib/jvm/java-8-openjdk-i386/jre/../bin/javadoc @options @packages}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MJAVADOC-703) maven-javadoc-plugin > 3.0.1 fail on JDK 8
[
https://issues.apache.org/jira/browse/MJAVADOC-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Glaser updated MJAVADOC-703:
-
Attachment: verbose1.txt
> maven-javadoc-plugin > 3.0.1 fail on JDK 8
> --
>
> Key: MJAVADOC-703
> URL: https://issues.apache.org/jira/browse/MJAVADOC-703
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.3.1
>Reporter: Thorsten Glaser
>Priority: Major
> Attachments: verbose1.txt
>
>
> Trying to use 3.1.0 or 3.3.1 with JDK 8 results in {{--release}} being passed
> to the {{javadoc}} command, which does not know it in JDK 8:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
> project maven-parent-lib: MavenReportException: Error while generating
> Javadoc: }}
> {{[ERROR] Exit code: 1 - javadoc: error - invalid flag: --release}}
> {{[ERROR]}}
> {{[ERROR] Command line was:
> /usr/lib/jvm/java-8-openjdk-i386/jre/../bin/javadoc @options @packages}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MCOMPILER-477) maven-compiler-plugin > 3.5.1 fail on JDK 8
Thorsten Glaser created MCOMPILER-477:
-
Summary: maven-compiler-plugin > 3.5.1 fail on JDK 8
Key: MCOMPILER-477
URL: https://issues.apache.org/jira/browse/MCOMPILER-477
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.8.1
Reporter: Thorsten Glaser
Trying to use 3.8.1 (or select older versions) with JDK 8 result in
{{--release}} being passed to {{{}javac{}}}, which does not like that.
{quote}{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project maven-parent-lib: Fatal error compiling: invalid flag: --release ->
[Help 1]}}
{quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MJAVADOC-703) maven-javadoc-plugin > 3.0.1 fail on JDK 8
Thorsten Glaser created MJAVADOC-703:
Summary: maven-javadoc-plugin > 3.0.1 fail on JDK 8
Key: MJAVADOC-703
URL: https://issues.apache.org/jira/browse/MJAVADOC-703
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.3.1, 3.1.0
Reporter: Thorsten Glaser
Trying to use 3.1.0 or 3.3.1 with JDK 8 results in {{--release}} being passed
to the {{javadoc}} command, which does not know it in JDK 8:
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.3.1:jar (attach-javadocs) on
project maven-parent-lib: MavenReportException: Error while generating Javadoc:
}}
{{[ERROR] Exit code: 1 - javadoc: error - invalid flag: --release}}
{{[ERROR]}}
{{[ERROR] Command line was: /usr/lib/jvm/java-8-openjdk-i386/jre/../bin/javadoc
@options @packages}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MDEP-780) “Non-test scoped test only dependencies found” false-positive in 3.2.0/1.11.2
Thorsten Glaser created MDEP-780:
Summary: “Non-test scoped test only dependencies found”
false-positive in 3.2.0/1.11.2
Key: MDEP-780
URL: https://issues.apache.org/jira/browse/MDEP-780
Project: Maven Dependency Plugin
Issue Type: Bug
Affects Versions: 3.2.0
Reporter: Thorsten Glaser
After upgrading maven-dependency-plugin 3.1.2 → 3.2.0 I get the following false
positives in [a
project|https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/extract-tool.git]:
{{[WARNING] Non-test scoped test only dependencies found:}}
{{[WARNING] org.springframework:spring-jdbc:jar:4.3.30.RELEASE:compile}}
This isn’t right, and with spring-jdbc scoped to test, the project doesn’t even
compile.
This also applies if I dowgrade the Maven dependency analyser to 1.11.2 [as in
this
commit|https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/extract-tool.git;a=commitdiff;h=d2b923304b6d2dfd2f52186d17843c492e4f5957];
I cannot test with 1.11.1 (same version maven-dependency-plugin 3.1.2 used)
because that’s incompatible with 3.2.0 so I cannot say for sure which of the
two introduced this bug. If this is a bug in the shared component, please
reassign appropriately.
I’m setting the severity as it is because this effectively prevents me from
upgrading past 3.1.2 in my projects.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-714) Add analyze parameter "ignoreUnusedRuntime"
[
https://issues.apache.org/jira/browse/MDEP-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458599#comment-17458599
]
Thorsten Glaser commented on MDEP-714:
--
I’m having the same problem, but with {{{}test{}}}-scoped dependencies.
{{}}
{{org.junit.jupiter:junit-jupiter-engine}}
… and…
{{}}
{{ org.junit.jupiter}}
{{ junit-jupiter-engine}}
{{ ${junit.version}}}
{{ test}}
{{}}
I’m not sure generally ignoring them all is the way to go, though…
> Add analyze parameter "ignoreUnusedRuntime"
> ---
>
> Key: MDEP-714
> URL: https://issues.apache.org/jira/browse/MDEP-714
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.2.0
>
>
> Typical output when analyzing the maven-archetype-plugin:
> [WARNING] Unused declared dependencies found:
> [WARNING]org.apache.ivy:ivy:jar:2.5.0:runtime
> However since this is needed at runtime, possibly via reflection, it seems
> likely that it is used but the dependency analyzer can't figure this out.
> Confirm and consider whether the plugin should simply never report runtime
> dependencies as unused.
> This is tricky because it's certainly possible that a runtime dependency is
> unused, but in practice it seems more likely than not to be a false positive.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHARED-1004) Two (2) issues with symbolic links
[
https://issues.apache.org/jira/browse/MSHARED-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458326#comment-17458326
]
Thorsten Glaser commented on MSHARED-1004:
--
The reverse case is also true, see the comments on
https://issues.apache.org/jira/browse/MRESOURCES-237
> Two (2) issues with symbolic links
> --
>
> Key: MSHARED-1004
> URL: https://issues.apache.org/jira/browse/MSHARED-1004
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.0
>Reporter: Jimisola Laursen
>Priority: Major
> Attachments: my-app-wo-symlinks.tar.gz, my-app.tar.gz
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Two issues with (relative) symbolic links as resources (use attached file for
> reference and MWE:
>
> {noformat}
> user@earhart:~/dev/test/my-app$ tree
> .
> ├── pom.xml
> ├── src
> │ ├── main
> │ │ ├── java
> │ │ │ └── com
> │ │ │ └── mycompany
> │ │ │ └── app
> │ │ │ └── App.java
> │ │ └── resources
> │ │ ├── B -> ../../../to_be_symlinked/B
> │ │ └── folder -> ../../../to_be_symlinked/folder
> │ └── test
> │ └── java
> │ └── com
> │ └── mycompany
> │ └── app
> │ └── AppTest.java
> └── to_be_symlinked
> ├── B
> └── folder
> └── A{noformat}
>
>
>
> * Symlinks for directories copies the actual directory (folder/A) whereas
> symlinks for files copies the symlink (B). Note the difference between file A
> and B. B is pointing incorrectly since it is relative.
> {noformat}
> user@earhart:~/dev/test/my-app/target/classes$ ls -l
> total 8
> lrwxrwxrwx 1 user user 26 dec 10 10:19 B -> ../../../to_be_symlinked/B
> drwxrwxr-x 3 user user 4096 dec 10 10:19 com
> drwxrwxr-x 2 user user 4096 dec 10 10:19 folder
> user@earhart:~/dev/test/my-app/target/classes$ ls -l folder/
> total 0
> -rw-rw-r-- 1 user user 0 dec 10 10:19 A{noformat}
> * Resources are not overwritten (java.nio.file.FileAlreadyExistsException).
> To reproduce run "mvn compile" two (2x) times:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources
> (default-resources) on project my-app: copying
> /home/user/dev/test/my-app/src/main/resources/folder/A to
> /home/user/dev/test/my-app/target/classes/folder/A failed with
> FileAlreadyExistsException:
> /home/user/dev/test/my-app/target/classes/folder/A -{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458325#comment-17458325
]
Thorsten Glaser commented on MRESOURCES-237:
{quote}[~mirabilos] Thank you for your comment. We both seem to have valid
use-cases.
{quote}
Precisely. Valid and opposite.
{quote}Feel free to comment there as well.
{quote}
I’ll see when I find the time. Things are hectic this week ☻
{quote}I have not tried to turn filtering off because we need filtering of our
resources
{quote}
I have projects that have both filtered and unfiltered resources ☺ I definitely
need both, and the symlink behaviour needs to be independent of whether it’s
filtered.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458306#comment-17458306
]
Thorsten Glaser commented on MRESOURCES-237:
I assume you’ve added a configuration item (or, perhaps ideally, a
per-resource-directory setting, just like {{false}} vs.
{{{}false{}}}) which we can use to configure this?
Because [~lfvjimisola] and I have totally opposite requirements: I *must* have
the symbolic links copied *as-is* while [~lfvjimisola] needs to have the
*content* of the symbolic link *targets* copied.
I could not find a release announcement for either maven-resources of
maven-filtering 3.3.0 on
[https://www.mail-archive.com/announce@maven.apache.org/] so I’ve got no idea
how we can even test both behaviours.
{quote}There seems to be inconsistency since another symbolic link that points
to a directory has all its content (5-6 files) copied to target/classes.
That is, actual directory structure is copied if sym link but just sym link if
it is a file. Is this correct or have I missed something?
{quote}
This would also be really bad. I *require* that symbolic links be copied as
symlinks, no matter whether they point to a file, directory, or are even
dangling in the source repository. (I have a project in which the symlink under
{{src/main/resources/}} is deliberately “broken” so that, when it is copied to
{{target/something/}} it will be correct. This is actually my use case, and one
which works with the 2.x series of Maven’s relevant plugins.)
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418689#comment-17418689
]
Thorsten Glaser commented on MRESOURCES-237:
2.7 works for you? I ran into MSHARED-325 there and had to downgrade to 2.6,
cf. org.evolvis.tartools:maven-parent in Central.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380851#comment-17380851
]
Thorsten Glaser commented on MNG-6241:
--
I don’t need to, I’m the maintainer of a shell and see it works.
But wouldn’t you want to add {{${NO_COLOR+-B}}} instead?
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380821#comment-17380821
]
Thorsten Glaser commented on MNG-6241:
--
Exactly.
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380593#comment-17380593
]
Thorsten Glaser commented on MNG-6241:
--
Sure. That would help with the colour option specifically, not with other
options, but that’s the one I need.
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331549#comment-17331549
]
Thorsten Glaser edited comment on MJAVADOC-669 at 4/25/21, 3:08 PM:
If the content is injected by the JDK itself, then, of course this is true.
We somehow need a way to be able to comment on the JDK bug though…
(On that topic, what does “fixed in JDK 16” mean… if the two files that “don’t
refer to a LICENSE file” are derived from jQuery, they are still MIT-licenced,
and the MIT licence requires redistribution of the copyright notice and licence
alongside…)
was (Author: mirabilos):
If the content is injected by the JDK itself, then, of course this is true.
We somehow need a way to be able to comment on the JDK bug though…
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective copyright
> notices for the various jQuery-related projects (including those _they_
> include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
> widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
> * {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
> exception as provided by Oracle
> * {{COPYING}} or {{js/COPYING}} (this being the customary name for this
> file) containing the verbatim text of the GNU GPL version 2
> * Ideally, add a top-level {{LICENCE}} file pointing out those three and
> briefly documenting the licence of all other non-generated files and state
> all other files are generated from the original project and share its licence
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331549#comment-17331549
]
Thorsten Glaser commented on MJAVADOC-669:
--
If the content is injected by the JDK itself, then, of course this is true.
We somehow need a way to be able to comment on the JDK bug though…
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective copyright
> notices for the various jQuery-related projects (including those _they_
> include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
> widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
> * {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
> exception as provided by Oracle
> * {{COPYING}} or {{js/COPYING}} (this being the customary name for this
> file) containing the verbatim text of the GNU GPL version 2
> * Ideally, add a top-level {{LICENCE}} file pointing out those three and
> briefly documenting the licence of all other non-generated files and state
> all other files are generated from the original project and share its licence
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268776#comment-17268776
]
Thorsten Glaser commented on MJAVADOC-669:
--
Yes, 11 was what my bugreport was about (I use 11 because I run Debian unstable
or stable and 8 is only available in *old*stable, even if I target 8 as JRE
when I don’t need 11’s features yet).
I was just looking at whether we’d _also_ need a fix for 8.
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective copyright
> notices for the various jQuery-related projects (including those _they_
> include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
> widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
> * {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
> exception as provided by Oracle
> * {{COPYING}} or {{js/COPYING}} (this being the customary name for this
> file) containing the verbatim text of the GNU GPL version 2
> * Ideally, add a top-level {{LICENCE}} file pointing out those three and
> briefly documenting the licence of all other non-generated files and state
> all other files are generated from the original project and share its licence
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268764#comment-17268764
]
Thorsten Glaser commented on MJAVADOC-669:
--
Thanks.
I checked 8u, and we’re probably fine there, only a rather trivial javascript
file without explicit notices. (And a CSS file, but…)
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective copyright
> notices for the various jQuery-related projects (including those _they_
> include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
> widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
> * {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
> exception as provided by Oracle
> * {{COPYING}} or {{js/COPYING}} (this being the customary name for this
> file) containing the verbatim text of the GNU GPL version 2
> * Ideally, add a top-level {{LICENCE}} file pointing out those three and
> briefly documenting the licence of all other non-generated files and state
> all other files are generated from the original project and share its licence
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263389#comment-17263389
]
Thorsten Glaser edited comment on MJAVADOC-669 at 1/12/21, 2:57 PM:
I cannot seem to comment in the Oracle bug database ☹ (even after logging in
with an Oracle account) so commenting here:
{quote}we are OK (minified files only)
{quote}
I’d like to ask that “minified files only” is not considered part of the
solution, as I wrote above: keeping the full files there makes it easier, well
possible at all, to check these files for backdoors etc. (the duplication I was
speaking of was that there were two identical copies of unminified jQuery).
{color:#ff}⚠{color} For the two GPL’d files ({{script.js}} and
{{search.js}}), minified-only would even add a GPL violation, because minified
is compiled and not the preferred form for working on.
So please do nōn-minified-only, or (if and only if you must) both.
{quote}The jquery files are fixed in JDK 16: there are now just two minified
files, which do not refer to a nearby LICENSE file.
{quote}
I don’t quite see what this is supposed to mean. {color:#ff}⚠{color} The
problem is not that the files refer to a nōnexisting licence file, the problem
is that the licence is missing.
was (Author: mirabilos):
I cannot seem to comment in the Oracle bug database ☹
{quote}we are OK (minified files only)
{quote}
I’d like to ask that “minified files only” is not considered part of the
solution, as I wrote above: keeping the full files there makes it easier, well
possible at all, to check these files for backdoors etc. (the duplication I was
speaking of was that there were two identical copies of unminified jQuery).
{color:#FF}⚠{color} For the two GPL’d files ({{script.js}} and
{{search.js}}), minified-only would even add a GPL violation, because minified
is compiled and not the preferred form for working on.
So please do nōn-minified-only, or (if and only if you must) both.
{quote}The jquery files are fixed in JDK 16: there are now just two minified
files, which do not refer to a nearby LICENSE file.
{quote}
I don’t quite see what this is supposed to mean. {color:#FF}⚠{color} The
problem is not that the files refer to a nōnexisting licence file, the problem
is that the licence is missing.
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective
[jira] [Commented] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263389#comment-17263389
]
Thorsten Glaser commented on MJAVADOC-669:
--
I cannot seem to comment in the Oracle bug database ☹
{quote}we are OK (minified files only)
{quote}
I’d like to ask that “minified files only” is not considered part of the
solution, as I wrote above: keeping the full files there makes it easier, well
possible at all, to check these files for backdoors etc. (the duplication I was
speaking of was that there were two identical copies of unminified jQuery).
{color:#FF}⚠{color} For the two GPL’d files ({{script.js}} and
{{search.js}}), minified-only would even add a GPL violation, because minified
is compiled and not the preferred form for working on.
So please do nōn-minified-only, or (if and only if you must) both.
{quote}The jquery files are fixed in JDK 16: there are now just two minified
files, which do not refer to a nearby LICENSE file.
{quote}
I don’t quite see what this is supposed to mean. {color:#FF}⚠{color} The
problem is not that the files refer to a nōnexisting licence file, the problem
is that the licence is missing.
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective copyright
> notices for the various jQuery-related projects (including those _they_
> include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
> widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
> * {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
> exception as provided by Oracle
> * {{COPYING}} or {{js/COPYING}} (this being the customary name for this
> file) containing the verbatim text of the GNU GPL version 2
> * Ideally, add a top-level {{LICENCE}} file pointing out those three and
> briefly documenting the licence of all other non-generated files and state
> all other files are generated from the original project and share its licence
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261436#comment-17261436
]
Thorsten Glaser edited comment on MJAVADOC-669 at 1/11/21, 5:20 PM:
[~michael-o] done:
{quote}We will review your report and have assigned it an internal review ID :
9068511.
{quote}
This is now [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8259530]
except they broke my nōn-ASCII characters…
{quote}Depending upon the completeness of the report and our ability to
reproduce the problem, either a new bug will be posted, or we will contact you
for further information.
{quote}
Note that it is preferable to have the +nōn-minified+ form there. Whether the
minified form is present and/or used is not as important, but the nōn-minified
form is the one that allows properly auditing what goes on. (I believe that
javadoc JARs can skip the minified form and use _only_ the nōn-minified one, as
they are not typically served over the network, and the files are
PKZIP-compressed anyway.) This stance is probably mandated by Open Source
distribution policies as well.
So, if you’re going to delete one, delete the _minified_ one, as it’s an opaque
binary.
I don’t mind having both too much, but having two copies of (the nōn-minified)
jQuery is still redundant ☺
was (Author: mirabilos):
[~michael-o] done:
{quote}We will review your report and have assigned it an internal review ID :
9068511. Depending upon the completeness of the report and our ability to
reproduce the problem, either a new bug will be posted, or we will contact you
for further information.
{quote}
Note that it is preferable to have the +nōn-minified+ form there. Whether the
minified form is present and/or used is not as important, but the nōn-minified
form is the one that allows properly auditing what goes on. (I believe that
javadoc JARs can skip the minified form and use _only_ the nōn-minified one, as
they are not typically served over the network, and the files are
PKZIP-compressed anyway.) This stance is probably mandated by Open Source
distribution policies as well.
So, if you’re going to delete one, delete the _minified_ one, as it’s an opaque
binary.
I don’t mind having both too much, but having two copies of (the nōn-minified)
jQuery is still redundant ☺
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective
[jira] [Commented] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261436#comment-17261436
]
Thorsten Glaser commented on MJAVADOC-669:
--
[~michael-o] done:
{quote}We will review your report and have assigned it an internal review ID :
9068511. Depending upon the completeness of the report and our ability to
reproduce the problem, either a new bug will be posted, or we will contact you
for further information.
{quote}
Note that it is preferable to have the +nōn-minified+ form there. Whether the
minified form is present and/or used is not as important, but the nōn-minified
form is the one that allows properly auditing what goes on. (I believe that
javadoc JARs can skip the minified form and use _only_ the nōn-minified one, as
they are not typically served over the network, and the files are
PKZIP-compressed anyway.) This stance is probably mandated by Open Source
distribution policies as well.
So, if you’re going to delete one, delete the _minified_ one, as it’s an opaque
binary.
I don’t mind having both too much, but having two copies of (the nōn-minified)
jQuery is still redundant ☺
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective copyright
> notices for the various jQuery-related projects (including those _they_
> include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
> widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
> * {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
> exception as provided by Oracle
> * {{COPYING}} or {{js/COPYING}} (this being the customary name for this
> file) containing the verbatim text of the GNU GPL version 2
> * Ideally, add a top-level {{LICENCE}} file pointing out those three and
> briefly documenting the licence of all other non-generated files and state
> all other files are generated from the original project and share its licence
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Glaser updated MJAVADOC-669:
-
Description:
A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
components under the MIT licence:
* jQuery 3.5.1
** {{jquery/external/jquery/jquery.js}}
** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
archive size of the JAR, why is it included like this?)
* JSZip 3.2.1
** {{jquery/jszip/dist/jszip.js}}
** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
** {{jquery/jszip-utils/dist/jszip-utils.js}}{{}}
* jQuery UI 1.12.1
** {{jquery/jquery-ui.css}}
** {{jquery/jquery-ui.js}}
** {{jquery/jquery-ui.structure.css}}
* and their respective minified versions
It also contains {{script.js}} and {{search.js}} which are
GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle in
the LICENSE file that accompanied this code” but no such file accompanies said
code.
There are also multiple static {{resources}} and {{jquery/images}} whose
licence is not documented.
The MIT licence specifically *requires* that “The […] copyright notice and this
permission notice [the licence body] shall be included in all copies or
substantial portions of the Software.” The distribution PKZIP archives (JAR
files) created by the Maven Javadoc Plugin violate this licence, making them
not redistributable.
Similarily, the GPLv2 used by the Oracle-provided files *requires* that
redistributors “give any other recipients of the Program a copy of this License
along with the Program.” The “if not, write to the Free Software Foundation”
comment is specifically *not sufficient* for this and only provided as fallback
should distributors violate this clause, as Maven Javadoc Plugin-generated
PKZIP archives do. To be effective, the Classpath exception must also be
provided.
h2. Suggested fix
Include the following new files:
* {{jquery/LICENCE}} containing the MIT licence and all respective copyright
notices for the various jQuery-related projects (including those _they_
include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
* {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
exception as provided by Oracle
* {{COPYING}} or {{js/COPYING}} (this being the customary name for this file)
containing the verbatim text of the GNU GPL version 2
* Ideally, add a top-level {{LICENCE}} file pointing out those three and
briefly documenting the licence of all other nōn-generated files and state all
other files are generated from the original project and share its licence
was:
A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
components under the MIT licence:
* jQuery 3.5.1
** {{jquery/external/jquery/jquery.js}}
** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
archive size of the JAR, why is it included like this?)
* JSZip 3.2.1
** {{jquery/jszip/dist/jszip.js}}
** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
** {{jquery/jszip-utils/dist/jszip-utils.js}}{{}}
* jQuery UI 1.12.1
** {{jquery/jquery-ui.css}}
** {{jquery/jquery-ui.js}}
** {{jquery/jquery-ui.structure.css}}
* and their respective minified versions
It also contains {{script.js}} and {{search.js}} which are
GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle in
the LICENSE file that accompanied this code” but no such file accompanies said
code.
There are also multiple static {{resources}} and {{jquery/images}} whose
licence is not documented.
The MIT licence specifically *requires* that “The […] copyright notice and this
permission notice [the licence body] shall be included in all copies or
substantial portions of the Software.” The distribution PKZIP archives (JAR
files) created by the Maven Javadoc Plugin violate this licence, making them
not redistributable.
Similarily, the GPLv2 used by the Oracle-provided files *requires* that
redistributors “give any other recipients of the Program a copy of this License
along with the Program.” The “if not, write to the Free Software Foundation”
comment is specifically *not sufficient* for this and only provided as fallback
should distributors violate this clause, as Maven Javadoc Plugin-generated
PKZIP archives do. To be effective, the Classpath exception must also be
provided.
h2. Suggested fix
Include the following new files:
* {{jquery/LICENCE}} containing the MIT licence and all respective copyright
notices for the various jQuery-related projects (including those _they_
include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
* {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
exception as provided by Oracle
*
[jira] [Updated] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Glaser updated MJAVADOC-669:
-
Description:
A javadoc JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
components under the MIT licence:
* jQuery 3.5.1
** {{jquery/external/jquery/jquery.js}}
** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
archive size of the JAR, why is it included like this?)
* JSZip 3.2.1
** {{jquery/jszip/dist/jszip.js}}
** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
** {{jquery/jszip-utils/dist/jszip-utils.js}}{{}}
* jQuery UI 1.12.1
** {{jquery/jquery-ui.css}}
** {{jquery/jquery-ui.js}}
** {{jquery/jquery-ui.structure.css}}
* and their respective minified versions
It also contains {{script.js}} and {{search.js}} which are
GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle in
the LICENSE file that accompanied this code” but no such file accompanies said
code.
There are also multiple static {{resources}} and {{jquery/images}} whose
licence is not documented.
The MIT licence specifically *requires* that “The […] copyright notice and this
permission notice [the licence body] shall be included in all copies or
substantial portions of the Software.” The distribution PKZIP archives (JAR
files) created by the Maven Javadoc Plugin violate this licence, making them
not redistributable.
Similarily, the GPLv2 used by the Oracle-provided files *requires* that
redistributors “give any other recipients of the Program a copy of this License
along with the Program.” The “if not, write to the Free Software Foundation”
comment is specifically *not sufficient* for this and only provided as fallback
should distributors violate this clause, as Maven Javadoc Plugin-generated
PKZIP archives do. To be effective, the Classpath exception must also be
provided.
h2. Suggested fix
Include the following new files:
* {{jquery/LICENCE}} containing the MIT licence and all respective copyright
notices for the various jQuery-related projects (including those _they_
include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
* {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
exception as provided by Oracle
* {{COPYING}} or {{js/COPYING}} (this being the customary name for this file)
containing the verbatim text of the GNU GPL version 2
was:
A sources JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
components under the MIT licence:
* jQuery 3.5.1
** {{jquery/external/jquery/jquery.js}}
** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
archive size of the JAR, why is it included like this?)
* JSZip 3.2.1
** {{jquery/jszip/dist/jszip.js}}
** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
** {{jquery/jszip-utils/dist/jszip-utils.js}}{{}}
* jQuery UI 1.12.1
** {{jquery/jquery-ui.css}}
** {{jquery/jquery-ui.js}}
** {{jquery/jquery-ui.structure.css}}
* and their respective minified versions
It also contains {{script.js}} and {{search.js}} which are
GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle in
the LICENSE file that accompanied this code” but no such file accompanies said
code.
There are also multiple static {{resources}} and {{jquery/images}} whose
licence is not documented.
The MIT licence specifically *requires* that “The […] copyright notice and this
permission notice [the licence body] shall be included in all copies or
substantial portions of the Software.” The distribution PKZIP archives (JAR
files) created by the Maven Javadoc Plugin violate this licence, making them
not redistributable.
Similarily, the GPLv2 used by the Oracle-provided files *requires* that
redistributors “give any other recipients of the Program a copy of this License
along with the Program.” The “if not, write to the Free Software Foundation”
comment is specifically *not sufficient* for this and only provided as fallback
should distributors violate this clause, as Maven Javadoc Plugin-generated
PKZIP archives do. To be effective, the Classpath exception must also be
provided.
h2. Suggested fix
Include the following new files:
* {{jquery/LICENCE}} containing the MIT licence and all respective copyright
notices for the various jQuery-related projects (including those _they_
include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
* {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
exception as provided by Oracle
* {{COPYING}} or {{js/COPYING}} (this being the customary name for this file)
containing the verbatim text of the GNU GPL version 2
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of
[jira] [Updated] (MJAVADOC-669) Generated javadoc JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
[
https://issues.apache.org/jira/browse/MJAVADOC-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Glaser updated MJAVADOC-669:
-
Summary: Generated javadoc JARs contain jQuery and other MIT-licenced works
without reproducing a copy of the MIT licence, same for GPL-licenced works
(was: Generated sources JARs contain jQuery and other MIT-licenced works
without reproducing a copy of the MIT licence, same for GPL-licenced works)
> Generated javadoc JARs contain jQuery and other MIT-licenced works without
> reproducing a copy of the MIT licence, same for GPL-licenced works
> -
>
> Key: MJAVADOC-669
> URL: https://issues.apache.org/jira/browse/MJAVADOC-669
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0
>Reporter: Thorsten Glaser
>Priority: Blocker
> Labels: legal, licensing
>
> A sources JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
> components under the MIT licence:
> * jQuery 3.5.1
> ** {{jquery/external/jquery/jquery.js}}
> ** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
> archive size of the JAR, why is it included like this?)
> * JSZip 3.2.1
> ** {{jquery/jszip/dist/jszip.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
> ** {{jquery/jszip-utils/dist/jszip-utils.js}}{{}}
> * jQuery UI 1.12.1
> ** {{jquery/jquery-ui.css}}
> ** {{jquery/jquery-ui.js}}
> ** {{jquery/jquery-ui.structure.css}}
> * and their respective minified versions
> It also contains {{script.js}} and {{search.js}} which are
> GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle
> in the LICENSE file that accompanied this code” but no such file accompanies
> said code.
> There are also multiple static {{resources}} and {{jquery/images}} whose
> licence is not documented.
> The MIT licence specifically *requires* that “The […] copyright notice and
> this permission notice [the licence body] shall be included in all copies or
> substantial portions of the Software.” The distribution PKZIP archives (JAR
> files) created by the Maven Javadoc Plugin violate this licence, making them
> not redistributable.
> Similarily, the GPLv2 used by the Oracle-provided files *requires* that
> redistributors “give any other recipients of the Program a copy of this
> License along with the Program.” The “if not, write to the Free Software
> Foundation” comment is specifically *not sufficient* for this and only
> provided as fallback should distributors violate this clause, as Maven
> Javadoc Plugin-generated PKZIP archives do. To be effective, the Classpath
> exception must also be provided.
> h2. Suggested fix
> Include the following new files:
> * {{jquery/LICENCE}} containing the MIT licence and all respective copyright
> notices for the various jQuery-related projects (including those _they_
> include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
> widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
> * {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
> exception as provided by Oracle
> * {{COPYING}} or {{js/COPYING}} (this being the customary name for this
> file) containing the verbatim text of the GNU GPL version 2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MJAVADOC-669) Generated sources JARs contain jQuery and other MIT-licenced works without reproducing a copy of the MIT licence, same for GPL-licenced works
Thorsten Glaser created MJAVADOC-669:
Summary: Generated sources JARs contain jQuery and other
MIT-licenced works without reproducing a copy of the MIT licence, same for
GPL-licenced works
Key: MJAVADOC-669
URL: https://issues.apache.org/jira/browse/MJAVADOC-669
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.2.0
Reporter: Thorsten Glaser
A sources JAR generated by the Maven Javadoc Plugin 3.2.0 contains multiple
components under the MIT licence:
* jQuery 3.5.1
** {{jquery/external/jquery/jquery.js}}
** {{jquery/jquery-3.5.1.js}} (duplicate of the above, blowing up the PKZIP
archive size of the JAR, why is it included like this?)
* JSZip 3.2.1
** {{jquery/jszip/dist/jszip.js}}
** {{jquery/jszip-utils/dist/jszip-utils-ie.js}}
** {{jquery/jszip-utils/dist/jszip-utils.js}}{{}}
* jQuery UI 1.12.1
** {{jquery/jquery-ui.css}}
** {{jquery/jquery-ui.js}}
** {{jquery/jquery-ui.structure.css}}
* and their respective minified versions
It also contains {{script.js}} and {{search.js}} which are
GPLv2-with-Classpath-exception-licenced and refer to “as provided by Oracle in
the LICENSE file that accompanied this code” but no such file accompanies said
code.
There are also multiple static {{resources}} and {{jquery/images}} whose
licence is not documented.
The MIT licence specifically *requires* that “The […] copyright notice and this
permission notice [the licence body] shall be included in all copies or
substantial portions of the Software.” The distribution PKZIP archives (JAR
files) created by the Maven Javadoc Plugin violate this licence, making them
not redistributable.
Similarily, the GPLv2 used by the Oracle-provided files *requires* that
redistributors “give any other recipients of the Program a copy of this License
along with the Program.” The “if not, write to the Free Software Foundation”
comment is specifically *not sufficient* for this and only provided as fallback
should distributors violate this clause, as Maven Javadoc Plugin-generated
PKZIP archives do. To be effective, the Classpath exception must also be
provided.
h2. Suggested fix
Include the following new files:
* {{jquery/LICENCE}} containing the MIT licence and all respective copyright
notices for the various jQuery-related projects (including those _they_
include, i.e. Sizzle, widget.js, position.js, keycode.js, unique-id.js,
widgets/autocomplete.js, widgets/menu.js, pako, and possibly others)
* {{js/LICENSE}} (creating a new subdirectory) containing the Classpath
exception as provided by Oracle
* {{COPYING}} or {{js/COPYING}} (this being the customary name for this file)
containing the verbatim text of the GNU GPL version 2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220815#comment-17220815
]
Thorsten Glaser commented on MRESOURCES-237:
[~j...@iname.com]that’s almost certainly an unrelated bug in the handling of
copying of symlinks; I’d report it as new issue. (I think something like if
(source exists && source is symlink) must be changed to if (source exists ||
source is symlink) to fix that; “exists” tests dereference symlinks, hence the
extra test.)
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17175613#comment-17175613
]
Thorsten Glaser commented on MRESOURCES-237:
I don’t know what an IT test is, but if you want a reproducer… attached:
[^a.tgz]
Run as {{mvn clean compile}} for m-r-p 2.6, or with {{mvn clean compile
-Dmaven.resources.version=3.1.0}} to test the version I have issues with
(“expected” vs. “actual”).
Note that the “actual” was requested in MRESOURCES-212 so we’ll most likely
need {{mvn clean compile -Dmaven.resources.version=3.3.0 -Dsomething}} to get
the “expected” value.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Glaser updated MRESOURCES-237:
---
Attachment: a.tgz
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171557#comment-17171557
]
Thorsten Glaser commented on MRESOURCES-237:
I see that now even the target milestone 3.2.0 has been removed.
Is this *ever* going to be fixed? This is a *blocker* from upgrading multiple
plugins (war, ear, resources) to their 3.x counterparts (see
[https://repo1.maven.org/maven2/org/evolvis/tartools/maven-parent/1.28/maven-parent-1.28.pom]
)…
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079153#comment-17079153
]
Thorsten Glaser commented on MRESOURCES-237:
A valid usecase for “broken” symlinks in the source that get fixed in the
target are test fixtures, so I wouldn’t discount it completely.
But a parameter is *long* overdue.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.1.1
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6241) colour output cannot be disabled from settings.xml or MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895448#comment-16895448
]
Thorsten Glaser commented on MNG-6241:
--
[~michael-o] not in {{MAVEN_OPTS}}, only as explicit command line argument (and
there, {{-B}} is clearly the better choice).
Ideally, both {{-B}} and {{-Dstyle.color=never}} would have corresponding
{{settings.xml}} equivalents (and the former superset the latter), so one can
easily declare it on a Jenkins system without having to worry about individual
jobs overriding the environment variable.
> colour output cannot be disabled from settings.xml or MAVEN_OPTS
>
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6724) Ability to exchange dependencies
[
https://issues.apache.org/jira/browse/MNG-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895444#comment-16895444
]
Thorsten Glaser commented on MNG-6724:
--
Thanks for the honesty and taking the time to respond.
> Ability to exchange dependencies
>
>
> Key: MNG-6724
> URL: https://issues.apache.org/jira/browse/MNG-6724
> Project: Maven
> Issue Type: New Feature
>Reporter: Thorsten Glaser
>Priority: Minor
>
> Feature Request: I would like to have the explicit ability to exchange
> dependencies globally, such as from dependencyManagement.
> Currently, I can do on a dependency’’s transitive dependency, then
> add an explicit to the POM of my final WAR (and possibly a
> test-scoped one on the JAR it’s in), but that makes the
> maven-dependency-plugin:3.1.1:analyze-only goal complain about a declared but
> unused dependency.
> With the javax.* → jakarta moves (and some others, e.g. I need the
> com.sun.activation version of jakarta.activation instead of the Jakarta one)
> and multiple JAXB implementations around, this is becoming troublesome.
> Therefore, I would like for Maven to allow something like this:
> {code:java}
>
>
>
>
> javax.xml.bind
> jaxb-api
>
>
> jakarta.xml.bind
> jakarta.xml.bind-api
>
>
>
>
>
>
>jakarta.xml.bind
>jakarta.xml.bind-api
>${jaxb-api.version}
>
>
>
>
> {code}
> This would recursively replace the old JAXB-API with the new one but not add
> them where unnecessary, and make the maven-dependency-plugin’s checks do the
> right thing.
> Thanks in advance for consideration!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MNG-6724) Ability to exchange dependencies
[
https://issues.apache.org/jira/browse/MNG-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892060#comment-16892060
]
Thorsten Glaser edited comment on MNG-6724 at 7/24/19 6:17 PM:
---
A substitution XML element must have exactly one exclusion XML element (of
which only groupId and artifactId are used, the others are silently ignored)
and may have one or more dependency XML elements, which are substituted (here,
similarily, only groupId and artifactId are used, the version MUST be set using
dependencyManagement→dependencies→dependency for this artifact). If the
dependency elements are missing, the excluded dependency is globally removed.
was (Author: mirabilos):
A substitution XML element must have exactly one exclusion XML element (of
which only groupId and artifactId are used, the others are silently ignored)
and may have one or more dependency XML elements, which are substituted. If the
dependency elements are missing, the excluded dependency is globally removed.
> Ability to exchange dependencies
>
>
> Key: MNG-6724
> URL: https://issues.apache.org/jira/browse/MNG-6724
> Project: Maven
> Issue Type: New Feature
>Reporter: Thorsten Glaser
>Priority: Minor
>
> Feature Request: I would like to have the explicit ability to exchange
> dependencies globally, such as from dependencyManagement.
> Currently, I can do on a dependency’’s transitive dependency, then
> add an explicit to the POM of my final WAR (and possibly a
> test-scoped one on the JAR it’s in), but that makes the
> maven-dependency-plugin:3.1.1:analyze-only goal complain about a declared but
> unused dependency.
> With the javax.* → jakarta moves (and some others, e.g. I need the
> com.sun.activation version of jakarta.activation instead of the Jakarta one)
> and multiple JAXB implementations around, this is becoming troublesome.
> Therefore, I would like for Maven to allow something like this:
> {code:java}
>
>
>
>
> javax.xml.bind
> jaxb-api
>
>
> jakarta.xml.bind
> jakarta.xml.bind-api
>
>
>
>
>
>
>jakarta.xml.bind
>jakarta.xml.bind-api
>${jaxb-api.version}
>
>
>
>
> {code}
> This would recursively replace the old JAXB-API with the new one but not add
> them where unnecessary, and make the maven-dependency-plugin’s checks do the
> right thing.
> Thanks in advance for consideration!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6724) Ability to exchange dependencies
[
https://issues.apache.org/jira/browse/MNG-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892060#comment-16892060
]
Thorsten Glaser commented on MNG-6724:
--
A substitution XML element must have exactly one exclusion XML element (of
which only groupId and artifactId are used, the others are silently ignored)
and may have one or more dependency XML elements, which are substituted. If the
dependency elements are missing, the excluded dependency is globally removed.
> Ability to exchange dependencies
>
>
> Key: MNG-6724
> URL: https://issues.apache.org/jira/browse/MNG-6724
> Project: Maven
> Issue Type: New Feature
>Reporter: Thorsten Glaser
>Priority: Minor
>
> Feature Request: I would like to have the explicit ability to exchange
> dependencies globally, such as from dependencyManagement.
> Currently, I can do on a dependency’’s transitive dependency, then
> add an explicit to the POM of my final WAR (and possibly a
> test-scoped one on the JAR it’s in), but that makes the
> maven-dependency-plugin:3.1.1:analyze-only goal complain about a declared but
> unused dependency.
> With the javax.* → jakarta moves (and some others, e.g. I need the
> com.sun.activation version of jakarta.activation instead of the Jakarta one)
> and multiple JAXB implementations around, this is becoming troublesome.
> Therefore, I would like for Maven to allow something like this:
> {code:java}
>
>
>
>
> javax.xml.bind
> jaxb-api
>
>
> jakarta.xml.bind
> jakarta.xml.bind-api
>
>
>
>
>
>
>jakarta.xml.bind
>jakarta.xml.bind-api
>${jaxb-api.version}
>
>
>
>
> {code}
> This would recursively replace the old JAXB-API with the new one but not add
> them where unnecessary, and make the maven-dependency-plugin’s checks do the
> right thing.
> Thanks in advance for consideration!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (MNG-6724) Ability to exchange dependencies
Thorsten Glaser created MNG-6724:
Summary: Ability to exchange dependencies
Key: MNG-6724
URL: https://issues.apache.org/jira/browse/MNG-6724
Project: Maven
Issue Type: New Feature
Reporter: Thorsten Glaser
Feature Request: I would like to have the explicit ability to exchange
dependencies globally, such as from dependencyManagement.
Currently, I can do on a dependency’’s transitive dependency, then
add an explicit to the POM of my final WAR (and possibly a
test-scoped one on the JAR it’s in), but that makes the
maven-dependency-plugin:3.1.1:analyze-only goal complain about a declared but
unused dependency.
With the javax.* → jakarta moves (and some others, e.g. I need the
com.sun.activation version of jakarta.activation instead of the Jakarta one)
and multiple JAXB implementations around, this is becoming troublesome.
Therefore, I would like for Maven to allow something like this:
{code:java}
javax.xml.bind
jaxb-api
jakarta.xml.bind
jakarta.xml.bind-api
jakarta.xml.bind
jakarta.xml.bind-api
${jaxb-api.version}
{code}
This would recursively replace the old JAXB-API with the new one but not add
them where unnecessary, and make the maven-dependency-plugin’s checks do the
right thing.
Thanks in advance for consideration!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing
[
https://issues.apache.org/jira/browse/MJAVADOC-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16705967#comment-16705967
]
Thorsten Glaser commented on MJAVADOC-523:
--
Please reopen!
{color:#FF}This is a *compile-time* dependency, *not* a run-time
resource{color}. It is actually baked into the WAR because parts of the backend
operation use it, and for this, we need it available during the compile phase
(package is too late).
> Exclude non-Java JARs from Maven Javadoc plugin processing
> --
>
> Key: MJAVADOC-523
> URL: https://issues.apache.org/jira/browse/MJAVADOC-523
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.8
>Reporter: Thorsten Glaser
>Assignee: Robert Scholte
>Priority: Minor
>
> I have a multi-module project which builds a couple of JARs and then
> distributed them into two WARs.
> However, one of the JARs does not contain any Java code at all, merely
> (maven-filtered) resources. This leads to warnings during the build like
> these:
> {noformat}[…]
> [INFO] — maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services —
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc'
> has not been previously called for the module:
> 'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...
> [WARNING] Creating fake javadoc directory to prevent repeated invocations:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
> [ERROR] Error fetching link:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
> Ignored it.
> [INFO]
> Loading source files for package de.tarent.foo.rest.transformation...
> […]{noformat}
> I found how I can exclude javadoc stuff by package, but not by artifact.
> The plugin is currently included ONLY in the parent POM, like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.8
>
>
> attach-javadocs
>
> jar
>
>
>
>
> {code}
> While it _is_ run during “compilation” of the resources-only JAR, it
> (obviously) produces no result, thus the warning (as it’s not excluded
> either).
> How can I either make it produce something (i.e. the ability to create a
> valid-looking yet contentless FOO-javadoc.jar that satisfies references by
> reverse dependencies, in a JAR not containing any Java™ code) or, probably
> preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc
> on modules depending on it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
[
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704866#comment-16704866
]
Thorsten Glaser commented on SUREFIRE-1588:
---
[~jgl...@netbeans.org] don’t rely on that.
The newer versions of OpenJDK just have the new stricter check disabled *by
default* but the code still exists, and we can expect it to eventually be
enabled by default again, probably when not so much stuff will be breaking.
So, a fix of the underlying issue in surefire-maven-plugin would still be very
much welcome, but is not as urgent any more.
> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that
> all the entries from the surefire JAR are simply ignored.
>
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing
[
https://issues.apache.org/jira/browse/MJAVADOC-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700745#comment-16700745
]
Thorsten Glaser commented on MJAVADOC-523:
--
Thanks for the workaround, it at least gets rid of several yellow and red lines
in my Jenkins output, making it more manageable. I’d still prefer a proper fix
of course, and I don’t know how this can negatively affect documentation.
Perhaps an invocation to build a dummy javadoc could be added to the non-Java
modules, if the plugin supports such… it’s easy enough to run it after all.
Even better would be if it could do that automatically, if invoked in a project
without Java files, *and* skip attaching the dummy javadoc, use it only to
satisfy resolution.
> Exclude non-Java JARs from Maven Javadoc plugin processing
> --
>
> Key: MJAVADOC-523
> URL: https://issues.apache.org/jira/browse/MJAVADOC-523
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.8
>Reporter: Thorsten Glaser
>Priority: Minor
>
> I have a multi-module project which builds a couple of JARs and then
> distributed them into two WARs.
> However, one of the JARs does not contain any Java code at all, merely
> (maven-filtered) resources. This leads to warnings during the build like
> these:
> {{[…]
> [INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc'
> has not been previously called for the module:
> 'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...
> [WARNING] Creating fake javadoc directory to prevent repeated invocations:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
> [ERROR] Error fetching link:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
> Ignored it.
> [INFO]
> Loading source files for package de.tarent.foo.rest.transformation...
> […]}}
> I found how I can exclude javadoc stuff by package, but not by artifact.
> The plugin is currently included ONLY in the parent POM, like this:
> {{org.apache.maven.pluginsmaven-javadoc-plugin2.8attach-javadocsjar}}
> While it _is_ run during “compilation” of the resources-only JAR, it
> (obviously) produces no result, thus the warning (as it’s not excluded
> either).
> How can I either make it produce something (i.e. the ability to create a
> valid-looking yet contentless FOO-javadoc.jar that satisfies references by
> reverse dependencies, in a JAR not containing any Java™ code) or, probably
> preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc
> on modules depending on it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
[
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670325#comment-16670325
]
Thorsten Glaser commented on SUREFIRE-1588:
---
Erm, can’t you please release a 2.x with the fix, as this is really important
{color:#FF}RIGHT NOW{color}?
We can upgrade to an incompatible 3.x later, but we’ll not use a -Mxxx
milestone snapshot in production, and who knows what other incompatibilities
3.x will have.
(As for making it Java 7+ that’s no problem, we got even the slowest and most
conservative of customers to upgrade to Java 7 years ago, and almost all to
Java 8 even, years ago even.)
> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that
> all the entries from the surefire JAR are simply ignored.
>
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1588) Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu Java8
[
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670083#comment-16670083
]
Thorsten Glaser commented on SUREFIRE-1588:
---
This is apparently a bug in the Debian package, in that they did not backport
the patch that disables these new stricter checks by default:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#38
There’s a workaround, but that involves either touching the POM of *every*
project one develops with manually to set useSystemClassLoader=false for
Surefire (and I’m not sure what other implications this has)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#10 or, worse, setting
a JVM property (I’m not sure where to even begin doing so, considering java is
invoked indirectly under a bazillion layers, from Jenkins over Maven to its
plugins…) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#29
Considering this is supposed to be a new stricter check for something, is there
a way we can get a new Surefire release that adheres to these stricter
standards? The Canonical/Debian people are, unfortunately, unwilling to
consider a full development showstopper as bug and consider it a “security
feature” and an “intentional upstream change” instead:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912333#53
For now, general advice is to downgrade to the last working OpenJDK version in
a development environment (and yes, thus not getting the latest security fixes,
which is extremely unfortunate) until the OpenJDK, Canonical/Debian, and
Maven/Surefire people “fight” this out among themselves. (And who knows what
*else* will break due to this change… there’s not even a warning output!)
> Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu
> Java8
>
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that
> all the entries from the surefire JAR are simply ignored.
>
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638699#comment-16638699
]
Thorsten Glaser commented on MRESOURCES-237:
Then, a new version which has a boolean parameter keepSymlinks or something
like that would be welcome. As I said, I’d have preferred a default of false,
but a default of true is ok as long as I can change this… I see now that newer
maven-ear-plugin versions use maven-resources-plugin 3.x so this has become
somewhat of a blocker of updating other plugins.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613650#comment-16613650
]
Thorsten Glaser commented on MRESOURCES-237:
“So there should be no need having symlinks inside a jar file”
Exactly. Which is why I require the 2.x behaviour of *following* symlinks
instead of *preserving* them during copy.
However, *other* people wish to have symlinks kept. That’s why I argue in
favour of an option.
“The question is why a shell script is packaged into a WAR file?” I never said
that. (There’s other stuff packaged into a WAR, which makes perfect sense in
our environment though. I can’t disclose details.)
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOURCES-212) maven resource plugin does not preserve symlinks
[ https://issues.apache.org/jira/browse/MRESOURCES-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613584#comment-16613584 ] Thorsten Glaser commented on MRESOURCES-212: Version 3.x *do* preserve symlinks, leading to the new bug: https://issues.apache.org/jira/browse/MRESOURCES-237 > maven resource plugin does not preserve symlinks > > > Key: MRESOURCES-212 > URL: https://issues.apache.org/jira/browse/MRESOURCES-212 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 2.7 >Reporter: Sachin Ramchandra Kothe >Priority: Minor > > If we have a symlinks under src/main/resources. Maven resources plugin does > not preserve the symlinks and just copies the files. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613582#comment-16613582
]
Thorsten Glaser commented on MRESOURCES-237:
+1, I just lost about two hours debugging an application initialisation failure
because a file was not copied to a JAR inside a WAR… turns out that an upgrade
of maven-resources-plugin in the parent POM (from 2.6 to 3.0.2… I wonder if we
should go to 3.1.0 even) broke this: the symlink (instead of its target, as
before) is copied from {{src/main/resources/FOO}} to {{target/classes/FOO}}
breaking relative link targets, and then it’s omitted from the JAR because it’s
a broken symlink. (In my scenario, this does not affect tests, and the symlink
is necessary, since it’s a multi-language project, with Java™, JavaScript,
shell and other parts.)
Given MRESOURCES-212 “maven resource plugin does not preserve symlinks” I think
that, while ① there _should_ be a +configuration option whether to copy
symlinks as symlinks or to follow them+, ② this configuration option *MUST*
+default to follow them+, to *not break pre-existing behaviour*.
Please fix this quickly. I think we’ll lower the version to 2.7 in the
meantime, assuming that fixes it.
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Priority: Minor
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing
[
https://issues.apache.org/jira/browse/MJAVADOC-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437765#comment-16437765
]
Thorsten Glaser commented on MJAVADOC-523:
--
Actually, I have *two* cases in which this occurs; one is a JAR without Java™
code, the other even has…
{{ pom}}
…so I cannot even use the workaround to add one dummy class into it.
> Exclude non-Java JARs from Maven Javadoc plugin processing
> --
>
> Key: MJAVADOC-523
> URL: https://issues.apache.org/jira/browse/MJAVADOC-523
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.8
>Reporter: Thorsten Glaser
>Priority: Minor
>
> I have a multi-module project which builds a couple of JARs and then
> distributed them into two WARs.
> However, one of the JARs does not contain any Java code at all, merely
> (maven-filtered) resources. This leads to warnings during the build like
> these:
> {{[…]
> [INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc'
> has not been previously called for the module:
> 'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...
> [WARNING] Creating fake javadoc directory to prevent repeated invocations:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
> [ERROR] Error fetching link:
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
> Ignored it.
> [INFO]
> Loading source files for package de.tarent.foo.rest.transformation...
> […]}}
> I found how I can exclude javadoc stuff by package, but not by artifact.
> The plugin is currently included ONLY in the parent POM, like this:
> {{org.apache.maven.pluginsmaven-javadoc-plugin2.8attach-javadocsjar}}
> While it _is_ run during “compilation” of the resources-only JAR, it
> (obviously) produces no result, thus the warning (as it’s not excluded
> either).
> How can I either make it produce something (i.e. the ability to create a
> valid-looking yet contentless FOO-javadoc.jar that satisfies references by
> reverse dependencies, in a JAR not containing any Java™ code) or, probably
> preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc
> on modules depending on it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing
Thorsten Glaser created MJAVADOC-523:
Summary: Exclude non-Java JARs from Maven Javadoc plugin processing
Key: MJAVADOC-523
URL: https://issues.apache.org/jira/browse/MJAVADOC-523
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 2.8
Reporter: Thorsten Glaser
I have a multi-module project which builds a couple of JARs and then
distributed them into two WARs.
However, one of the JARs does not contain any Java code at all, merely
(maven-filtered) resources. This leads to warnings during the build like these:
{{[…]
[INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services ---
[INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc' has
not been previously called for the module:
'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...
[WARNING] Creating fake javadoc directory to prevent repeated invocations:
/var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
[ERROR] Error fetching link:
/var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
Ignored it.
[INFO]
Loading source files for package de.tarent.foo.rest.transformation...
[…]}}
I found how I can exclude javadoc stuff by package, but not by artifact.
The plugin is currently included ONLY in the parent POM, like this:
{{org.apache.maven.pluginsmaven-javadoc-plugin2.8attach-javadocsjar}}
While it _is_ run during “compilation” of the resources-only JAR, it
(obviously) produces no result, thus the warning (as it’s not excluded either).
How can I either make it produce something (i.e. the ability to create a
valid-looking yet contentless FOO-javadoc.jar that satisfies references by
reverse dependencies, in a JAR not containing any Java™ code) or, probably
preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc on
modules depending on it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-799) update-versions fails when the project artifact is used with a version other than the current snapshot
[
https://issues.apache.org/jira/browse/MRELEASE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412317#comment-16412317
]
Thorsten Glaser commented on MRELEASE-799:
--
This still happens with 2.5.3
A workaround is to use ${project.version} instead of ${releaseVersion} in the
version tag of the dependency.
> update-versions fails when the project artifact is used with a version other
> than the current snapshot
> --
>
> Key: MRELEASE-799
> URL: https://issues.apache.org/jira/browse/MRELEASE-799
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: update-versions
>Affects Versions: 2.3.2
> Environment: maven 2.2.1, maven 3.0.3
>Reporter: Péter Miklós
>Priority: Major
>
> If a maven project uses its own artifact eg. as a dependency of a plugin with
> a version other than the current snapshot then release:update-versions will
> fail with an error like this:
> bq. The artifact (com.example:test) requires a different version (3.1.50)
> than what is found (3.1.49) for the expression (lastReleasedProjectVersion)
> in the project (com.example:test)
> Basically, the latest release of the same artifact is used for some sort of
> regression testing and it seems that the update-versions, after moving to the
> next release version from snapshot, notices that there is a discrepancy
> between the new release version and the version used as a plugin dependency.
> This error popped up when I started to use release plugin 2.2.2 and as a
> result of MRELEASE-412 the properties used in the version tag are also
> updated.
> I think the update-versions should remember which artifacts have been updated
> from snapshot to the new release version, and then check those only.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6241) colour output cannot be disabled from settings.xml or MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057930#comment-16057930
]
Thorsten Glaser commented on MNG-6241:
--
To add insult to injury, the 「MessageUtils.setColorEnabled(false);」 call is
only in the CLI, meaning everything that calls Maven via something else (like
Jenkins) must change their own code as well (like
maven35-interceptor/src/main/java/org/apache/maven/cli/DefaultMavenExecutionRequestBuilder.java
in Jenkins).
Centralised parsing of a settings.xml entry and an environment variable (or
even a JVM -Doption) would certainly help here.
> colour output cannot be disabled from settings.xml or MAVEN_OPTS
>
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6241) colour output cannot be disabled from settings.xml or MAVEN_OPTS
Thorsten Glaser created MNG-6241:
Summary: colour output cannot be disabled from settings.xml or
MAVEN_OPTS
Key: MNG-6241
URL: https://issues.apache.org/jira/browse/MNG-6241
Project: Maven
Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Thorsten Glaser
Coloured output does not look very nice in a Jenkins logfile *and* breaks some
plugins we use, therefore I wish to disable it programmatically.
However, looking at the source, I find it can only be disabled by passing the
command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
the environment.
I’ve worked around this by using dpkg-divert to move the mvn binary away and
placing this…
{{{
# cat /usr/share/maven/bin/mvn
#!/bin/mksh-static
exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
}}}
… in its stead, but that’s creepy at best. Please implement a setting, ideally
for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WAGON-426) Fingerprints loss in known_hosts
[
https://issues.apache.org/jira/browse/WAGON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15988768#comment-15988768
]
Thorsten Glaser commented on WAGON-426:
---
Or, as a workaround, put this…
{code}
Host *
VisualHostKey no
HashKnownHosts no
HostKeyAlgorithms ssh-rsa
{code}
… in /etc/ssh/ssh_config right from the start.
It’s better anyway, IMHO.
> Fingerprints loss in known_hosts
>
>
> Key: WAGON-426
> URL: https://issues.apache.org/jira/browse/WAGON-426
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 2.8
>Reporter: Maxime Robert
>Assignee: Dan Tran
>Priority: Critical
> Fix For: 2.12
>
>
> Currently, when adding new fingerprints the whole known_hosts file is
> rewritten from the loaded fingerprints.
> But only fingerprints with a compatible algorithm (from jsch point of view)
> are kept: for example, all "ecdsa-sha2-nistp256" are lost!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] Commented: (MSITE-374) Unable to upload to the site using sftp
[ http://jira.codehaus.org/browse/MSITE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=260005#action_260005 ] Thorsten Glaser commented on MSITE-374: --- +1, high urgency We can deploy to our server with sftp the build result but not the documentation. In the Jenkins build logs it shows that it hangs at this point: [JENKINS] Archiving site from /var/lib/hudson/jobs/(jobname)/workspace/target/site to /var/lib/hudson/jobs/(jobname)/site [INFO] [site:deploy] Using private key: /var/lib/hudson/.ssh/id_rsa sftp://(servername)/var/www/maven_repo/sites - Session: Opened Executing command: mkdir -p /var/www/maven_repo/sites/. Then nothing. On the server side, I just see an open PAM session with no activity. I suspect the mkdir call may be faulty, SFTP doesnt allow shell commands. Unable to upload to the site using sftp --- Key: MSITE-374 URL: http://jira.codehaus.org/browse/MSITE-374 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.0-beta-7 Environment: Windows visa professionnal french eclipse plugin Reporter: Jean-Philippe Gravel Unable to connect to remote repository using sftp or scp. Conecting to shell.sourceforge.net. Tried to connect using Putty before the using mvn site:deploy without success. Tried to connect using ssh in Cygwin and then copied the file known_hosts to C:\Users\jpgravel\.ssh without success too. * Note that my private key have been exported to the OpenSSH format using Putty. The following error occurs: Using private key: C:\Users\jpgravel\.ssh\sourceforge_priv sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: Disconnecting sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: Disconnected [ERROR] The following mojo encountered an error while executing: Group-Id: org.apache.maven.plugins Artifact-Id: maven-site-plugin Version: 2.0-beta-7 Mojo: deploy brought in via: Direct invocation While building project: Group-Id: net.sf.btb Artifact-Id: bridge Version: 1.1.0 From file: C:\Users\jpgravel\workspace\java\BridgeToBabylon\pom.xml Reason: Error uploading site When run wih -e I get the following exception: org.apache.maven.wagon.providers.ssh.knownhost.UnknownHostException: The host was not known and was not accepted by the configuration: web.sourceforge.net at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:178) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) at org.apache.maven.cli.MavenCli.main(MavenCli.java:52) Caused by: com.jcraft.jsch.JSchException: reject HostKey: web.sourceforge.net at com.jcraft.jsch.Session.checkHost(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) ... 17 more Error stacktrace: org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:deploy': Mojo execution failed. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505) at
