[jira] [Commented] (MPLUGIN-421) descriptor goal fails when there is .java file present with content that's just a comment
[
https://issues.apache.org/jira/browse/MPLUGIN-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614390#comment-17614390
]
Slawomir Jaranowski commented on MPLUGIN-421:
-
Wen we execute project with {{mvn -e ...}} we will see:
{code}
Caused by: com.thoughtworks.qdox.parser.ParseException: syntax error @[8,55] in
file:/descriptor-fail-poc/src/main/java/pan/leszeczek/DummyEmptySourceWithJavaExtension.java
at com.thoughtworks.qdox.parser.impl.Parser.yyerror (Parser.java:1963)
at com.thoughtworks.qdox.parser.impl.Parser.yyparse (Parser.java:2085)
at com.thoughtworks.qdox.parser.impl.Parser.parse (Parser.java:1944)
at com.thoughtworks.qdox.library.SourceLibrary.parse
(SourceLibrary.java:232)
at com.thoughtworks.qdox.library.SourceLibrary.parse
(SourceLibrary.java:209)
at com.thoughtworks.qdox.library.SourceLibrary.addSource
(SourceLibrary.java:159)
at com.thoughtworks.qdox.library.SortedClassLibraryBuilder.addSource
(SortedClassLibraryBuilder.java:174)
at com.thoughtworks.qdox.JavaProjectBuilder.addSource
(JavaProjectBuilder.java:151)
at com.thoughtworks.qdox.JavaProjectBuilder$2.visitFile
(JavaProjectBuilder.java:224)
at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk
(DirectoryScanner.java:103)
at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk
(DirectoryScanner.java:91)
at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk
(DirectoryScanner.java:91)
at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk
(DirectoryScanner.java:91)
at com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan
(DirectoryScanner.java:81)
at com.thoughtworks.qdox.JavaProjectBuilder.addSourceTree
(JavaProjectBuilder.java:218)
at com.thoughtworks.qdox.JavaProjectBuilder.addSourceTree
(JavaProjectBuilder.java:205)
at
org.apache.maven.tools.plugin.extractor.javadoc.JavaJavadocMojoDescriptorExtractor.discoverClasses
(JavaJavadocMojoDescriptorExtractor.java:625)
{code}
Which confirms your observations, so the issue is in {{qdox}} library:
https://github.com/paul-hammant/qdox
Thanks for report issue here - but we can't resolve issue in external library
here.
As workaround please not comments everything in source java file.
Or simply remove file, or change extension from java to something else.
> descriptor goal fails when there is .java file present with content that's
> just a comment
> -
>
> Key: MPLUGIN-421
> URL: https://issues.apache.org/jira/browse/MPLUGIN-421
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.6.4
>Reporter: Leszek Jadacki
>Priority: Minor
>
> Hello,
> As I was learning to create own custom plugin, during development process I
> decided not to compile one of my Mojo's. For ease I simply commented all its
> content.
> When trying to build my "custom" plugin _Install_ fails when it executes
> _descriptor_ goal.
> It seems like when there is a file in the source folder with .java extension
> but contains only commented lines the compiler omits the file, but the
> descriptor is taking it into account and fails during parsing the file with
> error "syntax error @[X,Y]" pointing to it's last line and column.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #818: v4 api enhancements
cstamas commented on PR #818: URL: https://github.com/apache/maven/pull/818#issuecomment-1272252142 > They are stateless beans, so they could be moved to the `@Singleton` scope. The question is: should they ? In general, components should be stateless and immutable. By having them in singleton scope, in some circumstances you can preserve some memory and/or GC pressure, especially if instances are used across multiple components (is enlisted several times in object graph) or, (this is more like webapp scenario) are injected per request or so. Maven codebase in general applies this clearly and consistently, as IMHO the intent is clear when you see singleton annotation on a component... So my preference is yes, if a component is meant to be singleton, then they should be made singletons (as later on, as codebase evolve, this can lead to issues, IMHO be explicit and follow Maven "style" re components) -- 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-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614392#comment-17614392 ] Michael Osipov commented on MNG-7545: - All described in the link. > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.DefaultGraphBuilder.build > (DefaultGraphBuilder.java:82) > at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:532) > at or
[jira] [Updated] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liuchangcheng updated MNG-7545: --- Attachment: image-2022-10-08-15-38-10-927.png > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Attachments: image-2022-10-08-15-38-10-927.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.DefaultGraphBuilder.build > (DefaultGraphBuilder.java:82) > at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven
[GitHub] [maven-help-plugin] pzygielo commented on pull request #72: (doc) Use names already imported
pzygielo commented on PR #72: URL: https://github.com/apache/maven-help-plugin/pull/72#issuecomment-1272255425 May I ask for review, please? -- 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-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614397#comment-17614397 ] liuchangcheng commented on MNG-7545: we use [link dev dist area|[https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.x-resolver-1.8.x/binaries/]] still get exeception at java.io.RandomAccessFile.open0 (Native Method) at java.io.RandomAccessFile.open (RandomAccessFile.java:316) at java.io.RandomAccessFile. (RandomAccessFile.java:243) at org.eclipse.aether.connector.basic.PartialFile$LockFile.tryLock (PartialFile.java:138) at org.eclipse.aether.connector.basic.PartialFile$LockFile.lock (PartialFile.java:82) at org.eclipse.aether.connector.basic.PartialFile$LockFile. (PartialFile.java:70) at org.eclipse.aether.connector.basic.PartialFile$Factory.newInstance (PartialFile.java:268) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask (BasicRepositoryConnector.java:481) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run (BasicRepositoryConnector.java:396) at org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0 (RunnableErrorForwarder.java:73) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute (BasicRepositoryConnector.java:669) at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get (BasicRepositoryConnector.java:290) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads (DefaultArtifactResolver.java:520) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve (DefaultArtifactResolver.java:408) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts (DefaultArtifactResolver.java:235) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact (DefaultArtifactResolver.java:212) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom (DefaultArtifactDescriptorReader.java:240) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor (DefaultArtifactDescriptorReader.java:171) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor (DfDependencyCollector.java:316) at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult (DfDependencyCollector.java:301) > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Attachments: image-2022-10-08-15-38-10-927.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifac
[GitHub] [maven-help-plugin] michael-o merged pull request #72: (doc) Use names already imported
michael-o merged PR #72: URL: https://github.com/apache/maven-help-plugin/pull/72 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MWAR-456) Latest maven-war-plugin causing vulnerable .jars to be downloaded
[ https://issues.apache.org/jira/browse/MWAR-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614405#comment-17614405 ] Michael Osipov edited comment on MWAR-456 at 10/8/22 7:54 AM: -- Does the problem still persist on master (3.4.0-SNAPSHOT)? Might be fixed with 136f2df8874a105f901e2f01fc0184d6d8a0c994. was (Author: michael-o): Does the problem still persist on master (3.4.0-SNAPSHOT)? > Latest maven-war-plugin causing vulnerable .jars to be downloaded > - > > Key: MWAR-456 > URL: https://issues.apache.org/jira/browse/MWAR-456 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 3.3.2 > Environment: Linux, Windows >Reporter: Joseph Angotti >Priority: Blocker > Fix For: waiting-for-feedback > > Attachments: Console-Log-Edit.JPG > > Original Estimate: 60h > Remaining Estimate: 60h > > We are planning to upgrade our project's parent pom.xml file to use > maven-war-plugin 3.3.2, which is the latest version, but somehow it is > causing 2 vulnerable .jar files, plexus-utils-2.0.5.jar, and > maven-shared-utils-3.2.1.jar, to download from our JFrog Artifactory > repository when it shouldn't be. Other versions of the maven-war-plugin seem > to result in the same issue. > Is there someone available who can assist with this issue as soon as > possible? Our development efforts are currently blocked because of this > issue. We need to be able to upgrade to the latest version of the > maven-war-plugin and prevent vulnerable .jar files from being downloaded as > soon as possible before our remediation deadline in a few weeks. Thank you > (see the maven console logs attached for more details). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWAR-456) Latest maven-war-plugin causing vulnerable .jars to be downloaded
[ https://issues.apache.org/jira/browse/MWAR-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614405#comment-17614405 ] Michael Osipov commented on MWAR-456: - Does the problem still persist on master (3.4.0-SNAPSHOT)? > Latest maven-war-plugin causing vulnerable .jars to be downloaded > - > > Key: MWAR-456 > URL: https://issues.apache.org/jira/browse/MWAR-456 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 3.3.2 > Environment: Linux, Windows >Reporter: Joseph Angotti >Priority: Blocker > Fix For: waiting-for-feedback > > Attachments: Console-Log-Edit.JPG > > Original Estimate: 60h > Remaining Estimate: 60h > > We are planning to upgrade our project's parent pom.xml file to use > maven-war-plugin 3.3.2, which is the latest version, but somehow it is > causing 2 vulnerable .jar files, plexus-utils-2.0.5.jar, and > maven-shared-utils-3.2.1.jar, to download from our JFrog Artifactory > repository when it shouldn't be. Other versions of the maven-war-plugin seem > to result in the same issue. > Is there someone available who can assist with this issue as soon as > possible? Our development efforts are currently blocked because of this > issue. We need to be able to upgrade to the latest version of the > maven-war-plugin and prevent vulnerable .jar files from being downloaded as > soon as possible before our remediation deadline in a few weeks. Thank you > (see the maven console logs attached for more details). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7541) Native support for PowerShell to start Maven
[ https://issues.apache.org/jira/browse/MNG-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614406#comment-17614406 ] Michael Osipov commented on MNG-7541: - [~jfahner], please note that in Maven 4 the start scripts have been broken up into single components. This is what you have to provide also. The scripts have been simplified in Maven 4 and aren't compatible with Maven 3. > Native support for PowerShell to start Maven > > > Key: MNG-7541 > URL: https://issues.apache.org/jira/browse/MNG-7541 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.8.3 > Environment: windows 10 / 11 >Reporter: Jurrian Fahner >Priority: Trivial > Labels: Script, Windows10, Windows11 > > Maven has two files in the bin dir: > ||command||its use|| > |mvn|POSIX shell| > |mvn.cmd|cmd.exe| > On windows there are two ways to write scripts, by using cmd.exe or using > powershell. > If you enter mvn in powershell it will look for `mvn.ps1` on the PATH first. > If it doesn't find anything it will execute `mvn.cmd` as fall-back. > When running maven for starting a server for development purposes and you do > ctrl-c to exit the server it will ask the question: Terminate batch job (Y/N)? > As far as I know it is default behaviour of cmd.exe. > Well if I don't want to terminate, I wouldn't press ctrl-c. ;) > It is not the case (as far as I know that Microsoft is going to deprecate > cmd.exe in favor of powershell: > [https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/] > Allthough I think it would be a good move for maven to have also a powershell > script as well... It is possible to integrate elegant support for native help > in powershell, `get-help mvn`. > But it also increases the maintenance effort as well. I don't know whether > this cost outweigh the benefits, though... > By the way I would happy to contribute if it is appreciated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resources-plugin] michael-o merged pull request #36: doc: adds alternative variable syntax using @ delimiters to the documentation
michael-o merged PR #36: URL: https://github.com/apache/maven-resources-plugin/pull/36 -- 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] (MWRAPPER-45) Migrate/Sync startup scripts with Maven 4
[ https://issues.apache.org/jira/browse/MWRAPPER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614408#comment-17614408 ] Michael Osipov commented on MWRAPPER-45: [~sjaranowski], I support that because the scripts right now are an ancient fork. > Migrate/Sync startup scripts with Maven 4 > - > > Key: MWRAPPER-45 > URL: https://issues.apache.org/jira/browse/MWRAPPER-45 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > > The scripts are Maven 3 based. Maven 4 has simplified the scripts and > introduced consistency improvements. We should port those over for version 4?! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[
https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614410#comment-17614410
]
Michael Osipov commented on MNG-7545:
-
To further procede with this and reopen, provide {{mvn -v} and all args passed
to Maven as well as the build output in verbose mode ({{-X}}).
> Multi building can create bad files for downloaded artifacts in local
> repository
>
>
> Key: MNG-7545
> URL: https://issues.apache.org/jira/browse/MNG-7545
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.6
>Reporter: liuchangcheng
>Assignee: Michael Osipov
>Priority: Major
> Attachments: image-2022-10-08-15-38-10-927.png
>
>
> Within a parallel build, modules A and B can start at the same time and
> decide at the same time that they need to download artifact X. Since X is not
> available locally, both can start download of X. Both will download X and
> both will try to write the file for X to disk.
> On Windows platforms, one of them can fail with file locking problems. On
> Unixes the contents of the written file can be non-deterministic.
> This issue is related to MNG-2802 in the sense that it can create a corrupted
> artifact file in the local repository, and it can happen to ANY file written.
> But as opposed to MNG-2802 the synhronization needed to fix this issue is
> basically only within a single running maven process, so regular java
> mechanisms can apply, whereas MNG-2802 probably needs to use a totally
> different solution space.
>
> is this issue fixed?
> we are still facing this problem with maven 3.8.6
>
> I get error like this below
> [WARNING] Failed to write tracking file
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> java.io.FileNotFoundException:
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> (另一个程序正在使用此文件，进程无法访问。)
> at java.io.RandomAccessFile.open0 (Native Method)
> at java.io.RandomAccessFile.open (RandomAccessFile.java:316)
> at java.io.RandomAccessFile. (RandomAccessFile.java:243)
> at org.eclipse.aether.internal.impl.TrackingFileManager.update
> (TrackingFileManager.java:86)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:590)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:526)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:634)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:525)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:402)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:229)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:340)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal
> (DefaultPluginDependenciesResolver.java:226)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> (DefaultPluginDependenciesResolver.java:165)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts
> (DefaultMavenPluginManager.java:911)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm
> (DefaultMavenPluginManager.java:842)
> at
> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm
> (DefaultProjectBuildingHelper.java:197)
> at
> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled
> (DefaultModelBuildingListener.java:101)
> at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire
> (ModelBuildingEventCatapult.java:44)
> at org.apache.maven.model.building.DefaultModelBuilder.fireEvent
> (DefaultModelBuilder.java:1450)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:530)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:510)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:618)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:387)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
>
[jira] [Reopened] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MNG-7545: - > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Attachments: image-2022-10-08-15-38-10-927.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.DefaultGraphBuilder.build > (DefaultGraphBuilder.java:82) > at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:532) > at org.apache.maven.DefaultMa
[jira] [Comment Edited] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[
https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614410#comment-17614410
]
Michael Osipov edited comment on MNG-7545 at 10/8/22 8:05 AM:
--
To further procede with this and reopen, provide {{mvn -v} and all args passed
to Maven as well as the build output in verbose mode ({{-X}}).
was (Author: michael-o):
To further procede with this and reopen, provide {{mvn -v} and all args passed
to Maven as well as the build output in verbose mode ({{-X}}).
> Multi building can create bad files for downloaded artifacts in local
> repository
>
>
> Key: MNG-7545
> URL: https://issues.apache.org/jira/browse/MNG-7545
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.6
>Reporter: liuchangcheng
>Assignee: Michael Osipov
>Priority: Major
> Attachments: image-2022-10-08-15-38-10-927.png
>
>
> Within a parallel build, modules A and B can start at the same time and
> decide at the same time that they need to download artifact X. Since X is not
> available locally, both can start download of X. Both will download X and
> both will try to write the file for X to disk.
> On Windows platforms, one of them can fail with file locking problems. On
> Unixes the contents of the written file can be non-deterministic.
> This issue is related to MNG-2802 in the sense that it can create a corrupted
> artifact file in the local repository, and it can happen to ANY file written.
> But as opposed to MNG-2802 the synhronization needed to fix this issue is
> basically only within a single running maven process, so regular java
> mechanisms can apply, whereas MNG-2802 probably needs to use a totally
> different solution space.
>
> is this issue fixed?
> we are still facing this problem with maven 3.8.6
>
> I get error like this below
> [WARNING] Failed to write tracking file
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> java.io.FileNotFoundException:
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> (另一个程序正在使用此文件，进程无法访问。)
> at java.io.RandomAccessFile.open0 (Native Method)
> at java.io.RandomAccessFile.open (RandomAccessFile.java:316)
> at java.io.RandomAccessFile. (RandomAccessFile.java:243)
> at org.eclipse.aether.internal.impl.TrackingFileManager.update
> (TrackingFileManager.java:86)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:590)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:526)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:634)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:525)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:402)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:229)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:340)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal
> (DefaultPluginDependenciesResolver.java:226)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> (DefaultPluginDependenciesResolver.java:165)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts
> (DefaultMavenPluginManager.java:911)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm
> (DefaultMavenPluginManager.java:842)
> at
> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm
> (DefaultProjectBuildingHelper.java:197)
> at
> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled
> (DefaultModelBuildingListener.java:101)
> at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire
> (ModelBuildingEventCatapult.java:44)
> at org.apache.maven.model.building.DefaultModelBuilder.fireEvent
> (DefaultModelBuilder.java:1450)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:530)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:510)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:618)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:38
[jira] [Comment Edited] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[
https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614410#comment-17614410
]
Michael Osipov edited comment on MNG-7545 at 10/8/22 8:05 AM:
--
To further procede with this and reopen, provide {{mvn -v}} and all args passed
to Maven as well as the build output in verbose mode ({{-X}}).
was (Author: michael-o):
To further procede with this and reopen, provide {{mvn -v} and all args passed
to Maven as well as the build output in verbose mode ({{-X}}).
> Multi building can create bad files for downloaded artifacts in local
> repository
>
>
> Key: MNG-7545
> URL: https://issues.apache.org/jira/browse/MNG-7545
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.6
>Reporter: liuchangcheng
>Assignee: Michael Osipov
>Priority: Major
> Attachments: image-2022-10-08-15-38-10-927.png
>
>
> Within a parallel build, modules A and B can start at the same time and
> decide at the same time that they need to download artifact X. Since X is not
> available locally, both can start download of X. Both will download X and
> both will try to write the file for X to disk.
> On Windows platforms, one of them can fail with file locking problems. On
> Unixes the contents of the written file can be non-deterministic.
> This issue is related to MNG-2802 in the sense that it can create a corrupted
> artifact file in the local repository, and it can happen to ANY file written.
> But as opposed to MNG-2802 the synhronization needed to fix this issue is
> basically only within a single running maven process, so regular java
> mechanisms can apply, whereas MNG-2802 probably needs to use a totally
> different solution space.
>
> is this issue fixed?
> we are still facing this problem with maven 3.8.6
>
> I get error like this below
> [WARNING] Failed to write tracking file
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> java.io.FileNotFoundException:
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> (另一个程序正在使用此文件，进程无法访问。)
> at java.io.RandomAccessFile.open0 (Native Method)
> at java.io.RandomAccessFile.open (RandomAccessFile.java:316)
> at java.io.RandomAccessFile. (RandomAccessFile.java:243)
> at org.eclipse.aether.internal.impl.TrackingFileManager.update
> (TrackingFileManager.java:86)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:590)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:526)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:634)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:525)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:402)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:229)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:340)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal
> (DefaultPluginDependenciesResolver.java:226)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> (DefaultPluginDependenciesResolver.java:165)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts
> (DefaultMavenPluginManager.java:911)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm
> (DefaultMavenPluginManager.java:842)
> at
> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm
> (DefaultProjectBuildingHelper.java:197)
> at
> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled
> (DefaultModelBuildingListener.java:101)
> at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire
> (ModelBuildingEventCatapult.java:44)
> at org.apache.maven.model.building.DefaultModelBuilder.fireEvent
> (DefaultModelBuilder.java:1450)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:530)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:510)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:618)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:3
[jira] [Updated] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7545: Fix Version/s: waiting-for-feedback > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-10-08-15-38-10-927.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.DefaultGraphBuilder.build > (DefaultGraphBuilder.java:82) > at org.apache.maven
[jira] [Commented] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614411#comment-17614411 ] liuchangcheng commented on MNG-7545: D:\DevCloud\test\maven-resolver-maven-resolver-1.8.2>mvn -v Apache Maven 3.8.6-resolver-1.8.2 (59f2fc14eb90e259445eddce0c79f2cf24c0789b) Maven home: D:\apache-maven-3.8.6 Java version: 1.8.0_141, vendor: Oracle Corporation, runtime: D:\Program Files\Java\jdk1.8.0_141\jre Default locale: zh_CN, platform encoding: GBK OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-10-08-15-38-10-927.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.m
[GitHub] [maven-site] kwin commented on pull request #325: Remove property from parameter for Map and Properties
kwin commented on PR #325: URL: https://github.com/apache/maven-site/pull/325#issuecomment-1272261474 Maybe an explicit hint would be good. -- 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-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614412#comment-17614412 ] liuchangcheng commented on MNG-7545: [DEBUG] Resolving artifact org.apache.maven:maven-artifact-manager:pom:2.0.8 from [z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)] [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://maven.gwtools.com/a/ [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://maven.gwtools.com/a/ Downloading from z_mirrors: https://maven.gwtools.com/a/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom [DEBUG] Concurrent download of D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\maven-artifact-manager-2.0.8.pom.part in progress, awaiting completion [DEBUG] Concurrent download of D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\maven-artifact-manager-2.0.8.pom just finished, skipping download Downloaded from z_mirrors: https://maven.gwtools.com/a/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom (0 B at 0 B/s) [DEBUG] Writing tracking file D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\_remote.repositories [DEBUG] Writing tracking file D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\maven-artifact-manager-2.0.8.pom.lastUpdated [DEBUG] Resolving artifact org.apache.maven:maven-plugin-registry:pom:2.0.8 from [z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)] [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://maven.gwtools.com/a/ [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://maven.gwtools.com/a/ Downloading from z_mirrors: https://maven.gwtools.com/a/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom [DEBUG] Concurrent download of D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\maven-plugin-registry-2.0.8.pom.part in progress, awaiting completion [DEBUG] Concurrent download of D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\maven-plugin-registry-2.0.8.pom just finished, skipping download Downloaded from z_mirrors: https://maven.gwtools.com/a/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom (0 B at 0 B/s) [DEBUG] Writing tracking file D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\_remote.repositories [DEBUG] Writing tracking file D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\maven-plugin-registry-2.0.8.pom.lastUpdated [DEBUG] Resolving artifact org.apache.maven:maven-plugin-api:pom:2.0.8 from [z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)] [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://maven.gwtools.com/a/ [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://maven.gwtools.com/a/ Downloading from z_mirrors: https://maven.gwtools.com/a/org/apache/maven/maven-plugin-api/2.0.8/maven-plugin-api-2.0.8.pom [DEBUG] Concurrent download of D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\maven-plugin-api-2.0.8.pom.part in progress, awaiting completion [DEBUG] Concurrent download of D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\maven-plugin-api-2.0.8.pom just finished, skipping download Downloaded from z_mirrors: https://maven.gwtools.com/a/org/apache/maven/maven-plugin-api/2.0.8/maven-plugin-api-2.0.8.pom (0 B at 0 B/s) [DEBUG] Writing tracking file D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\_remote.repositories [DEBUG] Writing tracking file D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\maven-plugin-api-2.0.8.pom.lastUpdated [DEBUG] Resolving artifact org.codehaus.plexus:plexus-classworlds:pom:2.2.2 from [z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)] [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://maven.gwtools.com/a/ [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://maven.gwtools.com/a/ Downloading from z_mirrors: https://maven.gwtools.com/a/org/codehaus/plexus/plexus-classworlds/2.2.2/plexus-classworlds-2.2.2.pom [DEBUG] Concurrent download of D:\opt\repository123\org\codehaus\plexus\plexus-classworlds\2.2.2\plexus-classworlds-2.2.2.pom.part in progress, awaiting completion [DEBUG] Concurrent download of D:\opt\repository123\org\codehaus\plexus\plexus-classworlds\2.2.2\plexus-classworlds-2.2.2.pom just finished, skipping download Downloaded from z_mirrors: https://maven.gwtools.com/a/org/codehaus/plexus/plexus-classworlds/2.2.2/plexus-classworlds-2.2.2.pom (0 B at 0 B/s) [DEBUG] Writing tracking file D:\opt\repository123\org\codehaus\plexus\plexus-classworlds\2.2.2\_remote.repositories [DEBUG] Writing tracking file D:\opt\repositor
[jira] [Commented] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614413#comment-17614413 ] Michael Osipov commented on MNG-7545: - Uprade to a test Java 8 version first. This one is years old. > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-10-08-15-38-10-927.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.Defa
[jira] [Comment Edited] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[
https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614412#comment-17614412
]
Michael Osipov edited comment on MNG-7545 at 10/8/22 8:16 AM:
--
{noformat}
[DEBUG] Resolving artifact org.apache.maven:maven-artifact-manager:pom:2.0.8
from [z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)]
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://maven.gwtools.com/a/
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://maven.gwtools.com/a/
Downloading from z_mirrors:
https://maven.gwtools.com/a/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom
[DEBUG] Concurrent download of
D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\maven-artifact-manager-2.0.8.pom.part
in progress, awaiting completion
[DEBUG] Concurrent download of
D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\maven-artifact-manager-2.0.8.pom
just finished, skipping download
Downloaded from z_mirrors:
https://maven.gwtools.com/a/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom
(0 B at 0 B/s)
[DEBUG] Writing tracking file
D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\_remote.repositories
[DEBUG] Writing tracking file
D:\opt\repository123\org\apache\maven\maven-artifact-manager\2.0.8\maven-artifact-manager-2.0.8.pom.lastUpdated
[DEBUG] Resolving artifact org.apache.maven:maven-plugin-registry:pom:2.0.8
from [z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)]
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://maven.gwtools.com/a/
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://maven.gwtools.com/a/
Downloading from z_mirrors:
https://maven.gwtools.com/a/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom
[DEBUG] Concurrent download of
D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\maven-plugin-registry-2.0.8.pom.part
in progress, awaiting completion
[DEBUG] Concurrent download of
D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\maven-plugin-registry-2.0.8.pom
just finished, skipping download
Downloaded from z_mirrors:
https://maven.gwtools.com/a/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom
(0 B at 0 B/s)
[DEBUG] Writing tracking file
D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\_remote.repositories
[DEBUG] Writing tracking file
D:\opt\repository123\org\apache\maven\maven-plugin-registry\2.0.8\maven-plugin-registry-2.0.8.pom.lastUpdated
[DEBUG] Resolving artifact org.apache.maven:maven-plugin-api:pom:2.0.8 from
[z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)]
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://maven.gwtools.com/a/
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://maven.gwtools.com/a/
Downloading from z_mirrors:
https://maven.gwtools.com/a/org/apache/maven/maven-plugin-api/2.0.8/maven-plugin-api-2.0.8.pom
[DEBUG] Concurrent download of
D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\maven-plugin-api-2.0.8.pom.part
in progress, awaiting completion
[DEBUG] Concurrent download of
D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\maven-plugin-api-2.0.8.pom
just finished, skipping download
Downloaded from z_mirrors:
https://maven.gwtools.com/a/org/apache/maven/maven-plugin-api/2.0.8/maven-plugin-api-2.0.8.pom
(0 B at 0 B/s)
[DEBUG] Writing tracking file
D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\_remote.repositories
[DEBUG] Writing tracking file
D:\opt\repository123\org\apache\maven\maven-plugin-api\2.0.8\maven-plugin-api-2.0.8.pom.lastUpdated
[DEBUG] Resolving artifact org.codehaus.plexus:plexus-classworlds:pom:2.2.2
from [z_mirrors (https://maven.gwtools.com/a/, default, releases+snapshots)]
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://maven.gwtools.com/a/
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://maven.gwtools.com/a/
Downloading from z_mirrors:
https://maven.gwtools.com/a/org/codehaus/plexus/plexus-classworlds/2.2.2/plexus-classworlds-2.2.2.pom
[DEBUG] Concurrent download of
D:\opt\repository123\org\codehaus\plexus\plexus-classworlds\2.2.2\plexus-classworlds-2.2.2.pom.part
in progress, awaiting completion
[DEBUG] Concurrent download of
D:\opt\repository123\org\codehaus\plexus\plexus-classworlds\2.2.2\plexus-classworlds-2.2.2.pom
just finished, skipping download
Downloaded from z_mirrors:
https://maven.gwtools.com/a/org/codehaus/plexus/plexus-classworlds/2.2.2/plexus-classworlds-2.2.2.pom
(0 B at 0 B/s)
[DEBUG] Writing tracking file
D:\opt\repository123\org\codehaus\plexus\plexus-classworlds\2.2.2\_remot
[jira] [Commented] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[
https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614414#comment-17614414
]
Michael Osipov commented on MNG-7545:
-
Read
https://maven.apache.org/resolver/maven-resolver-named-locks/analyzing-lock-issues.html
and run with:
{{mvn ... -Dmaven.repo.local=... -Dorg.slf4j.simpleLogger.showThreadName=true
-Dorg.slf4j.simpleLogger.showDateTime=true
-Dorg.slf4j.simpleLogger.log.org.eclipse.aether=trace -l build.log}}
> Multi building can create bad files for downloaded artifacts in local
> repository
>
>
> Key: MNG-7545
> URL: https://issues.apache.org/jira/browse/MNG-7545
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.6
>Reporter: liuchangcheng
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: image-2022-10-08-15-38-10-927.png
>
>
> Within a parallel build, modules A and B can start at the same time and
> decide at the same time that they need to download artifact X. Since X is not
> available locally, both can start download of X. Both will download X and
> both will try to write the file for X to disk.
> On Windows platforms, one of them can fail with file locking problems. On
> Unixes the contents of the written file can be non-deterministic.
> This issue is related to MNG-2802 in the sense that it can create a corrupted
> artifact file in the local repository, and it can happen to ANY file written.
> But as opposed to MNG-2802 the synhronization needed to fix this issue is
> basically only within a single running maven process, so regular java
> mechanisms can apply, whereas MNG-2802 probably needs to use a totally
> different solution space.
>
> is this issue fixed?
> we are still facing this problem with maven 3.8.6
>
> I get error like this below
> [WARNING] Failed to write tracking file
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> java.io.FileNotFoundException:
> D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated
> (另一个程序正在使用此文件，进程无法访问。)
> at java.io.RandomAccessFile.open0 (Native Method)
> at java.io.RandomAccessFile.open (RandomAccessFile.java:316)
> at java.io.RandomAccessFile. (RandomAccessFile.java:243)
> at org.eclipse.aether.internal.impl.TrackingFileManager.update
> (TrackingFileManager.java:86)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:590)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:526)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:634)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:525)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:402)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:229)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:340)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal
> (DefaultPluginDependenciesResolver.java:226)
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve
> (DefaultPluginDependenciesResolver.java:165)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts
> (DefaultMavenPluginManager.java:911)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm
> (DefaultMavenPluginManager.java:842)
> at
> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm
> (DefaultProjectBuildingHelper.java:197)
> at
> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled
> (DefaultModelBuildingListener.java:101)
> at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire
> (ModelBuildingEventCatapult.java:44)
> at org.apache.maven.model.building.DefaultModelBuilder.fireEvent
> (DefaultModelBuilder.java:1450)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:530)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:510)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:618)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:387)
> at org
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614417#comment-17614417
]
Michael Osipov commented on MRESOLVER-277:
--
[~cstamas], WDYT?
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #806: [MNG-7547] Simpler G level metadata generation
michael-o commented on code in PR #806:
URL: https://github.com/apache/maven/pull/806#discussion_r990610832
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -35,42 +43,35 @@
import org.eclipse.aether.metadata.Metadata;
import org.eclipse.aether.util.ConfigUtils;
-import static java.util.Objects.requireNonNull;
-
/**
- * Plugin G level metadata.
+ * Maven G level metadata generator.
+ *
+ * Plugin metadata contains G level list of "prefix" to A mapping for plugins
present under this G.
*/
class PluginsMetadataGenerator
-implements MetadataGenerator
+implements MetadataGenerator
{
-private final PluginsMetadataInfoProvider pluginsMetadataInfoProvider;
-
-private final Map plugins;
+private static final String PLUGIN_DESCRIPTOR_LOCATION =
"META-INF/maven/plugin.xml";
Review Comment:
All good, it is consistent with the rest of our code.
--
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-7547) Simplify G level metadata handling
[
https://issues.apache.org/jira/browse/MNG-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614419#comment-17614419
]
ASF GitHub Bot commented on MNG-7547:
-
michael-o commented on code in PR #806:
URL: https://github.com/apache/maven/pull/806#discussion_r990610832
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -35,42 +43,35 @@
import org.eclipse.aether.metadata.Metadata;
import org.eclipse.aether.util.ConfigUtils;
-import static java.util.Objects.requireNonNull;
-
/**
- * Plugin G level metadata.
+ * Maven G level metadata generator.
+ *
+ * Plugin metadata contains G level list of "prefix" to A mapping for plugins
present under this G.
*/
class PluginsMetadataGenerator
-implements MetadataGenerator
+implements MetadataGenerator
{
-private final PluginsMetadataInfoProvider pluginsMetadataInfoProvider;
-
-private final Map plugins;
+private static final String PLUGIN_DESCRIPTOR_LOCATION =
"META-INF/maven/plugin.xml";
Review Comment:
All good, it is consistent with the rest of our code.
> Simplify G level metadata handling
> --
>
> Key: MNG-7547
> URL: https://issues.apache.org/jira/browse/MNG-7547
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, Plugins and Lifecycle
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> The original fix from MNG-7055 can be tremendously simplified: the plugins
> about to be deployed are JARs with embedded plugin descriptor, that contains
> all the required information (GA, prefix, name) to make G level metadata
> generator does everything on it's own, no need for hoops and loops at all.
> Actually, with this, all 3 generators becomes self-sufficient, and no need
> for caller to even fiddle with deploying metadata (as it happens
> automatically, courtesy of resolver and resolver-provider in maven).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #806: [MNG-7547] Simpler G level metadata generation
michael-o commented on code in PR #806:
URL: https://github.com/apache/maven/pull/806#discussion_r990610911
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -124,7 +126,50 @@ public Collection finish( Collection art
}
}
}
-
return plugins.values();
}
+
+private PluginInfo extractPluginInfo( Artifact artifact )
+{
+// sanity: jar, no classifier and file exists
+if ( artifact != null
+&& "jar".equals( artifact.getExtension() )
+&& "".equals( artifact.getClassifier() )
+&& artifact.getFile() != null )
+{
+Path artifactPath = artifact.getFile().toPath();
+if ( Files.isRegularFile( artifactPath ) )
Review Comment:
Thanks, that is what I wanted to hear. We won't get so far w/o building the
JAR.
--
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-7547) Simplify G level metadata handling
[
https://issues.apache.org/jira/browse/MNG-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614421#comment-17614421
]
ASF GitHub Bot commented on MNG-7547:
-
michael-o commented on code in PR #806:
URL: https://github.com/apache/maven/pull/806#discussion_r990610911
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -124,7 +126,50 @@ public Collection finish( Collection art
}
}
}
-
return plugins.values();
}
+
+private PluginInfo extractPluginInfo( Artifact artifact )
+{
+// sanity: jar, no classifier and file exists
+if ( artifact != null
+&& "jar".equals( artifact.getExtension() )
+&& "".equals( artifact.getClassifier() )
+&& artifact.getFile() != null )
+{
+Path artifactPath = artifact.getFile().toPath();
+if ( Files.isRegularFile( artifactPath ) )
Review Comment:
Thanks, that is what I wanted to hear. We won't get so far w/o building the
JAR.
> Simplify G level metadata handling
> --
>
> Key: MNG-7547
> URL: https://issues.apache.org/jira/browse/MNG-7547
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, Plugins and Lifecycle
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> The original fix from MNG-7055 can be tremendously simplified: the plugins
> about to be deployed are JARs with embedded plugin descriptor, that contains
> all the required information (GA, prefix, name) to make G level metadata
> generator does everything on it's own, no need for hoops and loops at all.
> Actually, with this, all 3 generators becomes self-sufficient, and no need
> for caller to even fiddle with deploying metadata (as it happens
> automatically, courtesy of resolver and resolver-provider in maven).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #806: [MNG-7547] Simpler G level metadata generation
michael-o commented on PR #806: URL: https://github.com/apache/maven/pull/806#issuecomment-1272264963 @cstamas Can you please rebase? I want to test this as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7547) Simplify G level metadata handling
[ https://issues.apache.org/jira/browse/MNG-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614422#comment-17614422 ] ASF GitHub Bot commented on MNG-7547: - michael-o commented on PR #806: URL: https://github.com/apache/maven/pull/806#issuecomment-1272264963 @cstamas Can you please rebase? I want to test this as well. > Simplify G level metadata handling > -- > > Key: MNG-7547 > URL: https://issues.apache.org/jira/browse/MNG-7547 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Plugins and Lifecycle >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > The original fix from MNG-7055 can be tremendously simplified: the plugins > about to be deployed are JARs with embedded plugin descriptor, that contains > all the required information (GA, prefix, name) to make G level metadata > generator does everything on it's own, no need for hoops and loops at all. > Actually, with this, all 3 generators becomes self-sufficient, and no need > for caller to even fiddle with deploying metadata (as it happens > automatically, courtesy of resolver and resolver-provider in maven). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-release] michael-o commented on a diff in pull request #154: [MRELEASE-1107] Respect line separator also on release:prepare
michael-o commented on code in PR #154:
URL: https://github.com/apache/maven-release/pull/154#discussion_r990611236
##
maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java:
##
@@ -455,7 +453,8 @@ private String getLineSeparatorFromPom()
{
char current;
String lineSeparator = "";
-try ( InputStream is = new FileInputStream( this.project.getFile() ) )
+File releasePom = this.project.getFile();
+try ( InputStream is = new FileInputStream( releasePom ) )
Review Comment:
Why this change if you don't check for the existance? I don't see a
benefit...
--
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] (MRELEASE-1107) Respect "lineSeparator" also on "mvn release:prepare"
[ https://issues.apache.org/jira/browse/MRELEASE-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRELEASE-1107: - Fix Version/s: 3.0.0-M7 > Respect "lineSeparator" also on "mvn release:prepare" > - > > Key: MRELEASE-1107 > URL: https://issues.apache.org/jira/browse/MRELEASE-1107 > Project: Maven Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 3.0.0-M6 >Reporter: Pascal Knüppel >Assignee: Michael Osipov >Priority: Major > Fix For: 3.0.0-M7 > > > The `lineSeparator` configuration is only set if the the command `mvn > release:prepare-with-pom` is executed. But it should also take effect if `mvn > release:prepare` is used. > > I already created a pull-request to fix this: > https://github.com/apache/maven-release/pull/154 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRELEASE-1107) Respect "lineSeparator" also on "mvn release:prepare"
[ https://issues.apache.org/jira/browse/MRELEASE-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MRELEASE-1107: Assignee: Michael Osipov > Respect "lineSeparator" also on "mvn release:prepare" > - > > Key: MRELEASE-1107 > URL: https://issues.apache.org/jira/browse/MRELEASE-1107 > Project: Maven Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 3.0.0-M6 >Reporter: Pascal Knüppel >Assignee: Michael Osipov >Priority: Major > > The `lineSeparator` configuration is only set if the the command `mvn > release:prepare-with-pom` is executed. But it should also take effect if `mvn > release:prepare` is used. > > I already created a pull-request to fix this: > https://github.com/apache/maven-release/pull/154 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #197: [MRESOLVER-274] Remote Repository Filter
michael-o commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990611849
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
Review Comment:
Is this really worth an exception? I mean if I know that my repo will only
serve `com.example` it is not an error to skip `org` for reason.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614431#comment-17614431
]
ASF GitHub Bot commented on MRESOLVER-274:
--
michael-o commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990611849
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
Review Comment:
Is this really worth an exception? I mean if I know that my repo will only
serve `com.example` it is not an error to skip `org` for reason.
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #197: [MRESOLVER-274] Remote Repository Filter
michael-o commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990611901
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
Do we really have `#equals()` implemented on repo level?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614432#comment-17614432
]
ASF GitHub Bot commented on MRESOLVER-274:
--
michael-o commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990611901
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
Do we really have `#equals()` implemented on repo level?
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #197: [MRESOLVER-274] Remote Repository Filter
michael-o commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990612015
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
What if all repos are eligible to serve a specific artifact?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java:
##
@@ -226,6 +244,13 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+RemoteRepositoryFilter.Result filterResult =
remoteRepositoryFilter.acceptMetadata( repository, metadata );
+if ( !filterResult.isAccepted() )
+{
+result.setException( new MetadataNotFoundException( metadata,
repository, filterResult.reasoning() ) );
Review Comment:
Same as above.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614433#comment-17614433
]
ASF GitHub Bot commented on MRESOLVER-274:
--
michael-o commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990612015
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
What if all repos are eligible to serve a specific artifact?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java:
##
@@ -226,6 +244,13 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+RemoteRepositoryFilter.Result filterResult =
remoteRepositoryFilter.acceptMetadata( repository, metadata );
+if ( !filterResult.isAccepted() )
+{
+result.setException( new MetadataNotFoundException( metadata,
repository, filterResult.reasoning() ) );
Review Comment:
Same as above.
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on pull request #197: [MRESOLVER-274] Remote Repository Filter
michael-o commented on PR #197: URL: https://github.com/apache/maven-resolver/pull/197#issuecomment-1272268792 General question: Is it intended to plugin with Maven repo definition in POM and settings to have nested elements ``/``? Similar to maven-common-artifact-filters. This would be easily accessible, but requires model changes and would work without any brainfuck for the users. https://issues.apache.org/jira/browse/MNG-6763 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614434#comment-17614434
]
ASF GitHub Bot commented on MRESOLVER-274:
--
michael-o commented on PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#issuecomment-1272268792
General question: Is it intended to plugin with Maven repo definition in POM
and settings to have nested elements ``/``? Similar to
maven-common-artifact-filters. This would be easily accessible, but requires
model changes and would work without any brainfuck for the users.
https://issues.apache.org/jira/browse/MNG-6763
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] slawekjaranowski commented on pull request #325: Remove property from parameter for Map and Properties
slawekjaranowski commented on PR #325: URL: https://github.com/apache/maven-site/pull/325#issuecomment-1272269220 > Maybe an explicit hint would be good. Should be an another paragraph about using property with `Parameter`. -- 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-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liuchangcheng updated MNG-7545: --- Attachment: screenshot-1.png > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-10-08-15-38-10-927.png, screenshot-1.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.DefaultGraphBuilder.build > (DefaultGraphBuilder.java:82) > at org.apa
[jira] [Commented] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614435#comment-17614435 ] liuchangcheng commented on MNG-7545: running with maven 4.0.0- !screenshot-1.png! > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-10-08-15-38-10-927.png, screenshot-1.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.Defa
[GitHub] [maven-site] slawekjaranowski merged pull request #325: Remove property from parameter for Map and Properties
slawekjaranowski merged PR #325: URL: https://github.com/apache/maven-site/pull/325 -- 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-ear-plugin] slawekjaranowski merged pull request #54: Bump plexus-utils from 3.3.0 to 3.4.2
slawekjaranowski merged PR #54: URL: https://github.com/apache/maven-ear-plugin/pull/54 -- 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] (MEAR-320) Bump plexus-utils from 3.3.0 to 3.4.2
Slawomir Jaranowski created MEAR-320: Summary: Bump plexus-utils from 3.3.0 to 3.4.2 Key: MEAR-320 URL: https://issues.apache.org/jira/browse/MEAR-320 Project: Maven EAR Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.3.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MEAR-320) Bump plexus-utils from 3.3.0 to 3.4.2
[ https://issues.apache.org/jira/browse/MEAR-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MEAR-320. Resolution: Fixed > Bump plexus-utils from 3.3.0 to 3.4.2 > - > > Key: MEAR-320 > URL: https://issues.apache.org/jira/browse/MEAR-320 > Project: Maven EAR Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MEAR-308) Facing issues with "deleting outdated resource"
[
https://issues.apache.org/jira/browse/MEAR-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614439#comment-17614439
]
Slawomir Jaranowski commented on MEAR-308:
--
You should put your additional content in standard directory
{{src/main/aplication}}
If you need you can change location by {{earSourceDirectory}} parameter
> Facing issues with "deleting outdated resource"
> ---
>
> Key: MEAR-308
> URL: https://issues.apache.org/jira/browse/MEAR-308
> Project: Maven EAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Rich M
>Priority: Major
> Attachments: build.log, earmetainfissue.zip
>
>
> I am using maven-resources plugin to copy an additional file insider EAR
> META-INF folder. It works fine for the first time with clean. But when run
> again without clean, EAR plugin deletes the file saying "deleting outdated
> resource...".
> The pipeline runs the clean install first, and then run mvn deploy at later
> stage. Since mvn deploy builds ear again, it results in ear without the
> additional file.
> Here is a sample code attached. To recreate the problem:
> # Run mvn clean package. Note that \target\testear-1.0\META-INF will have 2
> files.
> # Run mvn package. \target\testear-1.0\META-INF will have only 1 file now.
> How can this behavior be fixed ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MEAR-308) Facing issues with "deleting outdated resource"
[ https://issues.apache.org/jira/browse/MEAR-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MEAR-308: - Fix Version/s: waiting-for-feedback > Facing issues with "deleting outdated resource" > --- > > Key: MEAR-308 > URL: https://issues.apache.org/jira/browse/MEAR-308 > Project: Maven EAR Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: Rich M >Priority: Major > Fix For: waiting-for-feedback > > Attachments: build.log, earmetainfissue.zip > > > I am using maven-resources plugin to copy an additional file insider EAR > META-INF folder. It works fine for the first time with clean. But when run > again without clean, EAR plugin deletes the file saying "deleting outdated > resource...". > The pipeline runs the clean install first, and then run mvn deploy at later > stage. Since mvn deploy builds ear again, it results in ear without the > additional file. > Here is a sample code attached. To recreate the problem: > # Run mvn clean package. Note that \target\testear-1.0\META-INF will have 2 > files. > # Run mvn package. \target\testear-1.0\META-INF will have only 1 file now. > How can this behavior be fixed ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MEAR-282) Support data-source element
[
https://issues.apache.org/jira/browse/MEAR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MEAR-282:
-
Labels: up-for-grabs (was: )
> Support data-source element
> ---
>
> Key: MEAR-282
> URL: https://issues.apache.org/jira/browse/MEAR-282
> Project: Maven EAR Plugin
> Issue Type: Wish
>Reporter: Joeren Haag
>Priority: Major
> Labels: up-for-grabs
>
> Since Version 6 and up to the latest Version of Java/Jakarta EE the
> data-source element is defined in the Schema of the {{application.xml}}
> ([#1]). So it would be nice to support the data-source element also in the
> configuration of the maven-ear-plugin. Here is my actual workaround:
> # enable the generation of {{application.xml}}
> # move the generated {{application.xml}} to the source folder
> {{src/main/application}}
> # disable the generation of {{application.xml}}
> # add the data-source configuration to {{application.xm}}
> Here is a "simple example" of the data-source element (the example is based
> on Version 8 of Java EE), like it's look in the {{application.xml}}:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ---
> * {anchor:1} 1: application-schema for Java EE version 6 -
> https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/application_6.xsd
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MEAR-227) Configuration option includeInApplicationXml accessible for all modules
[ https://issues.apache.org/jira/browse/MEAR-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MEAR-227: - Fix Version/s: waiting-for-feedback > Configuration option includeInApplicationXml accessible for all modules > --- > > Key: MEAR-227 > URL: https://issues.apache.org/jira/browse/MEAR-227 > Project: Maven EAR Plugin > Issue Type: Improvement >Reporter: Marek Gregor >Priority: Major > Fix For: waiting-for-feedback > > > Currently includeInApplicationXml configuration option is available only for > jarModule: > https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule > We need to use it also for another module (in our case it is webModule). I > think it will be fine to enable this option for all modules (ejb, web, ...). > The motivation is to enable specific ear to be built with modules by default > not described in application.xml. Person responsible for deploying will add > modules to application.xml based on current case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MEAR-227) Configuration option includeInApplicationXml accessible for all modules
[
https://issues.apache.org/jira/browse/MEAR-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614441#comment-17614441
]
Slawomir Jaranowski commented on MEAR-227:
--
I as see the standard module was added to {{application.xml}} by default.
Can you retest with the latest version of {{m-ear-p}}
> Configuration option includeInApplicationXml accessible for all modules
> ---
>
> Key: MEAR-227
> URL: https://issues.apache.org/jira/browse/MEAR-227
> Project: Maven EAR Plugin
> Issue Type: Improvement
>Reporter: Marek Gregor
>Priority: Major
>
> Currently includeInApplicationXml configuration option is available only for
> jarModule:
> https://maven.apache.org/plugins/maven-ear-plugin/modules.html#jarModule
> We need to use it also for another module (in our case it is webModule). I
> think it will be fine to enable this option for all modules (ejb, web, ...).
> The motivation is to enable specific ear to be built with modules by default
> not described in application.xml. Person responsible for deploying will add
> modules to application.xml based on current case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MEAR-269) Generate Websphere Deployment Descriptors
[ https://issues.apache.org/jira/browse/MEAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MEAR-269: - Fix Version/s: waiting-for-feedback > Generate Websphere Deployment Descriptors > - > > Key: MEAR-269 > URL: https://issues.apache.org/jira/browse/MEAR-269 > Project: Maven EAR Plugin > Issue Type: New Feature >Reporter: David Gautier >Priority: Minor > Fix For: waiting-for-feedback > > > Websphere deployment descriptors could be generated based on application.xml > and web.xml > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MEAR-269) Generate Websphere Deployment Descriptors
[ https://issues.apache.org/jira/browse/MEAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614442#comment-17614442 ] Slawomir Jaranowski commented on MEAR-269: -- Is still relevant? Please answer last questions. > Generate Websphere Deployment Descriptors > - > > Key: MEAR-269 > URL: https://issues.apache.org/jira/browse/MEAR-269 > Project: Maven EAR Plugin > Issue Type: New Feature >Reporter: David Gautier >Priority: Minor > > Websphere deployment descriptors could be generated based on application.xml > and web.xml > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MEAR-264) Optional Modules
[ https://issues.apache.org/jira/browse/MEAR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614443#comment-17614443 ] Slawomir Jaranowski commented on MEAR-264: -- You can put configuration of additional dependencies in profile. Also configuration for additional module can be done in profile. > Optional Modules > > > Key: MEAR-264 > URL: https://issues.apache.org/jira/browse/MEAR-264 > Project: Maven EAR Plugin > Issue Type: New Feature >Reporter: Frank Cornelis >Priority: Major > > Right now a module its corresponding dependency must always be provided. > But sometimes you want to change the content of an EAR using a Maven profile > to include more or less modules. > It would be handy if you could add > true > to a module. If set to true, the maven-ear-plugin will not error in case the > corresponding dependency has not been declared. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MEAR-264) Optional Modules
[ https://issues.apache.org/jira/browse/MEAR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MEAR-264: - Fix Version/s: waiting-for-feedback > Optional Modules > > > Key: MEAR-264 > URL: https://issues.apache.org/jira/browse/MEAR-264 > Project: Maven EAR Plugin > Issue Type: New Feature >Reporter: Frank Cornelis >Priority: Major > Fix For: waiting-for-feedback > > > Right now a module its corresponding dependency must always be provided. > But sometimes you want to change the content of an EAR using a Maven profile > to include more or less modules. > It would be handy if you could add > true > to a module. If set to true, the maven-ear-plugin will not error in case the > corresponding dependency has not been declared. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #197: [MRESOLVER-274] Remote Repository Filter
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990616796
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
Review Comment:
Yes, this is common way to communicate (up to the surface) why resolution
failed, see here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L380-L384
and here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L418-L425
and here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java#L222
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MEAR-269) Generate Websphere Deployment Descriptors
[ https://issues.apache.org/jira/browse/MEAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614446#comment-17614446 ] Benjamin Marwell commented on MEAR-269: --- The files I mentioned are part of a war file. So because you don't know the ear file at this point, I don't see how those files could be generated. They're easily handwritten anyway. As the OP never answered, I'd say: close this one. > Generate Websphere Deployment Descriptors > - > > Key: MEAR-269 > URL: https://issues.apache.org/jira/browse/MEAR-269 > Project: Maven EAR Plugin > Issue Type: New Feature >Reporter: David Gautier >Priority: Minor > Fix For: waiting-for-feedback > > > Websphere deployment descriptors could be generated based on application.xml > and web.xml > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614445#comment-17614445
]
ASF GitHub Bot commented on MRESOLVER-274:
--
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990616796
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
Review Comment:
Yes, this is common way to communicate (up to the surface) why resolution
failed, see here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L380-L384
and here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java#L418-L425
and here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java#L222
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #197: [MRESOLVER-274] Remote Repository Filter
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990616904
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
Yes, see here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/repository/RemoteRepository.java#L265-L300
(and it is a `final` class on purpose as well)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #197: [MRESOLVER-274] Remote Repository Filter
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990616953
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
then `filteringApplied` is `false`?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java:
##
@@ -226,6 +244,13 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+RemoteRepositoryFilter.Result filterResult =
remoteRepositoryFilter.acceptMetadata( repository, metadata );
+if ( !filterResult.isAccepted() )
+{
+result.setException( new MetadataNotFoundException( metadata,
repository, filterResult.reasoning() ) );
Review Comment:
Same as "see here, and here and 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] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614449#comment-17614449
]
ASF GitHub Bot commented on MRESOLVER-274:
--
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990616953
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
then `filteringApplied` is `false`?
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java:
##
@@ -226,6 +244,13 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+RemoteRepositoryFilter.Result filterResult =
remoteRepositoryFilter.acceptMetadata( repository, metadata );
+if ( !filterResult.isAccepted() )
+{
+result.setException( new MetadataNotFoundException( metadata,
repository, filterResult.reasoning() ) );
Review Comment:
Same as "see here, and here and here"
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614448#comment-17614448
]
ASF GitHub Bot commented on MRESOLVER-274:
--
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990616904
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
+}
+else
+{
+filteredRemoteRepositories.add( repository );
+}
+}
+
+final boolean remoteConsidered = !remoteRepositories.isEmpty();
+final boolean filteringApplied = remoteConsidered
+&& !remoteRepositories.equals( filteredRemoteRepositories
);
Review Comment:
Yes, see here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/repository/RemoteRepository.java#L265-L300
(and it is a `final` class on purpose as well)
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #197: [MRESOLVER-274] Remote Repository Filter
cstamas commented on PR #197: URL: https://github.com/apache/maven-resolver/pull/197#issuecomment-1272276273 > General question: Is it intended to plugin with Maven repo definition in POM and settings to have nested elements ``/``? Similar to maven-common-artifact-filters. This would be easily accessible, but requires model changes and would work without any brainfuck for the users. https://issues.apache.org/jira/browse/MNG-6763 This is maven-resolver, not maven. Hence, one can consier this as "foundation" (low level) implementation, that can be topped in many different ways, for example, Maven could either provide it's own filter implementations sourced from new model (if model is changed to support that) or just "manage" these "low level" sources in some way. This PR is not related in any way to Maven, as it have no access to models like POM, Settings, etc. It just lies down the foundations to solve that issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614450#comment-17614450
]
ASF GitHub Bot commented on MRESOLVER-274:
--
cstamas commented on PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#issuecomment-1272276273
> General question: Is it intended to plugin with Maven repo definition in
POM and settings to have nested elements ``/``? Similar
to maven-common-artifact-filters. This would be easily accessible, but requires
model changes and would work without any brainfuck for the users.
https://issues.apache.org/jira/browse/MNG-6763
This is maven-resolver, not maven. Hence, one can consier this as
"foundation" (low level) implementation, that can be topped in many different
ways, for example, Maven could either provide it's own filter implementations
sourced from new model (if model is changed to support that) or just "manage"
these "low level" sources in some way. This PR is not related in any way to
Maven, as it have no access to models like POM, Settings, etc. It just lies
down the foundations to solve that issue.
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #197: [MRESOLVER-274] Remote Repository Filter
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990617565
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
Review Comment:
Also, see here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/resolution/ArtifactResolutionException.java#L96
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-274) Introduce Remote Repository Filter feature
[
https://issues.apache.org/jira/browse/MRESOLVER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614451#comment-17614451
]
ASF GitHub Bot commented on MRESOLVER-274:
--
cstamas commented on code in PR #197:
URL: https://github.com/apache/maven-resolver/pull/197#discussion_r990617565
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:
##
@@ -282,10 +297,31 @@ private List resolve(
RepositorySystemSession session,
continue;
}
+List remoteRepositories =
request.getRepositories();
+List filteredRemoteRepositories = new
ArrayList<>( remoteRepositories.size() );
+for ( RemoteRepository repository : remoteRepositories )
+{
+RemoteRepositoryFilter.Result filterResult =
filter.acceptArtifact( repository, artifact );
+if ( !filterResult.isAccepted() )
+{
+result.addException( new ArtifactNotFoundException(
artifact, repository,
+filterResult.reasoning() ) );
Review Comment:
Also, see here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/resolution/ArtifactResolutionException.java#L96
> Introduce Remote Repository Filter feature
> --
>
> Key: MRESOLVER-274
> URL: https://issues.apache.org/jira/browse/MRESOLVER-274
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: resolver-next
>
>
> The feature, as it's name says should be able to "filter" RemoteRepositories
> by some criteria ("known bad GAVs", "allowed groupId", etc).
> In short, this feature allows following filtering: "should be Artifact
> available from RemoteRepository?" and is able to employ several combination
> (via consensus, or later possibly other strategies) of several "filter
> sources" that are extensible (via adding new components).
> Filter is used in two places:
> * in connector, preventing remote artifact to be fetched from remote
> repository (100% reliable)
> * in resolution, preventing locally *cached* artifact to be resolved
> (reliable as much as your local repository is "clean", ie. if you used Simple
> LRM on it, it does not track remote origins will fail to filter, while
> EnhancedLRM does track it and will work as expected).
> By default this feature is "dormant" (resolver behaves exactly same as before
> without it). This is intended as "low level" feature that later can be built
> upon, and implement some more user friendly solutions like MNG-6763. Hence,
> this issue and resolver code changes are NOT meant to completely implement
> MNG-6763, but more like to provide needed (lower level) functionalities to
> make it possible.
> Filters implemented in this round:
> * groupId - provide a list of groupIds per remote repository
> * prefix - use prefixes file for allowed prefixes (example central
> [https://repo.maven.apache.org/maven2/.meta/prefixes.txt] or ASF releases
> [https://repository.apache.org/content/repositories/releases/.meta/prefixes.txt)]
> * maybe package up an artifact holding list of "known" bad artifacts and
> consume that (and enforce it)
> * etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7547) Simplify G level metadata handling
[ https://issues.apache.org/jira/browse/MNG-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614453#comment-17614453 ] ASF GitHub Bot commented on MNG-7547: - cstamas commented on PR #806: URL: https://github.com/apache/maven/pull/806#issuecomment-1272278473 @michael-o rebased > Simplify G level metadata handling > -- > > Key: MNG-7547 > URL: https://issues.apache.org/jira/browse/MNG-7547 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Plugins and Lifecycle >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > The original fix from MNG-7055 can be tremendously simplified: the plugins > about to be deployed are JARs with embedded plugin descriptor, that contains > all the required information (GA, prefix, name) to make G level metadata > generator does everything on it's own, no need for hoops and loops at all. > Actually, with this, all 3 generators becomes self-sufficient, and no need > for caller to even fiddle with deploying metadata (as it happens > automatically, courtesy of resolver and resolver-provider in maven). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #806: [MNG-7547] Simpler G level metadata generation
cstamas commented on PR #806: URL: https://github.com/apache/maven/pull/806#issuecomment-1272278473 @michael-o rebased -- 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] (MWRAPPER-45) Migrate/Sync startup scripts with Maven 4
[ https://issues.apache.org/jira/browse/MWRAPPER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614465#comment-17614465 ] Slawomir Jaranowski commented on MWRAPPER-45: - Yes we should have and use only one scripts from distribution, in other case it will be difficult to provide proper script according to used Maven versions. > Migrate/Sync startup scripts with Maven 4 > - > > Key: MWRAPPER-45 > URL: https://issues.apache.org/jira/browse/MWRAPPER-45 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > > The scripts are Maven 3 based. Maven 4 has simplified the scripts and > introduced consistency improvements. We should port those over for version 4?! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIA-677) Macro for printing project properties
Slawomir Jaranowski created DOXIA-677:
-
Summary: Macro for printing project properties
Key: DOXIA-677
URL: https://issues.apache.org/jira/browse/DOXIA-677
Project: Maven Doxia
Issue Type: New Feature
Reporter: Slawomir Jaranowski
Many time we use velocity only for resolving project properties like:
{code}
${project.version}
{code}
Another case is that for Markdown we have conflicts
Velocity uses # as a prefix for macros and ## as a prefix for comments
but in Markdown those is used for headers
So Doxia macro will be useful is such cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIA-677) Macro for printing project properties
[
https://issues.apache.org/jira/browse/DOXIA-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated DOXIA-677:
--
Description:
Many time we use Velocity only for resolving project properties like:
{code}
${project.version}
{code}
Another case is that for Markdown we have conflicts
Velocity uses # as a prefix for macros and ## as a prefix for comments
but in Markdown those are used for headers
So Doxia macro will be useful is such cases.
was:
Many time we use velocity only for resolving project properties like:
{code}
${project.version}
{code}
Another case is that for Markdown we have conflicts
Velocity uses # as a prefix for macros and ## as a prefix for comments
but in Markdown those is used for headers
So Doxia macro will be useful is such cases.
> Macro for printing project properties
> -
>
> Key: DOXIA-677
> URL: https://issues.apache.org/jira/browse/DOXIA-677
> Project: Maven Doxia
> Issue Type: New Feature
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Many time we use Velocity only for resolving project properties like:
> {code}
> ${project.version}
> {code}
> Another case is that for Markdown we have conflicts
> Velocity uses # as a prefix for macros and ## as a prefix for comments
> but in Markdown those are used for headers
> So Doxia macro will be useful is such cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-ear-plugin] dependabot[bot] commented on pull request #62: Bump commons-io from 1.4 to 2.7 in /src/it/packaging-includes
dependabot[bot] commented on PR #62: URL: https://github.com/apache/maven-ear-plugin/pull/62#issuecomment-1272302042 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] slawekjaranowski closed pull request #62: Bump commons-io from 1.4 to 2.7 in /src/it/packaging-includes
slawekjaranowski closed pull request #62: Bump commons-io from 1.4 to 2.7 in /src/it/packaging-includes URL: https://github.com/apache/maven-ear-plugin/pull/62 -- 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-ear-plugin] slawekjaranowski closed pull request #63: Bump commons-io from 2.6 to 2.7 in /src/it/skinny-wars-javaee5/war-module3
slawekjaranowski closed pull request #63: Bump commons-io from 2.6 to 2.7 in /src/it/skinny-wars-javaee5/war-module3 URL: https://github.com/apache/maven-ear-plugin/pull/63 -- 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-ear-plugin] dependabot[bot] commented on pull request #63: Bump commons-io from 2.6 to 2.7 in /src/it/skinny-wars-javaee5/war-module3
dependabot[bot] commented on PR #63: URL: https://github.com/apache/maven-ear-plugin/pull/63#issuecomment-1272302091 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] (MNG-7545) Multi building can create bad files for downloaded artifacts in local repository
[ https://issues.apache.org/jira/browse/MNG-7545 ] liuchangcheng deleted comment on MNG-7545: was (Author: JIRAUSER296009): running with maven 4.0.0- !screenshot-1.png! > Multi building can create bad files for downloaded artifacts in local > repository > > > Key: MNG-7545 > URL: https://issues.apache.org/jira/browse/MNG-7545 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: liuchangcheng >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: image-2022-10-08-15-38-10-927.png, screenshot-1.png > > > Within a parallel build, modules A and B can start at the same time and > decide at the same time that they need to download artifact X. Since X is not > available locally, both can start download of X. Both will download X and > both will try to write the file for X to disk. > On Windows platforms, one of them can fail with file locking problems. On > Unixes the contents of the written file can be non-deterministic. > This issue is related to MNG-2802 in the sense that it can create a corrupted > artifact file in the local repository, and it can happen to ANY file written. > But as opposed to MNG-2802 the synhronization needed to fix this issue is > basically only within a single running maven process, so regular java > mechanisms can apply, whereas MNG-2802 probably needs to use a totally > different solution space. > > is this issue fixed? > we are still facing this problem with maven 3.8.6 > > I get error like this below > [WARNING] Failed to write tracking file > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > java.io.FileNotFoundException: > D:\opt\repository11\org\apache\ant\ant-launcher\1.10.12\ant-launcher-1.10.12.jar.lastUpdated > (另一个程序正在使用此文件，进程无法访问。) > at java.io.RandomAccessFile.open0 (Native Method) > at java.io.RandomAccessFile.open (RandomAccessFile.java:316) > at java.io.RandomAccessFile. (RandomAccessFile.java:243) > at org.eclipse.aether.internal.impl.TrackingFileManager.update > (TrackingFileManager.java:86) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:590) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:526) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:634) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:525) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:402) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:229) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:340) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal > (DefaultPluginDependenciesResolver.java:226) > at > org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve > (DefaultPluginDependenciesResolver.java:165) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.resolveExtensionArtifacts > (DefaultMavenPluginManager.java:911) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupExtensionsRealm > (DefaultMavenPluginManager.java:842) > at > org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm > (DefaultProjectBuildingHelper.java:197) > at > org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled > (DefaultModelBuildingListener.java:101) > at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire > (ModelBuildingEventCatapult.java:44) > at org.apache.maven.model.building.DefaultModelBuilder.fireEvent > (DefaultModelBuilder.java:1450) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:530) > at org.apache.maven.model.building.DefaultModelBuilder.build > (DefaultModelBuilder.java:510) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:618) > at org.apache.maven.project.DefaultProjectBuilder.build > (DefaultProjectBuilder.java:387) > at org.apache.maven.graph.DefaultGraphBuilder.collectProjects > (DefaultGraphBuilder.java:414) > at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor > (DefaultGraphBuilder.java:405) > at org.apache.maven.graph.DefaultGraphBuilder.build > (DefaultGraphBuilder.java:82) > at org.apa
[jira] [Assigned] (MEAR-304) Update plugin dependencies
[ https://issues.apache.org/jira/browse/MEAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MEAR-304: Assignee: Slawomir Jaranowski (was: Tamas Cservenak) > Update plugin dependencies > -- > > Key: MEAR-304 > URL: https://issues.apache.org/jira/browse/MEAR-304 > Project: Maven EAR Plugin > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.0 > > > Update plugin changes: > * set maven bits to provided scope > * update dependencies -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-ear-plugin] slawekjaranowski opened a new pull request, #75: [MEAR-304] Update dependencies used in IT tests
slawekjaranowski opened a new pull request, #75: URL: https://github.com/apache/maven-ear-plugin/pull/75 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/MEAR) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MEAR-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MEAR-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] amitmisra-ww commented on pull request #64: [MWRAPPER-33] Use java 8 in maven-wrapper
amitmisra-ww commented on PR #64: URL: https://github.com/apache/maven-wrapper/pull/64#issuecomment-1272316852 @slawekjaranowski please let me know if there is anything else required for this PR to be accepted. Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614487#comment-17614487
]
Tamas Cservenak commented on MRESOLVER-277:
---
IMHO, this works as intented. This is the definition of "never" policy:
{noformat}
/**
* Never update locally cached data.
*/
public static final String UPDATE_POLICY_NEVER = "never"; {noformat}
Key part: "never update *locally cached* data". With empty repository, you have
no locally cached data.
[~ralaoui] you probably mean "offline for metadata"? As such a feature would
prevent download, but is not supported.
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-33) Use java 8 in maven-wrapper
[
https://issues.apache.org/jira/browse/MWRAPPER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614485#comment-17614485
]
ASF GitHub Bot commented on MWRAPPER-33:
amitmisra-ww commented on PR #64:
URL: https://github.com/apache/maven-wrapper/pull/64#issuecomment-1272316852
@slawekjaranowski please let me know if there is anything else required for
this PR to be accepted. Thanks.
> Use java 8 in maven-wrapper
> ---
>
> Key: MWRAPPER-33
> URL: https://issues.apache.org/jira/browse/MWRAPPER-33
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Jar
>Affects Versions: 3.1.0
>Reporter: Slawomir Jaranowski
>Priority: Major
> Labels: up-for-grabs
>
> Currently {{maven-wrapper}} use java {*}5{*}.
> It blocks build project on java > 8.
> {{maven-wrapper-plugin}} require java 8, so we can use {{maven-wrapper}} with
> java 5 but we can't install it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCHECKSTYLE-342) Support XML 1.1
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614490#comment-17614490 ] Roman Ivanov commented on MCHECKSTYLE-342: -- [~eolivelli], can you reopen issue ? > Support XML 1.1 > --- > > Key: MCHECKSTYLE-342 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-342 > Project: Maven Checkstyle Plugin > Issue Type: New Feature > Components: checkstyle:check >Affects Versions: 2.17 >Reporter: richard >Assignee: Enrico Olivelli >Priority: Minor > > Checkstyle wishes to upgrade our XML logger to print out XML 1.1 documents. > We need this functionality to support escaping non-printable characters as > XML 1.0 doesn't allow this and considers it an invalid document. > > Exception in thread "main" javax.xml.stream.XMLStreamException: ParseError > > at [row,col]:[45615,80] > > Message: An invalid XML character (Unicode: 0x2) was found in the value of > > attribute "message" and element is "error". > Checkstyle cannot upgrade until maven-checkstyle does as we use it in alot of > regression testing. If we try to give the plugin an XML 1.1 document, it > fails with the following error: > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (default-cli) > > on project postgresql: Unable to read Checkstyle results xml: > > /pipeline/source/pgjdbc/pgjdbc/target/checkstyle-result.xml: only 1.0 is > > supported as > version="1.1"... @1:19) -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614494#comment-17614494
]
Réda Housni Alaoui edited comment on MRESOLVER-277 at 10/8/22 2:21 PM:
---
{quote}
Key part: "never update locally cached data". With empty repository, you have
no locally cached data.
{quote}
Indeed, therefore it is not a bug.
{quote}
Réda Housni Alaoui you probably mean "offline for metadata"? As such a feature
would prevent download, but is not supported.
{quote}
Yes. Would you accept this as a new feature? I can contribute with code if
needed.
was (Author: ralaoui):
{quote}
Key part: "never update locally cached data". With empty repository, you have
no locally cached data.
{quote}
Indeed, therefore it is not a bug.
{quote}
Réda Housni Alaoui you probably mean "offline for metadata"? As such a feature
would prevent download, but is not supported.
{quote}
Yes. Would you accept this as a new feature? I can contribute code if needed.
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614494#comment-17614494
]
Réda Housni Alaoui commented on MRESOLVER-277:
--
{quote}
Key part: "never update locally cached data". With empty repository, you have
no locally cached data.
{quote}
Indeed, therefore it is not a bug.
{quote}
Réda Housni Alaoui you probably mean "offline for metadata"? As such a feature
would prevent download, but is not supported.
{quote}
Yes. Would you accept this as a new feature? I can contribute code if needed.
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614495#comment-17614495
]
Tamas Cservenak commented on MRESOLVER-277:
---
Before doing a patch, am more interested in the problem, What do you mean by
"each time I build the project using an empty local repository, maven-resolver
tries to download the {{metadata.xml}} of each module". You mean the module you
are building? Can you create a small reproducer for this?
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] mprimeaux commented on issue #337: Add Apple M1 build.
mprimeaux commented on issue #337: URL: https://github.com/apache/maven-mvnd/issues/337#issuecomment-1272332628 @gnodet `mvnd` 0.8.2 works on all of my M1 machines (M1 Ultra and M1 Max) using Java 8 (Temurin JDK). A sincere thanks for your comments above. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614501#comment-17614501
]
Réda Housni Alaoui commented on MRESOLVER-277:
--
[~cstamas] I made a reproducer at =>
https://github.com/reda-alaoui/mresolver-277/
The issue is triggered by the following conditions:
- {{maven-enforcer-plugin}} with {{requireUpperBoundDeps}} rule enabled
- at least one custom snapshots repository declared
- no negative cache entry for the project modules in the local repository
The command to run would be like:
{code}
rm -fr .m2/repository/me/redaalaoui/mresolver_277 && mvn clean package
{code}
You will see these lines in the log:
{code}
[INFO] --< me.redaalaoui.mresolver_277:core >--
[INFO] Building core 1-SNAPSHOT [2/3]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ core ---
[INFO] Deleting /home/rhousni/projects/mresolver-277/core/target
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce) @ core ---
Downloading from spring-snapshot:
https://repo.spring.io/snapshot/me/redaalaoui/mresolver_277/core/1-SNAPSHOT/maven-metadata.xml
{code}
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614501#comment-17614501
]
Réda Housni Alaoui edited comment on MRESOLVER-277 at 10/8/22 3:32 PM:
---
[~cstamas] I made a reproducer at =>
https://github.com/reda-alaoui/mresolver-277/
The issue is triggered by the following conditions:
- {{maven-enforcer-plugin}} with {{requireUpperBoundDeps}} rule enabled
- at least one custom snapshots repository declared
- no negative cache entry for the project modules in the local repository
The command to run would be like:
{code}
rm -fr ~/.m2/repository/me/redaalaoui/mresolver_277 && mvn clean package
{code}
You will see these lines in the log:
{code}
[INFO] --< me.redaalaoui.mresolver_277:core >--
[INFO] Building core 1-SNAPSHOT [2/3]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ core ---
[INFO] Deleting /home/rhousni/projects/mresolver-277/core/target
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce) @ core ---
Downloading from spring-snapshot:
https://repo.spring.io/snapshot/me/redaalaoui/mresolver_277/core/1-SNAPSHOT/maven-metadata.xml
{code}
was (Author: ralaoui):
[~cstamas] I made a reproducer at =>
https://github.com/reda-alaoui/mresolver-277/
The issue is triggered by the following conditions:
- {{maven-enforcer-plugin}} with {{requireUpperBoundDeps}} rule enabled
- at least one custom snapshots repository declared
- no negative cache entry for the project modules in the local repository
The command to run would be like:
{code}
rm -fr .m2/repository/me/redaalaoui/mresolver_277 && mvn clean package
{code}
You will see these lines in the log:
{code}
[INFO] --< me.redaalaoui.mresolver_277:core >--
[INFO] Building core 1-SNAPSHOT [2/3]
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ core ---
[INFO] Deleting /home/rhousni/projects/mresolver-277/core/target
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce) @ core ---
Downloading from spring-snapshot:
https://repo.spring.io/snapshot/me/redaalaoui/mresolver_277/core/1-SNAPSHOT/maven-metadata.xml
{code}
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614504#comment-17614504
]
Réda Housni Alaoui commented on MRESOLVER-277:
--
{quote}
You mean the module you are building?
{quote}
Yes
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MCHECKSTYLE-342) Support XML 1.1
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reopened MCHECKSTYLE-342: -- Assignee: (was: Enrico Olivelli) > Support XML 1.1 > --- > > Key: MCHECKSTYLE-342 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-342 > Project: Maven Checkstyle Plugin > Issue Type: New Feature > Components: checkstyle:check >Affects Versions: 2.17 >Reporter: richard >Priority: Minor > > Checkstyle wishes to upgrade our XML logger to print out XML 1.1 documents. > We need this functionality to support escaping non-printable characters as > XML 1.0 doesn't allow this and considers it an invalid document. > > Exception in thread "main" javax.xml.stream.XMLStreamException: ParseError > > at [row,col]:[45615,80] > > Message: An invalid XML character (Unicode: 0x2) was found in the value of > > attribute "message" and element is "error". > Checkstyle cannot upgrade until maven-checkstyle does as we use it in alot of > regression testing. If we try to give the plugin an XML 1.1 document, it > fails with the following error: > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (default-cli) > > on project postgresql: Unable to read Checkstyle results xml: > > /pipeline/source/pgjdbc/pgjdbc/target/checkstyle-result.xml: only 1.0 is > > supported as > version="1.1"... @1:19) -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614516#comment-17614516
]
Tamas Cservenak commented on MRESOLVER-277:
---
To me this smells like enforcer rule bug... Thanks for reproducer! [~michael-o]
WDYT?
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-277) --no-snapshot-update option does not prevent metadata.xml download
[
https://issues.apache.org/jira/browse/MRESOLVER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614553#comment-17614553
]
Réda Housni Alaoui commented on MRESOLVER-277:
--
Enforcer invokes dependency which invokes resolver without any exotic
parameter. This is why I raised the issue in resolver.
> --no-snapshot-update option does not prevent metadata.xml download
> --
>
> Key: MRESOLVER-277
> URL: https://issues.apache.org/jira/browse/MRESOLVER-277
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a multi-module project.
> Each time I build the project using an empty local repository, maven-resolver
> tries to download the {{metadata.xml}} of each module even if I pass
> {{--no-snapshot-update}} option.
> I think it is a bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] 1013461195 commented on issue #693: can't use system environment variable?
1013461195 commented on issue #693:
URL: https://github.com/apache/maven-mvnd/issues/693#issuecomment-1272448622
thanks, but still can't read system env,
default read ${pwd}/bin/java?
--
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-7560) Provide a standard way to access the PGP signature for an artifact
Christoph Läubrich created MNG-7560: --- Summary: Provide a standard way to access the PGP signature for an artifact Key: MNG-7560 URL: https://issues.apache.org/jira/browse/MNG-7560 Project: Maven Issue Type: Improvement Reporter: Christoph Läubrich I recently needed to access the PGP signature of an artifact but found two problems: # It was surprisingly hard to get hold of it, I ended up in creating another artifact request for a special type so maven downloads it # I instantly was presented with a warning like described here: https://github.com/s4u/pgpverify-maven-plugin/issues/53 It would be good if maven would contain a method (e.g. in the ArtifactSystem or somwhere else) that allows to get the signature of an artifact, or some option when downloading an artifact that says what additional checksum (sha512 for example) or signatures (asc for example) should be made available alongside in the local repository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
