[GitHub] [maven-indexer] dependabot[bot] opened a new pull request #71: Bump junit from 4.13 to 4.13.1
dependabot[bot] opened a new pull request #71: URL: https://github.com/apache/maven-indexer/pull/71 Bumps [junit](https://github.com/junit-team/junit4) from 4.13 to 4.13.1. Release notes Sourced from https://github.com/junit-team/junit4/releases;>junit's releases. JUnit 4.13.1 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.1.md;>release notes for details. Changelog Sourced from https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.1.md;>junit's changelog. Summary of changes in version 4.13.1 Rules Security fix: TemporaryFolder now limits access to temporary folders on Java 1.7 or later A local information disclosure vulnerability in TemporaryFolder has been fixed. See the published https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp;>security advisory for details. Test Runners [Pull request https://github-redirect.dependabot.com/junit-team/junit4/issues/1669;>#1669:](https://github-redirect.dependabot.com/junit-team/junit/pull/1669;>junit-team/junit#1669) Make FrameworkField constructor public Prior to this change, custom runners could make FrameworkMethod instances, but not FrameworkField instances. This small change allows for both now, because FrameworkField's constructor has been promoted from package-private to public. Commits https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66;>1b683f4 [maven-release-plugin] prepare release r4.13.1 https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2;>ce6ce3a Draft 4.13.1 release notes https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24;>c29dd82 Change version to 4.13.1-SNAPSHOT https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567;>1d17486 Add a link to assertThrows in exception testing https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9;>543905d Use separate line for annotation in Javadoc https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944;>510e906 Add sub headlines to class Javadoc https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae;>610155b Merge pull request from GHSA-269g-pwp5-87pp https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec;>b6cfd1e Explicitly wrap float parameter for consistency (https://github-redirect.dependabot.com/junit-team/junit4/issues/1671;>#1671) https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646;>a5d205c Fix GitHub link in FAQ (https://github-redirect.dependabot.com/junit-team/junit4/issues/1672;>#1672) https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8;>3a5c6b4 Deprecated since jdk9 replacing constructor instance of Double and Float (https://github-redirect.dependabot.com/junit-team/junit4/issues/1660;>#1660) Additional commits viewable in https://github.com/junit-team/junit4/compare/r4.13...r4.13.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
[GitHub] [maven-dependency-plugin] dependabot[bot] opened a new pull request #111: Bump plexus-archiver from 4.2.2 to 4.2.3
dependabot[bot] opened a new pull request #111: URL: https://github.com/apache/maven-dependency-plugin/pull/111 Bumps [plexus-archiver](https://github.com/codehaus-plexus/plexus-archiver) from 4.2.2 to 4.2.3. Commits https://github.com/codehaus-plexus/plexus-archiver/commit/78e890e3f297a7f812c46617bb3da4e6a5eb886c;>78e890e Merge branch 'master' of https://github.com/codehaus-plexus/plexus-archiver;>https://github.com/codehaus-plexus/plexus-archiver https://github.com/codehaus-plexus/plexus-archiver/commit/6ee0828d510dbebfa121bca9bf95ca1afad802e8;>6ee0828 [maven-release-plugin] prepare release plexus-archiver-4.2.3 https://github.com/codehaus-plexus/plexus-archiver/commit/efd980ddaf3d98ebb19e06805258f9f978c9ebc1;>efd980d [MDEP-651] Warn on duplicate archive entries (https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/128;>#128) https://github.com/codehaus-plexus/plexus-archiver/commit/36bf6bcb7d741b7a05e0470364e2e707e61dc578;>36bf6bc Merge pull request https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/151;>#151 from codehaus-plexus/dependabot/maven/junit-junit-4.13.1 https://github.com/codehaus-plexus/plexus-archiver/commit/0435a9cf1df0f20255e04454d2165b474bf50955;>0435a9c Merge pull request https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/152;>#152 from codehaus-plexus/dependabot/github_actions/action... https://github.com/codehaus-plexus/plexus-archiver/commit/87b7d7ef06214ed25e2aa0ba1cf36668b0095ef0;>87b7d7e Bump actions/cache from v2.1.1 to v2.1.2 https://github.com/codehaus-plexus/plexus-archiver/commit/5b0c74873d7660d9266bf1bd655d58d4f5e70187;>5b0c748 Bump junit from 4.13 to 4.13.1 https://github.com/codehaus-plexus/plexus-archiver/commit/73ee0482c5d99ac10fb8fa6cd81548528472f699;>73ee048 File#lastModified on Linux JDK8 loses milliseconds precision (JDK-8177809) https://github.com/codehaus-plexus/plexus-archiver/commit/e55f320f190bc5fe2b1029c4fd8bb3e294a299bc;>e55f320 File#lastModified on Linux JDK8 loses milliseconds precision (JDK-8177809). https://github.com/codehaus-plexus/plexus-archiver/commit/b579cb12284379a881f0560e235a393ad378dabb;>b579cb1 Merge pull request https://github-redirect.dependabot.com/codehaus-plexus/plexus-archiver/issues/147;>#147 from codehaus-plexus/dependabot/github_actions/action... Additional commits viewable in https://github.com/codehaus-plexus/plexus-archiver/compare/plexus-archiver-4.2.2...plexus-archiver-4.2.3;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1853: --- Component/s: Maven Surefire Plugin Maven Failsafe Plugin > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Gili >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1853. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=4ded070ea82076441120ff1cf0baaae7f4a47554 > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 merged pull request #322: Clarified the documentation for useModulePath
Tibor17 merged pull request #322: URL: https://github.com/apache/maven-surefire/pull/322 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #322: Clarified the documentation for useModulePath
Tibor17 commented on pull request #322: URL: https://github.com/apache/maven-surefire/pull/322#issuecomment-707437763 @cowwoc Thx for contributing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1853: --- Fix Version/s: 3.0.0-M6 > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1853: -- Assignee: Tibor Digana > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Assignee: Tibor Digana >Priority: Major > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212773#comment-17212773 ] Igor Fedorenko commented on MNG-6995: - Core Extensions are discovered and loaded very early during the build, before Maven reads any projects files, iirc. This gives Core Extensions same capabilities (mostly) as if they were part of Maven installation, but also means Core Extensions resolution and instantiation cannot rely on anything in pom.xml. Core Extensions are global to the build, and aggregator project can conceivably include modules with mutually exclusive extensions. Hope this helps. > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: New Feature > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will currently be ignored. Only extensions defined in same directory as the > aggregator pom will be used and those extensions will not be invoked for the > modules, only for the aggregator itself. > Ideally modules should build with whatever core extensions they have defined. > Building a module as part of an aggregator should behave not differently than > building the module standalone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212754#comment-17212754 ] Gili commented on SUREFIRE-1853: Fixed by https://github.com/apache/maven-surefire/pull/322/ > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Priority: Major > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212742#comment-17212742
]
mike duigou commented on MNG-6135:
--
Why was this never cherry picked back in to maven master from the abandoned
3.4.0 branch?
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.7.x-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] cowwoc commented on pull request #322: Clarified the documentation for useModulePath
cowwoc commented on pull request #322: URL: https://github.com/apache/maven-surefire/pull/322#issuecomment-707397778 @Tibor17 I think I finally managed to clean up the PR. Let me know if you notice any other problems :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] cowwoc opened a new pull request #322: Clarified the documentation for useModulePath
cowwoc opened a new pull request #322: URL: https://github.com/apache/maven-surefire/pull/322 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #321: Clarified documentation for useModulePath
Tibor17 commented on pull request #321: URL: https://github.com/apache/maven-surefire/pull/321#issuecomment-707385843 ok, This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] cowwoc commented on pull request #321: Clarified documentation for useModulePath
cowwoc commented on pull request #321: URL: https://github.com/apache/maven-surefire/pull/321#issuecomment-707385664 @Tibor17 I'll recreate this PR momentarily. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] cowwoc closed pull request #321: Clarified documentation for useModulePath
cowwoc closed pull request #321: URL: https://github.com/apache/maven-surefire/pull/321 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] cowwoc opened a new pull request #321: Clarified documentation for useModulePath
cowwoc opened a new pull request #321: URL: https://github.com/apache/maven-surefire/pull/321 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212700#comment-17212700 ] mike duigou commented on MNG-6995: -- Perhaps [~ifedorenko] can provide some context or history as to why core extensions were supported by only top-level projects in MNG-5771 and some guidance for providing the same capability for modules. > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: New Feature > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will currently be ignored. Only extensions defined in same directory as the > aggregator pom will be used and those extensions will not be invoked for the > modules, only for the aggregator itself. > Ideally modules should build with whatever core extensions they have defined. > Building a module as part of an aggregator should behave not differently than > building the module standalone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5897) Make extensions configurable in a more convenient way.
[
https://issues.apache.org/jira/browse/MNG-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212698#comment-17212698
]
mike duigou commented on MNG-5897:
--
This would be a useful enhancement!
Be aware that more generality of the core extensions mechanism is also needed
to support multi-module and aggregator projects. (See MNG-6995)
> Make extensions configurable in a more convenient way.
> --
>
> Key: MNG-5897
> URL: https://issues.apache.org/jira/browse/MNG-5897
> Project: Maven
> Issue Type: New Feature
> Components: core
>Affects Versions: 3.3.3
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> Currently you can configure using an extensions via {{.mvn/extensions.xml}}
> to load it.
> But at the moment the only possibility to configure your extensions (or
> control behaviour) is via system properties like {{-Dwhatever=...}}.
> It would be convenient to make configuration possible in
> {{.mvn/extensions.xml}} like the plugin configuration are in pom file...
> {code:xml}
> http://maven.apache.org/EXTENSIONS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>
>
>
>
>
>
> ...
>
>
>
> {code}
> with some kind of replacements like in the pom.xml file (like
> {{$\{project.basedir}}} etc.) ?
> This could make the usage of extensions much more convenient...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1743) Allow custom listeners to request stop
[ https://issues.apache.org/jira/browse/SUREFIRE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1743: --- Fix Version/s: 3.0.0-M6 > Allow custom listeners to request stop > -- > > Key: SUREFIRE-1743 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1743 > Project: Maven Surefire > Issue Type: New Feature > Components: documentation, JUnit 5.x support, Maven Failsafe Plugin, > Maven Surefire Plugin >Reporter: Andrew Neeson >Priority: Major > Fix For: 3.0.0-M6 > > > Currently Surefire gives you the ability to [add custom listeners and > reporters|https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_Custom_Listeners_and_Reporters]. > However, those listeners do not have a hook on the Notifier which created > them. > I would like to be able to create listeners which have the ability to request > that the test run is stopped (RunNotifier.pleaseStop) under specific > conditions. These conditions are not currently covered by existing > mechanisms such as > [skipAfterFailure|https://maven.apache.org/surefire/maven-surefire-plugin/examples/skip-after-failure.html]. > Note: I originally considered this as [a change to Cucumber > JVM|https://github.com/cucumber/cucumber-jvm/issues/1854], but I realise that > it's more generic than that (hence this ticket). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1850) Unnecessary dependency incorrectly resolved in certain phases
[ https://issues.apache.org/jira/browse/SUREFIRE-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1850. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git > Unnecessary dependency incorrectly resolved in certain phases > - > > Key: SUREFIRE-1850 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1850 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M3, 3.0.0-M5 >Reporter: Eric Lilja >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.0.0-M6 > > > We had to set up Maven on a system which is completely offline, restricted to > work on a few, select projects. > > During testing, everything initially looked good, we could perform "mvn clean > install" in all projects without issue, and could perform other Maven-task as > well, Intellij was happy, it could resolve all projects fully, run all test > cases etcetera, and did not complain about any missing artifacts. > > However, we noticed we couldn't do "package" or "verify" (which was odd, > since install works, which is a later phase!), because then surefire > (3.0.0-M5) would complain it was missing > org.apache.maven:maven-toolchain:jar:3.0-alpha-2 (or some of its > dependencies, which are quite a few, and all very old, obviously). > > It would be nice if Surefire would not need to resolve this old artifact > (it's from 2009), regardless of phase used > > surefire-3.0.0-M3 also suffers from this issue...2.18.1 does not. Did not try > other versions. > > (description adapted from email sent to maven-dev) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 merged pull request #319: [SUREFIRE-1850] remove maven-toolchain dependency
Tibor17 merged pull request #319: URL: https://github.com/apache/maven-surefire/pull/319 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212630#comment-17212630 ] Tibor Digana edited comment on SUREFIRE-1853 at 10/12/20, 7:43 PM: --- [~cowwoc] you may try to rephrase the text in the documenttaion. The modular path is enabled by default (if module-info.java exists and the JVM is executed by JDK 9+) which is intended. The user can therefore disable the Java Modularity by setting the property to false. was (Author: tibor17): [~cowwoc] you may try to rephrase the text in the documenttaion. The modular path is enabled by default (if module-info.java exists and the JVM is executed by with JDK 9+) which is intended. The user can therefore disable the Java Modularity by setting the property to false. > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Priority: Major > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1853) Clarify useModulePath documentation
[ https://issues.apache.org/jira/browse/SUREFIRE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212630#comment-17212630 ] Tibor Digana commented on SUREFIRE-1853: [~cowwoc] you may try to rephrase the text in the documenttaion. The modular path is enabled by default (if module-info.java exists and the JVM is executed by with JDK 9+) which is intended. The user can therefore disable the Java Modularity by setting the property to false. > Clarify useModulePath documentation > --- > > Key: SUREFIRE-1853 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1853 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Gili >Priority: Major > > https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html states > that useModulePath disables the use of the module path. This contradicts the > option name which implies that a value of true *enables* the use of module > path. > Which is it please? And is the use of module path on by default? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1852) ReporterException: When writing xml report stdout/stderr
[
https://issues.apache.org/jira/browse/SUREFIRE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212627#comment-17212627
]
Tibor Digana commented on SUREFIRE-1852:
Hi [~kgyrtkirk], thank you that you are testing it with the latest version.
> ReporterException: When writing xml report stdout/stderr
>
>
> Key: SUREFIRE-1852
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1852
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Zoltan Haindrich
>Priority: Major
>
> I'm seeing some junit xml errors lately on ci.hive.apache.org (we are using
> 3.0.0-M4)
> jenkins is unable to parse the junit result xml because its not a valid xml.
> I was able to take a look at one of the problematic xmls and it doesn't "end
> well"
> {code}
>
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212607#comment-17212607 ] Gili commented on MCOMPILER-436: The hardest problem to solve is the split packages. The most straightforward way would be to assign each artifact a unique package (e.g. move all packages of sshd-core under org.apache.sshd.core, all packages of sshd-common under org.apache.sshd.common and so on) but this will break backwards compatibility. Another approach would be to merge any artifacts that split a package. This would retain the same package names but the artifacts would change (this would be a lesser breakage of backwards compatibility but might reduce the modularity of the library). There are many possibilities. Once you decide which way you want to proceed, we can move forward. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-707292374 Test failure when building with JDK 11 - refer to https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/19/2/testReport/ - was fixed in e5ea347 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212569#comment-17212569
]
Hudson commented on MEAR-267:
-
Build unstable in Jenkins: Maven » Maven TLP » maven-ear-plugin » 19 #3
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/19/3/
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212564#comment-17212564
]
Marat Abrarov edited comment on MEAR-166 at 10/12/20, 6:15 PM:
---
[~afloom], could you please provide a minimal maven project to reproduce your
use case? It looks like you don't follow
[https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html]
(refer to "the painful part"). I use [this
trick|https://github.com/mabrarov/maven-ear-plugin/blob/ea215eef8ea4cf429a793c29a15b6d48b7fe095c/src/test/resources/projects/project-092/ear/pom.xml#L40]
with {{pom}} to include all dependencies of EAR modules (of
{{eartest:war-sample-two:war}}) into EAR.
was (Author: abrarovm):
[~afloom], could you please provide a minimal maven project to reproduce your
use case? It looks like you don't follow
https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html
(refer to "the painful part").
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212564#comment-17212564 ] Marat Abrarov edited comment on MEAR-166 at 10/12/20, 6:12 PM: --- [~afloom], could you please provide a minimal maven project to reproduce your use case? It looks like you don't follow https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html (refer to "the painful part"). was (Author: abrarovm): [~afloom], could you please provide a minimal maven project to reproduce your use case? > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://issues.apache.org/jira/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > Labels: contributers-welcome > Fix For: more-investigation > > Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff > > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[ https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212564#comment-17212564 ] Marat Abrarov commented on MEAR-166: [~afloom], could you please provide a minimal maven project to reproduce your use case? > 'skinnyWar' doesn't work well with dependencies of type 'ejb' > - > > Key: MEAR-166 > URL: https://issues.apache.org/jira/browse/MEAR-166 > Project: Maven Ear Plugin > Issue Type: New Feature >Affects Versions: 2.8, 2.9 > Environment: many different environments I've verified this on >Reporter: Michal Michalski >Priority: Minor > Labels: contributers-welcome > Fix For: more-investigation > > Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff > > > It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it > does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies > exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic > trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's > dependencies should go to EAR's lib. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-707226752 @elharo, could you please trigger one more Jenkins build? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-707168003 > I just found an error during "dirty" build. Let me try to fix it before proceeding with this PR. That was fixed in f070e47. This PR is ready for testing and review now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212425#comment-17212425
]
Michael Osipov commented on MNG-6604:
-
The branch does not exist anymore and has been merged into master which in turn
has been tagged as 1.6.1 and is on Central.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-287) Failed to create target directory when run without clean
[
https://issues.apache.org/jira/browse/MEAR-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212424#comment-17212424
]
Hudson commented on MEAR-287:
-
Build unstable in Jenkins: Maven » Maven TLP » maven-ear-plugin » 19 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/19/2/
> Failed to create target directory when run without clean
>
>
> Key: MEAR-287
> URL: https://issues.apache.org/jira/browse/MEAR-287
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Mikhail Gavrilov
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.1.1
>
>
> Steps to reproduce:
> # Checkout [https://github.com/mabrarov/dockerfile-test]
> # Set version of maven-ear-plugin in pom.xml to '3.1.0'
> # Execute: {{mvn clean package -Ddocker.skip && mvn package -Ddocker.skip}}
> {code:bash}
> $ git clone --branch develop https://github.com/mabrarov/dockerfile-test.git
> && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip
> ...
> [INFO] --- maven-ear-plugin:3.1.0:ear (default-ear) @ ear ---
> [INFO] Copying artifact [war:org.mabrarov.dockerfile-test:war:1.1.7-SNAPSHOT]
> to [org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war]
> [INFO]
>
> [INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
> [INFO]
> [INFO] dockerfile-test SUCCESS [ 1.728
> s]
> [INFO] war SUCCESS [ 3.652
> s]
> [INFO] ear FAILURE [ 0.371
> s]
> [INFO] base-image . SUCCESS [ 2.297
> s]
> [INFO] hollow-image ... SUCCESS [ 1.152
> s]
> [INFO] app-image .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.011 s (Wall Clock)
> [INFO] Finished at: 2020-10-01T14:34:15+03:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on project
> ear: Failed to create directory
> XXX...\dockerfile-test\ear\target\temp\org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :ear
> {code}
> The same is described
> [here|https://github.com/apache/maven-ear-plugin/pull/15#issuecomment-702158521]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-707152278 I just found an error during "dirty" build. Let me try to fix it before proceeding with this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-common-artifact-filters] elharo opened a new pull request #14: deps: update JUnit
elharo opened a new pull request #14: URL: https://github.com/apache/maven-common-artifact-filters/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-707139419 Merge conflicts were fixed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-common-artifact-filters] elharo merged pull request #13: declare commons-io as a dependency
elharo merged pull request #13: URL: https://github.com/apache/maven-common-artifact-filters/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo merged pull request #21: deps: update JUnit
elharo merged pull request #21: URL: https://github.com/apache/maven-ear-plugin/pull/21 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212371#comment-17212371
]
Martin Todorov commented on MNG-6604:
-
The second link )to MRESOLVER=131) is broken.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-287) Failed to create target directory when run without clean
[
https://issues.apache.org/jira/browse/MEAR-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212354#comment-17212354
]
Hudson commented on MEAR-287:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-ear-plugin » master #35
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/35/
> Failed to create target directory when run without clean
>
>
> Key: MEAR-287
> URL: https://issues.apache.org/jira/browse/MEAR-287
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Mikhail Gavrilov
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.1.1
>
>
> Steps to reproduce:
> # Checkout [https://github.com/mabrarov/dockerfile-test]
> # Set version of maven-ear-plugin in pom.xml to '3.1.0'
> # Execute: {{mvn clean package -Ddocker.skip && mvn package -Ddocker.skip}}
> {code:bash}
> $ git clone --branch develop https://github.com/mabrarov/dockerfile-test.git
> && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip
> ...
> [INFO] --- maven-ear-plugin:3.1.0:ear (default-ear) @ ear ---
> [INFO] Copying artifact [war:org.mabrarov.dockerfile-test:war:1.1.7-SNAPSHOT]
> to [org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war]
> [INFO]
>
> [INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
> [INFO]
> [INFO] dockerfile-test SUCCESS [ 1.728
> s]
> [INFO] war SUCCESS [ 3.652
> s]
> [INFO] ear FAILURE [ 0.371
> s]
> [INFO] base-image . SUCCESS [ 2.297
> s]
> [INFO] hollow-image ... SUCCESS [ 1.152
> s]
> [INFO] app-image .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.011 s (Wall Clock)
> [INFO] Finished at: 2020-10-01T14:34:15+03:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on project
> ear: Failed to create directory
> XXX...\dockerfile-test\ear\target\temp\org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :ear
> {code}
> The same is described
> [here|https://github.com/apache/maven-ear-plugin/pull/15#issuecomment-702158521]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] elharo opened a new pull request #21: deps: update JUnit
elharo opened a new pull request #21: URL: https://github.com/apache/maven-ear-plugin/pull/21 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MEAR-287) Failed to create target directory when run without clean
[
https://issues.apache.org/jira/browse/MEAR-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MEAR-287.
--
> Failed to create target directory when run without clean
>
>
> Key: MEAR-287
> URL: https://issues.apache.org/jira/browse/MEAR-287
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Mikhail Gavrilov
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.1.1
>
>
> Steps to reproduce:
> # Checkout [https://github.com/mabrarov/dockerfile-test]
> # Set version of maven-ear-plugin in pom.xml to '3.1.0'
> # Execute: {{mvn clean package -Ddocker.skip && mvn package -Ddocker.skip}}
> {code:bash}
> $ git clone --branch develop https://github.com/mabrarov/dockerfile-test.git
> && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip
> ...
> [INFO] --- maven-ear-plugin:3.1.0:ear (default-ear) @ ear ---
> [INFO] Copying artifact [war:org.mabrarov.dockerfile-test:war:1.1.7-SNAPSHOT]
> to [org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war]
> [INFO]
>
> [INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
> [INFO]
> [INFO] dockerfile-test SUCCESS [ 1.728
> s]
> [INFO] war SUCCESS [ 3.652
> s]
> [INFO] ear FAILURE [ 0.371
> s]
> [INFO] base-image . SUCCESS [ 2.297
> s]
> [INFO] hollow-image ... SUCCESS [ 1.152
> s]
> [INFO] app-image .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.011 s (Wall Clock)
> [INFO] Finished at: 2020-10-01T14:34:15+03:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on project
> ear: Failed to create directory
> XXX...\dockerfile-test\ear\target\temp\org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :ear
> {code}
> The same is described
> [here|https://github.com/apache/maven-ear-plugin/pull/15#issuecomment-702158521]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MEAR-287) Failed to create target directory when run without clean
[
https://issues.apache.org/jira/browse/MEAR-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MEAR-287.
Resolution: Fixed
> Failed to create target directory when run without clean
>
>
> Key: MEAR-287
> URL: https://issues.apache.org/jira/browse/MEAR-287
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Mikhail Gavrilov
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.1.1
>
>
> Steps to reproduce:
> # Checkout [https://github.com/mabrarov/dockerfile-test]
> # Set version of maven-ear-plugin in pom.xml to '3.1.0'
> # Execute: {{mvn clean package -Ddocker.skip && mvn package -Ddocker.skip}}
> {code:bash}
> $ git clone --branch develop https://github.com/mabrarov/dockerfile-test.git
> && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip && \
> mvn -f dockerfile-test/pom.xml package -Dmaven-ear-plugin.version=3.1.0
> -Ddocker.skip
> ...
> [INFO] --- maven-ear-plugin:3.1.0:ear (default-ear) @ ear ---
> [INFO] Copying artifact [war:org.mabrarov.dockerfile-test:war:1.1.7-SNAPSHOT]
> to [org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war]
> [INFO]
>
> [INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
> [INFO]
> [INFO] dockerfile-test SUCCESS [ 1.728
> s]
> [INFO] war SUCCESS [ 3.652
> s]
> [INFO] ear FAILURE [ 0.371
> s]
> [INFO] base-image . SUCCESS [ 2.297
> s]
> [INFO] hollow-image ... SUCCESS [ 1.152
> s]
> [INFO] app-image .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.011 s (Wall Clock)
> [INFO] Finished at: 2020-10-01T14:34:15+03:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:3.1.0:ear (default-ear) on project
> ear: Failed to create directory
> XXX...\dockerfile-test\ear\target\temp\org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :ear
> {code}
> The same is described
> [here|https://github.com/apache/maven-ear-plugin/pull/15#issuecomment-702158521]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] elharo merged pull request #17: [MEAR-287] Fixed failure when destination directory exists
elharo merged pull request #17: URL: https://github.com/apache/maven-ear-plugin/pull/17 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
elharo commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-707104096 https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/19/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-707097781 > jenkins failed: https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/mear-267/ Looks like issue of Jenkins with checkout of pull request (https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/mear-267/1/console): ```text Fetching without tags Fetching upstream changes from https://gitbox.apache.org/repos/asf/maven-jenkins-lib.git > git fetch --no-tags --force --progress -- https://gitbox.apache.org/repos/asf/maven-jenkins-lib.git +refs/heads/*:refs/remotes/origin/* # timeout=10 Checking out Revision c10869c6952fe48d6d66f394802101bdc6d1a537 (master) > git config core.sparsecheckout # timeout=10 > git checkout -f c10869c6952fe48d6d66f394802101bdc6d1a537 # timeout=10 Commit message: "Restored the full maven version matrix default" First time build. Skipping changelog. > git --version # timeout=10 fatal: bad object 4a8c35fa6acb6a409ac027ebf16ae7f3073a ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on a change in pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#discussion_r503268545 ## File path: src/main/java/org/apache/maven/plugins/ear/EarMojo.java ## @@ -946,4 +946,27 @@ private void deleteOutdatedResources( final Collection outdatedResources } } } + +/** + * Searches for the given JAR module in the list of classpath elements and if found matching returns index of Review comment: Agree and broke into 3 sentences in c6d6d0a This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo commented on pull request #17: [MEAR-287] Fixed failure when destination directory exists
elharo commented on pull request #17: URL: https://github.com/apache/maven-ear-plugin/pull/17#issuecomment-707083686 Trying jenkins again: https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/17/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo commented on a change in pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
elharo commented on a change in pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#discussion_r503248443 ## File path: src/main/java/org/apache/maven/plugins/ear/EarMojo.java ## @@ -946,4 +946,27 @@ private void deleteOutdatedResources( final Collection outdatedResources } } } + +/** + * Searches for the given JAR module in the list of classpath elements and if found matching returns index of Review comment: This comment is a bit hard for me to track. I get it, but I had to read it twice. It would probably be clearer if it were broken up into two or more complete sentences. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-studies] slawekjaranowski commented on pull request #2: Maven sign plugin
slawekjaranowski commented on pull request #2: URL: https://github.com/apache/maven-studies/pull/2#issuecomment-707016968 tests on my fork https://github.com/slawekjaranowski/maven-studies/actions This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-studies] slawekjaranowski commented on a change in pull request #2: Maven sign plugin
slawekjaranowski commented on a change in pull request #2: URL: https://github.com/apache/maven-studies/pull/2#discussion_r503179845 ## File path: src/it/big-artifact/setup.groovy ## @@ -21,7 +21,7 @@ import java.security.SecureRandom */ -def random = new SecureRandom(); +def random = new Random(); Review comment: Probably it depend on OS, jdk version ... it is not important now for me, it it only test preparation, as we can see test pass. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-studies] michael-o commented on a change in pull request #2: Maven sign plugin
michael-o commented on a change in pull request #2: URL: https://github.com/apache/maven-studies/pull/2#discussion_r503149679 ## File path: src/it/big-artifact/setup.groovy ## @@ -21,7 +21,7 @@ import java.security.SecureRandom */ -def random = new SecureRandom(); +def random = new Random(); Review comment: Is this one tied to `/dev/random` or `/dev/urandom`? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] Serranya commented on pull request #59: [ARCHETYPE-606] - There is no way to include .gitignore files for the jar goal
Serranya commented on pull request #59: URL: https://github.com/apache/maven-archetype/pull/59#issuecomment-706988963 I addressed the comments on the code an got the IT working. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCHECKSTYLE-387) Deprecate method setUpCheckstyleClassloader in 3.1.2
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212169#comment-17212169
]
Benjamin Marwell commented on MCHECKSTYLE-387:
--
Hello [~dwelsh]
you are confusing the checkstyle "linked" version of this plugin with the
checkstyle versions you can actually use.
You can always updagrade any time you like.
You can update your checkstyle library anytime you like:
[https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html]
> Deprecate method setUpCheckstyleClassloader in 3.1.2
>
>
> Key: MCHECKSTYLE-387
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-387
> Project: Maven Checkstyle Plugin
> Issue Type: Task
>Affects Versions: 3.1.1
>Reporter: Benjamin Marwell
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Current situation
> In 3.1.1, the PR [https://github.com/apache/maven-checkstyle-plugin/pull/18]
> added a {{try-catch}}-block to the to-be-removed method call
> {{Checker::setClassLoader}}.
> Since users should be encuraged to upgrade and maven-plugin-developers should
> know that this method should be removed some time, a warning is to be issued
> if the method call was successful (i.e. when not entering the catch block).
> h2. Caveat and drawbacks
> * Users will have to update their {{checkstyle.xml}} file because of
> incompatible changes introduced in {{8.24}}.
> * Otherwise the warning might confuse users.
> * Once the method call to {{Checker::setClassLoader}} is removed,
> {{checkstyle}} versions prior to 8.26 (Source:
> [https://checkstyle.org/releasenotes.html#Release_8.26]) cannot be used
> anymore (Source:
> [https://github.com/checkstyle/checkstyle/commit/145160f5e21b80c27dc93a1904fe33b9afd4f212]
> and [https://github.com/checkstyle/checkstyle/issues/3773]). But this issue
> is not about removing this method call any time soon.
> => it will probably work fine for any 8.x version because this method existed
> for a deprecated check only.
> h2. Related issues
> *
> [MCHECKSTYLE-381|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-381]]
> The mentioned previous commit.
> *
> [MCHECKSTYLE-384|[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-384]]:
> Once this maven-checkstyle-plugin updates to checkstyle > 8.24, the default
> installation for users will break existing installations unless users use
> this method of downgrading their checkstyle version:
> [https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html.]
>
> * Also track [https://github.com/checkstyle/checkstyle/issues/7190.] This
> will tell when the checkstyle team removes that method.
> h2. Documentation
> * maven-checkstyle-plugin is compatible with all checkstyle versions by
> functionality.
> * maven-checkstyle-plugin >= 3.1.2 will complain if checkstyle < 8.29 is
> being used, which is the default (since it requires checkstyle 8.19).
> * If we are ever going to remove the method {{Checker::setClassLoader}},
> this means that earlier versions than checkstyle 8.26 are not supported. They
> will probably work just fine, but the method call became a 'real' no-op in
> 8.26. Might be worth documentation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212166#comment-17212166 ] Gili edited comment on MCOMPILER-436 at 10/12/20, 7:04 AM: --- I've lost 5 hours of my life to this issue. I tried: * Adding Automatic-Module-Name to Apache Mina SSH. This caused it to show up as a JPMS module so my applications' module-info could finally refer to it. But I cannot use it because it has a split package problem. * Using --patch-module per https://nipafx.dev/five-command-line-options-hack-java-module-system to add all the packages of org.apache.sshd.common into the org.apache.sshd.core JPMS module but I was never able to get this to work. The compiler keeps on complaining that the org.apache.sshd.core JPMS module does not contain the packages I am trying to add using patch-module. I finally got this working using the workaround described at https://stackoverflow.com/a/53329288/14731 but it's a rather ugly hack. I am hoping to improve upon this. was (Author: cowwoc): I've lost 5 hours of my life to this issue. I've tried: * I added Automatic-Module-Name to Apache Mina SSH. This caused it to show up as a JPMS module so my applications' module-info could finally refer to it. But I cannot use it because it has a split package problem. * I tried using --patch-module per https://nipafx.dev/five-command-line-options-hack-java-module-system to add all the packages of org.apache.sshd.common into the org.apache.sshd.core JPMS module but I was never able to get this to work. The compiler keeps on complaining that the org.apache.sshd.core JPMS module does not contain the packages I am trying to add using patch-module. I finally got this working using the workaround described at https://stackoverflow.com/a/53329288/14731 but it's a rather ugly hack. I am hoping to improve upon this. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212166#comment-17212166 ] Gili commented on MCOMPILER-436: I've lost 5 hours of my life to this issue. I've tried: * I added Automatic-Module-Name to Apache Mina SSH. This caused it to show up as a JPMS module so my applications' module-info could finally refer to it. But I cannot use it because it has a split package problem. * I tried using --patch-module per https://nipafx.dev/five-command-line-options-hack-java-module-system to add all the packages of org.apache.sshd.common into the org.apache.sshd.core JPMS module but I was never able to get this to work. The compiler keeps on complaining that the org.apache.sshd.core JPMS module does not contain the packages I am trying to add using patch-module. I finally got this working using the workaround described at https://stackoverflow.com/a/53329288/14731 but it's a rather ugly hack. I am hoping to improve upon this. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-script-interpreter] olamy merged pull request #31: Bump actions/cache from v2.1.1 to v2.1.2
olamy merged pull request #31: URL: https://github.com/apache/maven-script-interpreter/pull/31 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-script-interpreter] olamy merged pull request #30: Bump junit from 4.13 to 4.13.1
olamy merged pull request #30: URL: https://github.com/apache/maven-script-interpreter/pull/30 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #31: Bump actions/cache from v2.1.1 to v2.1.2
dependabot[bot] opened a new pull request #31: URL: https://github.com/apache/maven-script-interpreter/pull/31 Bumps [actions/cache](https://github.com/actions/cache) from v2.1.1 to v2.1.2. Release notes Sourced from https://github.com/actions/cache/releases;>actions/cache's releases. v2.1.2 Adds input to limit the chunk upload size, useful for self-hosted runners with slower upload speeds No-op when executing on GHES Commits https://github.com/actions/cache/commit/d1255ad9362389eac595a9ae406b8e8cb3331f16;>d1255ad Merge pull request https://github-redirect.dependabot.com/actions/cache/issues/424;>#424 from actions/dhadka/upload-chunk-size https://github.com/actions/cache/commit/68cfb2ccb73b1982be3fa55e3d7c842697d7f1ed;>68cfb2c Add units to description https://github.com/actions/cache/commit/cce3c03a74623545a53c433d301f3f7725c72454;>cce3c03 Add new input to action.yml https://github.com/actions/cache/commit/4bceb75b5b7743784c63c94b81c50a485cbdcda0;>4bceb75 Use parseInt instead of Number to handle empty strings https://github.com/actions/cache/commit/a6f1f4b32eec85780fedc5b354a583e9b2999100;>a6f1f4b Adds input for upload chunk size https://github.com/actions/cache/commit/d606e039ae32f64a8593bf4a37b0bf205c695237;>d606e03 Merge pull request https://github-redirect.dependabot.com/actions/cache/issues/421;>#421 from actions/dhadka/ghes https://github.com/actions/cache/commit/d3e4f218f30bd71a2c29e2b2a1e4f811f4327162;>d3e4f21 Use warning instead of info https://github.com/actions/cache/commit/55a58944386e69f7c5bad52ef43a61c578b6c1c6;>55a5894 Update dist https://github.com/actions/cache/commit/3f6dfcbcc44a8e2fd9e539c1dd15af6559e74ced;>3f6dfcb Merge branch 'main' of http://github.com/actions/cache;>http://github.com/actions/cache into dhadka/ghes https://github.com/actions/cache/commit/0f71d4ac9a7f4c36aba5ac3cfc4567d2d4eae813;>0f71d4a Add tests for isGhes Additional commits viewable in https://github.com/actions/cache/compare/v2.1.1...d1255ad9362389eac595a9ae406b8e8cb3331f16;>compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #30: Bump junit from 4.13 to 4.13.1
dependabot[bot] opened a new pull request #30: URL: https://github.com/apache/maven-script-interpreter/pull/30 Bumps [junit](https://github.com/junit-team/junit4) from 4.13 to 4.13.1. Release notes Sourced from https://github.com/junit-team/junit4/releases;>junit's releases. JUnit 4.13.1 Please refer to the https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md;>release notes for details. Changelog Sourced from https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.1.md;>junit's changelog. Summary of changes in version 4.13.1 Rules Security fix: TemporaryFolder now limits access to temporary folders on Java 1.7 or later A local information disclosure vulnerability in TemporaryFolder has been fixed. See the published https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp;>security advisory for details. Test Runners [Pull request https://github-redirect.dependabot.com/junit-team/junit4/issues/1669;>#1669:](https://github-redirect.dependabot.com/junit-team/junit/pull/1669;>junit-team/junit#1669) Make FrameworkField constructor public Prior to this change, custom runners could make FrameworkMethod instances, but not FrameworkField instances. This small change allows for both now, because FrameworkField's constructor has been promoted from package-private to public. Commits https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66;>1b683f4 [maven-release-plugin] prepare release r4.13.1 https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2;>ce6ce3a Draft 4.13.1 release notes https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24;>c29dd82 Change version to 4.13.1-SNAPSHOT https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567;>1d17486 Add a link to assertThrows in exception testing https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9;>543905d Use separate line for annotation in Javadoc https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944;>510e906 Add sub headlines to class Javadoc https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae;>610155b Merge pull request from GHSA-269g-pwp5-87pp https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec;>b6cfd1e Explicitly wrap float parameter for consistency (https://github-redirect.dependabot.com/junit-team/junit4/issues/1671;>#1671) https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646;>a5d205c Fix GitHub link in FAQ (https://github-redirect.dependabot.com/junit-team/junit4/issues/1672;>#1672) https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8;>3a5c6b4 Deprecated since jdk9 replacing constructor instance of Double and Float (https://github-redirect.dependabot.com/junit-team/junit4/issues/1660;>#1660) Additional commits viewable in https://github.com/junit-team/junit4/compare/r4.13...r4.13.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-studies] slawekjaranowski commented on a change in pull request #2: Maven sign plugin
slawekjaranowski commented on a change in pull request #2: URL: https://github.com/apache/maven-studies/pull/2#discussion_r503058689 ## File path: src/it/big-artifact/setup.groovy ## @@ -0,0 +1,32 @@ +import java.security.SecureRandom + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + * + */ + + +def random = new SecureRandom(); Review comment: ok, I don't see problem here, but change to Random This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-437) Clarify how to use --patch-module
[ https://issues.apache.org/jira/browse/MCOMPILER-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212138#comment-17212138 ] Gili commented on MCOMPILER-437: Per https://issues.apache.org/jira/browse/MCOMPILER-311?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel the documentation seems to be incorrect. The correct syntax is --patch-module=org.apache.sshd.core=sshd-common-2.6.0-SNAPSHOT.jar, sshd-core-2.6.0-SNAPSHOT.jar not: --patch-module org.apache.sshd.core=sshd-common-2.6.0-SNAPSHOT.jar, sshd-core-2.6.0-SNAPSHOT.jar So I am no longer getting the "Can't locate X" error. That said, the resulting module still does not work as expected: package org.apache.sshd.client.config.keys is not visible (package org.apache.sshd.client.config.keys is declared in the unnamed module, but module myapplication does not read it) I expected this to work because my application's module-info.java contains "requires org.apache.sshd.core". The package in question should be coming from the sshd-common JAR file, not from the unnamed module. > Clarify how to use --patch-module > - > > Key: MCOMPILER-437 > URL: https://issues.apache.org/jira/browse/MCOMPILER-437 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > > https://maven.apache.org/plugins/maven-compiler-plugin/examples/jpms_args.html > says that the --patch-module syntax is: > --patch-module =(, )* > But I am unable to get it to work. I always get "Can't locate X". > I couldn't find any integration tests or other example code showing how to > get this to work when the right hand side is meant to be a JAR file. > I am trying to work around split packages in org.apache.sshd:ssh-common and > org.apache.sshd:ssh-core by declaring a single module org.apache.sshd.core > that is meant to contain a merge of the two JAR files. How can I make this > work? > Consider augmenting the documentation and/or adding an integration test to > make this use-case more obvious. Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
