[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750089#comment-17750089 ] ASF GitHub Bot commented on MNG-7848: - olamy commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1661472603 > Hi @olamy @slachiewicz , > > Thanks for merging this PR. > > Yes, I think I know how to adjust it and I was working on that change (replacing `jenkinsNotify()` with another function which sends the notifications to our team). Since this PR has been merged, I will raise a new PR for it ASAP. correct you need to replace this with sending email to you > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] olamy commented on pull request #1207: [MNG-7848] Add s390x pipeline to Jenkins CI
olamy commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1661472603 > Hi @olamy @slachiewicz , > > Thanks for merging this PR. > > Yes, I think I know how to adjust it and I was working on that change (replacing `jenkinsNotify()` with another function which sends the notifications to our team). Since this PR has been merged, I will raise a new PR for it ASAP. correct you need to replace this with sending email to you -- 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] sinyagin commented on issue #836: `Could not acquire write lock for…` errors
sinyagin commented on issue #836: URL: https://github.com/apache/maven-mvnd/issues/836#issuecomment-1661295678 Faced the same issue on 1.0-m7 windows version. `Apache Maven Daemon (mvnd) 1.0-m7 windows-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 4.0.0-alpha-7 (bf699a388cc04b8e4088226ba09a403b68de6b7b) Maven home: C:\work\tools\mvnd-0.7.1-windows-amd64\mvn Java version: 11.0.15, vendor: Eclipse Adoptium, runtime: C:\work\tools\java\jdk-11.0.15.10-hotspot Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"` I was able to get a full stack trace ` Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire write lock for 'C:\work\repository\.locks\artifact~antlr~antlr~2.7.6.lock' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire (NamedLockFactoryAdapter.java:202) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve (DefaultArtifactResolver.java:271) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts (DefaultArtifactResolver.java:259) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies (DefaultRepositorySystem.java:352) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve (DefaultProjectDependenciesResolver.java:187) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies (LifecycleDependencyResolver.java:242) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectArtifacts (LifecycleDependencyResolver.java:193) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies (LifecycleDependencyResolver.java:131) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved (MojoExecutor.java:361) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:318) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:178) at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:77) at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:166) at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:163) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:114) at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject (SmartBuilderImpl.java:209) at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run (SmartBuilderImpl.java:81) at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515) at java.util.concurrent.FutureTask.run (FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628) at java.lang.Thread.run (Thread.java:829)` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPH-208) display leaf parameters if a parameter is a complex object
Ernst Reissner created MPH-208: -- Summary: display leaf parameters if a parameter is a complex object Key: MPH-208 URL: https://issues.apache.org/jira/browse/MPH-208 Project: Maven Help Plugin Issue Type: New Feature Components: describe Affects Versions: 3.4.0 Reporter: Ernst Reissner In my configuration I have a @Parameter named `settings` which is an object with fields again @Parameters. This is because I have a lot of parameters and this is a way to structure the parameters. The problem is, that `mvn latex:help -Ddetail=true` (`latex-maven-plugin` is my plugin) tells me only that `settings` is a parameter without displaying the parameters nested inside. Maybe I dont use this plugin properly, but then maybe some improvement in the documentation would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated MBUILDCACHE-64:
--
Labels: pull-request-available (was: )
> Apply global exclusions to folder names
> ---
>
> Key: MBUILDCACHE-64
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-64
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Frank Wagner
>Priority: Major
> Labels: pull-request-available
>
> It is currently not possible to exclude folders by their name, like
> {quote}
>
>
> node_modules
> dist
> build
>
>
> ...
> {quote}
> That's because isFilteredOutSubpath(),
> [https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L638,]
> uses startWith on normalized absolute paths.
> That function could be enhanced with an additional criterion like in
> [https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L510]
> {{filteredOutPaths.stream().anyMatch(it ->
> it.getFileName().equals(entry.getFileName()))}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750014#comment-17750014
]
ASF GitHub Bot commented on MBUILDCACHE-64:
---
kbuntrock opened a new pull request, #91:
URL: https://github.com/apache/maven-build-cache-extension/pull/91
### Description of this pull request
Fix a bug regarding the exclusion mechanism not working properly on folders.
It also add an integration test on this functionality (global + per project).
Finally add some documentation on these aspects.
Here a screenshot of the new "exclude" element in the documentation to
understand how this fix intend to work.
I did not implemented the following sentence in the Jira issue since I did
not got the exact meaning :
"That function could be enhanced with an additional criterion like in
MavenProjectInput.java#L510"
Nevertheless, I think this MR is already a huge improvement on the exclusion
topic since it's a critical feature and it was not possible to use it on
folders before (pretty hard to use it in a project with a "node_module" folder
for example).
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [MBUILDCACHE JIRA
issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [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)
- [x] 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/
> Apply global exclusions to folder names
> ---
>
> Key: MBUILDCACHE-64
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-64
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Frank Wagner
>Priority: Major
>
> It is currently not possible to exclude folders by their name, like
> {quote}
>
>
> node_modules
> dist
> build
>
>
> ...
> {quote}
> That's because isFilteredOutSubpath(),
> [https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L638,]
> uses startWith on normalized absolute paths.
> That function could be enhanced with an additional criterion like in
> [https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L510]
> {{filteredOutPaths.stream().anyMatch(it ->
> it.getFileName().equals(entry.getFileName()))}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-build-cache-extension] kbuntrock opened a new pull request, #91: [MBUILDCACHE-64] Exclusion mechanism bugfix + improvement
kbuntrock opened a new pull request, #91: URL: https://github.com/apache/maven-build-cache-extension/pull/91 ### Description of this pull request Fix a bug regarding the exclusion mechanism not working properly on folders. It also add an integration test on this functionality (global + per project). Finally add some documentation on these aspects. Here a screenshot of the new "exclude" element in the documentation to understand how this fix intend to work.  I did not implemented the following sentence in the Jira issue since I did not got the exact meaning : "That function could be enhanced with an additional criterion like in MavenProjectInput.java#L510" Nevertheless, I think this MR is already a huge improvement on the exclusion topic since it's a critical feature and it was not possible to use it on folders before (pretty hard to use it in a project with a "node_module" folder for example). Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [MBUILDCACHE JIRA issue](https://issues.apache.org/jira/browse/MBUILDCACHE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MBUILDCACHE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MBUILDCACHE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [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) - [x] 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-7541) Native support for PowerShell to start Maven
[ https://issues.apache.org/jira/browse/MNG-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749998#comment-17749998 ] ASF GitHub Bot commented on MNG-7541: - JurrianFahner commented on PR #982: URL: https://github.com/apache/maven/pull/982#issuecomment-1660960598 > > > Not now, ATM. I need to consult also a colleague who's proficient in PowerShell. > > > > > > Is there some progress? > > I hope to pick this up when my round with reporting stack is complete for next milestone. I guess somewere end of month. Please also raise your voice on dev@ to drag more attraction to this topic. Is there some progress? > Native support for PowerShell to start Maven > > > Key: MNG-7541 > URL: https://issues.apache.org/jira/browse/MNG-7541 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.8.3 > Environment: windows 10 / 11 >Reporter: Jurrian Fahner >Priority: Trivial > Labels: Script, Windows10, Windows11 > > Maven has two files in the bin dir: > ||command||its use|| > |mvn|POSIX shell| > |mvn.cmd|cmd.exe| > On windows there are two ways to write scripts, by using cmd.exe or using > powershell. > If you enter mvn in powershell it will look for `mvn.ps1` on the PATH first. > If it doesn't find anything it will execute `mvn.cmd` as fall-back. > When running maven for starting a server for development purposes and you do > ctrl-c to exit the server it will ask the question: Terminate batch job (Y/N)? > As far as I know it is default behaviour of cmd.exe. > Well if I don't want to terminate, I wouldn't press ctrl-c. ;) > It is not the case (as far as I know that Microsoft is going to deprecate > cmd.exe in favor of powershell: > [https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/] > Allthough I think it would be a good move for maven to have also a powershell > script as well... It is possible to integrate elegant support for native help > in powershell, `get-help mvn`. > But it also increases the maintenance effort as well. I don't know whether > this cost outweigh the benefits, though... > By the way I would happy to contribute if it is appreciated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] JurrianFahner commented on pull request #982: [MNG-7541] Implement powershell mvn command
JurrianFahner commented on PR #982: URL: https://github.com/apache/maven/pull/982#issuecomment-1660960598 > > > Not now, ATM. I need to consult also a colleague who's proficient in PowerShell. > > > > > > Is there some progress? > > I hope to pick this up when my round with reporting stack is complete for next milestone. I guess somewere end of month. Please also raise your voice on dev@ to drag more attraction to this topic. Is there some progress? -- 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] [Assigned] (MSKINS-229) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/MSKINS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSKINS-229:
-
Assignee: Michael Osipov
> Inconsistent anchors between toc macro and headers
> --
>
> Key: MSKINS-229
> URL: https://issues.apache.org/jira/browse/MSKINS-229
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSKINS-229) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/MSKINS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-229:
--
Fix Version/s: (was: wontfix-candidate)
> Inconsistent anchors between toc macro and headers
> --
>
> Key: MSKINS-229
> URL: https://issues.apache.org/jira/browse/MSKINS-229
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MSKINS-229) Inconsistent anchors between toc macro and headers
[
https://issues.apache.org/jira/browse/MSKINS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSKINS-229:
-
Assignee: (was: Michael Osipov)
> Inconsistent anchors between toc macro and headers
> --
>
> Key: MSKINS-229
> URL: https://issues.apache.org/jira/browse/MSKINS-229
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: wontfix-candidate
>
>
> In markdown document add:
> {code:java}
>
> {code}
> Then anchors generated by toc macro looks like: {{#Your_First_Mojo}}
> and anchors generated by skin looks like: {{#your-first-plugin}}
> - Doxia Site Renderer 2.0.0-M4
> - Fluido Skin 1.11.1
> Tested on Maven main site without more investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749968#comment-17749968
]
ASF GitHub Bot commented on MNG-7851:
-
michael-o commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1660814043
> LGTM
then please approve
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749936#comment-17749936
]
ASF GitHub Bot commented on MNG-7851:
-
cstamas commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1660695260
LGTM
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-scm] dependabot[bot] opened a new pull request, #182: Bump apache/maven-gh-actions-shared from 2 to 3
dependabot[bot] opened a new pull request, #182: URL: https://github.com/apache/maven-scm/pull/182 Bumps [apache/maven-gh-actions-shared](https://github.com/apache/maven-gh-actions-shared) from 2 to 3. Commits https://github.com/apache/maven-gh-actions-shared/commit/b961f080ae80df6f0869fd49b9e075e9904069db;>b961f08 Maven 3.9.3 as default https://github.com/apache/maven-gh-actions-shared/commit/89f2a04119d7328ba0d45cafda92e92e68540a48;>89f2a04 Use Java 17 as default. Remove Java 11 from ci https://github.com/apache/maven-gh-actions-shared/commit/e6be7431664b30d586dadf6507f29d1abe5170a0;>e6be743 Maven 3.9.2 as default https://github.com/apache/maven-gh-actions-shared/commit/830d986dbbd5832a410c0847e123503fd3f93f0b;>830d986 Use the same version of m-wrapper-p in every jobs https://github.com/apache/maven-gh-actions-shared/commit/ab56ffb91817ce8dfdb06a23ad8d4afbc6f62a29;>ab56ffb Execute test in sequence https://github.com/apache/maven-gh-actions-shared/commit/8aade8cc622ee09c991dc97bbd62eabcf5c3e781;>8aade8c Bump release-drafter to v5 https://github.com/apache/maven-gh-actions-shared/commit/0d124101aa05e4e7e385414f3c515d03d969d96d;>0d12410 Upgrade to latest Maven 3.9.1 and Maven Wrapper to 3.2.0 https://github.com/apache/maven-gh-actions-shared/commit/5348e2ad05f5d8ac75bc0a3cebe4928362443850;>5348e2a Bump release-drafter/release-drafter from 5.22.0 to 5.23.0 https://github.com/apache/maven-gh-actions-shared/commit/101cb08f66a0b3be6e2113675cc30e9f03d13db1;>101cb08 Switch to Maven 3.9.0 https://github.com/apache/maven-gh-actions-shared/commit/9073820ea078880a0f4edc7ce2000ea4ade4;>907 Switch to Maven 3.9.0 Additional commits viewable in https://github.com/apache/maven-gh-actions-shared/compare/v2...v3;>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-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749886#comment-17749886 ] Tamas Cservenak commented on MRESOLVER-387: --- Sure > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749868#comment-17749868 ] Grzegorz Grzybek commented on MRESOLVER-387: Sure - but tomorrow, ok? :) > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-5960) MojoExecutor overriding resolved artifacts of concurrently built MavenProject
[
https://issues.apache.org/jira/browse/MNG-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749841#comment-17749841
]
Joep Weijers commented on MNG-5960:
---
This is still an issue. The example project maven-mojo-jojo still fails with:
{code:java}
$ mvn --version
Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
Maven home: C:\ProgramData\chocolatey\lib\maven\apache-maven-3.9.3
Java version: 17.0.2, vendor: Eclipse Adoptium, runtime: C:\Program
Files\Eclipse Adoptium\jdk-17.0.2.8-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" {code}
The Maven
[maven-non-destructive-mojo-executor|https://github.com/fvanderveen/maven-non-destructive-mojo-executor]
Extension to prevent this issue stopped working with Maven 3.9.0, with the
following error:
{code:java}
[main] [ERROR] Cannot invoke
"org.codehaus.plexus.PlexusContainer.lookup(java.lang.Class)" because
"this.container" is null {code}
> MojoExecutor overriding resolved artifacts of concurrently built MavenProject
> -
>
> Key: MNG-5960
> URL: https://issues.apache.org/jira/browse/MNG-5960
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9, needing-scrub-3.4.0-fallout
> Environment: Linux 4.2.0-23-generic #28-Ubuntu SMP Sun Dec 27
> 17:47:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> (Ubuntu 15.10)
> Maven 3.3.9/3.4.0-SNAPSHOT
>Reporter: Fabian van der Veen
>Priority: Major
> Fix For: 4.x / Backlog, waiting-for-feedback
>
>
> I have found an issue with respect to the {{MojoExecutor}} in {{maven-core}}
> when building with multiple threads (e.g. {{-T1C}}).
> I have created a small reproduction project here:
> https://github.com/fvanderveen/maven-mojo-jojo (in the readme is some more
> explanation of what I found to be the problem)
> The reproduction, using the above code:
> 1. Clone this repository (`git clone
> https://github.com/fvanderveen/maven-mojo-jojo.git`)
> 2. Make sure the clone works single-threaded: `mvn clean package`. (This
> should succeed)
> 3. Clean the workspace (`mvn clean`)
> 4. Attempt multi-threaded compilation with at least 2 threads (`mvn package
> -T2`)
> Boiled down, it seems like the {{MojoExecutor#ensureDependenciesAreResolved}}
> will cause an invocation to
> {{LifecycleDependencyResolver#resolveProjectDependencies}} for _all_ projects
> in the current {{MavenSession}} if it's configuring a plugin that defines
> {{@Mojo(aggregator = true)}} and
> {{DependencyContext#isResolutionRequiredForAggregatedProjects}} return true.
> This resolving may, if triggered at an unfortunate time, override resolved
> artifacts for projects that are being built concurrently.
> In our case, a {{test-compile}} execution of the {{maven-compiler-plugin}}
> was just configured (setting the resolved artifacts to the test-scope
> artifacts), and right before its execution, the resolved artifacts got set
> back to the compile-scope artifacts due to a aggregator plugin being
> configured at around the same time.
> Given the way the `ensureDependenciesAreResolved` is structured and what
> aggregator plugins should do/depend on, I think it would make more sense to
> _only_ invoke {{LifecycleDependencyResolver#resolveProjectDependencies}} for
> the modules that are a (grand-)child of the current project.
> I've created a maven extension (which can be placed in lib/ext) as a
> temporary workaround using said change; which may be found here if any one
> else is having the same problems:
> https://github.com/fvanderveen/maven-non-destructive-mojo-executor
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749832#comment-17749832 ] Tamas Cservenak commented on MRESOLVER-387: --- [~ggrzybek] a quick peek at PR would be great! > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] kun-lu20 commented on pull request #1207: [MNG-7848] Add s390x pipeline to Jenkins CI
kun-lu20 commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1660336106 Hi @olamy @slachiewicz , Thanks for merging this PR. Yes, I think I know how to adjust it and I was working on that change (replacing `jenkinsNotify()` with another function which sends the notifications to our team). Since this PR has been merged, I will raise a new PR for it ASAP. -- 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-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749751#comment-17749751 ] ASF GitHub Bot commented on MNG-7848: - kun-lu20 commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1660336106 Hi @olamy @slachiewicz , Thanks for merging this PR. Yes, I think I know how to adjust it and I was working on that change (replacing `jenkinsNotify()` with another function which sends the notifications to our team). Since this PR has been merged, I will raise a new PR for it ASAP. > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[
https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749745#comment-17749745
]
ASF GitHub Bot commented on MRESOLVER-387:
--
michael-o commented on code in PR #319:
URL: https://github.com/apache/maven-resolver/pull/319#discussion_r1280642505
##
maven-resolver-supplier/src/test/java/org/eclipse/aether/supplier/RepositorySystemSupplierTest.java:
##
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.eclipse.aether.supplier;
+
+import java.util.Collections;
+import java.util.List;
+
+import org.apache.maven.repository.internal.MavenRepositorySystemUtils;
+import org.eclipse.aether.DefaultRepositorySystemSession;
+import org.eclipse.aether.RepositorySystem;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.artifact.DefaultArtifact;
+import org.eclipse.aether.repository.LocalRepository;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.resolution.VersionRangeRequest;
+import org.eclipse.aether.resolution.VersionRangeResult;
+import org.eclipse.aether.version.Version;
+import org.junit.Test;
+
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.Matchers.greaterThanOrEqualTo;
+import static org.hamcrest.Matchers.hasSize;
+
+public class RepositorySystemSupplierTest {
+private final RepositorySystemSupplier subject = new
RepositorySystemSupplier();
+
+public static DefaultRepositorySystemSession
newRepositorySystemSession(RepositorySystem system) {
+DefaultRepositorySystemSession session =
MavenRepositorySystemUtils.newSession();
+LocalRepository localRepo = new LocalRepository("target/local-repo");
+
session.setLocalRepositoryManager(system.newLocalRepositoryManager(session,
localRepo));
+return session;
+}
+
+@Test
+public void smoke() throws Exception {
+RepositorySystem system = subject.get();
+RepositorySystemSession session = newRepositorySystemSession(system);
+
+Artifact artifact = new
DefaultArtifact("org.apache.maven.resolver:maven-resolver-util:[0,)");
+VersionRangeRequest rangeRequest = new VersionRangeRequest();
+rangeRequest.setArtifact(artifact);
+rangeRequest.setRepositories(Collections.singletonList(
+new RemoteRepository.Builder("central", "default",
"https://repo.maven.apache.org/maven2/;).build()));
+VersionRangeResult rangeResult = system.resolveVersionRange(session,
rangeRequest);
+List versions = rangeResult.getVersions();
+
+// 2023. 07. 26.: as of today, Central has 33 versions of this
artifact (and it will just grow)
Review Comment:
As of 2023-08-01, Maven Central...
> Provide "static" supplier for RepositorySystem
> --
>
> Key: MRESOLVER-387
> URL: https://issues.apache.org/jira/browse/MRESOLVER-387
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.15
>
>
> To provide SL replacement.
> Something like this
> https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #319: [MRESOLVER-387] New RepositorySystem supplier
michael-o commented on code in PR #319:
URL: https://github.com/apache/maven-resolver/pull/319#discussion_r1280642505
##
maven-resolver-supplier/src/test/java/org/eclipse/aether/supplier/RepositorySystemSupplierTest.java:
##
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.eclipse.aether.supplier;
+
+import java.util.Collections;
+import java.util.List;
+
+import org.apache.maven.repository.internal.MavenRepositorySystemUtils;
+import org.eclipse.aether.DefaultRepositorySystemSession;
+import org.eclipse.aether.RepositorySystem;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.artifact.DefaultArtifact;
+import org.eclipse.aether.repository.LocalRepository;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.resolution.VersionRangeRequest;
+import org.eclipse.aether.resolution.VersionRangeResult;
+import org.eclipse.aether.version.Version;
+import org.junit.Test;
+
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.Matchers.greaterThanOrEqualTo;
+import static org.hamcrest.Matchers.hasSize;
+
+public class RepositorySystemSupplierTest {
+private final RepositorySystemSupplier subject = new
RepositorySystemSupplier();
+
+public static DefaultRepositorySystemSession
newRepositorySystemSession(RepositorySystem system) {
+DefaultRepositorySystemSession session =
MavenRepositorySystemUtils.newSession();
+LocalRepository localRepo = new LocalRepository("target/local-repo");
+
session.setLocalRepositoryManager(system.newLocalRepositoryManager(session,
localRepo));
+return session;
+}
+
+@Test
+public void smoke() throws Exception {
+RepositorySystem system = subject.get();
+RepositorySystemSession session = newRepositorySystemSession(system);
+
+Artifact artifact = new
DefaultArtifact("org.apache.maven.resolver:maven-resolver-util:[0,)");
+VersionRangeRequest rangeRequest = new VersionRangeRequest();
+rangeRequest.setArtifact(artifact);
+rangeRequest.setRepositories(Collections.singletonList(
+new RemoteRepository.Builder("central", "default",
"https://repo.maven.apache.org/maven2/;).build()));
+VersionRangeResult rangeResult = system.resolveVersionRange(session,
rangeRequest);
+List versions = rangeResult.getVersions();
+
+// 2023. 07. 26.: as of today, Central has 33 versions of this
artifact (and it will just grow)
Review Comment:
As of 2023-08-01, Maven Central...
--
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] [Assigned] (MRESOLVER-388) Transport HTTP old codec proper override
[ https://issues.apache.org/jira/browse/MRESOLVER-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-388: - Assignee: Tamas Cservenak > Transport HTTP old codec proper override > > > Key: MRESOLVER-388 > URL: https://issues.apache.org/jira/browse/MRESOLVER-388 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > The codec was overridden, but not properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-386. - Resolution: Fixed > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-387: - Assignee: Tamas Cservenak > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-386: - Assignee: Tamas Cservenak > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-388) Transport HTTP old codec proper override
[ https://issues.apache.org/jira/browse/MRESOLVER-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-388. - Resolution: Fixed > Transport HTTP old codec proper override > > > Key: MRESOLVER-388 > URL: https://issues.apache.org/jira/browse/MRESOLVER-388 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > The codec was overridden, but not properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7856) Maven Resolver Provider classes ctor change
Tamas Cservenak created MNG-7856: Summary: Maven Resolver Provider classes ctor change Key: MNG-7856 URL: https://issues.apache.org/jira/browse/MNG-7856 Project: Maven Issue Type: Task Reporter: Tamas Cservenak Fix For: 3.9.5 These classes in maven-resolver-provider should get similar change as done in MRESOLVER-386 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-388) Transport HTTP old codec proper override
[ https://issues.apache.org/jira/browse/MRESOLVER-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749650#comment-17749650 ] ASF GitHub Bot commented on MRESOLVER-388: -- cstamas merged PR #320: URL: https://github.com/apache/maven-resolver/pull/320 > Transport HTTP old codec proper override > > > Key: MRESOLVER-388 > URL: https://issues.apache.org/jira/browse/MRESOLVER-388 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > The codec was overridden, but not properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749649#comment-17749649 ] ASF GitHub Bot commented on MRESOLVER-386: -- cstamas merged PR #321: URL: https://github.com/apache/maven-resolver/pull/321 > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas merged pull request #320: [MRESOLVER-388] Proper overide of commons-codec
cstamas merged PR #320: URL: https://github.com/apache/maven-resolver/pull/320 -- 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-resolver] cstamas merged pull request #321: [MRESOLVER-386] Make all injected ctors public, deprecate def ctors
cstamas merged PR #321: URL: https://github.com/apache/maven-resolver/pull/321 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749647#comment-17749647 ] ASF GitHub Bot commented on MRESOLVER-387: -- michael-o commented on code in PR #319: URL: https://github.com/apache/maven-resolver/pull/319#discussion_r1280505936 ## maven-resolver-supplier/README.md: ## @@ -0,0 +1,52 @@ + + +# Maven Resolver Supplier + +This simple module serves the purpose to "bootstrap" resolver when there is no desire to use Eclipse SISU. It provides +one simple class `org.eclipse.aether.supplier.RepositorySystemSupplier` that implements `Supplier` +and supplies ready-to-use `RepositorySystem` instances. + +The supplier class is written in such way, to allow easy customization if needed: just extend the class and override +method one need (all methods are protected). + +Consumer/User of this module **must provide SLF4J backend**. Resolver uses `slf4j-api` for logging purposes, but this +module does NOT provide any backend for it. It is the consumer/user obligation to provide one at runtime. + +By default, "full resolver experience" is provided: +* for connector, the connector-basic is provided +* for transport the two transport-file and transport-http implementations are provided. If Wagon is needed, add + transport-wagon as dependency, and customize `RepositorySystemSupplier` to include it. This makes it available, but + NOT used yet! To use it, you still need to configure resolver to favor Wagon over native HTTP. + +# Resolver configuration + +The supplier will provide only a "vanilla" instance. To configure resolver, use session user (or +configuration) properties, when constructing session. All the configuration options are available as +[listed here](https://maven.apache.org/resolver/configuration.html). + +# Extending Resolver + +Extending supplied resolver is simple, and basically requires same 3 step for whatever extra you want to include Review Comment: three steps ## maven-resolver-supplier/README.md: ## @@ -0,0 +1,52 @@ + + +# Maven Resolver Supplier + +This simple module serves the purpose to "bootstrap" resolver when there is no desire to use Eclipse SISU. It provides +one simple class `org.eclipse.aether.supplier.RepositorySystemSupplier` that implements `Supplier` +and supplies ready-to-use `RepositorySystem` instances. + +The supplier class is written in such way, to allow easy customization if needed: just extend the class and override +method one need (all methods are protected). + +Consumer/User of this module **must provide SLF4J backend**. Resolver uses `slf4j-api` for logging purposes, but this +module does NOT provide any backend for it. It is the consumer/user obligation to provide one at runtime. + +By default, "full resolver experience" is provided: +* for connector, the connector-basic is provided +* for transport the two transport-file and transport-http implementations are provided. If Wagon is needed, add + transport-wagon as dependency, and customize `RepositorySystemSupplier` to include it. This makes it available, but + NOT used yet! To use it, you still need to configure resolver to favor Wagon over native HTTP. + +# Resolver configuration + +The supplier will provide only a "vanilla" instance. To configure resolver, use session user (or +configuration) properties, when constructing session. All the configuration options are available as +[listed here](https://maven.apache.org/resolver/configuration.html). + +# Extending Resolver + +Extending supplied resolver is simple, and basically requires same 3 step for whatever extra you want to include +(like Wagon transport, distributed locking, etc). + +First, you need to included needed module (with transitive deps) to your dependencies. Review Comment: include ## maven-resolver-supplier/README.md: ## @@ -0,0 +1,52 @@ + + +# Maven Resolver Supplier + +This simple module serves the purpose to "bootstrap" resolver when there is no desire to use Eclipse SISU. It provides +one simple class `org.eclipse.aether.supplier.RepositorySystemSupplier` that implements `Supplier` +and supplies ready-to-use `RepositorySystem` instances. + +The supplier class is written in such way, to allow easy customization if needed: just extend the class and override +method one need (all methods are protected). + +Consumer/User of this module **must provide SLF4J backend**. Resolver uses `slf4j-api` for logging purposes, but this +module does NOT provide any backend for it. It is the consumer/user obligation to provide one at runtime. + +By default, "full resolver experience" is provided: +* for connector, the connector-basic is provided +* for transport the two transport-file and transport-http implementations are provided. If Wagon is needed, add + transport-wagon as dependency, and customize `RepositorySystemSupplier` to
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749648#comment-17749648 ] ASF GitHub Bot commented on MRESOLVER-387: -- michael-o commented on PR #319: URL: https://github.com/apache/maven-resolver/pull/319#issuecomment-1660149458 If this is supposed to replace `ServiceLocator` then change the Javadoc of service locator as well. > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #319: [MRESOLVER-387] New RepositorySystem supplier
michael-o commented on code in PR #319: URL: https://github.com/apache/maven-resolver/pull/319#discussion_r1280505936 ## maven-resolver-supplier/README.md: ## @@ -0,0 +1,52 @@ + + +# Maven Resolver Supplier + +This simple module serves the purpose to "bootstrap" resolver when there is no desire to use Eclipse SISU. It provides +one simple class `org.eclipse.aether.supplier.RepositorySystemSupplier` that implements `Supplier` +and supplies ready-to-use `RepositorySystem` instances. + +The supplier class is written in such way, to allow easy customization if needed: just extend the class and override +method one need (all methods are protected). + +Consumer/User of this module **must provide SLF4J backend**. Resolver uses `slf4j-api` for logging purposes, but this +module does NOT provide any backend for it. It is the consumer/user obligation to provide one at runtime. + +By default, "full resolver experience" is provided: +* for connector, the connector-basic is provided +* for transport the two transport-file and transport-http implementations are provided. If Wagon is needed, add + transport-wagon as dependency, and customize `RepositorySystemSupplier` to include it. This makes it available, but + NOT used yet! To use it, you still need to configure resolver to favor Wagon over native HTTP. + +# Resolver configuration + +The supplier will provide only a "vanilla" instance. To configure resolver, use session user (or +configuration) properties, when constructing session. All the configuration options are available as +[listed here](https://maven.apache.org/resolver/configuration.html). + +# Extending Resolver + +Extending supplied resolver is simple, and basically requires same 3 step for whatever extra you want to include Review Comment: three steps ## maven-resolver-supplier/README.md: ## @@ -0,0 +1,52 @@ + + +# Maven Resolver Supplier + +This simple module serves the purpose to "bootstrap" resolver when there is no desire to use Eclipse SISU. It provides +one simple class `org.eclipse.aether.supplier.RepositorySystemSupplier` that implements `Supplier` +and supplies ready-to-use `RepositorySystem` instances. + +The supplier class is written in such way, to allow easy customization if needed: just extend the class and override +method one need (all methods are protected). + +Consumer/User of this module **must provide SLF4J backend**. Resolver uses `slf4j-api` for logging purposes, but this +module does NOT provide any backend for it. It is the consumer/user obligation to provide one at runtime. + +By default, "full resolver experience" is provided: +* for connector, the connector-basic is provided +* for transport the two transport-file and transport-http implementations are provided. If Wagon is needed, add + transport-wagon as dependency, and customize `RepositorySystemSupplier` to include it. This makes it available, but + NOT used yet! To use it, you still need to configure resolver to favor Wagon over native HTTP. + +# Resolver configuration + +The supplier will provide only a "vanilla" instance. To configure resolver, use session user (or +configuration) properties, when constructing session. All the configuration options are available as +[listed here](https://maven.apache.org/resolver/configuration.html). + +# Extending Resolver + +Extending supplied resolver is simple, and basically requires same 3 step for whatever extra you want to include +(like Wagon transport, distributed locking, etc). + +First, you need to included needed module (with transitive deps) to your dependencies. Review Comment: include ## maven-resolver-supplier/README.md: ## @@ -0,0 +1,52 @@ + + +# Maven Resolver Supplier + +This simple module serves the purpose to "bootstrap" resolver when there is no desire to use Eclipse SISU. It provides +one simple class `org.eclipse.aether.supplier.RepositorySystemSupplier` that implements `Supplier` +and supplies ready-to-use `RepositorySystem` instances. + +The supplier class is written in such way, to allow easy customization if needed: just extend the class and override +method one need (all methods are protected). + +Consumer/User of this module **must provide SLF4J backend**. Resolver uses `slf4j-api` for logging purposes, but this +module does NOT provide any backend for it. It is the consumer/user obligation to provide one at runtime. + +By default, "full resolver experience" is provided: +* for connector, the connector-basic is provided +* for transport the two transport-file and transport-http implementations are provided. If Wagon is needed, add + transport-wagon as dependency, and customize `RepositorySystemSupplier` to include it. This makes it available, but + NOT used yet! To use it, you still need to configure resolver to favor Wagon over native HTTP. + +# Resolver configuration + +The supplier will provide only a "vanilla" instance. To configure resolver, use
[jira] [Closed] (MRESOLVER-393) Transport HTTP does not retain last modified as sent by remote end
[ https://issues.apache.org/jira/browse/MRESOLVER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-393. - Resolution: Fixed > Transport HTTP does not retain last modified as sent by remote end > -- > > Key: MRESOLVER-393 > URL: https://issues.apache.org/jira/browse/MRESOLVER-393 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > All files it downloads are created with "now" as timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-393) Transport HTTP does not retain last modified as sent by remote end
[ https://issues.apache.org/jira/browse/MRESOLVER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749637#comment-17749637 ] ASF GitHub Bot commented on MRESOLVER-393: -- cstamas merged PR #323: URL: https://github.com/apache/maven-resolver/pull/323 > Transport HTTP does not retain last modified as sent by remote end > -- > > Key: MRESOLVER-393 > URL: https://issues.apache.org/jira/browse/MRESOLVER-393 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > All files it downloads are created with "now" as timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-393) Transport HTTP does not retain last modified as sent by remote end
[ https://issues.apache.org/jira/browse/MRESOLVER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-393: - Assignee: Tamas Cservenak > Transport HTTP does not retain last modified as sent by remote end > -- > > Key: MRESOLVER-393 > URL: https://issues.apache.org/jira/browse/MRESOLVER-393 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > All files it downloads are created with "now" as timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas merged pull request #323: [MRESOLVER-393] Transport HTTP should retain last-modified
cstamas merged PR #323: URL: https://github.com/apache/maven-resolver/pull/323 -- 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-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749614#comment-17749614 ] ASF GitHub Bot commented on MNG-7848: - slachiewicz commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1660049963 Do You know where we need to adjust it? I believe it's more at Jenkins pipeline level? > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749612#comment-17749612 ] ASF GitHub Bot commented on MNG-7848: - olamy commented on PR #1207: URL: https://github.com/apache/maven/pull/1207#issuecomment-1660043805 @slachiewicz this shouldn’t have to be merged. As @kun-lu20 said in the comment, he will update the notifications to not send to us. The idea was to wait for this merge > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749607#comment-17749607 ] ASF GitHub Bot commented on MNG-7848: - slachiewicz merged PR #1207: URL: https://github.com/apache/maven/pull/1207 > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749586#comment-17749586 ] ASF GitHub Bot commented on MRESOLVER-386: -- cstamas opened a new pull request, #321: URL: https://github.com/apache/maven-resolver/pull/321 All injection points are public and deprecate all def ctors (where ctor injection used). --- https://issues.apache.org/jira/browse/MRESOLVER-386 > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2189) Tests in src/main/java are not detected
[ https://issues.apache.org/jira/browse/SUREFIRE-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Važan updated SUREFIRE-2189: --- Description: There are sometimes reasons to put JUnit tests under src/main/java next to production code. Surefire cannot detect these tests and runs only tests under src/test/java. I tried to set testClassesDirectory to target/classes. That causes surefire to run tests under src/main/java, but then tests under src/test/java are ignored. Changing testClassesDirectory also causes weird module loading exceptions in a bigger project with more dependencies. If you are curious why anyone would put tests in production code, here are my reasons: # I want to run all tests in the background after the app starts in dev environment. Since the tests rarely fail, this lets me shorten edit-test-run cycle into edit-run cycle. # I want to visually annotate app UI that has associated tests. # I want to run tests in production environment as a sanity check. # I want to check compatibility between the app and its environment. This could be done with ordinary code, but structuring it as JUnit tests is convenient and results in clean code. I want to run these tests via surefire too to make sure they aren't already failing in dev environment. # Keeping tests under src/main/java makes them more salient during development. Tests hidden under src/test/java tend to be forgotten during refactoring or when the tested code changes. was: There are sometimes reasons to put JUnit tests under src/main/java next to production code. Surefire cannot detect these tests and runs only tests under src/test/java. I tried to set testClassesDirectory to target/classes. That causes surefire to run tests under src/main/java, but then tests under src/test/java are ignored. Changing testClassesDirectory also causes weird module loading exceptions in a bigger project with more dependencies. If you are curious why anyone would put tests in production code, here are my reasons: # I want to run all tests in the background after the app starts in dev environment. Since the tests rarely fail, this lets me shorten edit-test-run cycle into edit-run cycle. # I want to visually annotate app UI that has associated tests. # I want to run tests in production environment as a sanity check. # I want to check compatibility between the app and its environment. This could be done with ordinary code, but structuring it as JUnit tests is convenient and results in clean code. I want to run these tests via surefire too to make sure they aren't already failing in dev environment. > Tests in src/main/java are not detected > --- > > Key: SUREFIRE-2189 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2189 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support, Maven Surefire Plugin >Affects Versions: 3.1.2 > Environment: Java 17, with or without JPMS >Reporter: Robert Važan >Priority: Major > > There are sometimes reasons to put JUnit tests under src/main/java next to > production code. Surefire cannot detect these tests and runs only tests under > src/test/java. > I tried to set testClassesDirectory to target/classes. That causes surefire > to run tests under src/main/java, but then tests under src/test/java are > ignored. Changing testClassesDirectory also causes weird module loading > exceptions in a bigger project with more dependencies. > If you are curious why anyone would put tests in production code, here are my > reasons: > # I want to run all tests in the background after the app starts in dev > environment. Since the tests rarely fail, this lets me shorten edit-test-run > cycle into edit-run cycle. > # I want to visually annotate app UI that has associated tests. > # I want to run tests in production environment as a sanity check. > # I want to check compatibility between the app and its environment. This > could be done with ordinary code, but structuring it as JUnit tests is > convenient and results in clean code. I want to run these tests via surefire > too to make sure they aren't already failing in dev environment. > # Keeping tests under src/main/java makes them more salient during > development. Tests hidden under src/test/java tend to be forgotten during > refactoring or when the tested code changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749584#comment-17749584 ] ASF GitHub Bot commented on MRESOLVER-386: -- cstamas commented on PR #321: URL: https://github.com/apache/maven-resolver/pull/321#issuecomment-1659933788 WagonTrasnporterFactory injected ctor is missing public modifier > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-386) Make all injected ctors public, deprecate all def ctors
[ https://issues.apache.org/jira/browse/MRESOLVER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749585#comment-17749585 ] ASF GitHub Bot commented on MRESOLVER-386: -- cstamas closed pull request #321: [MRESOLVER-386] Make all injected ctors public, deprecate def ctors URL: https://github.com/apache/maven-resolver/pull/321 > Make all injected ctors public, deprecate all def ctors > --- > > Key: MRESOLVER-386 > URL: https://issues.apache.org/jira/browse/MRESOLVER-386 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > Example: DF and BF collector ctors: The two ctors (are also injected) are > package protected, making integrating code forced to use deprecated no-arg > ctor. > Actually, make sure all injection points are public as well and deprecate all > def ctors (where ctor injection used). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #321: [MRESOLVER-386] Make all injected ctors public, deprecate def ctors
cstamas closed pull request #321: [MRESOLVER-386] Make all injected ctors public, deprecate def ctors URL: https://github.com/apache/maven-resolver/pull/321 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SUREFIRE-2189) Tests in src/main/java are not detected
[ https://issues.apache.org/jira/browse/SUREFIRE-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Važan updated SUREFIRE-2189: --- Description: There are sometimes reasons to put JUnit tests under src/main/java next to production code. Surefire cannot detect these tests and runs only tests under src/test/java. I tried to set testClassesDirectory to target/classes. That causes surefire to run tests under src/main/java, but then tests under src/test/java are ignored. Changing testClassesDirectory also causes weird module loading exceptions in a bigger project with more dependencies. If you are curious why anyone would put tests in production code, here are my reasons: # I want to run all tests in the background after the app starts in dev environment. Since the tests rarely fail, this lets me shorten edit-test-run cycle into edit-run cycle. # I want to visually annotate app UI that has associated tests. # I want to run tests in production environment as a sanity check. # I want to check compatibility between the app and its environment. This could be done with ordinary code, but structuring it as JUnit tests is convenient and results in clean code. I want to run these tests via surefire too to make sure they aren't already failing in dev environment. was: There are sometimes reasons to put JUnit tests under src/main/java next to production code. Surefire cannot detect these tests and runs only tests under src/test/java. I tried to set testClassesDirectory to target/classes. That causes surefire to run tests under src/main/java, but then tests under src/test/java are ignored. Changing testClassesDirectory also causes weird module loading exceptions in a bigger project with more dependencies. If you are curious why anyone would put tests in production code, here are my reasons: # I want to run all tests in the background after the app starts in dev environment. Since the tests rarely fail, this lets me shorten edit-test-run cycle into edit-run cycle. # I want to visually annotate app UI that has associated tests. # I want to run tests in production environment as a sanity check. # I want to check compatibility between the app and its environment. This could be done with ordinary code, but structuring it as JUnit tests is convenient and results in clean code. > Tests in src/main/java are not detected > --- > > Key: SUREFIRE-2189 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2189 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support, Maven Surefire Plugin >Affects Versions: 3.1.2 > Environment: Java 17, with or without JPMS >Reporter: Robert Važan >Priority: Major > > There are sometimes reasons to put JUnit tests under src/main/java next to > production code. Surefire cannot detect these tests and runs only tests under > src/test/java. > I tried to set testClassesDirectory to target/classes. That causes surefire > to run tests under src/main/java, but then tests under src/test/java are > ignored. Changing testClassesDirectory also causes weird module loading > exceptions in a bigger project with more dependencies. > If you are curious why anyone would put tests in production code, here are my > reasons: > # I want to run all tests in the background after the app starts in dev > environment. Since the tests rarely fail, this lets me shorten edit-test-run > cycle into edit-run cycle. > # I want to visually annotate app UI that has associated tests. > # I want to run tests in production environment as a sanity check. > # I want to check compatibility between the app and its environment. This > could be done with ordinary code, but structuring it as JUnit tests is > convenient and results in clean code. I want to run these tests via surefire > too to make sure they aren't already failing in dev environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2189) Tests in src/main/java are not detected
[ https://issues.apache.org/jira/browse/SUREFIRE-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Važan updated SUREFIRE-2189: --- Description: There are sometimes reasons to put JUnit tests under src/main/java next to production code. Surefire cannot detect these tests and runs only tests under src/test/java. I tried to set testClassesDirectory to target/classes. That causes surefire to run tests under src/main/java, but then tests under src/test/java are ignored. Changing testClassesDirectory also causes weird module loading exceptions in a bigger project with more dependencies. If you are curious why anyone would put tests in production code, here are my reasons: # I want to run all tests in the background after the app starts in dev environment. Since the tests rarely fail, this lets me shorten edit-test-run cycle into edit-run cycle. # I want to visually annotate app UI that has associated tests. # I want to run tests in production environment as a sanity check. # I want to check compatibility between the app and its environment. This could be done with ordinary code, but structuring it as JUnit tests is convenient and results in clean code. was: There are sometimes reasons to put JUnit tests under src/main/java next to production code. Surefire cannot detect these tests and runs only tests under src/test/java. I tried to set testClassesDirectory to target/classes. That causes surefire to run tests under src/main/java, but then tests under src/test/java are ignored. Changing testClassesDirectory also causes weird module loading exceptions in a bigger project with more dependencies. If you are curious why anyone would put test in production code, here are my reasons: # I want to run all tests in the background after the app starts in dev environment. Since the tests rarely fail, this lets me shorten edit-test-run cycle into edit-run cycle. # I want to visually annotate app UI that has associated tests. # I want to run tests in production environment as a sanity check. # I want to check compatibility between the app and its environment. This could be done with ordinary code, but structuring it as JUnit tests is convenient and results in clean code. > Tests in src/main/java are not detected > --- > > Key: SUREFIRE-2189 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2189 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support, Maven Surefire Plugin >Affects Versions: 3.1.2 > Environment: Java 17, with or without JPMS >Reporter: Robert Važan >Priority: Major > > There are sometimes reasons to put JUnit tests under src/main/java next to > production code. Surefire cannot detect these tests and runs only tests under > src/test/java. > I tried to set testClassesDirectory to target/classes. That causes surefire > to run tests under src/main/java, but then tests under src/test/java are > ignored. Changing testClassesDirectory also causes weird module loading > exceptions in a bigger project with more dependencies. > If you are curious why anyone would put tests in production code, here are my > reasons: > # I want to run all tests in the background after the app starts in dev > environment. Since the tests rarely fail, this lets me shorten edit-test-run > cycle into edit-run cycle. > # I want to visually annotate app UI that has associated tests. > # I want to run tests in production environment as a sanity check. > # I want to check compatibility between the app and its environment. This > could be done with ordinary code, but structuring it as JUnit tests is > convenient and results in clean code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SUREFIRE-2189) Tests in src/main/java are not detected
Robert Važan created SUREFIRE-2189: -- Summary: Tests in src/main/java are not detected Key: SUREFIRE-2189 URL: https://issues.apache.org/jira/browse/SUREFIRE-2189 Project: Maven Surefire Issue Type: Bug Components: JUnit 5.x support, Maven Surefire Plugin Affects Versions: 3.1.2 Environment: Java 17, with or without JPMS Reporter: Robert Važan There are sometimes reasons to put JUnit tests under src/main/java next to production code. Surefire cannot detect these tests and runs only tests under src/test/java. I tried to set testClassesDirectory to target/classes. That causes surefire to run tests under src/main/java, but then tests under src/test/java are ignored. Changing testClassesDirectory also causes weird module loading exceptions in a bigger project with more dependencies. If you are curious why anyone would put test in production code, here are my reasons: # I want to run all tests in the background after the app starts in dev environment. Since the tests rarely fail, this lets me shorten edit-test-run cycle into edit-run cycle. # I want to visually annotate app UI that has associated tests. # I want to run tests in production environment as a sanity check. # I want to check compatibility between the app and its environment. This could be done with ordinary code, but structuring it as JUnit tests is convenient and results in clean code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
