[jira] [Assigned] (MNG-7345) Missing exported packages
[ https://issues.apache.org/jira/browse/MNG-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-7345: Assignee: Guillaume Nodet > Missing exported packages > - > > Key: MNG-7345 > URL: https://issues.apache.org/jira/browse/MNG-7345 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Labels: must-be-in-4.0.0-alpha-1 > Fix For: 4.0.0, 4.0.0-alpha-1, 3.9.0-candidate > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-mvnd] gnodet edited a comment on issue #571: windows11 and mvnd-0.7.1 and JDK 11.0.2
gnodet edited a comment on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1011862265 > > This is very weird as your first report indicates the jansi library cannot be loaded or does not find the `isatty` function, but the second indicates that it works. The `mvnd` invocation always fail and the `jansi` call always work or does it depend on the terminal used (cmd, powershell, git bash, ... )? > > I found that the path containing Chinese was not recognized when `mvnd.exe` started. `mvnd.cmd` can be used normally. > > The scenario I'm using now is to rename `mvnd.exe` to another name (the CMD command will identify the `mvnd` command execution file as `mvnd.exe` based on the environment variable) So the problem is when the `mvnd.exe` is in a directory which contains Chinese characters or when the `pom.xml` is in a directory which contains Chinese characters ? It would be nice to be able to reproduce the problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet edited a comment on issue #571: windows11 and mvnd-0.7.1 and JDK 11.0.2
gnodet edited a comment on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1011862265 > > This is very weird as your first report indicates the jansi library cannot be loaded or does not find the `isatty` function, but the second indicates that it works. The `mvnd` invocation always fail and the `jansi` call always work or does it depend on the terminal used (cmd, powershell, git bash, ... )? > > I found that the path containing Chinese was not recognized when `mvnd.exe` started. `mvnd.cmd` can be used normally. > > The scenario I'm using now is to rename `mvnd.exe` to another name (the CMD command will identify the `mvnd` command execution file as `mvnd.exe` based on the environment variable) So the problem is when the `mvnd.exe` is in a directory which contains Chinese characters or when the `pom.xml` is in a directory which contains Chinese characters ? It would bench to be able to reproduce the problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on issue #571: windows11 and mvnd-0.7.1 and JDK 11.0.2
gnodet commented on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1011862265 > > This is very weird as your first report indicates the jansi library cannot be loaded or does not find the `isatty` function, but the second indicates that it works. The `mvnd` invocation always fail and the `jansi` call always work or does it depend on the terminal used (cmd, powershell, git bash, ... )? > > I found that the path containing Chinese was not recognized when `mvnd.exe` started. `mvnd.cmd` can be used normally. > > The scenario I'm using now is to rename `mvnd.exe` to another name (the CMD command will identify the `mvnd` command execution file as `mvnd.exe` based on the environment variable) So the problem is when the `mvnd.exe` is in a directory which contains Chinese characters or when the `pom.xml` is in a directory which contains Chinese characters ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on a change in pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
slawekjaranowski commented on a change in pull request #440:
URL: https://github.com/apache/maven-surefire/pull/440#discussion_r783682775
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
##
@@ -2289,16 +2321,13 @@ private void maybeAppendList( List base,
List list )
private void checkMethodFilterInIncludesExcludes( Iterable
patterns )
throws MojoFailureException
{
-if ( patterns != null )
+for ( String pattern : patterns )
{
-for ( String pattern : patterns )
+if ( pattern != null && pattern.contains( "#" ) )
{
-if ( pattern != null && pattern.contains( "#" ) )
-{
-throw new MojoFailureException( "Method filter prohibited
in "
-+
"includes|excludes|includesFile|excludesFile parameter: "
-+ pattern );
-}
+throw new MojoFailureException( "Method filter prohibited in "
++ "includes|excludes|includesFile|excludesFile parameter: "
Review comment:
`includesFile|excludesFile` should not be supported?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-mvnd] 710850609 edited a comment on issue #571: windows11 and mvnd-0.7.1 and JDK 11.0.2
710850609 edited a comment on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1011816925 > This is very weird as your first report indicates the jansi library cannot be loaded or does not find the `isatty` function, but the second indicates that it works. The `mvnd` invocation always fail and the `jansi` call always work or does it depend on the terminal used (cmd, powershell, git bash, ... )? I found that the path containing Chinese was not recognized when `mvnd.exe` started. `mvnd.cmd` can be used normally. The scenario I'm using now is to rename `mvnd.exe` to another name (the CMD command will identify the `mvnd` command execution file as `mvnd.exe` based on the environment variable) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] 710850609 edited a comment on issue #571: windows11 and mvnd-0.7.1 and JDK 11.0.2
710850609 edited a comment on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1011816925 > This is very weird as your first report indicates the jansi library cannot be loaded or does not find the `isatty` function, but the second indicates that it works. The `mvnd` invocation always fail and the `jansi` call always work or does it depend on the terminal used (cmd, powershell, git bash, ... )? I found that the path containing Chinese was not recognized when `mvnd.exe` started. `mvnd.cmd` can be used normally. The scenario I'm using now is to rename `mvnd.exe` to another name (the CMD command will identify the `mvnd` command execution file as `mvnd.exe` based on the environment variable. CMD) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] 710850609 edited a comment on issue #571: windows11 and mvnd-0.7.1 and JDK 11.0.2
710850609 edited a comment on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1011816925 > This is very weird as your first report indicates the jansi library cannot be loaded or does not find the `isatty` function, but the second indicates that it works. The `mvnd` invocation always fail and the `jansi` call always work or does it depend on the terminal used (cmd, powershell, git bash, ... )? I found that the mvnd.exe startup did not recognize the path containing Chinese. Use mvnd.cmd to start normally I now use the scheme: rename mvnd.exe (CMD command will identify the MVND command execution file according to the environment variable as mvnd.cmd) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] 710850609 commented on issue #571: windows11 and mvnd-0.7.1 and JDK 11.0.2
710850609 commented on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1011816925 > This is very weird as your first report indicates the jansi library cannot be loaded or does not find the `isatty` function, but the second indicates that it works. The `mvnd` invocation always fail and the `jansi` call always work or does it depend on the terminal used (cmd, powershell, git bash, ... )? I found that the mvnd.exe startup did not recognize the path containing Chinese. Use mvnd. CMD to start normally I now use the scheme: rename mvnd.exe (CMD command will identify the MVND command execution file according to the environment variable as mvnd.cmd) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] dependabot[bot] opened a new pull request #442: Bump maven-invoker-plugin from 3.2.0 to 3.2.2
dependabot[bot] opened a new pull request #442: URL: https://github.com/apache/maven-surefire/pull/442 Bumps [maven-invoker-plugin](https://github.com/apache/maven-invoker-plugin) from 3.2.0 to 3.2.2. Commits https://github.com/apache/maven-invoker-plugin/commit/efe8ee0bc66068da1e4bbb4f80d74c8c0ba6ca4b";>efe8ee0 [maven-release-plugin] prepare release maven-invoker-plugin-3.2.2 https://github.com/apache/maven-invoker-plugin/commit/32eef92a247a12ab1686f0566f04ac53ddeda77d";>32eef92 [MINVOKER-277] Require Maven 3.1.1 https://github.com/apache/maven-invoker-plugin/commit/7fc141894986923dcca022e955bd52a236cb7407";>7fc1418 Bump maven-artifact-transfer from 0.11.0 to 0.13.1 https://github.com/apache/maven-invoker-plugin/commit/f1ea2c657408918b4af3e26a0a30e392376635ff";>f1ea2c6 [MINVOKER-276] Update maven-invoker from 3.0.1 to 3.1.0 https://github.com/apache/maven-invoker-plugin/commit/d2f5cb6bb831eefc51450baa7b981e6139834af3";>d2f5cb6 Bump actions/cache from v2 to v2.1.4 https://github.com/apache/maven-invoker-plugin/commit/9afab19b423494a5b666727a89f015c3fb81b01d";>9afab19 Update maven-site-plugin to 3.9.1 and use Fluido Skin 1.9 https://github.com/apache/maven-invoker-plugin/commit/ebe5c5ae69af7b7b17649a66769aa9d7124cb153";>ebe5c5a [MINVOKER-254] Bump groovy-all from 2.4.20 to 2.4.21 https://github.com/apache/maven-invoker-plugin/commit/bfecb96f148d217d8765fcc6b7644c8fc57d4b24";>bfecb96 [MINVOKER-260] confirm streamLogs by IT tests https://github.com/apache/maven-invoker-plugin/commit/a46bf19905ec0560c3119537836b4391e43f44ee";>a46bf19 [MINVOKER-272] use Java 7 Files.createTempDirectory(...) API https://github.com/apache/maven-invoker-plugin/commit/c18d8e5a7a708abfcf9c11a5caef247e63b4ee38";>c18d8e5 Enable Dependabot v2 Additional commits viewable in https://github.com/apache/maven-invoker-plugin/compare/maven-invoker-plugin-3.2.0...maven-invoker-plugin-3.2.2";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] dependabot[bot] opened a new pull request #441: Bump maven-enforcer-plugin from 3.0.0-M3 to 3.0.0
dependabot[bot] opened a new pull request #441: URL: https://github.com/apache/maven-surefire/pull/441 Bumps [maven-enforcer-plugin](https://github.com/apache/maven-enforcer) from 3.0.0-M3 to 3.0.0. Commits https://github.com/apache/maven-enforcer/commit/b1b22822174bc92857a2e674c9a024035ee6d7cd";>b1b2282 [maven-release-plugin] prepare release enforcer-3.0.0 https://github.com/apache/maven-enforcer/commit/70de3ad6b6cf83505fe049896e37d90ac81e13f3";>70de3ad Lock maven-jxr-plugin https://github.com/apache/maven-enforcer/commit/da3f8886d41522450c4b187a5f3562a4f6309610";>da3f888 Fix JavaDoc and lock sisu-maven-plugin https://github.com/apache/maven-enforcer/commit/014253f19260b04eedccfd00678b2777f93fa4e3";>014253f update CI url https://github.com/apache/maven-enforcer/commit/5409be83dc3b621121e6222ad3830f8e95cf6614";>5409be8 [MENFORCER-211] wildcard ignore in requireReleaseDeps https://github.com/apache/maven-enforcer/commit/335f26e39d1f20e157c46485481e36f858135a14";>335f26e [MENFORCER-364] requireFilesExist rule should be case sensitive https://github.com/apache/maven-enforcer/commit/faaf5c118bd9cda06cecca94ab3f9656c1cb7927";>faaf5c1 [MENFORCER-280] Enforcer dependency convergence stumbles on selenium-java https://github.com/apache/maven-enforcer/commit/ab53fd99607eb36554f2fd3af41847ad9568a5ed";>ab53fd9 [MENFORCER-357] RequirePluginVersions not recognizing versions-from-properties https://github.com/apache/maven-enforcer/commit/1b8ca8f82815ec721e09abbd2330ce315893f2ed";>1b8ca8f [MENFORCER-388] Extends RequirePluginVersions with banMavenDefaults https://github.com/apache/maven-enforcer/commit/ca73329888b925899f4f57419a1d2ed208b1e0c4";>ca73329 [MENFORCER-359] RequirePluginVersions fails when versions are inherited Additional commits viewable in https://github.com/apache/maven-enforcer/compare/enforcer-3.0.0-M3...enforcer-3.0.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[
https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17475069#comment-17475069
]
wei cai commented on MRESOLVER-133:
---
[~ibabiankou] [~michael-o]
Here maven is using below code to resolve only the latest version
*Version version = versions.get( versions.size() - 1 );*
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L187]
And here maven is resolving all versions of a version range:
*for ( Version version : versions )*
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L405]
Why not keep the same?
We don't need to iterate over reversed list of versions, I think resolve the
latest version by "{*}Version version = versions.get( versions.size() - 1 ){*}"
is enough.
Any thoughts?
With such change, no tests broken at all.
> Improve resolver performance by using breadth-first search
> --
>
> Key: MRESOLVER-133
> URL: https://issues.apache.org/jira/browse/MRESOLVER-133
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.4.2
>Reporter: Gregory Ducharme
>Priority: Major
> Attachments: mvnbaddeps.zip
>
>
>
> I believe the maven resolver is unnecessarily inefficient because it performs
> a depth-first search of components to resolve dependencies. Consider the case
> when dependencies use version ranges, the user intent is for maven to resolve
> with the highest versions of dependencies that satisfy all constraints. If
> maven were to use a breadth-first search (and terminate searching as soon as
> a solution is found) then in many cases a valid set of dependencies can be
> resolved (at the top of the version ranges) without requiring that all
> historical versions are resolvable. One should get the same answer with both
> depth-first and breadth first strategies, but with the breadth-first approach
> not being vulnerable to a missing parent POM somewhere in history making it
> impossible to build the head of code. Additionally, I suspect that
> breadth-first would be faster and use less memory than depth first.
>
> Additionally the depth-first approach has a weakness that when ny version of
> a parent pom of a component referenced in a dependency tree of another
> component is missing maven fails to resolve dependencies. One get a message
> of the form:
> Failed to execute goal on project module: Could not resolve dependencies for
> project baddepdemo.project2:module:jar:1: Failed to collect dependencies ...
>
> Currently the only way to resolve this issue is one of three ways:
> 1) restore a missing parent POM into the repository history, or
> 2) delete all modules associated with the missing parent POM from the
> repository
> 3) manually adjust version ranges in consumer dependencies to exclude the
> bad versions of dependencies that refer to the missing parent POM.
>
> What I would like is a configuration switch that would allow one to select
> between the two search strategies So that the manual interventions described
> above are not required.
>
> I have include a zip file that include the minimal projects needed to
> demonstrate the dependency resolution problem:
> project 1 has a module and parent pom.
> project 2 is a single pom that has a dependency on the module in project 1.
> Project 2 uses a dependency range [1,) that indicates that the latest version
> of project1's module is to be used.
> If one builds two versions (1 and 2) of project 1, project2 will resolve to
> use version 2 as expected. However if you delete the parent pom of project1
> from the repository maven cannot resolve dependencies and fails. If the
> version range in project 2 is changed to [2,) then the expected behavior is
> observed.
> The zip file contains a shell script (demo.sh) that can be run without
> parameters to demonstrate the behavior when all versions are present in the
> repository. Run it with 1 as a parameter (the lower end of the version range
> used in project2) and the script will delete the parent pom from project 1
> and the error condition will be demonstrated. Run it with 2 and maven will
> resolve dependencies as version1 of project1 is explicitly excluded from the
> dependency resolution process.
>
> I am also willing to look at the source and propose a patch, but I would need
> guidance on which modules/source I should look at.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] mattsheppard commented on pull request #339: [SUREFIRE-1890] Support TestNG 7.4.0
mattsheppard commented on pull request #339: URL: https://github.com/apache/maven-surefire/pull/339#issuecomment-1011711965 I'd also like to see a release with this fix. Unfortunately all versions of testng prior to 7.5.0 are subject to a number of CVEs in their dependencies which are hard to fix in our environment because of this issue. The specific CVEs in the last compatible testng version (7.3.0) are as follows if it's at all helpful: - https://nvd.nist.gov/vuln/detail/CVE-2021-36374 - https://nvd.nist.gov/vuln/detail/CVE-2021-36373 - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - https://nvd.nist.gov/vuln/detail/CVE-2020-15250 - https://nvd.nist.gov/vuln/detail/CVE-2017-18640 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 commented on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1011669630 The docs and IT does not exist in here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #400: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 commented on pull request #400: URL: https://github.com/apache/maven-surefire/pull/400#issuecomment-1011657874 @imonteroperez @slawekjaranowski Pls let a have a look into #440 as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 commented on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1011650210 @imonteroperez @slawekjaranowski Let's see this as well. The ASM class used `getTest()` for the tests filter. We want to extend it with inc/excludedFiles param but it is not exactly the same list of patterns used by directory/dependency scanner. Additionally, the tests filter should not have the default inc/exc patterns because they should be only in the directory/dependency filters. This way the behavior would be backwards compatible and your feature would present new. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #431: Bump maven-common-artifact-filters from 3.1.0 to 3.2.0
Tibor17 commented on pull request #431: URL: https://github.com/apache/maven-surefire/pull/431#issuecomment-1011549888 We should rename the name of PR and commit to a typical Jira issue. This is part of usual non-test dependency. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #431: Bump maven-common-artifact-filters from 3.1.0 to 3.2.0
Tibor17 commented on pull request #431: URL: https://github.com/apache/maven-surefire/pull/431#issuecomment-1011546595 @slawekjaranowski This artifact is not part of Maven Core, so it is not too dangerous to skip this, but still we may suffer from ignoring this dependency upgrade. The logs shows the following broken test, not sure about the root cause `org.apache.maven.plugin.surefire.util.DependenciesScannerTest.testLocateTestClassesFromArtifactWithClassifier(DependenciesScannerTest.java:120)` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] dependabot[bot] commented on pull request #437: Bump junit-jupiter-params from 5.3.2 to 5.8.2
dependabot[bot] commented on pull request #437: URL: https://github.com/apache/maven-surefire/pull/437#issuecomment-1011540680 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 closed pull request #437: Bump junit-jupiter-params from 5.3.2 to 5.8.2
Tibor17 closed pull request #437: URL: https://github.com/apache/maven-surefire/pull/437 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 removed a comment on pull request #437: Bump junit-jupiter-params from 5.3.2 to 5.8.2
Tibor17 removed a comment on pull request #437: URL: https://github.com/apache/maven-surefire/pull/437#issuecomment-1011537758 . -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #437: Bump junit-jupiter-params from 5.3.2 to 5.8.2
Tibor17 commented on pull request #437: URL: https://github.com/apache/maven-surefire/pull/437#issuecomment-1011537758 . -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #437: Bump junit-jupiter-params from 5.3.2 to 5.8.2
Tibor17 commented on pull request #437: URL: https://github.com/apache/maven-surefire/pull/437#issuecomment-1011537317 This upgrade may lead to another upgrade of `junit-jupiter-engine` and we won't break the old users of JUnit5 surefire provider. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 opened a new pull request #440: Included Excluded Files as patterns
Tibor17 opened a new pull request #440: URL: https://github.com/apache/maven-surefire/pull/440 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga commented on pull request #574: Refactor build and release workflows
ppalaga commented on pull request #574: URL: https://github.com/apache/maven-mvnd/pull/574#issuecomment-1011520767 Looks good, 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MSHARED-997) Failed / error test DefaultProjectDependencyAnalyzerTest in maven-dependency-analyzer
[
https://issues.apache.org/jira/browse/MSHARED-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MSHARED-997.
---
> Failed / error test DefaultProjectDependencyAnalyzerTest in
> maven-dependency-analyzer
> -
>
> Key: MSHARED-997
> URL: https://issues.apache.org/jira/browse/MSHARED-997
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Fix For: maven-dependency-analyzer-1.12.0
>
>
> There is no possibility to build project by:
> {code:java}
> mvn clean verify
> {code}
> Tested last commit: {{b6adba0bcda5036a9bc59e23be2976672b729198}}
> Maven and java versin:
> {code:java}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/Cellar/maven/3.8.2/libexec
> Java version: 1.8.0_302, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+302/libexec/openjdk.jdk/Contents/Home/jre
> {code}
> I have many logs like:
> {code:java}
> 37) No implementation for
> java.util.Set
> was bound.
> while locating
> java.util.Set
> for parameter 0 at
> org.eclipse.aether.internal.impl.DefaultLocalRepositoryProvider.(Unknown
> Source)
> while locating
> org.eclipse.aether.internal.impl.DefaultLocalRepositoryProvider
> at ClassRealm[plexus.core, parent: null]
> at ClassRealm[plexus.core, parent: null]
> while locating org.eclipse.aether.impl.LocalRepositoryProvider
> for parameter 8 at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.(Unknown
> Source)
> while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
> at ClassRealm[plexus.core, parent: null]
> at ClassRealm[plexus.core, parent: null]
> while locating org.eclipse.aether.RepositorySystem
> while locating org.apache.maven.artifact.resolver.DefaultArtifactResolver
> at ClassRealm[plexus.core, parent: null]
> at ClassRealm[plexus.core, parent: null]
> {code}
> and test result:
> {code:java}
> INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [ERROR]
> DefaultProjectDependencyAnalyzerTest.setUp:81->PlexusTestCase.lookup:199 »
> ComponentLookup
> [INFO]
> [ERROR] Tests run: 101, Failures: 0, Errors: 15, Skipped: 0
> {code}
> h3. Build on Apache Jenkins
> There is also strange behavior that {{jenkins}} build also has similar errors
> - but failed tests aren't reported.
> [https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dependency-analyzer/job/master/]
> h3. Build on GitHub
> There is also the same problem on GitHub:
> https://github.com/apache/maven-dependency-analyzer/actions
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MSHARED-1021) Handle different classes from same artifact used by model and test code
[ https://issues.apache.org/jira/browse/MSHARED-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MSHARED-1021. Resolution: Fixed > Handle different classes from same artifact used by model and test code > --- > > Key: MSHARED-1021 > URL: https://issues.apache.org/jira/browse/MSHARED-1021 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer >Reporter: Slawomir Jaranowski >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: maven-dependency-analyzer-1.12.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MSHARED-1021) Handle different classes from same artifact used by model and test code
Slawomir Jaranowski created MSHARED-1021: Summary: Handle different classes from same artifact used by model and test code Key: MSHARED-1021 URL: https://issues.apache.org/jira/browse/MSHARED-1021 Project: Maven Shared Components Issue Type: Bug Components: maven-dependency-analyzer Reporter: Slawomir Jaranowski Assignee: Elliotte Rusty Harold Fix For: maven-dependency-analyzer-1.12.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (MDEP-779) dependency:analyze should list the classes that cause a used undeclared dependency
[
https://issues.apache.org/jira/browse/MDEP-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reopened MDEP-779:
--
PR 178 is not merged
> dependency:analyze should list the classes that cause a used undeclared
> dependency
> --
>
> Key: MDEP-779
> URL: https://issues.apache.org/jira/browse/MDEP-779
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: analyze-dep-mgt
>Reporter: Joseph Walton
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.3.0
>
>
> When {{dependency:analyze}} shows that a module has used classes from an
> undeclared dependency, it may not be clear which classes are involved. In
> particular, on large projects where modules and packages don't have a clear
> 1:1 relationship.
> It would be useful if there was (opt-in?) display of the classes involved.
> This could make it significantly quicker to identify the specific issue
> without switching to another tool.
> For example:
> {noformat}
> [WARNING] Used undeclared dependencies found:
> [WARNING]xml-apis:xml-apis:jar:1.0.b2:compile
> [WARNING]class org.apache.xmlcommons.Version
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MSHARED-1020) Include class names in used undeclared dependencies
[ https://issues.apache.org/jira/browse/MSHARED-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MSHARED-1020. Assignee: Sylwester Lachiewicz Resolution: Fixed > Include class names in used undeclared dependencies > --- > > Key: MSHARED-1020 > URL: https://issues.apache.org/jira/browse/MSHARED-1020 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-dependency-analyzer >Reporter: Slawomir Jaranowski >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: maven-dependency-analyzer-1.12.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MSHARED-1020) Include class names in used undeclared dependencies
Slawomir Jaranowski created MSHARED-1020: Summary: Include class names in used undeclared dependencies Key: MSHARED-1020 URL: https://issues.apache.org/jira/browse/MSHARED-1020 Project: Maven Shared Components Issue Type: New Feature Components: maven-dependency-analyzer Reporter: Slawomir Jaranowski Fix For: maven-dependency-analyzer-1.12.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHARED-632) Expose which dependency classes are used and where
[ https://issues.apache.org/jira/browse/MSHARED-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474986#comment-17474986 ] Slawomir Jaranowski commented on MSHARED-632: - [~slachiewicz] I can't find commits from PR #20 on master branch. Issue closed as fixed. Can you point me which commits is connected with it? > Expose which dependency classes are used and where > -- > > Key: MSHARED-632 > URL: https://issues.apache.org/jira/browse/MSHARED-632 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-dependency-analyzer >Reporter: Jonathan Haber >Assignee: Sylwester Lachiewicz >Priority: Minor > Labels: S2 > Fix For: maven-dependency-analyzer-1.12.0 > > > We use the maven-dependency-plugin to analyze dependencies and fail our build > if there are any used undeclared or unused declared dependencies. In the case > of used undeclared dependencies, it is often helpful to know which classes > are being used and where they are being used. We've found a few workarounds > to make this a little easier, but the plugin has access to this information > so what we really want is for the plugin to just print this info along with > each used undeclared dependency. We've made this change in our fork and our > developers are very happy with it, so I'd like to contribute it back > ([here|https://gist.github.com/jhaber/d8204829fe61569e0034250df74300fb] is an > example of the output before and after the change). > If you agree this is a useful feature, the first step is to update the > maven-dependency-analyzer to return this information so that the > maven-dependency-plugin can use it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MSHARED-879) make build Reproducible
[ https://issues.apache.org/jira/browse/MSHARED-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-879: Fix Version/s: (was: maven-dependency-analyzer-1.11.3) > make build Reproducible > --- > > Key: MSHARED-879 > URL: https://issues.apache.org/jira/browse/MSHARED-879 > Project: Maven Shared Components > Issue Type: Improvement > Components: file-management, maven-archiver, > maven-artifact-transfer, maven-common-artifact-filters, > maven-dependency-analyzer, maven-filtering, maven-invoker, maven-jarsigner, > maven-mapping, maven-project-utils, maven-reporting-api, > maven-reporting-exec, maven-reporting-impl, maven-script-interpreter, > maven-shared-incremental, maven-shared-io, maven-shared-jar, > maven-shared-resources, maven-shared-utils >Affects Versions: maven-dependency-analyzer-1.11.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: maven-shared-utils-3.3.3, maven-shared-resources-3, > maven-shared-jar-3.0.0, maven-shared-io-3.0.1, > maven-shared-incremental-2.0.0, maven-script-interpreter-1.3, > maven-reporting-impl-3.1.0, maven-reporting-exec-1.5, > maven-reporting-api-3.1.0, maven-project-utils-1.0.0, maven-mapping-3.1.0, > maven-jarsigner-3.0.1, maven-invoker-3.1.0, maven-filtering-3.2.0, > maven-dependency-analyzer-1.11.2, maven-common-artifact-filters-3.1.1, > maven-artifact-transfer-0.13.0, maven-artifact-transfer-0.13.1, > maven-archiver-3.5.1, file-management-3.0.1 > > > https://github.com/jvm-repo-rebuild/reproducible-maven-HEAD -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
slawekjaranowski commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1011476860 OK, local branch for jenkins created https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-surefire/job/SUREFIRE-1967/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7386) ModelMerger$MergingList is not serializable
[
https://issues.apache.org/jira/browse/MNG-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7386:
Fix Version/s: 4.0.0
> ModelMerger$MergingList is not serializable
> ---
>
> Key: MNG-7386
> URL: https://issues.apache.org/jira/browse/MNG-7386
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.4
>Reporter: Kostiantyn Liutovych
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
>
> Hello!
> [Spotless Maven plugin|https://github.com/diffplug/spotless] serializes
> {{org.apache.maven.model.Plugin}} instances to fingerprint plugin's
> configuration. Serialization fails for Maven 3.6.3 with:
> {code}
> java.io.NotSerializableException:
> org.apache.maven.model.merge.ModelMerger$MergingList
> {code}
> when plugin configuration comes from {{pluginManagement}}. Class
> {{org.apache.maven.model.Plugin}} implements {{java.io.Serializable}},
> however nested class {{org.apache.maven.model.merge.ModelMerger$MergingList}}
> does not.
> Would it be possible to make {{MergingList}} serializable or make
> {{Plugin#dependencies}} field always hold a serializable collection?
> Related issue for the Spotless Maven plugin:
> https://github.com/diffplug/spotless/issues/1073 and PR with a workaround
> https://github.com/diffplug/spotless/pull/1074.
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] findepi commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r783434179
##
File path:
surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/TestNGExecutor.java
##
@@ -137,6 +152,31 @@ static void run( Iterable> testClasses, String
testSourceDirectory,
testng.run();
}
+private static void addXmlClass( List xmlClasses, String
testClassName )
+{
+XmlClass xmlClass = new XmlClass( testClassName );
+if ( XML_CLASS_SET_INDEX != null )
+{
+try
+{
+// In case of parallel test execution with parallel="methods",
TestNG orders test execution
+// by XmlClass.m_index field. When unset (equal for all
XmlClass instances), TestNG can
+// invoke `@BeforeClass` setup methods on many instances,
without invoking `@AfterClass`
+// tearDown methods, thus leading to high resource
consumptions when test instances
+// allocate resources.
+// With index set, order of setup, test and tearDown methods
is reasonable, with approximately
+// #thread-count many test classes being initialized at given
point in time.
+// Note: XmlClass.m_index field is set automatically by TestNG
when it reads a suite file.
+XML_CLASS_SET_INDEX.invoke( xmlClass, xmlClasses.size() );
+}
+catch ( ReflectiveOperationException e )
+{
+throw new RuntimeException( e );
+}
+}
Review comment:
> Pls add a line with a comment regarding TestNG 5.10. It was very good
point.
You mean this one:
_The code is compiled against TestNG 5.10 and that version doesn't have the
`index` field in `XmlClass`, hence use of reflection._ ?
I wouldn't want to put exact TestNG 5.10 version in the source, as it's
subject to change, but i added explanatory comment above XML_CLASS_SET_INDEX
constant:
```
// Using reflection because XmlClass.setIndex is available since TestNG 6.3
// XmlClass.m_index field is available since TestNG 5.13, but prior to 6.3
required invoking constructor
// and constructor XmlClass constructor signatures evolved over time.
```
i tried to make it convey same meaning: that we have to use the reflection.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] findepi commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r783424283
##
File path:
surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/TestNGExecutor.java
##
@@ -137,6 +152,31 @@ static void run( Iterable> testClasses, String
testSourceDirectory,
testng.run();
}
+private static void addXmlClass( List xmlClasses, String
testClassName )
+{
+XmlClass xmlClass = new XmlClass( testClassName );
+if ( XML_CLASS_SET_INDEX != null )
+{
+try
+{
+// In case of parallel test execution with parallel="methods",
TestNG orders test execution
+// by XmlClass.m_index field. When unset (equal for all
XmlClass instances), TestNG can
+// invoke `@BeforeClass` setup methods on many instances,
without invoking `@AfterClass`
+// tearDown methods, thus leading to high resource
consumptions when test instances
+// allocate resources.
+// With index set, order of setup, test and tearDown methods
is reasonable, with approximately
+// #thread-count many test classes being initialized at given
point in time.
+// Note: XmlClass.m_index field is set automatically by TestNG
when it reads a suite file.
+XML_CLASS_SET_INDEX.invoke( xmlClass, xmlClasses.size() );
+}
+catch ( ReflectiveOperationException e )
+{
+throw new RuntimeException( e );
+}
+}
Review comment:
@Tibor17 it's possible to select and invoke one of the constructors, but
i don't think the added complexity is worth the effort (i am mostly concerned
about future code readability and maintainability). Note that after all, we're
solving a problem that exists in TestNG >= 6.3, and TestNG 5.x is not going to
change. The m_index field is used in TestNG 5.x when `preserve-order` is set,
but it's not possible to set it when invoking tests via surefire. More
precisely, `preserve-order` seems to require a suite file, but then TestNG will
populate the m_index, not us.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MNG-7386) ModelMerger$MergingList is not serializable
[
https://issues.apache.org/jira/browse/MNG-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7386:
-
Fix Version/s: 4.0.0-alpha-1
3.8.5
> ModelMerger$MergingList is not serializable
> ---
>
> Key: MNG-7386
> URL: https://issues.apache.org/jira/browse/MNG-7386
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.4
>Reporter: Kostiantyn Liutovych
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-alpha-1, 3.8.5
>
>
> Hello!
> [Spotless Maven plugin|https://github.com/diffplug/spotless] serializes
> {{org.apache.maven.model.Plugin}} instances to fingerprint plugin's
> configuration. Serialization fails for Maven 3.6.3 with:
> {code}
> java.io.NotSerializableException:
> org.apache.maven.model.merge.ModelMerger$MergingList
> {code}
> when plugin configuration comes from {{pluginManagement}}. Class
> {{org.apache.maven.model.Plugin}} implements {{java.io.Serializable}},
> however nested class {{org.apache.maven.model.merge.ModelMerger$MergingList}}
> does not.
> Would it be possible to make {{MergingList}} serializable or make
> {{Plugin#dependencies}} field always hold a serializable collection?
> Related issue for the Spotless Maven plugin:
> https://github.com/diffplug/spotless/issues/1073 and PR with a workaround
> https://github.com/diffplug/spotless/pull/1074.
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-mvnd] aalmiray commented on pull request #539: Do not cut sha256 in release workflow
aalmiray commented on pull request #539: URL: https://github.com/apache/maven-mvnd/pull/539#issuecomment-1011345697 FWIW #574 addresses this with JReleaser -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-build-cache-extension] hboutemy merged pull request #1: MNG-7129 fix for cleanup of partial state
hboutemy merged pull request #1: URL: https://github.com/apache/maven-build-cache-extension/pull/1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
Tibor17 edited a comment on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1011289025 @findepi One more thing. Is this new method `tryGetConstructor` called in some unit test? It would be great to have a coverage. I know your implementation is okay but it is useful for our test coverage graph to keep the coverage on the same level or let it grow. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
Tibor17 commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1011289025 One more thing. Is this new method `tryGetConstructor` called in some unit test? It would be great to have a coverage. I know your implementation is okay but it is useful for our test coverage graph to keep the coverage on the same level or let it grow. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
Tibor17 commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r774992573
##
File path:
surefire-its/src/test/resources/surefire-1967-testng-method-parallel-ordering/src/test/java/testng/parallelOrdering/Base.java
##
@@ -0,0 +1,59 @@
+package testng.parallelOrdering;
+
+import org.testng.annotations.AfterClass;
+import org.testng.annotations.BeforeClass;
+import org.testng.annotations.Test;
+
+import java.util.concurrent.ThreadLocalRandom;
+import java.util.concurrent.atomic.AtomicInteger;
+
+public abstract class Base
+{
+private static final AtomicInteger resources = new AtomicInteger();
+
+// This simulates resource allocation
+@BeforeClass
+public void setupAllocateResources()
+{
+int concurrentResources = resources.incrementAndGet();
+if (concurrentResources > 2) {
+throw new IllegalStateException("Tests execute in two threads, so
there should be at most 2 resources allocated, got: " + concurrentResources);
+}
+}
+
+// This simulates freeing resources
+@AfterClass(alwaysRun = true)
+public void tearDownReleaseResources()
+{
+resources.decrementAndGet();
+}
+
+@Test
+public void test1()
+{
+sleepShortly();
+}
+
+@Test
+public void test2()
+{
+sleepShortly();
+}
+
+@Test
+public void test3()
+{
+sleepShortly();
+}
+
+// Sleep random time to let tests interleave. Keep sleep short not to
extend tests duration too much.
+private void sleepShortly()
+{
+try {
+Thread.sleep(ThreadLocalRandom.current().nextInt(3));
Review comment:
Feel free to add the `throws` clause in the method signature and in the
tests. Catching exceptions in tests should not be used in tests because it
leads to situation where developers are tolerant to hiding errors.
##
File path:
surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/TestNGExecutor.java
##
@@ -137,6 +152,31 @@ static void run( Iterable> testClasses, String
testSourceDirectory,
testng.run();
}
+private static void addXmlClass( List xmlClasses, String
testClassName )
+{
+XmlClass xmlClass = new XmlClass( testClassName );
+if ( XML_CLASS_SET_INDEX != null )
+{
+try
+{
+// In case of parallel test execution with parallel="methods",
TestNG orders test execution
+// by XmlClass.m_index field. When unset (equal for all
XmlClass instances), TestNG can
+// invoke `@BeforeClass` setup methods on many instances,
without invoking `@AfterClass`
+// tearDown methods, thus leading to high resource
consumptions when test instances
+// allocate resources.
+// With index set, order of setup, test and tearDown methods
is reasonable, with approximately
+// #thread-count many test classes being initialized at given
point in time.
+// Note: XmlClass.m_index field is set automatically by TestNG
when it reads a suite file.
+XML_CLASS_SET_INDEX.invoke( xmlClass, xmlClasses.size() );
+}
+catch ( ReflectiveOperationException e )
+{
+throw new RuntimeException( e );
+}
+}
Review comment:
These two constructors handle the same information across versions
`XmlClass(String className, int index, boolean loadClasses)`
`XmlClass(String name, Boolean declaredClass, int index)`
@juherr Can you ensure that the constructors, at least two, would not be
removed in the future? Difficult question for IT development, I know. :-)
##
File path:
surefire-its/src/test/resources/surefire-1967-testng-method-parallel-ordering/pom.xml
##
@@ -0,0 +1,60 @@
+
+
+
+http://maven.apache.org/POM/4.0.0";
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
+ 4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+../pom.xml
+
+
+ org.apache.maven.plugins.surefire
+ surefire-1967-testng-method-parallel-ordering
+ 1.0-SNAPSHOT
+ TestNG parallel ordering
+
+
+
+ org.testng
+ testng
+ ${testNgVersion}
+
+
+
+
+
+
+org.apache.maven.plugins
+maven-surefire-plugin
+${surefire.version}
+
Review comment:
If the CPU is overloaded in Jenkins, this hypothesis may be broken and
parallel threads turn to serial. Don;t rely on parallel execution even if you
run parallel tests. Let's see the Jenkins test result especially on Windows...
##
File path:
surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/TestNGExecutor.java
##
@@
[GitHub] [maven-surefire] Tibor17 commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
Tibor17 commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1011214473 One more thing. The `Base` class has try-catch. Please use throws Exception , it is typical for tests to process the exception by itself in the report, not necessary to rethrow exceptions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #656: [MNG-7386] Make sure the ModelMerger$MergingList can be serialized
gnodet commented on pull request #656: URL: https://github.com/apache/maven/pull/656#issuecomment-1011213043 I'll try to backport the test from https://github.com/diffplug/spotless/pull/1074 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7386) ModelMerger$MergingList is not serializable
[
https://issues.apache.org/jira/browse/MNG-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474656#comment-17474656
]
Guillaume Nodet commented on MNG-7386:
--
Untested PR available at https://github.com/apache/maven/pull/656
> ModelMerger$MergingList is not serializable
> ---
>
> Key: MNG-7386
> URL: https://issues.apache.org/jira/browse/MNG-7386
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.4
>Reporter: Kostiantyn Liutovych
>Assignee: Guillaume Nodet
>Priority: Minor
>
> Hello!
> [Spotless Maven plugin|https://github.com/diffplug/spotless] serializes
> {{org.apache.maven.model.Plugin}} instances to fingerprint plugin's
> configuration. Serialization fails for Maven 3.6.3 with:
> {code}
> java.io.NotSerializableException:
> org.apache.maven.model.merge.ModelMerger$MergingList
> {code}
> when plugin configuration comes from {{pluginManagement}}. Class
> {{org.apache.maven.model.Plugin}} implements {{java.io.Serializable}},
> however nested class {{org.apache.maven.model.merge.ModelMerger$MergingList}}
> does not.
> Would it be possible to make {{MergingList}} serializable or make
> {{Plugin#dependencies}} field always hold a serializable collection?
> Related issue for the Spotless Maven plugin:
> https://github.com/diffplug/spotless/issues/1073 and PR with a workaround
> https://github.com/diffplug/spotless/pull/1074.
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] gnodet opened a new pull request #656: [MNG-7386] Make sure the ModelMerger$MergingList can be serialized
gnodet opened a new pull request #656: URL: https://github.com/apache/maven/pull/656 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7386) ModelMerger$MergingList is not serializable
[
https://issues.apache.org/jira/browse/MNG-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474655#comment-17474655
]
Guillaume Nodet commented on MNG-7386:
--
The {{MergingList}} has been introduced to provide a performance boost, so we
should rather keep it and make it serialisable somehow. I think the easiest
way is to add something like:
{code}
Object writeReplace() throws ObjectStreamException
{
return new ArrayList<>( this );
}
{code}
which should be sufficient to serialize the {{Model}} instance.
> ModelMerger$MergingList is not serializable
> ---
>
> Key: MNG-7386
> URL: https://issues.apache.org/jira/browse/MNG-7386
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.4
>Reporter: Kostiantyn Liutovych
>Assignee: Guillaume Nodet
>Priority: Minor
>
> Hello!
> [Spotless Maven plugin|https://github.com/diffplug/spotless] serializes
> {{org.apache.maven.model.Plugin}} instances to fingerprint plugin's
> configuration. Serialization fails for Maven 3.6.3 with:
> {code}
> java.io.NotSerializableException:
> org.apache.maven.model.merge.ModelMerger$MergingList
> {code}
> when plugin configuration comes from {{pluginManagement}}. Class
> {{org.apache.maven.model.Plugin}} implements {{java.io.Serializable}},
> however nested class {{org.apache.maven.model.merge.ModelMerger$MergingList}}
> does not.
> Would it be possible to make {{MergingList}} serializable or make
> {{Plugin#dependencies}} field always hold a serializable collection?
> Related issue for the Spotless Maven plugin:
> https://github.com/diffplug/spotless/issues/1073 and PR with a workaround
> https://github.com/diffplug/spotless/pull/1074.
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] findepi commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1011201165 > can be replaced with > > ``` > import static org.apache.maven.surefire.its.fixture.HelperAssertions.assumeJavaMaxVersion; > ``` nice, thanks @Tibor17, updated. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7386) ModelMerger$MergingList is not serializable
[
https://issues.apache.org/jira/browse/MNG-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474645#comment-17474645
]
Guillaume Nodet commented on MNG-7386:
--
This is a regression caused by MNG-6695.
> ModelMerger$MergingList is not serializable
> ---
>
> Key: MNG-7386
> URL: https://issues.apache.org/jira/browse/MNG-7386
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.4
>Reporter: Kostiantyn Liutovych
>Assignee: Guillaume Nodet
>Priority: Minor
>
> Hello!
> [Spotless Maven plugin|https://github.com/diffplug/spotless] serializes
> {{org.apache.maven.model.Plugin}} instances to fingerprint plugin's
> configuration. Serialization fails for Maven 3.6.3 with:
> {code}
> java.io.NotSerializableException:
> org.apache.maven.model.merge.ModelMerger$MergingList
> {code}
> when plugin configuration comes from {{pluginManagement}}. Class
> {{org.apache.maven.model.Plugin}} implements {{java.io.Serializable}},
> however nested class {{org.apache.maven.model.merge.ModelMerger$MergingList}}
> does not.
> Would it be possible to make {{MergingList}} serializable or make
> {{Plugin#dependencies}} field always hold a serializable collection?
> Related issue for the Spotless Maven plugin:
> https://github.com/diffplug/spotless/issues/1073 and PR with a workaround
> https://github.com/diffplug/spotless/pull/1074.
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MNG-7386) ModelMerger$MergingList is not serializable
[
https://issues.apache.org/jira/browse/MNG-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7386:
Assignee: Guillaume Nodet
> ModelMerger$MergingList is not serializable
> ---
>
> Key: MNG-7386
> URL: https://issues.apache.org/jira/browse/MNG-7386
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.4
>Reporter: Kostiantyn Liutovych
>Assignee: Guillaume Nodet
>Priority: Minor
>
> Hello!
> [Spotless Maven plugin|https://github.com/diffplug/spotless] serializes
> {{org.apache.maven.model.Plugin}} instances to fingerprint plugin's
> configuration. Serialization fails for Maven 3.6.3 with:
> {code}
> java.io.NotSerializableException:
> org.apache.maven.model.merge.ModelMerger$MergingList
> {code}
> when plugin configuration comes from {{pluginManagement}}. Class
> {{org.apache.maven.model.Plugin}} implements {{java.io.Serializable}},
> however nested class {{org.apache.maven.model.merge.ModelMerger$MergingList}}
> does not.
> Would it be possible to make {{MergingList}} serializable or make
> {{Plugin#dependencies}} field always hold a serializable collection?
> Related issue for the Spotless Maven plugin:
> https://github.com/diffplug/spotless/issues/1073 and PR with a workaround
> https://github.com/diffplug/spotless/pull/1074.
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-build-cache-extension] maximilian-novikov-db opened a new pull request #1: MNG-7129 fix for cleanup of partial state
maximilian-novikov-db opened a new pull request #1: URL: https://github.com/apache/maven-build-cache-extension/pull/1 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
Tibor17 commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1011178942 ``` Matcher matcher = Pattern.compile( "^(\\d+)\\..*$" ).matcher( System.getProperty( "java.version" ) ); assertTrue( matcher.matches() ); int javaVersionFirstNumber = Integer.parseInt( matcher.group( 1 ) ); assumeTrue( "TestNG 5.13 does not work with Java 17", javaVersionFirstNumber < 17 ); ``` can be replaced with ``` import static org.apache.maven.surefire.its.fixture.HelperAssertions.assumeJavaMaxVersion; assumeJavaMaxVersion( 16 ); ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-assembly-plugin] dependabot[bot] commented on pull request #42: Bump sisu-inject-plexus from 1.4.2 to 2.6.0
dependabot[bot] commented on pull request #42: URL: https://github.com/apache/maven-assembly-plugin/pull/42#issuecomment-1011172576 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-assembly-plugin] slachiewicz closed pull request #42: Bump sisu-inject-plexus from 1.4.2 to 2.6.0
slachiewicz closed pull request #42: URL: https://github.com/apache/maven-assembly-plugin/pull/42 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-assembly-plugin] dependabot[bot] commented on pull request #46: Bump maven-aether-provider from 3.0 to 3.3.9
dependabot[bot] commented on pull request #46: URL: https://github.com/apache/maven-assembly-plugin/pull/46#issuecomment-1011172227 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-assembly-plugin] slachiewicz closed pull request #46: Bump maven-aether-provider from 3.0 to 3.3.9
slachiewicz closed pull request #46: URL: https://github.com/apache/maven-assembly-plugin/pull/46 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski merged pull request #439: Use the latest release version of failsafe in ITs
slawekjaranowski merged pull request #439: URL: https://github.com/apache/maven-surefire/pull/439 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
Tibor17 commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1011149404 `JUnit47ParallelIT.forcedShutdownVerifyingLogs` is not related to this issue since the IT is not related to TestNG. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
cstamas commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783124929
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
The
```
if ( log.isTraceEnabled() )
{
log.debug( " Included {} located at {}", id, file );
}
else
{
log.debug( " Included {}", id );
}
```
one. These are two orthogonal things:
* message is always DEBUG
* level may be "tuned", and based on set level, message is either not
emitted, emitted, or emitted with more details
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] cstamas commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
cstamas commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783124929
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
The
```
if ( log.isTraceEnabled() )
{
log.debug( " Included {} located at {}", id, file );
}
else
{
log.debug( " Included {}", id );
}
```
one. These are two orthogonal things:
* message is always DEBUG
* level may be "tuned", ans based on set level, message either becomes
invisible, visible, or more detailed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
michael-o commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783106746
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
...still crunching... @cstamas Which pattern explicitly?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-plugin-tools] dependabot[bot] opened a new pull request #64: Bump mockito-core from 2.28.2 to 4.2.0
dependabot[bot] opened a new pull request #64: URL: https://github.com/apache/maven-plugin-tools/pull/64 Bumps [mockito-core](https://github.com/mockito/mockito) from 2.28.2 to 4.2.0. Release notes Sourced from https://github.com/mockito/mockito/releases";>mockito-core's releases. v4.2.0 Changelog generated by https://github.com/shipkit/shipkit-changelog";>Shipkit Changelog Gradle Plugin 4.2.0 2021-12-16 - https://github.com/mockito/mockito/compare/v4.1.0...v4.2.0";>21 commit(s) by Liam Miller-Cushon, Rafael Winterhalter, Tim van der Lippe, dependabot[bot], temp-droid Update ByteBuddy to 1.12.4 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2515";>#2515)](https://github-redirect.dependabot.com/mockito/mockito/pull/2515";>mockito/mockito#2515) Bump kotlinVersion from 1.6.0 to 1.6.10 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2514";>#2514)](https://github-redirect.dependabot.com/mockito/mockito/pull/2514";>mockito/mockito#2514) Add DoNotMock mention to main JavaDoc [(https://github-redirect.dependabot.com/mockito/mockito/issues/2512";>#2512)](https://github-redirect.dependabot.com/mockito/mockito/pull/2512";>mockito/mockito#2512) Replace ExpectedException in MissingInvocationInOrderCheckerTest [(https://github-redirect.dependabot.com/mockito/mockito/issues/2511";>#2511)](https://github-redirect.dependabot.com/mockito/mockito/pull/2511";>mockito/mockito#2511) Update Gradle to version 7.3.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2509";>#2509)](https://github-redirect.dependabot.com/mockito/mockito/pull/2509";>mockito/mockito#2509) Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2497";>#2497: Throw exception on invalid matchers for mockStatic [(https://github-redirect.dependabot.com/mockito/mockito/issues/2506";>#2506)](https://github-redirect.dependabot.com/mockito/mockito/pull/2506";>mockito/mockito#2506) Make sure interface types are initialized before inline mocking to avoid blocking code of static initializers. [(https://github-redirect.dependabot.com/mockito/mockito/issues/2505";>#2505)](https://github-redirect.dependabot.com/mockito/mockito/pull/2505";>mockito/mockito#2505) Bump org.eclipse.osgi from 3.17.0 to 3.17.100 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2504";>#2504)](https://github-redirect.dependabot.com/mockito/mockito/pull/2504";>mockito/mockito#2504) Bump com.diffplug.spotless from 6.0.2 to 6.0.4 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2501";>#2501)](https://github-redirect.dependabot.com/mockito/mockito/pull/2501";>mockito/mockito#2501) Bump com.diffplug.spotless from 6.0.1 to 6.0.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2498";>#2498)](https://github-redirect.dependabot.com/mockito/mockito/pull/2498";>mockito/mockito#2498) ArgumentMatchers not working for Mockito.mockStatic [(https://github-redirect.dependabot.com/mockito/mockito/issues/2497";>#2497)](https://github-redirect.dependabot.com/mockito/mockito/issues/2497";>mockito/mockito#2497) Bump versions.bytebuddy from 1.12.2 to 1.12.3 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2496";>#2496)](https://github-redirect.dependabot.com/mockito/mockito/pull/2496";>mockito/mockito#2496) Bump com.diffplug.spotless from 6.0.0 to 6.0.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2495";>#2495)](https://github-redirect.dependabot.com/mockito/mockito/pull/2495";>mockito/mockito#2495) Remove the recommendation to import ArgumentMatchers methods using Mockito [(https://github-redirect.dependabot.com/mockito/mockito/issues/2494";>#2494)](https://github-redirect.dependabot.com/mockito/mockito/pull/2494";>mockito/mockito#2494) Bump versions.junitJupiter from 5.8.1 to 5.8.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2491";>#2491)](https://github-redirect.dependabot.com/mockito/mockito/pull/2491";>mockito/mockito#2491) Bump junit-platform-launcher from 1.8.1 to 1.8.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2490";>#2490)](https://github-redirect.dependabot.com/mockito/mockito/pull/2490";>mockito/mockito#2490) Fix typo 'DoNoMock' should be 'DoNotMock' [(https://github-redirect.dependabot.com/mockito/mockito/issues/2487";>#2487)](https://github-redirect.dependabot.com/mockito/mockito/pull/2487";>mockito/mockito#2487) Bump biz.aQute.bnd.gradle from 6.0.0 to 6.1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2486";>#2486)](https://github-redirect.dependabot.com/mockito/mockito/pull/2486";>mockito/mockito#2486) Bump biz.aQute.bnd.builder from 6.0.0 to 6.1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2485";>#2485)](https://github-redirect.dependabot.com/mockito/mockito/pull/2485";>mockito/mockito#2485) Bump versions.bytebuddy from 1.12.1 to 1.12.2 [(https://github-redirect.dependabot.com/m
[GitHub] [maven-plugin-tools] dependabot[bot] opened a new pull request #63: Bump plexus-utils from 3.3.0 to 3.4.1
dependabot[bot] opened a new pull request #63: URL: https://github.com/apache/maven-plugin-tools/pull/63 Bumps [plexus-utils](https://github.com/codehaus-plexus/plexus-utils) from 3.3.0 to 3.4.1. Release notes Sourced from https://github.com/codehaus-plexus/plexus-utils/releases";>plexus-utils's releases. 3.4.1 🐛 Bug Fixes Fixes https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/163";>#163: Regression: encoding error when parsing a ISO-8859-1 xml (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/164";>#164) https://github.com/belingueres";>@belingueres 📦 Dependency updates Bump actions/setup-java from 2.2.0 to 2.3.0 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/168";>#168) https://github.com/dependabot";>@dependabot Bump jmh-generator-annprocess from 1.32 to 1.33 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/166";>#166) https://github.com/dependabot";>@dependabot Bump jmh-core from 1.32 to 1.33 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/165";>#165) https://github.com/dependabot";>@dependabot Bump actions/setup-java from 2.1.0 to 2.2.0 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/167";>#167) https://github.com/dependabot";>@dependabot Bump junit from 4.13.1 to 4.13.2 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/162";>#162) https://github.com/dependabot";>@dependabot Bump actions/setup-java from 1 to 2.1.0 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/157";>#157) https://github.com/dependabot";>@dependabot Bump jmh-generator-annprocess from 1.29 to 1.32 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/159";>#159) https://github.com/dependabot";>@dependabot Bump jmh-core from 1.29 to 1.32 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/160";>#160) https://github.com/dependabot";>@dependabot Bump actions/cache from 2.1.5 to 2.1.6 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/161";>#161) https://github.com/dependabot";>@dependabot Bump actions/checkout from 2 to 2.3.4 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/154";>#154) https://github.com/dependabot";>@dependabot 3.4.0 Enforcing JDK 11 on release (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/148";>#148) https://github.com/mkarg";>@mkarg Using JDK 16 GA instead of JDK 16 EA (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/147";>#147) https://github.com/mkarg";>@mkarg Fixed infinite loop in MXParser and reactivate tests in MXParserTest (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/119";>#119,https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/118";>#118) https://github.com/belingueres";>@belingueres Added support for PPC64LE (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/97";>#97) https://github.com/ezeeyahoo";>@ezeeyahoo Avoid build issues with symlink (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/90";>#90) https://github.com/olamy";>@olamy New feature FileUtils.linkFile(source, destination) (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/82";>#82) https://github.com/mkarg";>@mkarg Fix Javadoc build with Java 11 (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/88";>#88) https://github.com/olamy";>@olamy Support combine.keys (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/76";>#76) https://github.com/rfscholte";>@rfscholte Support combine.self="remove" (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/75";>#75,https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/74";>#74) https://github.com/belingueres";>@belingueres Input location (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/62";>#62,https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/61";>#61) https://github.com/hboutemy";>@hboutemy UT improvement : Check that symlinks resources are preserved during git clone (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/56";>#56) https://github.com/rfscholte";>@rfscholte Junit4 annotations (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/55";>#55) https://github.com/rfscholte";>@rfscholte Test failure in CommandlineTest#testExecuteBinaryOnPath with Maven 3.5.4 or later (https://github-redirect.dependabot.com/codehaus-plexus/plexus-utils/issues/50";>#50) https://github.com/belingueres";>@belingueres PrettyPrintXMLWriter fails with a java.uti
[jira] [Comment Edited] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[ https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474532#comment-17474532 ] Arkadiusz Biczewski edited comment on MASSEMBLY-874 at 1/12/22, 1:42 PM: - Hello, As not only dependencies are always re-downloaded, but they are always re-downloaded from real central, regardless of whether it's overwritten in the pom's and section, are there any chances, to finally include [[MASSEMBLY-874] maven-assembly plugin always downloads dependencies from net by turbanoff · Pull Request #16 · apache/maven-assembly-plugin (github.com)|https://github.com/apache/maven-assembly-plugin/pull/16] in mainline and next release? Version 2.6 of assembly plugin starts to have issues with building more recent/complex projects, so it is no longer a working work-around solution :( was (Author: axi): Hello, As not only dependencies are always re-downloaded, but they are always re-downloaded from real central, regardless of whether it's overwritten in the pom's and section, are there any chances, to finally include [[MASSEMBLY-874] maven-assembly plugin always downloads dependencies from net by turbanoff · Pull Request #16 · apache/maven-assembly-plugin (github.com)|https://github.com/apache/maven-assembly-plugin/pull/16] in mainline and next release? > maven-assembly plugin always downloads dependencies from net > > > Key: MASSEMBLY-874 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-874 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 > Environment: Multi-Module build >Reporter: Roland Schäuble >Assignee: Enrico Olivelli >Priority: Major > Attachments: make.log, > maven_assembly_repositories_after_and_before_change.png > > Time Spent: 10m > Remaining Estimate: 0h > > The maven-assembly-plugin always loads it own dependencies from the internet, > although the required dependencies are available in the local m2 repositiory. > The local repository is updated with the dependencies but during the next > build, the files are downloaded from the internet again instead of getting > them from the local repo. > In the attached log, near the end, the unnecessary downloads begin with > "Downloading from central: > [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.";|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.] > The files are definitely available in my local repository under > ~/.m2/repository/com/... -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MASSEMBLY-874) maven-assembly plugin always downloads dependencies from net
[ https://issues.apache.org/jira/browse/MASSEMBLY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474532#comment-17474532 ] Arkadiusz Biczewski commented on MASSEMBLY-874: --- Hello, As not only dependencies are always re-downloaded, but they are always re-downloaded from real central, regardless of whether it's overwritten in the pom's and section, are there any chances, to finally include [[MASSEMBLY-874] maven-assembly plugin always downloads dependencies from net by turbanoff · Pull Request #16 · apache/maven-assembly-plugin (github.com)|https://github.com/apache/maven-assembly-plugin/pull/16] in mainline and next release? > maven-assembly plugin always downloads dependencies from net > > > Key: MASSEMBLY-874 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-874 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.1.0 > Environment: Multi-Module build >Reporter: Roland Schäuble >Assignee: Enrico Olivelli >Priority: Major > Attachments: make.log, > maven_assembly_repositories_after_and_before_change.png > > Time Spent: 10m > Remaining Estimate: 0h > > The maven-assembly-plugin always loads it own dependencies from the internet, > although the required dependencies are available in the local m2 repositiory. > The local repository is updated with the dependencies but during the next > build, the files are downloaded from the internet again instead of getting > them from the local repo. > In the attached log, near the end, the unnecessary downloads begin with > "Downloading from central: > [https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.";|https://repo.maven.apache.org/maven2/com/lowagie/itext/2.1.7.js5/itext-2.1.7.js5.pom.] > The files are definitely available in my local repository under > ~/.m2/repository/com/... -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
cstamas commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783084437
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
+1 for this pattern, I use it as well: emit (same) DEBUG message w/ less
or more info... make possible grepping as well, etc.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474525#comment-17474525
]
Marat Abrarov commented on MEAR-307:
Hi [~asbachb],
Regarding [your
note|https://issues.apache.org/jira/browse/MEAR-307?focusedCommentId=17474463&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17474463]
{quote}
I'd expect that the war should behave somehow similar to other modules where I
don't need to define the dependencies manually.
{quote}
{{war}} packaging / artifact type (as well as {{ear}} packaging and some other
packing types) "contains all of its dependencies" in terms of Maven, so these
dependencies are not visible (do not come as transitive dependencies) to EARs
which depend on WARs.
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474516#comment-17474516
]
Benjamin Asbach commented on MEAR-307:
--
Actually I'm unable to close the issue. Feel free to close it.
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474515#comment-17474515
]
Benjamin Asbach commented on MEAR-307:
--
[~abrarovm] thanks for your support. The solution referencing the pom seems to
work for me as well.
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474463#comment-17474463
]
Benjamin Asbach edited comment on MEAR-307 at 1/12/22, 1:16 PM:
[~abrarovm], thansk for your fast response. I wonder if this is a technical
limitation?
I'd expect that the war should behave somehow similar to other modules where I
don't need to define the dependencies manually.
-For my use case (1war + 2ejb) I also end up with doubled dependencies: Some
war dependencies are present in libs and in war/WEB-INF/lib.-
was (Author: asbachb):
[~abrarovm], thansk for your fast response. I wonder if this is a technical
limitation?
I'd expect that the war should behave somehow similar to other modules where I
don't need to define the dependencies manually.
For my use case (1war + 2ejb) I also end up with doubled dependencies: Some
war dependencies are present in libs and in war/WEB-INF/lib.
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #139: [MRESOLVER-230] Make supported checksum algorithms extensible
cstamas commented on pull request #139:
URL: https://github.com/apache/maven-resolver/pull/139#issuecomment-1011013483
> > Can you adjust
https://github.com/apache/maven-resolver/blob/master/src/site/markdown/configuration.md
on how to configure this (probably requires adjustment of description for
`aether.checksums.algorithms`)?
>
> @kwin once this merged nothing changes re that doco, as "out of the box"
resolver will still fallback to `MessageDigest`. But, at the same time this
opens a door to extend checksum support, and probably resolver itself will add
some new ones (but not in 1.x line, probably 2.x line).
Doco updated, as after last changes this above ("nothing changes") is
untrue: MessageDigest is not "exposed" as before.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
michael-o commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783026282
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
Let me think about this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783019478
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
> Warn is warn, regardless which level is enabled.
I agree.
> I am not really convinced by this.
> I would have expected this:
>
> ```
> if ( log.isTraceEnabled() )
> {
> log.trace( " Included {} located at {}", id, file );
> }
> else
> {
> log.debug( " Included {}", id );
> }
> ```
>
> The message remains the same, but the granularity changes.
This exactly contradicts your statement above which is "warn is warn".
Here, a _debug_ is logged either at _trace_ *or* _debug_ which is really wrong
to me.
> Why do you I have to enable debug to see more information with the same
warn level?
The level choosen in the `mvnd` example is _warn_ because that's its
semantic. The exception stack trace however, is not necessary to understand
the warning usually. But in case you need to have more detailed information,
you raise the log level to debug, and you have more information provided. But
that does not mean the _warning_ becomes a _debug_ statement as you said.
I think we have the exact same use case here. The fact that an artifact is
included or excluded is _debug_ level message. If you need more, in this case
the exact file location, you can raise the log level, but the semantic about
the fact that the artifact is included or not does not change, nor should its
log level.
If we can't agree on that solution, I'd go for the alternative using two
statements, one at debug and one at trace level.
```
log.debug( " Included {}", id );
log.trace( " -> {}", file );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet merged pull request #582: Remove unused subclass
gnodet merged pull request #582: URL: https://github.com/apache/maven-mvnd/pull/582 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783019478
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
> Warn is warn, regardless which level is enabled.
I agree.
> I am not really convinced by this.
> I would have expected this:
>
> ```
> if ( log.isTraceEnabled() )
> {
> log.trace( " Included {} located at {}", id, file );
> }
> else
> {
> log.debug( " Included {}", id );
> }
> ```
>
> The message remains the same, but the granularity changes.
This exactly contradicts your statement above which is "warn is warn".
Here, a _debug_ is logged either at _trace_ *or* _debug_ which is really wrong
to me.
> Why do you I have to enable debug to see more information with the same
warn level?
The level choosen in the `mvnd` example is _warn_ because that's it's
semantic. The exception stack trace however, is not necessary to understand
the warning usually. But in case you need to have more detailed information,
you raise the log level to debug, and you have more information provided. But
that does not mean the _warning_ becomes a _debug_ statement as you said.
I think we have the exact same use case here. The fact that an artifact is
included or excluded is _debug_ level message. If you need more, in this case
the exact file location, you can raise the log level, but the semantic about
the fact that the artifact is included or not does not change, nor should its
log level.
If we can't agree on that solution, I'd go for the alternative using two
statements, one at debug and one at trace level.
```
log.debug( " Included {}", id );
log.trace( " -> {}", file );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783019478
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
> I consider this as an antipattern. Warn is warn, regardless which
level is enabled.
I agree.
> I am not really convinced by this.
> I would have expected this:
>
> ```
> if ( log.isTraceEnabled() )
> {
> log.trace( " Included {} located at {}", id, file );
> }
> else
> {
> log.debug( " Included {}", id );
> }
> ```
>
> The message remains the same, but the granularity changes.
This exactly contradicts your statement above which is "warn is warn".
Here, a _debug_ is logged either at _trace_ *or* _debug_ which is really wrong
to me.
> Why do you I have to enable debug to see more information with the same
warn level?
The level choosen in the `mvnd` example is _warn_ because that's it's
semantic. The exception stack trace however, is not necessary to understand
the warning usually. But in case you need to have more detailed information,
you raise the log level to debug, and you have more information provided. But
that does not mean the _warning_ becomes a _debug_ statement as you said.
I think we have the exact same use case here. The fact that an artifact is
included or excluded is _debug_ level message. If you need more, in this case
the exact file location, you can raise the log level, but the semantic about
the fact that the artifact is included or not does not change, nor should its
log level.
If we can't agree on that solution, I'd go for the alternative using two
statements, one at debug and one at trace level.
```
log.debug( " Included {}", id );
log.trace( " -> {}", file );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783019478
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
> I consider this as an antipattern. Warn is warn, regardless which
level is enabled.
I agree.
> I am not really convinced by this.
> I would have expected this:
>
> ```
> if ( log.isTraceEnabled() )
> {
> log.trace( " Included {} located at {}", id, file );
> }
> else
> {
> log.debug( " Included {}", id );
> }
> ```
>
> The message remains the same, but the granularity changes.
This exactly contradicts your statement above which is "warn is warn".
Here, a _debug_ is logged either at _trace_ *or* _debug_ which is really wrong
to me.
> Why do you I have to enable debug to see more information with the same
warn level?
The level choosen in the `mvnd` example is _warn_ because that's it's
semantic. The exception stack trace however, is not necessary to understand
the warning usually. But in case you need to have more detailed information,
you raise the log level to debug, and you have more information provided. But
that does not mean the _warning_ becomes a _debug_ statement as you said.
I think we have the exact same use case here. The fact that an artifact is
included or excluded is _debug_ level info. If you need more, in this case the
exact file location, you can raise the log level, but the semantic about the
fact that the artifact is included or not does not change, nor should its log
level.
If we can't agree on that solution, I'd go for the alternative using two
statements, one at debug and one at trace level.
```
log.debug( " Included {}", id );
log.trace( " -> {}", file );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783019478
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
> I consider this as an antipattern. Warn is warn, regardless which
level is enabled.
I agree.
> I am not really convinced by this.
> I would have expected this:
>
> ```
> if ( log.isTraceEnabled() )
> {
> log.trace( " Included {} located at {}", id, file );
> }
> else
> {
> log.debug( " Included {}", id );
> }
> ```
>
> The message remains the same, but the granularity changes.
This exactly contradicts your statement above which is "warn is warn".
Here, a _debug_ is logged either at _trace_ *or* _debug_ which is really wrong
to me.
> Why do you I have to enable debug to see more information with the same
warn level?
Same as here. The level choosen in the `mvnd` example is _warn_ because
that's what it is. The exception stack trace however, is not necessary to
understand the warning usually. But in case you need to have more detailed
information, you raise the log level to debug, and you have more information
provided. But that does not mean the _warning_ becomes a _trace_ as you said.
I think we have the exact same use case here. The fact that an artifact is
included or excluded is _debug_ level info. If you need more, in this case the
exact file location, you can raise the log level, but the semantic about the
fact that the artifact is included or not does not change, nor should its log
level.
If we can't agree on that solution, I'd go for the alternative using two
statements, one at debug and one at trace level.
```
log.debug( " Included {}", id );
log.trace( " -> {}", file );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r783019478
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
> I consider this as an antipattern. Warn is warn, regardless which
level is enabled.
I agree.
> I am not really convinced by this.
> I would have expected this:
>
> ```
> if ( log.isTraceEnabled() )
> {
> log.trace( " Included {} located at {}", id, file );
> }
> else
> {
> log.debug( " Included {}", id );
> }
> ```
>
> The message remains the same, but the granularity changes.
This exactly contradicts your statement above which is "warn is warn".
Here, a _debug_ is logged either at _trace_ *or* _debug_ which is really wrong
to me.
> Why do you I have to enable debug to see more information with the same
warn level?
Same as here. The level choosen in the `mvnd` example is _warn_ because
that's what it is. The exception stack trace however, is not necessary to
understand the warning usually. But in case you need to have more detailed
information, you raise the log level to debug, and you have more information
provided. But that does not mean the _warning_ becomes a _trace_ as you said.
I think we have the exact same use case here. The fact that an artifact is
included or excluded is _debug_ level info. If you need more, in this case the
exact file location, you can raise the log level, but the semantic about the
fact that the artifact is included or not does not change, nor should its log
level.
If we can't agree on that solution, I'd go for the alternative using two
statements, one at debug and one at trace level.
```
log.debug( " Included {}", id );
log.trace( " -> {}", file );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:50 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what JARs to keep as is. I was ensured that
the trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is
simple to implement (e.g. there is no pain here).
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what JARs to keep as is. I was ensured that
the trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is
simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:50 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what JARs to keep as is. I was ensured that
the trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is
simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what keep as is. I was ensured that the
trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is simple to
implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:49 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared library directory of EAR and what keep as is. I was ensured that the
trick I shared in [^MEAR-307_fixed_example.zip] is widely used and is simple to
implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474469#comment-17474469
]
Marat Abrarov commented on MEAR-307:
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / WARs / etc to move into shared
folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474469#comment-17474469
]
Marat Abrarov edited comment on MEAR-307 at 1/12/22, 11:48 AM:
---
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / HARs / SARs / etc to move into
shared folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
was (Author: abrarovm):
[~asbachb],
I'm not the author of this approach, but I believe it's by design - this way
users have fine-grained control over what JARs / WARs / etc to move into shared
folder and what keep as is. I was ensured that the trick I shared in
[^MEAR-307_fixed_example.zip] is widely used and is simple to implement.
Refer to https://github.com/apache/maven-ear-plugin/pull/24. There are rare
cases (e.g. some Spring Web libraries, JSF libraries) when you need to keep JAR
inside WAR even if this JAR is located in multiple web modules of the same EAR
(otherwise JAR doesn't work as expected).
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
michael-o commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r782980780
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
Why do you I hve to enable debug to see more information with the same
warn level?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
michael-o commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r782979548
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
I consider this as an antipattern. Warn is warn, regardless which level
is enabled. I am not really convinced by this. I would have expected this:
```
if ( log.isTraceEnabled() )
{
log.trace( " Included {} located at {}", id, file );
}
else
{
log.debug( " Included {}", id );
}
```
The message remains the same, but the granularity chagnes.
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
I consider this as an antipattern. Warn is warn, regardless which level
is enabled. I am not really convinced by this. I would have expected this:
```
if ( log.isTraceEnabled() )
{
log.trace( " Included {} located at {}", id, file );
}
else
{
log.debug( " Included {}", id );
}
```
The message remains the same, but the granularity changes.
--
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 commen
[jira] [Commented] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474463#comment-17474463
]
Benjamin Asbach commented on MEAR-307:
--
[~abrarovm], thansk for your fast response. I wonder if this is a technical
limitation?
I'd expect that the war should behave somehow similar to other modules where I
don't need to define the dependencies manually.
For my use case (1war + 2ejb) I also end up with doubled dependencies: Some
war dependencies are present in libs and in war/WEB-INF/lib.
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r782944181
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
> That's exactly what I have expected. Notice that the first log message
must be `trace`. Likely just a typo.
Not a typo at all. If I want a trace statement, I'd have to use
```
log.debug( " Included {}", id );
if ( log.isTraceEnabled() )
{
log.trace( "located at {}", file );
}
```
but then, the log output contains two lines at different levels which makes
things less readable (if needed). That's why I propose to log at level debug,
but have a different output at debug/trace. This is an usual pattern but I've
used it several times in order to provide more information at certain level,
see
https://github.com/apache/maven-mvnd/blob/71631fd1919513aa8765008fb8c96fb7b4c82b6e/daemon/src/main/java/org/apache/maven/project/CachingProjectBuilder.java#L828-L834
for example
I think this makes the log output more readable while still conditioning the
level of data that appears.
I haven't seen this pattern used in maven, hence the question which was very
specific and without typo ;-)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
michael-o commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r782934356
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
That's exactly what I have expected. Notice that the first log message
must be `trace`. Likely just a typo.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
michael-o commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r782934356
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
That's exactly what I have expected.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MNG-7345) Missing exported packages
[
https://issues.apache.org/jira/browse/MNG-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448456#comment-17448456
]
Guillaume Nodet edited comment on MNG-7345 at 1/12/22, 10:33 AM:
-
Packages not exported from maven-core:
* o.a.m.bridge
* o.a.m.eventspy
* o.a.m.execution.infoproviders
* o.a.m.lifecycle.mapping
* o.a.m.feature
Packages that should not be exported
* o.a.m.rtinfo.internal
was (Author: gnt):
Packages not exported from maven-core:
* o.a.m.bridge
* o.a.m.eventspy
* o.a.m.execution.infoproviders
* o.a.m.lifecycle.mapping
* o.a.m.feature
Packages not exported from dependencies
* org.eclipse.sisu
the above one is required for {{@Priority}}, but there may be others needed,
not sure.
Packages that should not be exported
* o.a.m.rtinfo.internal
> Missing exported packages
> -
>
> Key: MNG-7345
> URL: https://issues.apache.org/jira/browse/MNG-7345
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Priority: Major
> Labels: must-be-in-4.0.0-alpha-1
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.9.0-candidate
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] michael-o commented on pull request #552: [MNG-7260] [MNG-7266] Remove maven-compat module
michael-o commented on pull request #552: URL: https://github.com/apache/maven/pull/552#issuecomment-1010895881 > The `ArtifactDeployer` and `ArtifactInstaller`, `ArtifactCollector`, `ArtifactResolver` interfaces contains various methods used in https://github.com/apache/maven-integration-testing/blob/master/core-it-support/core-it-plugins/maven-it-plugin-artifact/src/main/java/org/apache/maven/plugin/coreit and thus cause some failures in the ITs. Should I bring it back somehow or should I fix the testing plugins ? or get rid of the tests that do use indirectly those old interfaces ? It needs to be evaluated whether those ITs are for Maven 2, or 2. If 2 only, we need to discuss whether to remove them. If 3+ we likely need to migrate them. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
gnodet commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r782930812
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
I then propose the following code to avoid logging 2 lines in case trace
is enabled:
```
if ( log.isTraceEnabled() )
{
log.debug( " Included {} located at {}", id, file );
}
else
{
log.debug( " Included {}", id );
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet closed pull request #552: [MNG-7260] [MNG-7266] Remove maven-compat module
gnodet closed pull request #552: URL: https://github.com/apache/maven/pull/552 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Ability to customize core extensions classloaders
michael-o commented on a change in pull request #616:
URL: https://github.com/apache/maven/pull/616#discussion_r782922523
##
File path:
maven-embedder/src/main/java/org/apache/maven/cli/internal/BootstrapCoreExtensionManager.java
##
@@ -114,14 +123,42 @@ private CoreExtensionEntry createExtension( CoreExtension
extension, List providedArtifacts = Collections.emptySet();
+String classLoadingStrategy = extension.getClassLoadingStrategy();
+if ( STRATEGY_PARENT_FIRST.equals( classLoadingStrategy ) )
+{
+realm.importFrom( parentRealm, "" );
+}
+else if ( STRATEGY_PLUGIN.equals( classLoadingStrategy ) )
+{
+coreExports.getExportedPackages().forEach( ( p, cl ) ->
realm.importFrom( cl, p ) );
+providedArtifacts = coreExports.getExportedArtifacts();
+}
+else if ( STRATEGY_SELF_FIRST.equals( classLoadingStrategy ) )
+{
+realm.setParentRealm( parentRealm );
+}
+else
+{
+throw new IllegalArgumentException( "Unsupported class-loading
strategy '"
++ classLoadingStrategy + "'. Supported values are: " +
STRATEGY_PARENT_FIRST
++ ", " + STRATEGY_PLUGIN + " and " + STRATEGY_SELF_FIRST );
+}
+log.debug( "Populating class realm {}", realm.getId() );
for ( Artifact artifact : artifacts )
{
-File file = artifact.getFile();
-log.debug( " Included " + file );
-realm.addURL( file.toURI().toURL() );
+String id = artifact.getGroupId() + ":" + artifact.getArtifactId();
+if ( providedArtifacts.contains( id ) )
+{
+log.debug( " Excluded {}", id );
+}
+else
+{
+File file = artifact.getFile();
+log.debug( " Included {}", file );
Review comment:
This doesn't make sense. The exclude logs id and this one logs files.
Inconsistent.
If you need to print the file, I would recommend to print the id at debug
level, but at trace level print both.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski opened a new pull request #439: Use the latest release version of failsafe in ITs
slawekjaranowski opened a new pull request #439: URL: https://github.com/apache/maven-surefire/pull/439 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MEAR-307:
Summary: skinny modules war libs are not put into shared lib directory
(was: skinny modules war libs are not put into shared lib folder)
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs folder.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MEAR-307) skinny modules war libs are not put into shared lib directory
[
https://issues.apache.org/jira/browse/MEAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MEAR-307:
Description:
{code:xml}
maven-ear-plugin
3.2.0
8
libs/
true
org.jenkins-ci.main
jenkins-war
2.328
war
{code}
With the current configuration the libs of war application are not placed into
libs directory.
This causes problems when you add an ejb module: The ejb dependencies are
placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
with the libs classpath.
This causes problems with classloading in JBoss EAP.
was:
{code:xml}
maven-ear-plugin
3.2.0
8
libs/
true
org.jenkins-ci.main
jenkins-war
2.328
war
{code}
With the current configuration the libs of war application are not placed into
libs folder.
This causes problems when you add an ejb module: The ejb dependencies are
placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
with the libs classpath.
This causes problems with classloading in JBoss EAP.
> skinny modules war libs are not put into shared lib directory
> -
>
> Key: MEAR-307
> URL: https://issues.apache.org/jira/browse/MEAR-307
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Benjamin Asbach
>Priority: Major
> Attachments: MEAR-307_fixed_example.zip, ear-war-skinny-bug-ear.zip
>
>
> {code:xml}
>
>
>
> maven-ear-plugin
> 3.2.0
>
> 8
> libs/
> true
>
>
>
>
>
>
> org.jenkins-ci.main
> jenkins-war
> 2.328
> war
>
>
> {code}
> With the current configuration the libs of war application are not placed
> into libs directory.
> This causes problems when you add an ejb module: The ejb dependencies are
> placed in libs and the META-INF/MANIFEST-MF classpath entry of the war is set
> with the libs classpath.
> This causes problems with classloading in JBoss EAP.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-156) shade plugin is transforming also strings that are not supposed to be transformed
[
https://issues.apache.org/jira/browse/MSHADE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474344#comment-17474344
]
Shengnan YU commented on MSHADE-156:
Any solution on this issue? It is annoying.
> shade plugin is transforming also strings that are not supposed to be
> transformed
> -
>
> Key: MSHADE-156
> URL: https://issues.apache.org/jira/browse/MSHADE-156
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Neeme Praks
>Priority: Major
> Fix For: backlog
>
>
> I'm shading several third party libraries into a single JAR. In the context
> of this issue, there are two important libraries:
> 1. com.nothome:javaxdelta:2.0.1 - this library is in "at.spardat.xma.xdelta"
> package.
> 2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
> ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to
> convert stack trace elements into strings:
> {code}
> public String getSTEAsString() {
> if (steAsString == null) {
> steAsString = "at " + ste.toString();
> }
> return steAsString;
> }
> {code}
> I use "org.myorgname.appname.shaded" package for shading.
> During shading, the constant "at " is replaced with
> "org.myorgname.appname.shaded.at" -- shade plugin thinks that the "at" in the
> beginning of that string is a package name and shades it.
> This results in an unfortunate side-effect: all logged stack traces now look
> like this:
> {noformat}
> Caused by: java.util.zip.ZipException: error in opening zip file
> org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
> Method) ~[na:1.6.0_19]
> org.myorgname.appname.shaded.at
> java.util.zip.ZipFile.(ZipFile.java:114) ~[na:1.6.0_19]
> org.myorgname.appname.shaded.at
> java.util.zip.ZipFile.(ZipFile.java:131) ~[na:1.6.0_19]
> {noformat}
> Possible fixes:
> * instead of just checking the first part of the package (at), check for the
> full package (at.spardat.xma.xdelta).
> * allow to configure shade plugin to ignore certain string constants in
> certain classes (this would solve also some other issues we have with shade
> plugin being too eager).
> * both of the above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
