[jira] [Comment Edited] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
[ https://issues.apache.org/jira/browse/MRESOLVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736646#comment-17736646 ] Victor Rubezhny edited comment on MRESOLVER-374 at 6/24/23 12:47 AM: - You nay find the full build logs in [PR Check |https://github.com/eclipse/lemminx-maven/pull/422] `Details` of [Windows PR CI / build (pull_request) (Windows) |https://github.com/eclipse/lemminx-maven/actions/runs/5357211056/jobs/9717765237?pr=422] and [continuous-integration/jenkins/pr-merge (linux)|https://ci.eclipse.org/lemminx/job/LemMinX-Maven/job/PR-422/4/display/redirect] was (Author: vrubezhny): You nay find the full build logs in `Details` of [Windows PR CI / build (pull_request) (Windows) |https://github.com/eclipse/lemminx-maven/actions/runs/5357211056/jobs/9717765237?pr=422] and [continuous-integration/jenkins/pr-merge (linux)|https://ci.eclipse.org/lemminx/job/LemMinX-Maven/job/PR-422/4/display/redirect] > With v.1.9.13 70% of acquire lock attempts end up with > java.lang.IllegalStateException: Could not acquire lock(s) > - > > Key: MRESOLVER-374 > URL: https://issues.apache.org/jira/browse/MRESOLVER-374 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Victor Rubezhny >Priority: Major > > While trying to update the maven resolver dependency of Lemminx-Maven project > to v. 1.9.13 we faced the following problem - > [https://github.com/eclipse/lemminx-maven/pull/422] > With version v.1.9.13 more than 70% of attempts to build a Maven Project end > up with getting `.IllegalStateException: Could not acquire lock(s)` exception: > > ``` > Jun 23, 2023 2:23:02 PM > org.eclipse.lemminx.extensions.maven.MavenProjectCache parseAndCache > SEVERE: Could not acquire lock(s) > java.lang.IllegalStateException: Could not acquire lock(s) > at > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) > 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.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:231) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108) > at > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222) > at > org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305) > at > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151) > at > org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:224) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:202) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:139) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:159) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:240) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.check(MavenProjectCache.java:130) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.getLastSuccessfulMavenProject(MavenProjectCache.java:105) > at >
[jira] [Commented] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
[ https://issues.apache.org/jira/browse/MRESOLVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736646#comment-17736646 ] Victor Rubezhny commented on MRESOLVER-374: --- You nay find the full build logs in `Details` of [Windows PR CI / build (pull_request) (Windows) |https://github.com/eclipse/lemminx-maven/actions/runs/5357211056/jobs/9717765237?pr=422] and [continuous-integration/jenkins/pr-merge (linux)|https://ci.eclipse.org/lemminx/job/LemMinX-Maven/job/PR-422/4/display/redirect] > With v.1.9.13 70% of acquire lock attempts end up with > java.lang.IllegalStateException: Could not acquire lock(s) > - > > Key: MRESOLVER-374 > URL: https://issues.apache.org/jira/browse/MRESOLVER-374 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Victor Rubezhny >Priority: Major > > While trying to update the maven resolver dependency of Lemminx-Maven project > to v. 1.9.13 we faced the following problem - > [https://github.com/eclipse/lemminx-maven/pull/422] > With version v.1.9.13 more than 70% of attempts to build a Maven Project end > up with getting `.IllegalStateException: Could not acquire lock(s)` exception: > > ``` > Jun 23, 2023 2:23:02 PM > org.eclipse.lemminx.extensions.maven.MavenProjectCache parseAndCache > SEVERE: Could not acquire lock(s) > java.lang.IllegalStateException: Could not acquire lock(s) > at > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) > 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.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:231) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108) > at > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222) > at > org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305) > at > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151) > at > org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:224) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:202) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:139) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:159) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:240) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.check(MavenProjectCache.java:130) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.getLastSuccessfulMavenProject(MavenProjectCache.java:105) > at > org.eclipse.lemminx.extensions.maven.MavenLemminxWorkspaceReader$ResolveArtifactsAndPopulateWorkspaceRunnable.run(MavenLemminxWorkspaceReader.java:79) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:833) > Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire > write lock for 'artifact:org.test.modules:ModuleA:0.0.1-SNAPSHOT' in 30 > SECONDS > at >
[jira] [Comment Edited] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
[ https://issues.apache.org/jira/browse/MRESOLVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736643#comment-17736643 ] Victor Rubezhny edited comment on MRESOLVER-374 at 6/24/23 12:37 AM: - Note that this never happened with v.1.9.12 - there probably were some problems with resolve (at least I suspect so), but NOT that serious - at least I haven't seen locking problems for quite a long time. I tried (from Lemminx-Maven side) to exclude the resolving for Maven project dependencies (by `setResolveDependencies(false)` on `ProjectBuildingRequest` used when building a project) - this has made the stacktrace shorter, but still `NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire()` is invoked and threw `IllegalStateException` the same number of cases: ``` Jun 24, 2023 2:35:48 AM org.eclipse.lemminx.extensions.maven.MavenProjectCache getSnapshotProject SEVERE: Could not acquire lock(s) java.lang.IllegalStateException: Could not acquire lock(s) at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) 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.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:277) at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:172) at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:218) at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1009) at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:801) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:327) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:243) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:176) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:123) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.getSnapshotProject(MavenProjectCache.java:149) at org.eclipse.lemminx.extensions.maven.MavenLemminxWorkspaceReader$ResolveArtifactsAndPopulateWorkspaceRunnable.run(MavenLemminxWorkspaceReader.java:88) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire write lock for 'artifact:mygroup:root:0.0.1-SNAPSHOT' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) ... 17 more Suppressed: java.lang.IllegalStateException: Attempt 2: Could not acquire write lock for 'artifact:mygroup:root:0.0.1-SNAPSHOT' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) ... 17 more ``` was (Author: vrubezhny): Note that this never happened with v.1.9.12 - there probably were some problems with resolve (at least I suspect so), but NOT that serious - at least I haven't seen locking problems for quite a long time. I tried (from Lemminx-Maven side) to exclude the resolving for Maven project dependencies (by `setResolveDependencies(false)` on `ProjectBuildingRequest` used when building a project) - this has made the stacktrace shorter, but still `NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire()` is invoked and threw `IllegalStateException` the same number of cases. > With v.1.9.13 70% of acquire lock attempts end up with > java.lang.IllegalStateException: Could not acquire lock(s) > - > > Key: MRESOLVER-374 > URL: https://issues.apache.org/jira/browse/MRESOLVER-374 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Victor Rubezhny >Priority: Major > > While trying to update the maven resolver dependency of Lemminx-Maven project > to v. 1.9.13 we faced the following problem - > [https://github.com/eclipse/lemminx-maven/pull/422] > With version v.1.9.13 more
[jira] [Commented] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
[ https://issues.apache.org/jira/browse/MRESOLVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736643#comment-17736643 ] Victor Rubezhny commented on MRESOLVER-374: --- Note that this never happened with v.1.9.12 - there probably were some problems with resolve (at least I suspect so), but NOT that serious - at least I haven't seen locking problems for quite a long time. I tried (from Lemminx-Maven side) to exclude the resolving for Maven project dependencies (by `setResolveDependencies(false)` on `ProjectBuildingRequest` used when building a project) - this has made the stacktrace shorter, but still `NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire()` is invoked and threw `IllegalStateException` the same number of cases. > With v.1.9.13 70% of acquire lock attempts end up with > java.lang.IllegalStateException: Could not acquire lock(s) > - > > Key: MRESOLVER-374 > URL: https://issues.apache.org/jira/browse/MRESOLVER-374 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Victor Rubezhny >Priority: Major > > While trying to update the maven resolver dependency of Lemminx-Maven project > to v. 1.9.13 we faced the following problem - > [https://github.com/eclipse/lemminx-maven/pull/422] > With version v.1.9.13 more than 70% of attempts to build a Maven Project end > up with getting `.IllegalStateException: Could not acquire lock(s)` exception: > > ``` > Jun 23, 2023 2:23:02 PM > org.eclipse.lemminx.extensions.maven.MavenProjectCache parseAndCache > SEVERE: Could not acquire lock(s) > java.lang.IllegalStateException: Could not acquire lock(s) > at > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) > 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.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:231) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108) > at > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222) > at > org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305) > at > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151) > at > org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:224) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:202) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:139) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:159) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:240) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.check(MavenProjectCache.java:130) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.getLastSuccessfulMavenProject(MavenProjectCache.java:105) > at > org.eclipse.lemminx.extensions.maven.MavenLemminxWorkspaceReader$ResolveArtifactsAndPopulateWorkspaceRunnable.run(MavenLemminxWorkspaceReader.java:79) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at >
[jira] [Commented] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
[ https://issues.apache.org/jira/browse/MRESOLVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736641#comment-17736641 ] Tamas Cservenak commented on MRESOLVER-374: --- Hm, that sounds very bad... Otp right now, will take a peek at pr. > With v.1.9.13 70% of acquire lock attempts end up with > java.lang.IllegalStateException: Could not acquire lock(s) > - > > Key: MRESOLVER-374 > URL: https://issues.apache.org/jira/browse/MRESOLVER-374 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.13 >Reporter: Victor Rubezhny >Priority: Major > > While trying to update the maven resolver dependency of Lemminx-Maven project > to v. 1.9.13 we faced the following problem - > [https://github.com/eclipse/lemminx-maven/pull/422] > With version v.1.9.13 more than 70% of attempts to build a Maven Project end > up with getting `.IllegalStateException: Could not acquire lock(s)` exception: > > ``` > Jun 23, 2023 2:23:02 PM > org.eclipse.lemminx.extensions.maven.MavenProjectCache parseAndCache > SEVERE: Could not acquire lock(s) > java.lang.IllegalStateException: Could not acquire lock(s) > at > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) > 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.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:231) > at > org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138) > at > org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108) > at > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222) > at > org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305) > at > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151) > at > org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:224) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:202) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:139) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:159) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:240) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.check(MavenProjectCache.java:130) > at > org.eclipse.lemminx.extensions.maven.MavenProjectCache.getLastSuccessfulMavenProject(MavenProjectCache.java:105) > at > org.eclipse.lemminx.extensions.maven.MavenLemminxWorkspaceReader$ResolveArtifactsAndPopulateWorkspaceRunnable.run(MavenLemminxWorkspaceReader.java:79) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:833) > Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire > write lock for 'artifact:org.test.modules:ModuleA:0.0.1-SNAPSHOT' in 30 > SECONDS > at > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) > ... 26 more > Suppressed: java.lang.IllegalStateException: Attempt 2: Could not acquire > write lock for
[jira] [Updated] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
[ https://issues.apache.org/jira/browse/MRESOLVER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Victor Rubezhny updated MRESOLVER-374: -- Description: While trying to update the maven resolver dependency of Lemminx-Maven project to v. 1.9.13 we faced the following problem - [https://github.com/eclipse/lemminx-maven/pull/422] With version v.1.9.13 more than 70% of attempts to build a Maven Project end up with getting `.IllegalStateException: Could not acquire lock(s)` exception: ``` Jun 23, 2023 2:23:02 PM org.eclipse.lemminx.extensions.maven.MavenProjectCache parseAndCache SEVERE: Could not acquire lock(s) java.lang.IllegalStateException: Could not acquire lock(s) at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) 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.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:231) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108) at org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151) at org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:224) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:202) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:139) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:159) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:240) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.check(MavenProjectCache.java:130) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.getLastSuccessfulMavenProject(MavenProjectCache.java:105) at org.eclipse.lemminx.extensions.maven.MavenLemminxWorkspaceReader$ResolveArtifactsAndPopulateWorkspaceRunnable.run(MavenLemminxWorkspaceReader.java:79) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire write lock for 'artifact:org.test.modules:ModuleA:0.0.1-SNAPSHOT' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) ... 26 more Suppressed: java.lang.IllegalStateException: Attempt 2: Could not acquire write lock for 'artifact:org.test.modules:ModuleA:0.0.1-SNAPSHOT' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) ... 26 more ``` Every such failing attempt to acquire a lock takes ~60 seconds to finish (fail) - while normally a test Maven Project (from Lemminx-Maven JUnit tests) takes 5-50 ms to resolve. So building and running JUnit tests with maven-resolver v.1.9.13 took 3h 16m while it normally takes about 7m 30s to finish. Not a single `ProjectBuildingException` is returned during the tests so no recovery is possible for the projects that cannot be built for various reasons, as well as we don't have any statistics on how many "good and buildable' vs. `bad and not
[jira] [Created] (MRESOLVER-374) With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s)
Victor Rubezhny created MRESOLVER-374: - Summary: With v.1.9.13 70% of acquire lock attempts end up with java.lang.IllegalStateException: Could not acquire lock(s) Key: MRESOLVER-374 URL: https://issues.apache.org/jira/browse/MRESOLVER-374 Project: Maven Resolver Issue Type: Bug Components: Resolver Affects Versions: 1.9.13 Reporter: Victor Rubezhny While trying to update the maven resolver dependency of Lemminx-Maven project to v. 1.9.13 we faced the following problem - https://github.com/eclipse/lemminx-maven/pull/422 With version v.1.9.13 more than 70% of attempts to build a Maven Project end up with getting `.IllegalStateException: Could not acquire lock(s)` exception: ``` Jun 23, 2023 2:23:02 PM org.eclipse.lemminx.extensions.maven.MavenProjectCache parseAndCache SEVERE: Could not acquire lock(s) java.lang.IllegalStateException: Could not acquire lock(s) at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:219) 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.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:231) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108) at org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222) at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151) at org.apache.maven.project.DefaultProjectBuilder.resolveDependencies(DefaultProjectBuilder.java:224) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:202) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:139) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:159) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.parseAndCache(MavenProjectCache.java:240) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.check(MavenProjectCache.java:130) at org.eclipse.lemminx.extensions.maven.MavenProjectCache.getLastSuccessfulMavenProject(MavenProjectCache.java:105) at org.eclipse.lemminx.extensions.maven.MavenLemminxWorkspaceReader$ResolveArtifactsAndPopulateWorkspaceRunnable.run(MavenLemminxWorkspaceReader.java:79) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire write lock for 'artifact:org.test.modules:ModuleA:0.0.1-SNAPSHOT' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) ... 26 more Suppressed: java.lang.IllegalStateException: Attempt 2: Could not acquire write lock for 'artifact:org.test.modules:ModuleA:0.0.1-SNAPSHOT' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:202) ... 26 more ``` Every such failing attempt to acquire a lock takes ~60 seconds to finish (fail) - while normally a test Maven Project (from Lemminx-Maven JUnit tests) takes 5-50 ms to resolve. So building and running JUnit tests with maven-resolver v.1.9.13 took 3h 16m while it normally takes about 7m 30s to
[jira] [Closed] (MNG-7824) Bump plexus-xml from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MNG-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7824. Resolution: Fixed > Bump plexus-xml from 4.0.0 to 4.0.1 > --- > > Key: MNG-7824 > URL: https://issues.apache.org/jira/browse/MNG-7824 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7824) Bump plexus-xml from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MNG-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-7824: Assignee: Guillaume Nodet > Bump plexus-xml from 4.0.0 to 4.0.1 > --- > > Key: MNG-7824 > URL: https://issues.apache.org/jira/browse/MNG-7824 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7824) Bump plexus-xml from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MNG-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736615#comment-17736615 ] Elliotte Rusty Harold commented on MNG-7824: any release notes for this anywhere? The website hasn't been updated to 4.0.1: https://codehaus-plexus.github.io/plexus-xml/ > Bump plexus-xml from 4.0.0 to 4.0.1 > --- > > Key: MNG-7824 > URL: https://issues.apache.org/jira/browse/MNG-7824 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7824) Bump plexus-xml from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MNG-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736616#comment-17736616 ] ASF GitHub Bot commented on MNG-7824: - gnodet merged PR #1184: URL: https://github.com/apache/maven/pull/1184 > Bump plexus-xml from 4.0.0 to 4.0.1 > --- > > Key: MNG-7824 > URL: https://issues.apache.org/jira/browse/MNG-7824 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] dependabot[bot] commented on pull request #1161: Bump guava from 30.1-jre to 32.0.0-jre
dependabot[bot] commented on PR #1161: URL: https://github.com/apache/maven/pull/1161#issuecomment-1604950145 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`. 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] elharo closed pull request #1161: Bump guava from 30.1-jre to 32.0.0-jre
elharo closed pull request #1161: Bump guava from 30.1-jre to 32.0.0-jre URL: https://github.com/apache/maven/pull/1161 -- 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] elharo commented on a diff in pull request #1179: Remove references to deprecated ReaderFactory in non generated code
elharo commented on code in PR #1179: URL: https://github.com/apache/maven/pull/1179#discussion_r1240382329 ## maven-compat/src/main/java/org/apache/maven/artifact/repository/metadata/AbstractRepositoryMetadata.java: ## @@ -29,8 +29,8 @@ import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Writer; -import org.codehaus.plexus.util.ReaderFactory; -import org.codehaus.plexus.util.WriterFactory; +import org.codehaus.plexus.util.xml.XmlStreamReader; Review Comment: best of all possible worlds. +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
[jira] [Updated] (MNG-7228) MavenProject.getOriginalModel returns interpolated parts
[
https://issues.apache.org/jira/browse/MNG-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7228:
-
Fix Version/s: 4.0.0-alpha-7
(was: 4.0.0-alpha-8)
> MavenProject.getOriginalModel returns interpolated parts
>
>
> Key: MNG-7228
> URL: https://issues.apache.org/jira/browse/MNG-7228
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.0-alpha-7
>
>
> I have tested the maven-enforcer-plugin 3.0.0 running in a project where I
> use the following configuration:
> {code:xml}
>
> The rules for repo1.maven.org are that pom.xml
> files should not include repository definitions. If
> repository definitions are included, they must be limited
> to SNAPSHOT only repositories.
> true
> true
> true
>
>
> {code}
> The project works correct with Maven 3.X but fails with Maven 4.X (current
> state of master 92d2c2e3b43ca214989f0f517aa90f1525f0ff2e).
> After some investigation it looks like that the
> {{mavenProject.getOriginalModel()}} returns already interpolated model and
> **NOT** the original model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7824) Bump plexus-xml from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MNG-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7824: - Fix Version/s: 4.0.0-alpha-7 (was: 4.0.0-alpha-8) > Bump plexus-xml from 4.0.0 to 4.0.1 > --- > > Key: MNG-7824 > URL: https://issues.apache.org/jira/browse/MNG-7824 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1179: Remove references to deprecated ReaderFactory in non generated code
gnodet commented on code in PR #1179: URL: https://github.com/apache/maven/pull/1179#discussion_r1240171985 ## maven-compat/src/main/java/org/apache/maven/artifact/repository/metadata/AbstractRepositoryMetadata.java: ## @@ -29,8 +29,8 @@ import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Writer; -import org.codehaus.plexus.util.ReaderFactory; -import org.codehaus.plexus.util.WriterFactory; +import org.codehaus.plexus.util.xml.XmlStreamReader; Review Comment: Actually, I think the usage of those classes is just wrong and they already have caused issues with tycho. So I'll modify this PR to simply use plain InputStream / OutputStream as the parser should be responsible for handling the encoding. -- 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-7824) Bump plexus-xml from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MNG-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736605#comment-17736605 ] ASF GitHub Bot commented on MNG-7824: - gnodet opened a new pull request, #1184: URL: https://github.com/apache/maven/pull/1184 JIRA issue: https://issues.apache.org/jira/browse/MNG-7824 > Bump plexus-xml from 4.0.0 to 4.0.1 > --- > > Key: MNG-7824 > URL: https://issues.apache.org/jira/browse/MNG-7824 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7824) Bump plexus-xml from 4.0.0 to 4.0.1
Guillaume Nodet created MNG-7824: Summary: Bump plexus-xml from 4.0.0 to 4.0.1 Key: MNG-7824 URL: https://issues.apache.org/jira/browse/MNG-7824 Project: Maven Issue Type: Dependency upgrade Reporter: Guillaume Nodet Fix For: 4.0.0-alpha-7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] cstamas opened a new pull request, #273: [MNG-7228] Add IT that ensure nothing "leaks" into installe model
cstamas opened a new pull request, #273: URL: https://github.com/apache/maven-integration-testing/pull/273 (no comment) -- 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 diff in pull request #1179: Remove references to deprecated ReaderFactory in non generated code
gnodet commented on code in PR #1179: URL: https://github.com/apache/maven/pull/1179#discussion_r1240171985 ## maven-compat/src/main/java/org/apache/maven/artifact/repository/metadata/AbstractRepositoryMetadata.java: ## @@ -29,8 +29,8 @@ import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Writer; -import org.codehaus.plexus.util.ReaderFactory; -import org.codehaus.plexus.util.WriterFactory; +import org.codehaus.plexus.util.xml.XmlStreamReader; Review Comment: Actually, I think the usage of those classes is just wrong and they already have caused issues with tycho. So I'll modify this PR to simply use plain InputStream / OutputStream. -- 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] elharo commented on a diff in pull request #1179: Remove references to deprecated ReaderFactory in non generated code
elharo commented on code in PR #1179: URL: https://github.com/apache/maven/pull/1179#discussion_r1240146420 ## maven-compat/src/main/java/org/apache/maven/artifact/repository/metadata/AbstractRepositoryMetadata.java: ## @@ -29,8 +29,8 @@ import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Writer; -import org.codehaus.plexus.util.ReaderFactory; -import org.codehaus.plexus.util.WriterFactory; +import org.codehaus.plexus.util.xml.XmlStreamReader; Review Comment: It;s not just about going away. I have more expectation that the version in apache commons will be maintained and correct than the one in plexus. -- 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-7228) MavenProject.getOriginalModel returns interpolated parts
[
https://issues.apache.org/jira/browse/MNG-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736587#comment-17736587
]
ASF GitHub Bot commented on MNG-7228:
-
cstamas commented on PR #1183:
URL: https://github.com/apache/maven/pull/1183#issuecomment-1604662507
Confirmed: MIMA build now behaves, unlike with 4-alpha-6 ✅
> MavenProject.getOriginalModel returns interpolated parts
>
>
> Key: MNG-7228
> URL: https://issues.apache.org/jira/browse/MNG-7228
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.0-alpha-7
>
>
> I have tested the maven-enforcer-plugin 3.0.0 running in a project where I
> use the following configuration:
> {code:xml}
>
> The rules for repo1.maven.org are that pom.xml
> files should not include repository definitions. If
> repository definitions are included, they must be limited
> to SNAPSHOT only repositories.
> true
> true
> true
>
>
> {code}
> The project works correct with Maven 3.X but fails with Maven 4.X (current
> state of master 92d2c2e3b43ca214989f0f517aa90f1525f0ff2e).
> After some investigation it looks like that the
> {{mavenProject.getOriginalModel()}} returns already interpolated model and
> **NOT** the original model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1183: [MNG-7228] MavenProject.getOriginalModel returns interpolated parts
cstamas commented on PR #1183: URL: https://github.com/apache/maven/pull/1183#issuecomment-1604662507 Confirmed: MIMA build now behaves, unlike with 4-alpha-6 ✅ -- 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 diff in pull request #1179: Remove references to deprecated ReaderFactory in non generated code
gnodet commented on code in PR #1179: URL: https://github.com/apache/maven/pull/1179#discussion_r1240141249 ## maven-compat/src/main/java/org/apache/maven/artifact/repository/metadata/AbstractRepositoryMetadata.java: ## @@ -29,8 +29,8 @@ import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Writer; -import org.codehaus.plexus.util.ReaderFactory; -import org.codehaus.plexus.util.WriterFactory; +import org.codehaus.plexus.util.xml.XmlStreamReader; Review Comment: I don't want to introduce a new dependency for one class. This one is in plexus-xml which won't go away any time soon. We may be able to get rid of plexus-utils, but not plexus-xml which contains classes that are part of the maven 3 api. -- 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-7228) MavenProject.getOriginalModel returns interpolated parts
[
https://issues.apache.org/jira/browse/MNG-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7228:
-
Priority: Blocker (was: Minor)
> MavenProject.getOriginalModel returns interpolated parts
>
>
> Key: MNG-7228
> URL: https://issues.apache.org/jira/browse/MNG-7228
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.0-alpha-7
>
>
> I have tested the maven-enforcer-plugin 3.0.0 running in a project where I
> use the following configuration:
> {code:xml}
>
> The rules for repo1.maven.org are that pom.xml
> files should not include repository definitions. If
> repository definitions are included, they must be limited
> to SNAPSHOT only repositories.
> true
> true
> true
>
>
> {code}
> The project works correct with Maven 3.X but fails with Maven 4.X (current
> state of master 92d2c2e3b43ca214989f0f517aa90f1525f0ff2e).
> After some investigation it looks like that the
> {{mavenProject.getOriginalModel()}} returns already interpolated model and
> **NOT** the original model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7228) MavenProject.getOriginalModel returns interpolated parts
[
https://issues.apache.org/jira/browse/MNG-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736584#comment-17736584
]
Guillaume Nodet commented on MNG-7228:
--
This is quite a big problem as this issue cause projects using
maven-shade-plugin to leak sensitive information during release and can put
properties containing passwords, passkeys and such information from
{{settings.xml}} into the deployed pom.
> MavenProject.getOriginalModel returns interpolated parts
>
>
> Key: MNG-7228
> URL: https://issues.apache.org/jira/browse/MNG-7228
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-alpha-7
>
>
> I have tested the maven-enforcer-plugin 3.0.0 running in a project where I
> use the following configuration:
> {code:xml}
>
> The rules for repo1.maven.org are that pom.xml
> files should not include repository definitions. If
> repository definitions are included, they must be limited
> to SNAPSHOT only repositories.
> true
> true
> true
>
>
> {code}
> The project works correct with Maven 3.X but fails with Maven 4.X (current
> state of master 92d2c2e3b43ca214989f0f517aa90f1525f0ff2e).
> After some investigation it looks like that the
> {{mavenProject.getOriginalModel()}} returns already interpolated model and
> **NOT** the original model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7228) MavenProject.getOriginalModel returns interpolated parts
[
https://issues.apache.org/jira/browse/MNG-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7228:
-
Fix Version/s: 4.0.0-alpha-7
(was: 4.0.x-candidate)
(was: 4.0.0)
> MavenProject.getOriginalModel returns interpolated parts
>
>
> Key: MNG-7228
> URL: https://issues.apache.org/jira/browse/MNG-7228
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-alpha-7
>
>
> I have tested the maven-enforcer-plugin 3.0.0 running in a project where I
> use the following configuration:
> {code:xml}
>
> The rules for repo1.maven.org are that pom.xml
> files should not include repository definitions. If
> repository definitions are included, they must be limited
> to SNAPSHOT only repositories.
> true
> true
> true
>
>
> {code}
> The project works correct with Maven 3.X but fails with Maven 4.X (current
> state of master 92d2c2e3b43ca214989f0f517aa90f1525f0ff2e).
> After some investigation it looks like that the
> {{mavenProject.getOriginalModel()}} returns already interpolated model and
> **NOT** the original model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7228) MavenProject.getOriginalModel returns interpolated parts
[
https://issues.apache.org/jira/browse/MNG-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7228:
-
Affects Version/s: (was: 3.0-alpha-1)
> MavenProject.getOriginalModel returns interpolated parts
>
>
> Key: MNG-7228
> URL: https://issues.apache.org/jira/browse/MNG-7228
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> I have tested the maven-enforcer-plugin 3.0.0 running in a project where I
> use the following configuration:
> {code:xml}
>
> The rules for repo1.maven.org are that pom.xml
> files should not include repository definitions. If
> repository definitions are included, they must be limited
> to SNAPSHOT only repositories.
> true
> true
> true
>
>
> {code}
> The project works correct with Maven 3.X but fails with Maven 4.X (current
> state of master 92d2c2e3b43ca214989f0f517aa90f1525f0ff2e).
> After some investigation it looks like that the
> {{mavenProject.getOriginalModel()}} returns already interpolated model and
> **NOT** the original model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7228) MavenProject.getOriginalModel returns interpolated parts
[
https://issues.apache.org/jira/browse/MNG-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7228:
Assignee: Guillaume Nodet
> MavenProject.getOriginalModel returns interpolated parts
>
>
> Key: MNG-7228
> URL: https://issues.apache.org/jira/browse/MNG-7228
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0-alpha-1, 4.0.0-alpha-3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.x-candidate, 4.0.0
>
>
> I have tested the maven-enforcer-plugin 3.0.0 running in a project where I
> use the following configuration:
> {code:xml}
>
> The rules for repo1.maven.org are that pom.xml
> files should not include repository definitions. If
> repository definitions are included, they must be limited
> to SNAPSHOT only repositories.
> true
> true
> true
>
>
> {code}
> The project works correct with Maven 3.X but fails with Maven 4.X (current
> state of master 92d2c2e3b43ca214989f0f517aa90f1525f0ff2e).
> After some investigation it looks like that the
> {{mavenProject.getOriginalModel()}} returns already interpolated model and
> **NOT** the original model.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet opened a new pull request, #1183: Fix missing clone
gnodet opened a new pull request, #1183: URL: https://github.com/apache/maven/pull/1183 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. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both 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] [Updated] (MNG-7592) String deduplication in model building
[ https://issues.apache.org/jira/browse/MNG-7592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7592: - Fix Version/s: 4.0.x-candidate > String deduplication in model building > -- > > Key: MNG-7592 > URL: https://issues.apache.org/jira/browse/MNG-7592 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: 4.0.x-candidate > > > I currently investigate improving memory consumption in m2eclipse (maven ide > extension) and noticed that one problem is that maven model seem to not > deduplicate strings, so for large projects (I used apache camel as an > example), there are a lot of duplicate strings hanging around, e.g. I see > 12.000 instances of "org.apache.maven.plugins" or around 10.000 of > "org.apache.camel" (please note that probably not all related to maven!). > If I look at the Graph of incoming references I see for example that these > are from Model/Artifact groupId. > I know that string deduplication in general is hard and even controversial, > but maybe one could think about such thing at least for the "hotsposts", e,g, > groupId, artifactId and version or even managementKeys seem good candidates > to be considered for such thing as these are used all over the place. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet closed pull request #840: [MNG-7038] Introducing project.topdir
gnodet closed pull request #840: [MNG-7038] Introducing project.topdir URL: https://github.com/apache/maven/pull/840 -- 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-5659) Project specific settings.xml
[ https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736512#comment-17736512 ] ASF GitHub Bot commented on MNG-5659: - gnodet closed pull request #839: [MNG-5659] Project level settings.xml URL: https://github.com/apache/maven/pull/839 > Project specific settings.xml > - > > Key: MNG-5659 > URL: https://issues.apache.org/jira/browse/MNG-5659 > Project: Maven > Issue Type: New Feature > Components: FDPFC >Reporter: Joachim Van der Auwera >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > Attachments: mvn.patch > > > It would be useful to have a settings.xml file next to the project pom that > could contain project specific settings. For example, when switching between > projects it is sometimes necessary to also change the location of the local > repository, or use a different set of repositories and/or mirror settings for > each project. > If a settings.xml file could be included with a project checkout, then the > repositories needed for the build could be included (instead of putting them > in the pom) along with any other project specific settings. > The tricky part is intelligently handling multi-module projects. For a > multi-module project I don't want to include a separate settings.xml file for > each directory. So Maven could recursively check each parent directory until > it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or > (3) finds the root directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet closed pull request #839: [MNG-5659] Project level settings.xml
gnodet closed pull request #839: [MNG-5659] Project level settings.xml URL: https://github.com/apache/maven/pull/839 -- 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-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736511#comment-17736511
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet closed pull request #840: [MNG-7038] Introducing project.topdir
URL: https://github.com/apache/maven/pull/840
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-6
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-7714:
---
Fix Version/s: 4.0.0-alpha-6
(was: 4.0.0-alpha-7)
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 4.0.0-alpha-6
>
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7812) Get rid of maven-shared-utils dependency
[ https://issues.apache.org/jira/browse/MNG-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736501#comment-17736501 ] ASF GitHub Bot commented on MNG-7812: - elharo commented on code in PR #1158: URL: https://github.com/apache/maven/pull/1158#discussion_r1239857867 ## maven-embedder/src/main/java/org/apache/maven/cli/jansi/MessageUtils.java: ## @@ -0,0 +1,193 @@ +/* + * 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.apache.maven.cli.jansi; + +import org.apache.maven.api.services.MessageBuilder; +import org.apache.maven.internal.impl.DefaultMessageBuilder; +import org.fusesource.jansi.Ansi; +import org.fusesource.jansi.AnsiConsole; +import org.fusesource.jansi.AnsiMode; + +/** + * Colored message utils, to manage colors consistently across plugins (only if Maven version is at least 3.5.0). + * For Maven version before 3.5.0, message built with this util will never add color. + * + * Internally, http://fusesource.github.io/jansi/;>Jansi is used to render + * https://en.wikipedia.org/wiki/ANSI_escape_code#Colors;>ANSI colors on any platform. + * @since 3.1.0 Review Comment: This comment should be updated. ## maven-embedder/src/main/java/org/apache/maven/cli/jansi/Style.java: ## @@ -0,0 +1,147 @@ +/* + * 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.apache.maven.cli.jansi; + +import java.util.Locale; + +import org.fusesource.jansi.Ansi; +import org.fusesource.jansi.Ansi.Color; + +/** + * Configurable message styles. + * @since 3.1.0 Review Comment: 4.0 > Get rid of maven-shared-utils dependency > > > Key: MNG-7812 > URL: https://issues.apache.org/jira/browse/MNG-7812 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > > This issue will seek to remove maven-shared-utils from the list of maven > dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] elharo commented on a diff in pull request #1158: [MNG-7812] Get rid of maven-shared-utils
elharo commented on code in PR #1158: URL: https://github.com/apache/maven/pull/1158#discussion_r1239857867 ## maven-embedder/src/main/java/org/apache/maven/cli/jansi/MessageUtils.java: ## @@ -0,0 +1,193 @@ +/* + * 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.apache.maven.cli.jansi; + +import org.apache.maven.api.services.MessageBuilder; +import org.apache.maven.internal.impl.DefaultMessageBuilder; +import org.fusesource.jansi.Ansi; +import org.fusesource.jansi.AnsiConsole; +import org.fusesource.jansi.AnsiMode; + +/** + * Colored message utils, to manage colors consistently across plugins (only if Maven version is at least 3.5.0). + * For Maven version before 3.5.0, message built with this util will never add color. + * + * Internally, http://fusesource.github.io/jansi/;>Jansi is used to render + * https://en.wikipedia.org/wiki/ANSI_escape_code#Colors;>ANSI colors on any platform. + * @since 3.1.0 Review Comment: This comment should be updated. ## maven-embedder/src/main/java/org/apache/maven/cli/jansi/Style.java: ## @@ -0,0 +1,147 @@ +/* + * 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.apache.maven.cli.jansi; + +import java.util.Locale; + +import org.fusesource.jansi.Ansi; +import org.fusesource.jansi.Ansi.Color; + +/** + * Configurable message styles. + * @since 3.1.0 Review Comment: 4.0 -- 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] elharo commented on a diff in pull request #1179: Remove references to deprecated ReaderFactory in non generated code
elharo commented on code in PR #1179: URL: https://github.com/apache/maven/pull/1179#discussion_r1239847208 ## maven-compat/src/main/java/org/apache/maven/artifact/repository/metadata/AbstractRepositoryMetadata.java: ## @@ -29,8 +29,8 @@ import org.apache.maven.artifact.repository.ArtifactRepositoryPolicy; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader; import org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Writer; -import org.codehaus.plexus.util.ReaderFactory; -import org.codehaus.plexus.util.WriterFactory; +import org.codehaus.plexus.util.xml.XmlStreamReader; Review Comment: org.apache.commons.io.input.XmlStreamReader is preferred 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
[jira] [Updated] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SUREFIRE-2179:
--
Description:
Currently the parameter {{additionalClasspathElements}}
(https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
only supports file paths. That usually requires to add an additional step to
first download the necessary artifact to a temporary folder with another Mojo.
In addition {{additionalClasspathElements}} only support full paths to JARs but
no wildcards which makes configuration very verbose.
For these reasons there should be an additional parameter supporting Maven
coordinates which are then resolved automatically (even transitively) and added
to the test execution classpath.
was:
Currently the parameter {{additionalClasspathElements}}
(https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
only supports file paths. That usually requires to add an additional step to
first download the necessary artifact to a temporary folder with another Mojo.
In addition {{additionalClasspathElements}} only support full paths to JARs but
no wildcards which makes configuration very verbose.
For these reasons there should be an additional parameter supporting Maven
coordinates which are then resolved automatically and added to the test
execution classpath.
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SUREFIRE-2179:
--
Description:
Currently the parameter {{additionalClasspathElements}}
(https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
only supports file paths. That usually requires to add an additional step to
first download the necessary artifact to a temporary folder with another Mojo.
In addition {{additionalClasspathElements}} only support full paths to JARs but
no wildcards which makes configuration very verbose.
For these reasons there should be an additional parameter supporting Maven
coordinates which are then resolved automatically and added to the test
execution classpath.
was:Currently the parameter {{additionalClasspathElements}}
(https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
only supports file paths. That usually requires to add an additional step to
first download the necessary artifact to a temporary folder with another Mojo.
Optionally this parameter should support Maven coordinates which are then
resolved automatically.
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically and added to the test
> execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736482#comment-17736482
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1239759169
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -281,6 +290,17 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
@Parameter(property = "maven.test.additionalClasspath")
private String[] additionalClasspathElements;
+/**
+ * Maven coordinates in the format {@code
:[:[:]]:} of additional
artifacts.
+ * Those artifacts are automatically resolved from the repository
(including their transitive dependencies).
Review Comment:
Probably mentioning the scope here ("runtime" + "compile") would make sense.
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. Optionally this parameter should support Maven coordinates which are
> then resolved automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] kwin commented on a diff in pull request #667: [SUREFIRE-2179] Support adding additional Maven artifacts to the test classpath
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1239759169
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -281,6 +290,17 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
@Parameter(property = "maven.test.additionalClasspath")
private String[] additionalClasspathElements;
+/**
+ * Maven coordinates in the format {@code
:[:[:]]:} of additional
artifacts.
+ * Those artifacts are automatically resolved from the repository
(including their transitive dependencies).
Review Comment:
Probably mentioning the scope here ("runtime" + "compile") would make sense.
--
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] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736480#comment-17736480
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin commented on code in PR #667:
URL: https://github.com/apache/maven-surefire/pull/667#discussion_r1239758247
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -2542,8 +2563,57 @@ private TestClassPath generateTestClasspath() {
classpathArtifacts = filterArtifacts(classpathArtifacts,
dependencyFilter);
}
+Set additionalClasspathElements = new HashSet<>();
+if (getAdditionalClasspathElements() != null) {
+
Arrays.stream(getAdditionalClasspathElements()).forEach(additionalClasspathElements::add);
+}
+if (getAdditionalClasspathArtifacts() != null) {
+
resolveDependencies(Arrays.stream(getAdditionalClasspathArtifacts())).stream()
+.map(File::getAbsolutePath)
+.forEach(additionalClasspathElements::add);
+}
return new TestClassPath(
-classpathArtifacts, getMainBuildPath(),
getTestClassesDirectory(), getAdditionalClasspathElements());
+classpathArtifacts, getMainBuildPath(),
getTestClassesDirectory(), additionalClasspathElements);
+}
+
+Set resolveDependencies(Stream mavenCoordinates) throws
MojoFailureException {
Review Comment:
Should we move this method and `resolveArtifact` to
`SurefireDependencyResolver` instead?
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. Optionally this parameter should support Maven coordinates which are
> then resolved automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736476#comment-17736476
]
ASF GitHub Bot commented on SUREFIRE-2179:
--
kwin opened a new pull request, #667:
URL: https://github.com/apache/maven-surefire/pull/667
(no comment)
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. Optionally this parameter should support Maven coordinates which are
> then resolved automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736472#comment-17736472
]
ASF GitHub Bot commented on MNG-7818:
-
elharo commented on PR #1178:
URL: https://github.com/apache/maven/pull/1178#issuecomment-1604176070
Not sure if this is related but I see some warnigns in this area:
```
[INFO] <<< maven-dependency-plugin:3.6.0:analyze (default-cli) <
test-compile @ maven-api-meta <<<
[INFO]
[INFO]
[INFO] -
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.9.3
>
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] elharo commented on pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4
elharo commented on PR #1178: URL: https://github.com/apache/maven/pull/1178#issuecomment-1604176070 Not sure if this is related but I see some warnigns in this area: ``` [INFO] <<< maven-dependency-plugin:3.6.0:analyze (default-cli) < test-compile @ maven-api-meta <<< [INFO] [INFO] [INFO] --- maven-dependency-plugin:3.6.0:analyze (default-cli) @ maven-api-meta --- [WARNING] Unused declared dependencies found: [WARNING]org.junit.jupiter:junit-jupiter-engine:jar:5.9.1:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [INFO] ``` -- 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] (MNG-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-7823:
Assignee: Tamas Cservenak
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7823:
-
Component/s: Plugins and Lifecycle
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-7823.
Resolution: Fixed
master
https://github.com/apache/maven/commit/764a9ca0bef69995f5ca40aced0c63ba60917d95
maven-3.9.x
https://github.com/apache/maven/commit/958112991dc0f0d491881b939ace71f6432e9cf4
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736458#comment-17736458
]
ASF GitHub Bot commented on MNG-7823:
-
cstamas merged PR #1182:
URL: https://github.com/apache/maven/pull/1182
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas merged pull request #1182: [MNG-7823] Improve plugin validation level parsing
cstamas merged PR #1182: URL: https://github.com/apache/maven/pull/1182 -- 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-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736452#comment-17736452
]
ASF GitHub Bot commented on MNG-7823:
-
cstamas commented on code in PR #1182:
URL: https://github.com/apache/maven/pull/1182#discussion_r1239655242
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -83,13 +83,23 @@ private enum ValidationReportLevel {
public void onEvent(Object event) {
if (event instanceof ExecutionEvent) {
ExecutionEvent executionEvent = (ExecutionEvent) event;
-if (executionEvent.getType() == ExecutionEvent.Type.SessionEnded) {
+if (executionEvent.getType() ==
ExecutionEvent.Type.SessionStarted) {
+RepositorySystemSession repositorySystemSession =
+executionEvent.getSession().getRepositorySession();
+ValidationReportLevel level =
parseValidationReportLevel(repositorySystemSession);
+
repositorySystemSession.getData().set(MAVEN_PLUGIN_VALIDATION_KEY, level);
+} else if (executionEvent.getType() ==
ExecutionEvent.Type.SessionEnded) {
reportSessionCollectedValidationIssues(executionEvent.getSession());
}
}
}
private ValidationReportLevel
validationReportLevel(RepositorySystemSession session) {
+return (ValidationReportLevel) session.getData()
+.computeIfAbsent(MAVEN_PLUGIN_VALIDATION_KEY, () ->
parseValidationReportLevel(session));
Review Comment:
changed to not reuse keys as this may cause misunderstanding
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas commented on a diff in pull request #1182: [MNG-7823] Improve plugin validation level parsing
cstamas commented on code in PR #1182:
URL: https://github.com/apache/maven/pull/1182#discussion_r1239655242
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -83,13 +83,23 @@ private enum ValidationReportLevel {
public void onEvent(Object event) {
if (event instanceof ExecutionEvent) {
ExecutionEvent executionEvent = (ExecutionEvent) event;
-if (executionEvent.getType() == ExecutionEvent.Type.SessionEnded) {
+if (executionEvent.getType() ==
ExecutionEvent.Type.SessionStarted) {
+RepositorySystemSession repositorySystemSession =
+executionEvent.getSession().getRepositorySession();
+ValidationReportLevel level =
parseValidationReportLevel(repositorySystemSession);
+
repositorySystemSession.getData().set(MAVEN_PLUGIN_VALIDATION_KEY, level);
+} else if (executionEvent.getType() ==
ExecutionEvent.Type.SessionEnded) {
reportSessionCollectedValidationIssues(executionEvent.getSession());
}
}
}
private ValidationReportLevel
validationReportLevel(RepositorySystemSession session) {
+return (ValidationReportLevel) session.getData()
+.computeIfAbsent(MAVEN_PLUGIN_VALIDATION_KEY, () ->
parseValidationReportLevel(session));
Review Comment:
changed to not reuse keys as this may cause misunderstanding
--
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-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736449#comment-17736449
]
ASF GitHub Bot commented on MNG-7823:
-
cstamas commented on code in PR #1182:
URL: https://github.com/apache/maven/pull/1182#discussion_r1239650547
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -83,13 +83,23 @@ private enum ValidationReportLevel {
public void onEvent(Object event) {
if (event instanceof ExecutionEvent) {
ExecutionEvent executionEvent = (ExecutionEvent) event;
-if (executionEvent.getType() == ExecutionEvent.Type.SessionEnded) {
+if (executionEvent.getType() ==
ExecutionEvent.Type.SessionStarted) {
+RepositorySystemSession repositorySystemSession =
+executionEvent.getSession().getRepositorySession();
+ValidationReportLevel level =
parseValidationReportLevel(repositorySystemSession);
+
repositorySystemSession.getData().set(MAVEN_PLUGIN_VALIDATION_KEY, level);
+} else if (executionEvent.getType() ==
ExecutionEvent.Type.SessionEnded) {
reportSessionCollectedValidationIssues(executionEvent.getSession());
}
}
}
private ValidationReportLevel
validationReportLevel(RepositorySystemSession session) {
+return (ValidationReportLevel) session.getData()
+.computeIfAbsent(MAVEN_PLUGIN_VALIDATION_KEY, () ->
parseValidationReportLevel(session));
Review Comment:
no, this is session.data while string is in session.configProperties, two
distinct maps
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas commented on a diff in pull request #1182: [MNG-7823] Improve plugin validation level parsing
cstamas commented on code in PR #1182:
URL: https://github.com/apache/maven/pull/1182#discussion_r1239650547
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -83,13 +83,23 @@ private enum ValidationReportLevel {
public void onEvent(Object event) {
if (event instanceof ExecutionEvent) {
ExecutionEvent executionEvent = (ExecutionEvent) event;
-if (executionEvent.getType() == ExecutionEvent.Type.SessionEnded) {
+if (executionEvent.getType() ==
ExecutionEvent.Type.SessionStarted) {
+RepositorySystemSession repositorySystemSession =
+executionEvent.getSession().getRepositorySession();
+ValidationReportLevel level =
parseValidationReportLevel(repositorySystemSession);
+
repositorySystemSession.getData().set(MAVEN_PLUGIN_VALIDATION_KEY, level);
+} else if (executionEvent.getType() ==
ExecutionEvent.Type.SessionEnded) {
reportSessionCollectedValidationIssues(executionEvent.getSession());
}
}
}
private ValidationReportLevel
validationReportLevel(RepositorySystemSession session) {
+return (ValidationReportLevel) session.getData()
+.computeIfAbsent(MAVEN_PLUGIN_VALIDATION_KEY, () ->
parseValidationReportLevel(session));
Review Comment:
no, this is session.data while string is in session.configProperties, two
distinct maps
--
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-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736447#comment-17736447
]
ASF GitHub Bot commented on MNG-7823:
-
slawekjaranowski commented on code in PR #1182:
URL: https://github.com/apache/maven/pull/1182#discussion_r1239648238
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -83,13 +83,23 @@ private enum ValidationReportLevel {
public void onEvent(Object event) {
if (event instanceof ExecutionEvent) {
ExecutionEvent executionEvent = (ExecutionEvent) event;
-if (executionEvent.getType() == ExecutionEvent.Type.SessionEnded) {
+if (executionEvent.getType() ==
ExecutionEvent.Type.SessionStarted) {
+RepositorySystemSession repositorySystemSession =
+executionEvent.getSession().getRepositorySession();
+ValidationReportLevel level =
parseValidationReportLevel(repositorySystemSession);
+
repositorySystemSession.getData().set(MAVEN_PLUGIN_VALIDATION_KEY, level);
+} else if (executionEvent.getType() ==
ExecutionEvent.Type.SessionEnded) {
reportSessionCollectedValidationIssues(executionEvent.getSession());
}
}
}
private ValidationReportLevel
validationReportLevel(RepositorySystemSession session) {
+return (ValidationReportLevel) session.getData()
+.computeIfAbsent(MAVEN_PLUGIN_VALIDATION_KEY, () ->
parseValidationReportLevel(session));
Review Comment:
Can be empty here?
We use the same key and assume that will contains correct type.
If code from onEvent will not execute we can have wrong type.
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSOURCES-139) Typo in exception
[ https://issues.apache.org/jira/browse/MSOURCES-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSOURCES-139. --- Resolution: Fixed Fixed with [1edeea47f80bc5c5903e88c1adbff56501248a8b|https://gitbox.apache.org/repos/asf?p=maven-artifact-plugin.git=commit=1edeea47f80bc5c5903e88c1adbff56501248a8b]. > Typo in exception > - > > Key: MSOURCES-139 > URL: https://issues.apache.org/jira/browse/MSOURCES-139 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Alexander Brandes >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > AbstractSourceJarMojo#packageSources throws an exception with an improperly > spelled plugin name: "Presumably you have configured maven-source-plugn..." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #1182: [MNG-7823] Improve plugin validation level parsing
slawekjaranowski commented on code in PR #1182:
URL: https://github.com/apache/maven/pull/1182#discussion_r1239648238
##
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java:
##
@@ -83,13 +83,23 @@ private enum ValidationReportLevel {
public void onEvent(Object event) {
if (event instanceof ExecutionEvent) {
ExecutionEvent executionEvent = (ExecutionEvent) event;
-if (executionEvent.getType() == ExecutionEvent.Type.SessionEnded) {
+if (executionEvent.getType() ==
ExecutionEvent.Type.SessionStarted) {
+RepositorySystemSession repositorySystemSession =
+executionEvent.getSession().getRepositorySession();
+ValidationReportLevel level =
parseValidationReportLevel(repositorySystemSession);
+
repositorySystemSession.getData().set(MAVEN_PLUGIN_VALIDATION_KEY, level);
+} else if (executionEvent.getType() ==
ExecutionEvent.Type.SessionEnded) {
reportSessionCollectedValidationIssues(executionEvent.getSession());
}
}
}
private ValidationReportLevel
validationReportLevel(RepositorySystemSession session) {
+return (ValidationReportLevel) session.getData()
+.computeIfAbsent(MAVEN_PLUGIN_VALIDATION_KEY, () ->
parseValidationReportLevel(session));
Review Comment:
Can be empty here?
We use the same key and assume that will contains correct type.
If code from onEvent will not execute we can have wrong type.
--
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-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7823:
-
Description:
Currently, the value of {{maven.plugin.validation}} is:
* parsed each time is needed (from string)
* warns for bad value lazily (when parsed), this implies WARN is "lazy",
happens when needed, and can make things "look like" some plugin warns for some
reason
* will warn EACH time needed
Instead:
* on session start parse it and store it into session.data
* this means on session start will warn as well, and warn once
* parsed enum should be reused, instead to repeatedly parse and warn whenever
level needed
was:
Currently, the value of {{maven.plugin.validation}} is:
* parsed each time is needed (for string)
* warns for bad value lazily (when parsed)
* will warn EACH time needed
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (from string)
> * warns for bad value lazily (when parsed), this implies WARN is "lazy",
> happens when needed, and can make things "look like" some plugin warns for
> some reason
> * will warn EACH time needed
> Instead:
> * on session start parse it and store it into session.data
> * this means on session start will warn as well, and warn once
> * parsed enum should be reused, instead to repeatedly parse and warn whenever
> level needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSOURCES-139) Typo in exception
[ https://issues.apache.org/jira/browse/MSOURCES-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736445#comment-17736445 ] ASF GitHub Bot commented on MSOURCES-139: - michael-o merged PR #11: URL: https://github.com/apache/maven-source-plugin/pull/11 > Typo in exception > - > > Key: MSOURCES-139 > URL: https://issues.apache.org/jira/browse/MSOURCES-139 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Alexander Brandes >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > AbstractSourceJarMojo#packageSources throws an exception with an improperly > spelled plugin name: "Presumably you have configured maven-source-plugn..." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-source-plugin] michael-o merged pull request #11: [MSOURCES-139] Fix typo in AbstractSourceJarMojo exception
michael-o merged PR #11: URL: https://github.com/apache/maven-source-plugin/pull/11 -- 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] (MSOURCES-139) Typo in exception
[ https://issues.apache.org/jira/browse/MSOURCES-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MSOURCES-139: --- Assignee: Michael Osipov > Typo in exception > - > > Key: MSOURCES-139 > URL: https://issues.apache.org/jira/browse/MSOURCES-139 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Alexander Brandes >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > AbstractSourceJarMojo#packageSources throws an exception with an improperly > spelled plugin name: "Presumably you have configured maven-source-plugn..." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSOURCES-139) Typo in exception
[ https://issues.apache.org/jira/browse/MSOURCES-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSOURCES-139: Fix Version/s: next-release > Typo in exception > - > > Key: MSOURCES-139 > URL: https://issues.apache.org/jira/browse/MSOURCES-139 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Alexander Brandes >Priority: Minor > Fix For: next-release > > > AbstractSourceJarMojo#packageSources throws an exception with an improperly > spelled plugin name: "Presumably you have configured maven-source-plugn..." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7823) Make plugin validation level parsing more consistent
[
https://issues.apache.org/jira/browse/MNG-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736442#comment-17736442
]
ASF GitHub Bot commented on MNG-7823:
-
cstamas opened a new pull request, #1182:
URL: https://github.com/apache/maven/pull/1182
Changes:
* always parse it at session start
* (hence, will WARN if needed there as well)
* do not re-parse and re-warn always, reuse parsed enum
---
https://issues.apache.org/jira/browse/MNG-7823
> Make plugin validation level parsing more consistent
>
>
> Key: MNG-7823
> URL: https://issues.apache.org/jira/browse/MNG-7823
> Project: Maven
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Currently, the value of {{maven.plugin.validation}} is:
> * parsed each time is needed (for string)
> * warns for bad value lazily (when parsed)
> * will warn EACH time needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas opened a new pull request, #1182: [MNG-7823] Improve plugin validation handling level parsing
cstamas opened a new pull request, #1182: URL: https://github.com/apache/maven/pull/1182 Changes: * always parse it at session start * (hence, will WARN if needed there as well) * do not re-parse and re-warn always, reuse parsed enum --- https://issues.apache.org/jira/browse/MNG-7823 -- 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] (MNG-7823) Make plugin validation level parsing more consistent
Tamas Cservenak created MNG-7823:
Summary: Make plugin validation level parsing more consistent
Key: MNG-7823
URL: https://issues.apache.org/jira/browse/MNG-7823
Project: Maven
Issue Type: Improvement
Reporter: Tamas Cservenak
Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
Currently, the value of {{maven.plugin.validation}} is:
* parsed each time is needed (for string)
* warns for bad value lazily (when parsed)
* will warn EACH time needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-source-plugin] NotMyFault opened a new pull request, #11: [MSOURCES-139] Fix typo in AbstractSourceJarMojo exception
NotMyFault opened a new pull request, #11: URL: https://github.com/apache/maven-source-plugin/pull/11 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSOURCES) 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: https://issues.apache.org/jira/browse/MSOURCES-139 - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MSOURCES-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSOURCES-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 -Prun-its` to make sure integration tests checks pass. A more thorough check will be performed on your pull request automatically. 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](https://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](https://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
[jira] [Commented] (MSOURCES-139) Typo in exception
[ https://issues.apache.org/jira/browse/MSOURCES-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736433#comment-17736433 ] ASF GitHub Bot commented on MSOURCES-139: - NotMyFault opened a new pull request, #11: URL: https://github.com/apache/maven-source-plugin/pull/11 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSOURCES) 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: https://issues.apache.org/jira/browse/MSOURCES-139 - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MSOURCES-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSOURCES-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 -Prun-its` to make sure integration tests checks pass. A more thorough check will be performed on your pull request automatically. 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](https://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](https://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). > Typo in exception > - > > Key: MSOURCES-139 > URL: https://issues.apache.org/jira/browse/MSOURCES-139 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Alexander Brandes >Priority: Minor > > AbstractSourceJarMojo#packageSources throws an exception with an improperly > spelled plugin name: "Presumably you have configured maven-source-plugn..." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSOURCES-139) Typo in exception
Alexander Brandes created MSOURCES-139: -- Summary: Typo in exception Key: MSOURCES-139 URL: https://issues.apache.org/jira/browse/MSOURCES-139 Project: Maven Source Plugin Issue Type: Bug Affects Versions: 3.3.0 Reporter: Alexander Brandes AbstractSourceJarMojo#packageSources throws an exception with an improperly spelled plugin name: "Presumably you have configured maven-source-plugn..." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736426#comment-17736426
]
ASF GitHub Bot commented on MNG-7818:
-
cstamas merged PR #1178:
URL: https://github.com/apache/maven/pull/1178
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.9.3
>
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-7818.
Resolution: Fixed
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.9.3
>
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas merged pull request #1178: [MNG-7818] Removed exclusion of hamcrest from junit 4
cstamas merged PR #1178: URL: https://github.com/apache/maven/pull/1178 -- 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] (MNG-7819) Create IT that exercise file locking with snaphots
[ https://issues.apache.org/jira/browse/MNG-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7819. Resolution: Fixed > Create IT that exercise file locking with snaphots > -- > > Key: MNG-7819 > URL: https://issues.apache.org/jira/browse/MNG-7819 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Integration Tests >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Blocker > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Resolver (1.9.8-1.9.12) contained a nasty bug, that was triggered in Maven > under certain circumstances and is related to file locking. > Example reproducer: > * using file-lock factory and file-gav naming > * the built project has a snapshot dependency > * the snapshot dependency has a snapshot parent > * here, model builder will want to resolve parent POM and cause "lock upgrade" > Reproducer for 3.9.2 bug: > https://gist.github.com/cstamas/0f1909c81d975f513ceb88012d7c0529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7800) Upgrade to Maven Resolver 1.9.13
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7800. Resolution: Fixed > Upgrade to Maven Resolver 1.9.13 > > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.13 with latest fixed. > Was: > Ingest resolver 1.9.11 with latest fixes (but MRESOLVER-371) > Ingest resolver 1.9.12 (but MRESOLVER-373) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7800) Upgrade to Maven Resolver 1.9.13
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736417#comment-17736417 ] Tamas Cservenak commented on MNG-7800: -- master https://github.com/apache/maven/commit/c9ba8bc4bfc956c3d95c89fc58bc3e35e17a222c maven-3.9.x https://github.com/apache/maven/commit/917e9561cfcf72c16b60e54463d78013a40fb88d > Upgrade to Maven Resolver 1.9.13 > > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.13 with latest fixed. > Was: > Ingest resolver 1.9.11 with latest fixes (but MRESOLVER-371) > Ingest resolver 1.9.12 (but MRESOLVER-373) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7800) Upgrade to Maven Resolver 1.9.13
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736416#comment-17736416 ] ASF GitHub Bot commented on MNG-7800: - cstamas merged PR #1181: URL: https://github.com/apache/maven/pull/1181 > Upgrade to Maven Resolver 1.9.13 > > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.13 with latest fixed. > Was: > Ingest resolver 1.9.11 with latest fixes (but MRESOLVER-371) > Ingest resolver 1.9.12 (but MRESOLVER-373) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7800) Upgrade to Maven Resolver 1.9.13
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736415#comment-17736415 ] ASF GitHub Bot commented on MNG-7800: - cstamas merged PR #1180: URL: https://github.com/apache/maven/pull/1180 > Upgrade to Maven Resolver 1.9.13 > > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.13 with latest fixed. > Was: > Ingest resolver 1.9.11 with latest fixes (but MRESOLVER-371) > Ingest resolver 1.9.12 (but MRESOLVER-373) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736407#comment-17736407
]
Michael Osipov commented on MSHARED-1032:
-
Duplcate call has been resolved, let's move on with the actual request...
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice
[
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSHARED-1275.
---
Resolution: Fixed
Fixed with
[daa27fede2492689a72cd8614d548f6e0d4c99fc|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git=commit=daa27fede2492689a72cd8614d548f6e0d4c99fc].
> MavenReport#canGenerateReport() is invoked twice
>
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink,
> SinkFactory, Locale)}} also both uses cases make sure that
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This
> is clearly redudant and can incur a performance overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice
[
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736406#comment-17736406
]
ASF GitHub Bot commented on MSHARED-1275:
-
asfgit closed pull request #21: [MSHARED-1275] MavenReport#canGenerateReport()
is invoked twice
URL: https://github.com/apache/maven-reporting-impl/pull/21
> MavenReport#canGenerateReport() is invoked twice
>
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink,
> SinkFactory, Locale)}} also both uses cases make sure that
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This
> is clearly redudant and can incur a performance overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice
[
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736402#comment-17736402
]
Michael Osipov commented on MSHARED-1275:
-
Those are exactly the spots I have identified for.
> MavenReport#canGenerateReport() is invoked twice
>
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink,
> SinkFactory, Locale)}} also both uses cases make sure that
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This
> is clearly redudant and can incur a performance overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7800) Upgrade to Maven Resolver 1.9.13
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736395#comment-17736395 ] ASF GitHub Bot commented on MNG-7800: - cstamas opened a new pull request, #1181: URL: https://github.com/apache/maven/pull/1181 --- https://issues.apache.org/jira/browse/MNG-7800 > Upgrade to Maven Resolver 1.9.13 > > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.13 with latest fixed. > Was: > Ingest resolver 1.9.11 with latest fixes (but MRESOLVER-371) > Ingest resolver 1.9.12 (but MRESOLVER-373) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7800) Upgrade to Maven Resolver 1.9.13
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736394#comment-17736394 ] ASF GitHub Bot commented on MNG-7800: - cstamas opened a new pull request, #1180: URL: https://github.com/apache/maven/pull/1180 --- https://issues.apache.org/jira/browse/MNG-7800 > Upgrade to Maven Resolver 1.9.13 > > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.13 with latest fixed. > Was: > Ingest resolver 1.9.11 with latest fixes (but MRESOLVER-371) > Ingest resolver 1.9.12 (but MRESOLVER-373) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice
[
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736358#comment-17736358
]
Herve Boutemy edited comment on MSHARED-1275 at 6/23/23 6:11 AM:
-
for the goal execution use case that maven-reporting-impl fully implements,
yes, it is clear that there are 2 executions then one should be dropped: see
https://github.com/apache/maven-reporting-impl/blame/d2032091c1bd86c6f52d80a23852aff0e8c0b6ae/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L165
where canGenerate is called first in Mojo.execute then later in generate
for site:site execution, equivalent call is done when preparing report
execution
https://github.com/apache/maven-site-plugin/blob/8c597d8db03633feb010cacb2a036b1cceb29aee/src/main/java/org/apache/maven/plugins/site/render/AbstractSiteRenderingMojo.java#L231
then yes, checking during generate() means calling twice: all has been checked
before
was (Author: hboutemy):
for the goal execution use case that maven-reporting-impl fully implements,
yes, it is clear that there are 2 executions then one should be dropped: see
https://github.com/apache/maven-reporting-impl/blame/d2032091c1bd86c6f52d80a23852aff0e8c0b6ae/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L165
where canGenerate is called first in Mojo.execute then later in generate
for site:site execution, need to clarify yet
> MavenReport#canGenerateReport() is invoked twice
>
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink,
> SinkFactory, Locale)}} also both uses cases make sure that
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This
> is clearly redudant and can incur a performance overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1275) MavenReport#canGenerateReport() is invoked twice
[
https://issues.apache.org/jira/browse/MSHARED-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736358#comment-17736358
]
Herve Boutemy commented on MSHARED-1275:
for the goal execution use case that maven-reporting-impl fully implements,
yes, it is clear that there are 2 executions then one should be dropped: see
https://github.com/apache/maven-reporting-impl/blame/d2032091c1bd86c6f52d80a23852aff0e8c0b6ae/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L165
where canGenerate is called first in Mojo.execute then later in generate
for site:site execution, need to clarify yet
> MavenReport#canGenerateReport() is invoked twice
>
>
> Key: MSHARED-1275
> URL: https://issues.apache.org/jira/browse/MSHARED-1275
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M9
>
>
> The mentioned method called twice for standalone *and* Maven Site Plugin use
> case in {{org.apache.maven.reporting.AbstractMavenReport.generate(Sink,
> SinkFactory, Locale)}} also both uses cases make sure that
> {{canGenerateReport()}} is invoked _before_ {{generate()}} is invoked. This
> is clearly redudant and can incur a performance overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
