[jira] [Commented] (MNG-7413) Fix POM model documentation confusion on report plugins, distribution repository and profile build
[
https://issues.apache.org/jira/browse/MNG-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495376#comment-17495376
]
Herve Boutemy commented on MNG-7413:
this requires modello 2.0.0, that will require JDK 8 for building => post
poning to Maven 3.9
> Fix POM model documentation confusion on report plugins, distribution
> repository and profile build
> --
>
> Key: MNG-7413
> URL: https://issues.apache.org/jira/browse/MNG-7413
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General, POM
>Affects Versions: 3.8.4
>Reporter: Herve Boutemy
>Priority: Minor
> Fix For: 3.8.5
>
>
> after upgrading Modello to 2.0.0, it detected following conflicts in POM
> documentation:
> {noformat}
> [warn] model class repository/org.apache.maven.model.Repository with tagName
> repository gets duplicate anchorName class_repository, conflicting with model
> class repository/org.apache.maven.model.DeploymentRepository
> [warn] model class plugin/org.apache.maven.model.ReportPlugin with tagName
> plugin gets duplicate anchorName class_plugin, conflicting with model class
> plugin/org.apache.maven.model.Plugin
> [warn] model class build/org.apache.maven.model.BuildBase with tagName build
> gets duplicate anchorName class_build, conflicting with model class
> build/org.apache.maven.model.Build
> {noformat}
> it corresponds to:
> - "repository" link
> https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_repository is
> the same for project/repository, but also for
> distributionManagement/repository which does not have same fields
> - "plugin" link
> https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_plugin is the
> same from build plugin but also report plugin which does not have same fields
> - 'build" link
> https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_build is for
> build and profile/build
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7413) Fix POM model documentation confusion on report plugins, distribution repository and profile build
[
https://issues.apache.org/jira/browse/MNG-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-7413:
---
Fix Version/s: 3.9.0
(was: 3.8.5)
> Fix POM model documentation confusion on report plugins, distribution
> repository and profile build
> --
>
> Key: MNG-7413
> URL: https://issues.apache.org/jira/browse/MNG-7413
> Project: Maven
> Issue Type: Bug
> Components: Documentation: General, POM
>Affects Versions: 3.8.4
>Reporter: Herve Boutemy
>Priority: Minor
> Fix For: 3.9.0
>
>
> after upgrading Modello to 2.0.0, it detected following conflicts in POM
> documentation:
> {noformat}
> [warn] model class repository/org.apache.maven.model.Repository with tagName
> repository gets duplicate anchorName class_repository, conflicting with model
> class repository/org.apache.maven.model.DeploymentRepository
> [warn] model class plugin/org.apache.maven.model.ReportPlugin with tagName
> plugin gets duplicate anchorName class_plugin, conflicting with model class
> plugin/org.apache.maven.model.Plugin
> [warn] model class build/org.apache.maven.model.BuildBase with tagName build
> gets duplicate anchorName class_build, conflicting with model class
> build/org.apache.maven.model.Build
> {noformat}
> it corresponds to:
> - "repository" link
> https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_repository is
> the same for project/repository, but also for
> distributionManagement/repository which does not have same fields
> - "plugin" link
> https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_plugin is the
> same from build plugin but also report plugin which does not have same fields
> - 'build" link
> https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_build is for
> build and profile/build
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7244) Remove deprecated WARNING for usage of pom.X placeholders
[
https://issues.apache.org/jira/browse/MNG-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495378#comment-17495378
]
Hudson commented on MNG-7244:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » master #329
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/329/
> Remove deprecated WARNING for usage of pom.X placeholders
> -
>
> Key: MNG-7244
> URL: https://issues.apache.org/jira/browse/MNG-7244
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-1
>Reporter: Karl Heinz Marbaise
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Currently, we produce a {{WARNING}} in case of using {{pom.version}} or alike.
> We've been doing that for years so people have had enough time to update
> their projects. We can now remove the support and the accompanying warning,
> resorting to the default behaviour of not resolving the expression at all.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${pom.version} is deprecated. Please use
> ${project.version} instead.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7395) Support interpolation in extensions.xml
[
https://issues.apache.org/jira/browse/MNG-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495377#comment-17495377
]
Hudson commented on MNG-7395:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » master #329
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/329/
> Support interpolation in extensions.xml
> ---
>
> Key: MNG-7395
> URL: https://issues.apache.org/jira/browse/MNG-7395
> Project: Maven
> Issue Type: New Feature
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
>
> Currently an entry has to be the following form:
> {code:xml}
>
> org.eclipse.tycho
> tycho-build
> 2.7.0-SNAPSHOT
>
> {code}
> This has the drawback that I always need to edit the extension.xml file and
> there is no way to specify it on the commandline.
> The proposal is to allow the follwoing:
> {code:xml}
>
> org.eclipse.tycho
> tycho-build
> ${tycho-version|2.6.0}
>
> {code}
> I would then expect the following:
> # If no systemproperty with name 'tycho-version' exits, the value after the |
> is used as a default
> # If a systemproperty with name 'tycho-version' exits it is used as a version
> That way I can call mvn -Dtycho-version=2.7.0-SNAPSHOT clean install to
> override the default version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7390) Allow selecting modules outside the cwd into the reactor using --projects
[
https://issues.apache.org/jira/browse/MNG-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495379#comment-17495379
]
Hudson commented on MNG-7390:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » master #329
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/329/
> Allow selecting modules outside the cwd into the reactor using --projects
> -
>
> Key: MNG-7390
> URL: https://issues.apache.org/jira/browse/MNG-7390
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> MNG-6118 enables users to build other projects of a multi-module project even
> when those projects are not located in the current directory or below.
> Imagine a multi module project as follows:
> * root
> ** library
> ** app (dependent on library)
> When navigating to app, a user can execute {{mvn -am}} and it will
> build library and root next to app. This is nice because no matter where you
> are in the directory structure of the multi module project, the full multi
> module project context is known and can be used.
> The next logical step would be to be able to select submodules from anywhere
> in the directories using the {{--projects}} flag.
> Using the project structure of above, I should be able to navigate into
> {{app}} and compile another (sub)module (or multiple modules) by specifying
> the project:
> {code:bash}
> cd app
> mvn compile -pl :library
> # or by directory
> mvn compile -pl ../library
> # or to build multiple
> mvn compile -pl :app,:library
> {code}
> I have started working on this and should be able to provide PRs later today.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7395) Support interpolation in extensions.xml
[
https://issues.apache.org/jira/browse/MNG-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495385#comment-17495385
]
Hudson commented on MNG-7395:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #113
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/113/
> Support interpolation in extensions.xml
> ---
>
> Key: MNG-7395
> URL: https://issues.apache.org/jira/browse/MNG-7395
> Project: Maven
> Issue Type: New Feature
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
>
> Currently an entry has to be the following form:
> {code:xml}
>
> org.eclipse.tycho
> tycho-build
> 2.7.0-SNAPSHOT
>
> {code}
> This has the drawback that I always need to edit the extension.xml file and
> there is no way to specify it on the commandline.
> The proposal is to allow the follwoing:
> {code:xml}
>
> org.eclipse.tycho
> tycho-build
> ${tycho-version|2.6.0}
>
> {code}
> I would then expect the following:
> # If no systemproperty with name 'tycho-version' exits, the value after the |
> is used as a default
> # If a systemproperty with name 'tycho-version' exits it is used as a version
> That way I can call mvn -Dtycho-version=2.7.0-SNAPSHOT clean install to
> override the default version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7244) Remove deprecated WARNING for usage of pom.X placeholders
[
https://issues.apache.org/jira/browse/MNG-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495386#comment-17495386
]
Hudson commented on MNG-7244:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #113
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/113/
> Remove deprecated WARNING for usage of pom.X placeholders
> -
>
> Key: MNG-7244
> URL: https://issues.apache.org/jira/browse/MNG-7244
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-1
>Reporter: Karl Heinz Marbaise
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> Currently, we produce a {{WARNING}} in case of using {{pom.version}} or alike.
> We've been doing that for years so people have had enough time to update
> their projects. We can now remove the support and the accompanying warning,
> resorting to the default behaviour of not resolving the expression at all.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${pom.version} is deprecated. Please use
> ${project.version} instead.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7390) Allow selecting modules outside the cwd into the reactor using --projects
[
https://issues.apache.org/jira/browse/MNG-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495387#comment-17495387
]
Hudson commented on MNG-7390:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #113
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/113/
> Allow selecting modules outside the cwd into the reactor using --projects
> -
>
> Key: MNG-7390
> URL: https://issues.apache.org/jira/browse/MNG-7390
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> MNG-6118 enables users to build other projects of a multi-module project even
> when those projects are not located in the current directory or below.
> Imagine a multi module project as follows:
> * root
> ** library
> ** app (dependent on library)
> When navigating to app, a user can execute {{mvn -am}} and it will
> build library and root next to app. This is nice because no matter where you
> are in the directory structure of the multi module project, the full multi
> module project context is known and can be used.
> The next logical step would be to be able to select submodules from anywhere
> in the directories using the {{--projects}} flag.
> Using the project structure of above, I should be able to navigate into
> {{app}} and compile another (sub)module (or multiple modules) by specifying
> the project:
> {code:bash}
> cd app
> mvn compile -pl :library
> # or by directory
> mvn compile -pl ../library
> # or to build multiple
> mvn compile -pl :app,:library
> {code}
> I have started working on this and should be able to provide PRs later today.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MRESOLVER-240) Using breadth-first approach to resolve maven dependencies
wei cai created MRESOLVER-240: - Summary: Using breadth-first approach to resolve maven dependencies Key: MRESOLVER-240 URL: https://issues.apache.org/jira/browse/MRESOLVER-240 Project: Maven Resolver Issue Type: Improvement Components: Resolver Affects Versions: 1.7.3 Reporter: wei cai There was discussions about the DFS or BFS algorithm for maven resolver in MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much easier to implement. Here is the plan for multiple changes requested recently: * DFS > BFS - preparation for parallel download * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) * Download descriptors in parallel (MRESOLVER-7) This Jira would focus on DFS -> BFS. Basically maven would: * Go through all nodes and their dependencies starting from the root node to form a dependency graph. * Resolve the version conflicts by a nearest first approach (close to BFS) and determine the effective dependencies. Changing DFS to BFS is just a sequence change (depth first -> width first), all nodes and their dependencies are still traversed, thus it won't change the dependency resolve result. When changing to BFS, we cannot break below rules: * Exclusions and dependency management can be inherited from parent node. [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by @ibabiankou) is fired. The basic idea of this PR is: * Use queue instead of stack as required by BFS algorithm. * Track the objects such as DependencySelector, DependencyManager in DependencyProcessingContext and put into the queue, so inheritance of Exclusions and dependency management won't break. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2019) ThreadedStreamConsumer - use Thread.join() instead of CountDownLatch.await()
Tibor Digana created SUREFIRE-2019:
--
Summary: ThreadedStreamConsumer - use Thread.join() instead of
CountDownLatch.await()
Key: SUREFIRE-2019
URL: https://issues.apache.org/jira/browse/SUREFIRE-2019
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
forking
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 3.0.0-M6
Currently, {{ThreadedStreamConsumer}} uses {{CountDownLatch.await()}} which is
not 100% reliable. The thread may die if it is in the waiting state during
shutdown period. Let's use {{Thread.join()}} in the {{close()}}.
Attention: do NOT use {{Thread.join()}} in the method {{handleEvent()}} - too
slow, and therefore we use {{AtomicBoolean}} as a treatment.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2019) ThreadedStreamConsumer - use Thread.join() instead of CountDownLatch.await()
[
https://issues.apache.org/jira/browse/SUREFIRE-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2019:
---
Fix Version/s: 2.22.3
> ThreadedStreamConsumer - use Thread.join() instead of CountDownLatch.await()
>
>
> Key: SUREFIRE-2019
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2019
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> Currently, {{ThreadedStreamConsumer}} uses {{CountDownLatch.await()}} which
> is not 100% reliable. The thread may die if it is in the waiting state during
> shutdown period. Let's use {{Thread.join()}} in the {{close()}}.
> Attention: do NOT use {{Thread.join()}} in the method {{handleEvent()}} - too
> slow, and therefore we use {{AtomicBoolean}} as a treatment.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOLVER-240) Using breadth-first approach to resolve maven dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495391#comment-17495391 ] wei cai commented on MRESOLVER-240: --- [https://github.com/apache/maven-resolver/pull/144] is for this JIRA. > Using breadth-first approach to resolve maven dependencies > -- > > Key: MRESOLVER-240 > URL: https://issues.apache.org/jira/browse/MRESOLVER-240 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.7.3 >Reporter: wei cai >Priority: Major > > There was discussions about the DFS or BFS algorithm for maven resolver in > MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much > easier to implement. Here is the plan for multiple changes requested recently: > * DFS > BFS - preparation for parallel download > * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) > * Download descriptors in parallel (MRESOLVER-7) > This Jira would focus on DFS -> BFS. > Basically maven would: > * Go through all nodes and their dependencies starting from the root node to > form a dependency graph. > * Resolve the version conflicts by a nearest first approach (close to BFS) > and determine the effective dependencies. > Changing DFS to BFS is just a sequence change (depth first -> width first), > all nodes and their dependencies are still traversed, thus it won't change > the dependency resolve result. > When changing to BFS, we cannot break below rules: > * Exclusions and dependency management can be inherited from parent node. > [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by > @ibabiankou) is fired. The basic idea of this PR is: > * Use queue instead of stack as required by BFS algorithm. > * Track the objects such as DependencySelector, DependencyManager in > DependencyProcessingContext and put into the queue, so inheritance of > Exclusions and dependency management won't break. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2019) ThreadedStreamConsumer - use Thread.join() instead of CountDownLatch.await()
[
https://issues.apache.org/jira/browse/SUREFIRE-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2019.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=892b9db9d7ed8f472bd6d88f24b70441744e828e
> ThreadedStreamConsumer - use Thread.join() instead of CountDownLatch.await()
>
>
> Key: SUREFIRE-2019
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2019
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> Currently, {{ThreadedStreamConsumer}} uses {{CountDownLatch.await()}} which
> is not 100% reliable. The thread may die if it is in the waiting state during
> shutdown period. Let's use {{Thread.join()}} in the {{close()}}.
> Attention: do NOT use {{Thread.join()}} in the method {{handleEvent()}} - too
> slow, and therefore we use {{AtomicBoolean}} as a treatment.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-project-info-reports-plugin] michael-o commented on pull request #32: [MPIR-413] Fix building project for plugins from plugin management
michael-o commented on pull request #32: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/32#issuecomment-1046610571 Will happily review -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2019) ThreadedStreamConsumer - use Thread.join() instead of CountDownLatch.await()
[
https://issues.apache.org/jira/browse/SUREFIRE-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495395#comment-17495395
]
Tibor Digana commented on SUREFIRE-2019:
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=e7fe0ddda6211babe39f565da739db3a86c89264
> ThreadedStreamConsumer - use Thread.join() instead of CountDownLatch.await()
>
>
> Key: SUREFIRE-2019
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2019
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> Currently, {{ThreadedStreamConsumer}} uses {{CountDownLatch.await()}} which
> is not 100% reliable. The thread may die if it is in the waiting state during
> shutdown period. Let's use {{Thread.join()}} in the {{close()}}.
> Attention: do NOT use {{Thread.join()}} in the method {{handleEvent()}} - too
> slow, and therefore we use {{AtomicBoolean}} as a treatment.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SUREFIRE-2020) Use addShutDownHook() from maven-shared-utils
Tibor Digana created SUREFIRE-2020: -- Summary: Use addShutDownHook() from maven-shared-utils Key: SUREFIRE-2020 URL: https://issues.apache.org/jira/browse/SUREFIRE-2020 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin, Maven Surefire Plugin, process forking Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 3.0.0-M6 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRESOLVER-240) Using breadth-first approach to resolve maven dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wei cai updated MRESOLVER-240: -- Description: There was discussions about the DFS or BFS algorithm for maven resolver in MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much easier to implement. Here is the plan for multiple changes requested recently: * DFS > BFS - preparation for parallel download * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) * Download descriptors in parallel (MRESOLVER-7) This Jira would focus on DFS -> BFS. Basically maven would: * Go through all nodes and their dependencies starting from the root node to form a dependency graph. * Resolve the version conflicts by a nearest first approach (close to BFS) based on above graph and determine the effective dependencies. Changing DFS to BFS is just a sequence change (depth first -> width first), all nodes and their dependencies are still traversed to build the graph, thus it won't affect the dependency resolve result. When changing to BFS, we cannot break below rules: * Exclusions and dependency management can be inherited from parent nodes. [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by @ibabiankou) is fired. The basic idea of this PR is: * Use queue instead of stack as required by BFS algorithm. * Track the objects such as DependencySelector, DependencyManager in DependencyProcessingContext and put into the queue, this means inheritance of Exclusions and dependency management won't break. was: There was discussions about the DFS or BFS algorithm for maven resolver in MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much easier to implement. Here is the plan for multiple changes requested recently: * DFS > BFS - preparation for parallel download * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) * Download descriptors in parallel (MRESOLVER-7) This Jira would focus on DFS -> BFS. Basically maven would: * Go through all nodes and their dependencies starting from the root node to form a dependency graph. * Resolve the version conflicts by a nearest first approach (close to BFS) and determine the effective dependencies. Changing DFS to BFS is just a sequence change (depth first -> width first), all nodes and their dependencies are still traversed, thus it won't change the dependency resolve result. When changing to BFS, we cannot break below rules: * Exclusions and dependency management can be inherited from parent node. [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by @ibabiankou) is fired. The basic idea of this PR is: * Use queue instead of stack as required by BFS algorithm. * Track the objects such as DependencySelector, DependencyManager in DependencyProcessingContext and put into the queue, so inheritance of Exclusions and dependency management won't break. > Using breadth-first approach to resolve maven dependencies > -- > > Key: MRESOLVER-240 > URL: https://issues.apache.org/jira/browse/MRESOLVER-240 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.7.3 >Reporter: wei cai >Priority: Major > > There was discussions about the DFS or BFS algorithm for maven resolver in > MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much > easier to implement. Here is the plan for multiple changes requested recently: > * DFS > BFS - preparation for parallel download > * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) > * Download descriptors in parallel (MRESOLVER-7) > This Jira would focus on DFS -> BFS. > Basically maven would: > * Go through all nodes and their dependencies starting from the root node to > form a dependency graph. > * Resolve the version conflicts by a nearest first approach (close to BFS) > based on above graph and determine the effective dependencies. > Changing DFS to BFS is just a sequence change (depth first -> width first), > all nodes and their dependencies are still traversed to build the graph, thus > it won't affect > the dependency resolve result. > When changing to BFS, we cannot break below rules: > * Exclusions and dependency management can be inherited from parent nodes. > [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by > @ibabiankou) is fired. > The basic idea of this PR is: > * Use queue instead of stack as required by BFS algorithm. > * Track the objects such as DependencySelector, DependencyManager in > DependencyProcessingContext and put into the queue, this means inheritance of > Exclusions and dependency management won't break. -- This message was sent by Atlassian Jira (v8.20.1#82
[GitHub] [maven-resolver] caiwei-ebay commented on pull request #144: Use BFS approach
caiwei-ebay commented on pull request #144: URL: https://github.com/apache/maven-resolver/pull/144#issuecomment-1046618472 @michael-o MRESOLVER-240 is fired for this PR. Please check. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (SUREFIRE-2020) Use addShutDownHook() from maven-shared-utils
[ https://issues.apache.org/jira/browse/SUREFIRE-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-2020. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9621bb6ef96c627a4f7654bf20304aa59226210e > Use addShutDownHook() from maven-shared-utils > - > > Key: SUREFIRE-2020 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2020 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-plugin-tools] gnodet merged pull request #68: [MPLUGIN-391] Deprecate scripting support for mojos
gnodet merged pull request #68: URL: https://github.com/apache/maven-plugin-tools/pull/68 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MPLUGIN-391) Deprecate scripting support for mojos
[ https://issues.apache.org/jira/browse/MPLUGIN-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MPLUGIN-391. --- Fix Version/s: 3.7.0 Resolution: Fixed > Deprecate scripting support for mojos > - > > Key: MPLUGIN-391 > URL: https://issues.apache.org/jira/browse/MPLUGIN-391 > Project: Maven Plugin Tools > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPLUGIN-391) Deprecate scripting support for mojos
[ https://issues.apache.org/jira/browse/MPLUGIN-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MPLUGIN-391: --- Assignee: Guillaume Nodet > Deprecate scripting support for mojos > - > > Key: MPLUGIN-391 > URL: https://issues.apache.org/jira/browse/MPLUGIN-391 > Project: Maven Plugin Tools > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPLUGIN-391) Deprecate scripting support for mojos
[ https://issues.apache.org/jira/browse/MPLUGIN-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495403#comment-17495403 ] ASF GitHub Bot commented on MPLUGIN-391: gnodet merged pull request #68: URL: https://github.com/apache/maven-plugin-tools/pull/68 -- 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 > Deprecate scripting support for mojos > - > > Key: MPLUGIN-391 > URL: https://issues.apache.org/jira/browse/MPLUGIN-391 > Project: Maven Plugin Tools > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2021) Commands should be flushed immediately. Use Channels.newChannel() instead of newBufferedChannel(). Delete the old flushing mechanism on forked processes.
Tibor Digana created SUREFIRE-2021: -- Summary: Commands should be flushed immediately. Use Channels.newChannel() instead of newBufferedChannel(). Delete the old flushing mechanism on forked processes. Key: SUREFIRE-2021 URL: https://issues.apache.org/jira/browse/SUREFIRE-2021 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin, Maven Surefire Plugin, process forking Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 3.0.0-M6 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MPOM-292) upgrade parent to ASF 25
Herve Boutemy created MPOM-292: -- Summary: upgrade parent to ASF 25 Key: MPOM-292 URL: https://issues.apache.org/jira/browse/MPOM-292 Project: Maven POMs Issue Type: Dependency upgrade Components: maven Affects Versions: MAVEN-34 Reporter: Herve Boutemy Fix For: MAVEN-35 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MPOM-292) upgrade parent to ASF 25
[ https://issues.apache.org/jira/browse/MPOM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPOM-292. -- Assignee: Herve Boutemy Resolution: Fixed done in https://github.com/apache/maven-parent/commit/88aac092d5bf91466ed4c74a8098e91402484c50 > upgrade parent to ASF 25 > > > Key: MPOM-292 > URL: https://issues.apache.org/jira/browse/MPOM-292 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Affects Versions: MAVEN-34 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-35 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MPOM-281) Update maven-plugin-plugin to 3.6.4
[ https://issues.apache.org/jira/browse/MPOM-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPOM-281. -- Assignee: Herve Boutemy Resolution: Fixed fixed by MPOM-292 upgrade of parent POM > Update maven-plugin-plugin to 3.6.4 > --- > > Key: MPOM-281 > URL: https://issues.apache.org/jira/browse/MPOM-281 > Project: Maven POMs > Issue Type: Task > Components: maven >Reporter: Tamás Cservenák >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-35 > > > h1. Release Notes - Maven Plugin Tools - Version 3.6.4 > h2. Bug > * [MPLUGIN-382] - Too many dependencies in plugin descriptor > * [MPLUGIN-383] - Missing prerequisites in plugin pom > * [MPLUGIN-384] - Nexus Staging Plugin - incompatibility > h2. Task > * [MPLUGIN-386] - Filter out maven-archiver and maven-jxr from scope > warning > h2. Dependency upgrade > * [MPLUGIN-387] - Upgrade dependencies -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPLUGIN-391) Deprecate scripting support for mojos
[ https://issues.apache.org/jira/browse/MPLUGIN-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495423#comment-17495423 ] Hudson commented on MPLUGIN-391: Build succeeded in Jenkins: Maven » The Apache Software Foundation » maven-plugin-tools » master #3 See https://ci-maven.apache.org/job/Maven/job/maven-github/job/maven-plugin-tools/job/master/3/ > Deprecate scripting support for mojos > - > > Key: MPLUGIN-391 > URL: https://issues.apache.org/jira/browse/MPLUGIN-391 > Project: Maven Plugin Tools > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-parent] dependabot[bot] commented on pull request #46: Bump mavenPluginToolsVersion from 3.6.2 to 3.6.4
dependabot[bot] commented on pull request #46: URL: https://github.com/apache/maven-parent/pull/46#issuecomment-1046667624 Looks like these dependencies are up-to-date now, so this is no longer needed. -- 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-parent] dependabot[bot] closed pull request #46: Bump mavenPluginToolsVersion from 3.6.2 to 3.6.4
dependabot[bot] closed pull request #46: URL: https://github.com/apache/maven-parent/pull/46 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-plugin-tools] gnodet commented on a change in pull request #67: [MPLUGIN-390] Do not overwrite generate files with no content change
gnodet commented on a change in pull request #67: URL: https://github.com/apache/maven-plugin-tools/pull/67#discussion_r810945203 ## File path: maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/CachingOutputStream.java ## @@ -0,0 +1,63 @@ +package org.apache.maven.tools.plugin.generator; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.ByteArrayOutputStream; +import java.io.File; +import java.io.IOException; +import java.nio.file.Files; +import java.nio.file.Path; +import java.util.Arrays; +import java.util.Objects; + +/** + * Caching OutputStream to avoid overwriting a file with + * the same content. + */ +public class CachingOutputStream extends ByteArrayOutputStream Review comment: I've introduced a similar one, but in modello (https://github.com/codehaus-plexus/modello/pull/116) and in plexus-containers (https://github.com/codehaus-plexus/plexus-containers/pull/46). So only location would be in `plexus-utils` I suppose. But the two classes in modello and plexus-containers are `Writer`s and this is the only `OutputStream`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-390) Do not overwrite generate files with no content change
[ https://issues.apache.org/jira/browse/MPLUGIN-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495431#comment-17495431 ] ASF GitHub Bot commented on MPLUGIN-390: gnodet commented on a change in pull request #67: URL: https://github.com/apache/maven-plugin-tools/pull/67#discussion_r810945203 ## File path: maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/CachingOutputStream.java ## @@ -0,0 +1,63 @@ +package org.apache.maven.tools.plugin.generator; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.ByteArrayOutputStream; +import java.io.File; +import java.io.IOException; +import java.nio.file.Files; +import java.nio.file.Path; +import java.util.Arrays; +import java.util.Objects; + +/** + * Caching OutputStream to avoid overwriting a file with + * the same content. + */ +public class CachingOutputStream extends ByteArrayOutputStream Review comment: I've introduced a similar one, but in modello (https://github.com/codehaus-plexus/modello/pull/116) and in plexus-containers (https://github.com/codehaus-plexus/plexus-containers/pull/46). So only location would be in `plexus-utils` I suppose. But the two classes in modello and plexus-containers are `Writer`s and this is the only `OutputStream`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Do not overwrite generate files with no content change > -- > > Key: MPLUGIN-390 > URL: https://issues.apache.org/jira/browse/MPLUGIN-390 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Major > > This breaks incremental compilation as the jars will be regenerated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPOM-292) upgrade parent to ASF 25
[ https://issues.apache.org/jira/browse/MPOM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495434#comment-17495434 ] Hudson commented on MPOM-292: - Build succeeded in Jenkins: Maven » The Apache Software Foundation » maven-parent » master #6 See https://ci-maven.apache.org/job/Maven/job/maven-github/job/maven-parent/job/master/6/ > upgrade parent to ASF 25 > > > Key: MPOM-292 > URL: https://issues.apache.org/jira/browse/MPOM-292 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Affects Versions: MAVEN-34 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-35 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPOM-292) upgrade parent to ASF 25
[ https://issues.apache.org/jira/browse/MPOM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495433#comment-17495433 ] Hudson commented on MPOM-292: - Build failed in Jenkins: Maven » The Apache Software Foundation » maven-parent » master #5 See https://ci-maven.apache.org/job/Maven/job/maven-github/job/maven-parent/job/master/5/ > upgrade parent to ASF 25 > > > Key: MPOM-292 > URL: https://issues.apache.org/jira/browse/MPOM-292 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Affects Versions: MAVEN-34 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-35 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] michael-o commented on pull request #144: Use BFS approach
michael-o commented on pull request #144: URL: https://github.com/apache/maven-resolver/pull/144#issuecomment-1046690518 Thank you, assigned. Will pick up next week. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MRESOLVER-240) Using breadth-first approach to resolve maven dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MRESOLVER-240: Assignee: Michael Osipov > Using breadth-first approach to resolve maven dependencies > -- > > Key: MRESOLVER-240 > URL: https://issues.apache.org/jira/browse/MRESOLVER-240 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.7.3 >Reporter: wei cai >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.0 > > > There was discussions about the DFS or BFS algorithm for maven resolver in > MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much > easier to implement. Here is the plan for multiple changes requested recently: > * DFS > BFS - preparation for parallel download > * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) > * Download descriptors in parallel (MRESOLVER-7) > This Jira would focus on DFS -> BFS. > Basically maven would: > * Go through all nodes and their dependencies starting from the root node to > form a dependency graph. > * Resolve the version conflicts by a nearest first approach (close to BFS) > based on above graph and determine the effective dependencies. > Changing DFS to BFS is just a sequence change (depth first -> width first), > all nodes and their dependencies are still traversed to build the graph, thus > it won't affect > the dependency resolve result. > When changing to BFS, we cannot break below rules: > * Exclusions and dependency management can be inherited from parent nodes. > [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by > @ibabiankou) is fired. > The basic idea of this PR is: > * Use queue instead of stack as required by BFS algorithm. > * Track the objects such as DependencySelector, DependencyManager in > DependencyProcessingContext and put into the queue, this means inheritance of > Exclusions and dependency management won't break. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRESOLVER-240) Using breadth-first approach to resolve maven dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-240: - Fix Version/s: 1.8.0 > Using breadth-first approach to resolve maven dependencies > -- > > Key: MRESOLVER-240 > URL: https://issues.apache.org/jira/browse/MRESOLVER-240 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.7.3 >Reporter: wei cai >Priority: Major > Fix For: 1.8.0 > > > There was discussions about the DFS or BFS algorithm for maven resolver in > MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much > easier to implement. Here is the plan for multiple changes requested recently: > * DFS > BFS - preparation for parallel download > * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) > * Download descriptors in parallel (MRESOLVER-7) > This Jira would focus on DFS -> BFS. > Basically maven would: > * Go through all nodes and their dependencies starting from the root node to > form a dependency graph. > * Resolve the version conflicts by a nearest first approach (close to BFS) > based on above graph and determine the effective dependencies. > Changing DFS to BFS is just a sequence change (depth first -> width first), > all nodes and their dependencies are still traversed to build the graph, thus > it won't affect > the dependency resolve result. > When changing to BFS, we cannot break below rules: > * Exclusions and dependency management can be inherited from parent nodes. > [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by > @ibabiankou) is fired. > The basic idea of this PR is: > * Use queue instead of stack as required by BFS algorithm. > * Track the objects such as DependencySelector, DependencyManager in > DependencyProcessingContext and put into the queue, this means inheritance of > Exclusions and dependency management won't break. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRESOLVER-240) Using breadth-first approach to resolve maven dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wei cai updated MRESOLVER-240: -- Description: There was discussions about the DFS or BFS algorithm for maven resolver in MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much easier to implement. Here is the plan for multiple changes requested recently: * DFS > BFS - preparation for parallel download * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) * Download descriptors in parallel (MRESOLVER-7) This Jira would focus on DFS -> BFS. Basically maven would: * Go through all nodes and their dependencies starting from the root node to form a dependency graph. * Resolve the version conflicts by a nearest first approach (close to BFS) based on above graph and determine the effective dependencies. Changing DFS to BFS is just a sequence change (depth first -> width first), all nodes and their dependencies are still traversed to build the graph, thus it won't affect the dependency resolve result. [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by @ibabiankou) is fired. The basic idea of this PR is: * Use queue instead of stack as required by BFS algorithm. * When comes to a node, iterate its children, create DependencyProcessingContext for each child and put into the queue. The DependencyProcessingContext stores the objects such as current child node, DependencySelector, DependencyManager and so on. Here classes such as DependencySelector, DependencyManager is for exclusions and dependency management that inherited from parent nodes. * Process the DependencyProcessingContext queue. was: There was discussions about the DFS or BFS algorithm for maven resolver in MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much easier to implement. Here is the plan for multiple changes requested recently: * DFS > BFS - preparation for parallel download * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) * Download descriptors in parallel (MRESOLVER-7) This Jira would focus on DFS -> BFS. Basically maven would: * Go through all nodes and their dependencies starting from the root node to form a dependency graph. * Resolve the version conflicts by a nearest first approach (close to BFS) based on above graph and determine the effective dependencies. Changing DFS to BFS is just a sequence change (depth first -> width first), all nodes and their dependencies are still traversed to build the graph, thus it won't affect the dependency resolve result. When changing to BFS, we cannot break below rules: * Exclusions and dependency management can be inherited from parent nodes. [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by @ibabiankou) is fired. The basic idea of this PR is: * Use queue instead of stack as required by BFS algorithm. * Track the objects such as DependencySelector, DependencyManager in DependencyProcessingContext and put into the queue, this means inheritance of Exclusions and dependency management won't break. > Using breadth-first approach to resolve maven dependencies > -- > > Key: MRESOLVER-240 > URL: https://issues.apache.org/jira/browse/MRESOLVER-240 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.7.3 >Reporter: wei cai >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.0 > > > There was discussions about the DFS or BFS algorithm for maven resolver in > MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much > easier to implement. Here is the plan for multiple changes requested recently: > * DFS > BFS - preparation for parallel download > * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) > * Download descriptors in parallel (MRESOLVER-7) > This Jira would focus on DFS -> BFS. > Basically maven would: > * Go through all nodes and their dependencies starting from the root node to > form a dependency graph. > * Resolve the version conflicts by a nearest first approach (close to BFS) > based on above graph and determine the effective dependencies. > Changing DFS to BFS is just a sequence change (depth first -> width first), > all nodes and their dependencies are still traversed to build the graph, thus > it won't affect > the dependency resolve result. > [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by > @ibabiankou) is fired. The basic idea of this PR is: > * Use queue instead of stack as required by BFS algorithm. > * When comes to a node, iterate its children, create > DependencyProcessingContext for each child and put into the queue. > The DependencyProcessingContext stores t
[jira] [Updated] (MRESOLVER-240) Using breadth-first approach to resolve maven dependencies
[ https://issues.apache.org/jira/browse/MRESOLVER-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wei cai updated MRESOLVER-240: -- Description: There was discussions about the DFS or BFS algorithm for maven resolver in MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much easier to implement. Here is the plan for multiple changes requested recently: * DFS > BFS - preparation for parallel download * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) * Download descriptors in parallel (MRESOLVER-7) This Jira would focus on DFS -> BFS. Basically maven would: * Go through all nodes and their dependencies starting from the root node to form a dependency graph. * Resolve the version conflicts by a nearest first approach (close to BFS) based on above graph and determine the effective dependencies. Changing DFS to BFS is just a sequence change (depth first -> width first), all nodes and their dependencies are still traversed to build the graph, thus it won't affect the dependency resolve result. [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by @ibabiankou) is fired. The basic idea of this PR is: * Use queue instead of stack as required by BFS algorithm. * When comes to a node, iterate its children, create DependencyProcessingContext for each child and put into the queue. The DependencyProcessingContext stores the objects such as current child node, DependencySelector, DependencyManager and so on. Here classes such as DependencySelector, DependencyManager is for exclusions and dependency management that inherited from parent nodes. * Process the next node from queue. was: There was discussions about the DFS or BFS algorithm for maven resolver in MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much easier to implement. Here is the plan for multiple changes requested recently: * DFS > BFS - preparation for parallel download * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) * Download descriptors in parallel (MRESOLVER-7) This Jira would focus on DFS -> BFS. Basically maven would: * Go through all nodes and their dependencies starting from the root node to form a dependency graph. * Resolve the version conflicts by a nearest first approach (close to BFS) based on above graph and determine the effective dependencies. Changing DFS to BFS is just a sequence change (depth first -> width first), all nodes and their dependencies are still traversed to build the graph, thus it won't affect the dependency resolve result. [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by @ibabiankou) is fired. The basic idea of this PR is: * Use queue instead of stack as required by BFS algorithm. * When comes to a node, iterate its children, create DependencyProcessingContext for each child and put into the queue. The DependencyProcessingContext stores the objects such as current child node, DependencySelector, DependencyManager and so on. Here classes such as DependencySelector, DependencyManager is for exclusions and dependency management that inherited from parent nodes. * Process the DependencyProcessingContext queue. > Using breadth-first approach to resolve maven dependencies > -- > > Key: MRESOLVER-240 > URL: https://issues.apache.org/jira/browse/MRESOLVER-240 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.7.3 >Reporter: wei cai >Assignee: Michael Osipov >Priority: Major > Fix For: 1.8.0 > > > There was discussions about the DFS or BFS algorithm for maven resolver in > MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much > easier to implement. Here is the plan for multiple changes requested recently: > * DFS > BFS - preparation for parallel download > * Skip & Reconcile - avoid unnecessary version resolution (MRESOLVER-228) > * Download descriptors in parallel (MRESOLVER-7) > This Jira would focus on DFS -> BFS. > Basically maven would: > * Go through all nodes and their dependencies starting from the root node to > form a dependency graph. > * Resolve the version conflicts by a nearest first approach (close to BFS) > based on above graph and determine the effective dependencies. > Changing DFS to BFS is just a sequence change (depth first -> width first), > all nodes and their dependencies are still traversed to build the graph, thus > it won't affect > the dependency resolve result. > [PR|https://github.com/apache/maven-resolver/pull/144] (co-authored by > @ibabiankou) is fired. The basic idea of this PR is: > * Use queue instead of stack as required by BFS algorithm. > * When comes to a node, iterate its children, create > DependencyPr
[jira] [Commented] (MRESOLVER-236) Make it possible to resolve .asc on a 'fail' respository.
[
https://issues.apache.org/jira/browse/MRESOLVER-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495480#comment-17495480
]
Rod Widdowson commented on MRESOLVER-236:
-
[~cstamas] I'm not completely sure that I understand what you are asking but
let me try
Our plugin (the thing which tries to resolve asc files) isn't up on central.
Source is
[here|https://git.shibboleth.net/view/?p=java-mvn-enforcer.git;a=summary] and
the latest version is up on our [snapshot repository
|https://build.shibboleth.net/maven/snapshots/net/shibboleth/maven/enforcer/rules/maven-dist-enforcer/]
I just provoked the failure when looking at central (suitably configured to
enforce checksums) when looking for
[spring-jdbc.jar|https://repo1.maven.org/maven2/org/springframework/spring-jdbc/5.3.14/]
which does *not* have a checksum.
setting {{-D aether.checksums.forSignature=true} makes no difference {code}
[DEBUG] Resolving artifact org.springframework:spring-jdbc:jar.asc:5.3.14 from
[shib-releases (https://build.shibboleth.net/maven/releases/, default,
releases), shib-snapshots (https://build.shibboleth.net/maven/snapshots/,
default, snapshots), shib-thirdparty
(https://build.shibboleth.net/maven/thirdparty/, default, releases),
shib-thirdparty-snapshots
(https://build.shibboleth.net/maven/thirdparty-snapshots/, default, snapshots),
shib-release (https://build.shibboleth.net/nexus/content/groups/public,
default, releases), shib-snapshot
(https://build.shibboleth.net/nexus/content/repositories/snapshots, default,
snapshots), shib-thirdparty-snapshot
(https://build.shibboleth.net/nexus/content/repositories/thirdparty-snapshots,
default, snapshots), central (https://repo1.maven.org/maven2, default,
releases)]
[DEBUG] Skipped remote request for
org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this
session
[DEBUG] Skipped remote request for
org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this
session
[DEBUG] Skipped remote request for
org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this
session
[DEBUG] Skipped remote request for
org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this
session
{code}
Note also that another project [has programmed around
it|https://github.com/s4u/pgpverify-maven-plugin/issues/53] but I'd sooner
avoid that kludge.
> Make it possible to resolve .asc on a 'fail' respository.
> ---
>
> Key: MRESOLVER-236
> URL: https://issues.apache.org/jira/browse/MRESOLVER-236
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Affects Versions: 1.7.3
>Reporter: Rod Widdowson
>Priority: Minor
>
> (I'm guessing the resolver version - maven version is 3.8.4).
> We accidently made one of our repositories
> {{fail}} some time ago and over the weekend
> an plugin we run started failing.
> After some digging I discovered that the problem was when the code was
> programmatically trying to resolve a {{jar.asc}} file. Eventually the code
> ended up in
> {code}org.eclipse.aether.internal.impl.Maven2RepositoryLayoutFactory line 196
> public List getChecksums {
> if ( isSignature( artifact.getExtension() ) )
> {
> return Collections.emptyList();
> }
> {code}
> This means that when the resolution hit the correct repository it (silently)
> failed the checksum check and moved on to the next one, eventually falling
> off the end of the list and failing to resolve.
> Our work around is to set the {{}} to warn (which is what it
> used to be).
> 'It would be nice if'
> * The failure was slightly less quiet
> * If it was possible - programmatically or by configuration - to resolve
> signatures from checksuming repositories.
> I have not dived very deeply into the code - just enough to diagnose why our
> CI was exploding so spectacularly so I may have missed some trick in which
> case I apologise for asking for existing function
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7414) Maven version 3.8.3 + 3.8.4 have jsoup vulnerability
[ https://issues.apache.org/jira/browse/MNG-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495486#comment-17495486 ] Ksenia Hershkovici commented on MNG-7414: - Sure. We provide our customers an image that includes maven 3.8.3, hence providing a product with mentioned above vulnerability. > Maven version 3.8.3 + 3.8.4 have jsoup vulnerability > > > Key: MNG-7414 > URL: https://issues.apache.org/jira/browse/MNG-7414 > Project: Maven > Issue Type: Bug >Reporter: Ksenia Hershkovici >Priority: Major > > Hi Team, > We are facing jsoup component vulnerability with maven versions 3.8.3 and > 3.8.4 which is the latest released version of maven. The CVE details are: > CVE-2021-37714 > Jsoup version which is getting installed while installing maven 3.8.3 and > 3.8.4 is v1.12.1. > We noticed that both versions have wagon 3.4.3 that is probably installing > Jsoup v1.12.1. > Can you please provide the details of next maven version release with this > fix in it? > Thanks. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPIR-413) Plugin repositories defined in project are not used by plugin-management report
[
https://issues.apache.org/jira/browse/MPIR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPIR-413:
---
Assignee: Michael Osipov
> Plugin repositories defined in project are not used by plugin-management
> report
> ---
>
> Key: MPIR-413
> URL: https://issues.apache.org/jira/browse/MPIR-413
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: plugin-management
>Affects Versions: 3.2.1
>Reporter: Piotr Zygielo
>Assignee: Michael Osipov
>Priority: Minor
>
> Given: project that defines pluginRepository != central and manages plugin
> available from such repository
> When plugin-management report is requested
> Then
> # not user-friendly stack trace from exception is logged at INFO level
> {quote}[INFO] Generating "Plugin Management" report ---
> maven-project-info-reports-plugin:3.2.1:plugin-management[INFO] Could not
> build project for: groovy-eclipse-compiler:Error resolving project artifact:
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1 was not found in
> https://repo.maven.apache.org/maven2 during a previous attempt. This failure
> was cached in the local repository and resolution is not reattempted until
> the update interval of central has elapsed or updates are forced for project
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1
> +ST{quote}
> # the plugin in produced report is not linked to its site url
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-jxr] dependabot[bot] opened a new pull request #49: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.1
dependabot[bot] opened a new pull request #49: URL: https://github.com/apache/maven-jxr/pull/49 Bumps [maven-project-info-reports-plugin](https://github.com/apache/maven-project-info-reports-plugin) from 3.1.2 to 3.2.1. Commits https://github.com/apache/maven-project-info-reports-plugin/commit/8c25c66593f488f6609910b95ae2b246c196d734";>8c25c66 [maven-release-plugin] prepare release maven-project-info-reports-plugin-3.2.1 https://github.com/apache/maven-project-info-reports-plugin/commit/d85aec37c385d64196f7db5c3c27b400b46032ca";>d85aec3 [MPIR-412] Dependency report generates non-well-formed output if the POM of a... https://github.com/apache/maven-project-info-reports-plugin/commit/3c155a8231fac8b018c257d6dbe6bff0902633a2";>3c155a8 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-project-info-reports-plugin/commit/b130e220569301f89c58bfd10bf9de36efa20b1e";>b130e22 [maven-release-plugin] prepare release maven-project-info-reports-plugin-3.2.0 https://github.com/apache/maven-project-info-reports-plugin/commit/0190d0563be718c6be9c678d6149f97414c571ce";>0190d05 [MPIR-405] Regression in Maven site rendering due to Doxia change to HTML5 https://github.com/apache/maven-project-info-reports-plugin/commit/51a051b23dd5a97d472c45ac0850b949907fafef";>51a051b [MPIR-409] Upgrade Maven Site Plugin to 3.10.0 https://github.com/apache/maven-project-info-reports-plugin/commit/83c7f648db9fc6dcf4398c87e3dbfc72ccf87f01";>83c7f64 [MPIR-411] Upgrade Doxia to 1.11.1 and Doxia Sitetools to 1.11.1 https://github.com/apache/maven-project-info-reports-plugin/commit/c3ec75d8880296ba0fac46cc74994f82d8d90a0d";>c3ec75d [MPIR-410] Upgrade Maven SCM to 1.12.2 https://github.com/apache/maven-project-info-reports-plugin/commit/82ea24458afcab14f2cbbbc165d64114b7454640";>82ea244 [MPIR-404] Warn and accept invalid mailing list links https://github.com/apache/maven-project-info-reports-plugin/commit/cf0c168d8813d5bbf5592b6923fcc70598b7361a";>cf0c168 [MPIR-403] Travis link should point to travis-ci.com instead of travis-ci.org Additional commits viewable in https://github.com/apache/maven-project-info-reports-plugin/compare/maven-project-info-reports-plugin-3.1.2...maven-project-info-reports-plugin-3.2.1";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-project-info-reports-plugin] pzygielo commented on pull request #32: [MPIR-413] Fix building project for plugins from plugin management
pzygielo commented on pull request #32: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/32#issuecomment-1046840754 @slachiewicz - thanks for running the workflow @michael-o - thanks for checking Should it be helpful - https://github.com/pzrep/mpir-pmgmt - example pom with non-central repository and managed plugin. -- 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-7414) Maven version 3.8.3 + 3.8.4 have jsoup vulnerability
[ https://issues.apache.org/jira/browse/MNG-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495516#comment-17495516 ] Michael Osipov commented on MNG-7414: - This does not explain how you are truly affected by this issue. > Maven version 3.8.3 + 3.8.4 have jsoup vulnerability > > > Key: MNG-7414 > URL: https://issues.apache.org/jira/browse/MNG-7414 > Project: Maven > Issue Type: Bug >Reporter: Ksenia Hershkovici >Priority: Major > > Hi Team, > We are facing jsoup component vulnerability with maven versions 3.8.3 and > 3.8.4 which is the latest released version of maven. The CVE details are: > CVE-2021-37714 > Jsoup version which is getting installed while installing maven 3.8.3 and > 3.8.4 is v1.12.1. > We noticed that both versions have wagon 3.4.3 that is probably installing > Jsoup v1.12.1. > Can you please provide the details of next maven version release with this > fix in it? > Thanks. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-plugin-tools] dependabot[bot] closed pull request #64: Bump mockito-core from 2.28.2 to 4.2.0
dependabot[bot] closed pull request #64: URL: https://github.com/apache/maven-plugin-tools/pull/64 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-plugin-tools] dependabot[bot] opened a new pull request #71: Bump mockito-core from 2.28.2 to 4.3.1
dependabot[bot] opened a new pull request #71: URL: https://github.com/apache/maven-plugin-tools/pull/71 Bumps [mockito-core](https://github.com/mockito/mockito) from 2.28.2 to 4.3.1. Release notes Sourced from https://github.com/mockito/mockito/releases";>mockito-core's releases. v4.3.1 Changelog generated by https://github.com/shipkit/shipkit-changelog";>Shipkit Changelog Gradle Plugin 4.3.1 2022-01-25 - https://github.com/mockito/mockito/compare/v4.3.0...v4.3.1";>1 commit(s) by Stefano Cordio Add mockito-core to the BOM [(https://github-redirect.dependabot.com/mockito/mockito/issues/2550";>#2550)](https://github-redirect.dependabot.com/mockito/mockito/pull/2550";>mockito/mockito#2550) v4.3.0 Changelog generated by https://github.com/shipkit/shipkit-changelog";>Shipkit Changelog Gradle Plugin 4.3.0 2022-01-24 - https://github.com/mockito/mockito/compare/v4.2.0...v4.3.0";>20 commit(s) by Andrew Kozel, John Pyeatt, Liam Miller-Cushon, Thomas Keller, Tim van der Lippe, dependabot[bot], temp-droid Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2489";>#2489 : Fixed issue related to exceptions thrown from the nested spies [(https://github-redirect.dependabot.com/mockito/mockito/issues/2546";>#2546)](https://github-redirect.dependabot.com/mockito/mockito/pull/2546";>mockito/mockito#2546) Issue 2544 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2545";>#2545)](https://github-redirect.dependabot.com/mockito/mockito/pull/2545";>mockito/mockito#2545) Bump versions.bytebuddy from 1.12.6 to 1.12.7 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2543";>#2543)](https://github-redirect.dependabot.com/mockito/mockito/pull/2543";>mockito/mockito#2543) Bump com.diffplug.spotless from 6.1.2 to 6.2.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2542";>#2542)](https://github-redirect.dependabot.com/mockito/mockito/pull/2542";>mockito/mockito#2542) Bump material from 1.4.0 to 1.5.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2541";>#2541)](https://github-redirect.dependabot.com/mockito/mockito/pull/2541";>mockito/mockito#2541) Bump appcompat from 1.4.0 to 1.4.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2539";>#2539)](https://github-redirect.dependabot.com/mockito/mockito/pull/2539";>mockito/mockito#2539) Bump com.diffplug.spotless from 6.1.1 to 6.1.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2536";>#2536)](https://github-redirect.dependabot.com/mockito/mockito/pull/2536";>mockito/mockito#2536) Remove an @link [(https://github-redirect.dependabot.com/mockito/mockito/issues/2535";>#2535)](https://github-redirect.dependabot.com/mockito/mockito/pull/2535";>mockito/mockito#2535) Bump com.diffplug.spotless from 6.1.0 to 6.1.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2534";>#2534)](https://github-redirect.dependabot.com/mockito/mockito/pull/2534";>mockito/mockito#2534) Bump com.github.ben-manes.versions from 0.40.0 to 0.41.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2533";>#2533)](https://github-redirect.dependabot.com/mockito/mockito/pull/2533";>mockito/mockito#2533) Bump assertj-core from 3.21.0 to 3.22.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2531";>#2531)](https://github-redirect.dependabot.com/mockito/mockito/pull/2531";>mockito/mockito#2531) Bump com.github.ben-manes.versions from 0.39.0 to 0.40.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2529";>#2529)](https://github-redirect.dependabot.com/mockito/mockito/pull/2529";>mockito/mockito#2529) Bump com.diffplug.spotless from 6.0.5 to 6.1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2527";>#2527)](https://github-redirect.dependabot.com/mockito/mockito/pull/2527";>mockito/mockito#2527) Bump kotlinx-coroutines-core from 1.5.2-native-mt to 1.6.0-native-mt [(https://github-redirect.dependabot.com/mockito/mockito/issues/2526";>#2526)](https://github-redirect.dependabot.com/mockito/mockito/pull/2526";>mockito/mockito#2526) Bump versions.bytebuddy from 1.12.5 to 1.12.6 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2524";>#2524)](https://github-redirect.dependabot.com/mockito/mockito/pull/2524";>mockito/mockito#2524) Bump com.diffplug.spotless from 6.0.4 to 6.0.5 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2520";>#2520)](https://github-redirect.dependabot.com/mockito/mockito/pull/2520";>mockito/mockito#2520) Bump versions.bytebuddy from 1.12.4 to 1.12.5 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2519";>#2519)](https://github-redirect.dependabot.com/mockito/mockito/pull/2519";>mockito/mockito#2519) Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2510";>#2510: Remove ExpectedException from internal test suite [(https://github-redirect.dependabot
[GitHub] [maven-plugin-tools] dependabot[bot] commented on pull request #64: Bump mockito-core from 2.28.2 to 4.2.0
dependabot[bot] commented on pull request #64: URL: https://github.com/apache/maven-plugin-tools/pull/64#issuecomment-1046914948 Superseded by #71. -- 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] (MCHECKSTYLE-411) There should be info on skipped checkstyle check in maven build log
Marcin Slusarczyk created MCHECKSTYLE-411: - Summary: There should be info on skipped checkstyle check in maven build log Key: MCHECKSTYLE-411 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-411 Project: Maven Checkstyle Plugin Issue Type: Improvement Components: checkstyle:check Affects Versions: 3.1.1 Environment: Windows Reporter: Marcin Slusarczyk EXPECTED BEHAVIOR: There should be info on skipped checkstyle check in maven build log ACTUAL BEHAVIOR: There is no info in maven log that the Checkstyle check was skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2021) Commands should be flushed immediately. Use Channels.newChannel() instead of newBufferedChannel(). Delete the old flushing mechanism on forked processes.
[ https://issues.apache.org/jira/browse/SUREFIRE-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-2021. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=1c4e68e17b325e26defd161b80a4638ef6990694 > Commands should be flushed immediately. Use Channels.newChannel() instead of > newBufferedChannel(). Delete the old flushing mechanism on forked processes. > - > > Key: SUREFIRE-2021 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2021 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-mvnd] hcq413 commented on issue #593: How to solve it???
hcq413 commented on issue #593: URL: https://github.com/apache/maven-mvnd/issues/593#issuecomment-1046996875 大佬解决了吗 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on issue #593: How to solve it???
gnodet commented on issue #593: URL: https://github.com/apache/maven-mvnd/issues/593#issuecomment-1047007378 See https://github.com/apache/maven-mvnd/issues/571 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet closed issue #593: How to solve it???
gnodet closed issue #593: URL: https://github.com/apache/maven-mvnd/issues/593 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ToDropBombs removed a comment on issue #571: Failed to load native library on Windows with a Chinese user name
ToDropBombs removed a comment on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1031130865 这是来自QQ邮箱的假期自动回复邮件。 您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ToDropBombs edited a comment on issue #571: Failed to load native library on Windows with a Chinese user name
ToDropBombs edited a comment on issue #571:
URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1008484050
```
PS D:\> java -jar D:\mvnd-0.7.1-windows-amd64\mvn\lib\ext\jansi-2.4.0.jar
Jansi 2.4.0
library.jansi.path=
library.jansi.version=
Jansi native library loaded from
C:\Users\大米\AppData\Local\Temp\jansi-2.4.0-4ad7fea7eb28539c-jansi.dll
which was auto-extracted from
jar:file:/D:/mvnd-0.7.1-windows-amd64/mvn/lib/ext/jansi-2.4.0.jar!/org/fusesource/jansi/internal/native/Windows/x86_64/jansi.dll
os.name= Windows 10, os.version= 10.0, os.arch= amd64
file.encoding= GBK
java.version= 11.0.2, java.vendor= Oracle Corporation, java.home= C:\Program
Files\jdk-11.0.2
jansi.graceful=
jansi.mode=
jansi.out.mode=
jansi.err.mode=
jansi.colors=
jansi.out.colors=
jansi.err.colors=
jansi.passthrough= false
jansi.strip= false
jansi.force= false
jansi.noreset= false
org.fusesource.jansi.Ansi.disable= false
IS_WINDOWS: true
IS_CONEMU: false
IS_CYGWIN: false
IS_MSYSTEM: false
isatty(STDOUT_FILENO): 1, System.out is a terminal
isatty(STDERR_FILENO): 1, System.err is a terminal
Resulting Jansi modes for stout/stderr streams:
- System.out: AnsiPrintStream{type=VirtualTerminal, colors=Colors16,
mode=Default, resetAtUninstall=true}
- System.err: AnsiPrintStream{type=VirtualTerminal, colors=Colors16,
mode=Default, resetAtUninstall=true}
Processor types description:
- Native: Supports ansi sequences natively
- Unsupported: Ansi sequences are stripped out
- VirtualTerminal: Supported through windows virtual terminal
- Emulation: Emulated through using windows API console commands
- Redirected: The stream is redirected to a file or a pipe
Colors support description:
- Colors16: 16 colors
- Colors256: 256 colors
- TrueColor: 24-bit colors
Modes description:
- Strip: Strip all ansi sequences
- Default: Print ansi sequences if the stream is a terminal
- Force: Always print ansi sequences, even if the stream is redirected
test on System.out: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
bright: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
bold: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
bold+faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
256 colors:
truecolor: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\
test on System.err: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
bright: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
bold: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
bold+faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT
256 colors:
truecolor: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/\/\/\/\/\
┌──┐┌─┐ ┌─┐ ┌──┬──┐
│██├┘█└┬┘█└┬┘██│?▌│
┌──┐ │██│██▄▄▄██│██┌─┐██│██ │▄▄│
│??└─┘?█│?█┌─┐?█│?█│ │?█│ ?█│?█│
└┐▓┌┤▓▓│ │▓▓│▓▓│ │▓▓│?▓?│▓▓│
└─┘└──┘ └──┴──┘ └──┴───┴──┘
```
> Could you run `java -jar
D:\mvnd-0.7.1-windows-amd64\mvn\lib\ext\jansi-2.4.0.jar` and report the output ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on issue #571: Failed to load native library on Windows with a Chinese user name
gnodet commented on issue #571: URL: https://github.com/apache/maven-mvnd/issues/571#issuecomment-1047014411 Looks like it's caused by https://github.com/adoptium/temurin-build/issues/1496 and has been fixed with https://bugs.openjdk.java.net/browse/JDK-8240823 in JDK 11.0.8 Please upgrade the JDK. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet closed issue #571: Failed to load native library on Windows with a Chinese user name
gnodet closed issue #571: URL: https://github.com/apache/maven-mvnd/issues/571 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] imonteroperez commented on pull request #460: Add some javadoc and unit tests to includesFile and excludesFile
imonteroperez commented on pull request #460: URL: https://github.com/apache/maven-surefire/pull/460#issuecomment-1047083042 @Tibor17 I added the pending unit tests. I would propose you to review and merge this to your opened PR https://github.com/apache/maven-surefire/pull/440 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] suninformation commented on issue #561: The same build fails on the second run
suninformation commented on issue #561: URL: https://github.com/apache/maven-mvnd/issues/561#issuecomment-1047089734 @gnodet I created a project to reproduce #561 problems, please visit https://github.com/suninformation/maven-mvnd-demo-561 I hope I can get your help, thank you! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] jglick commented on a change in pull request #88: [MCOMPILER-205] Add a boolean to generate missing package-info classes by default
jglick commented on a change in pull request #88:
URL:
https://github.com/apache/maven-compiler-plugin/pull/88#discussion_r811352086
##
File path:
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
##
@@ -1286,6 +1315,72 @@ else if ( message.getKind() ==
CompilerMessage.Kind.WARNING
}
}
+private void createMissingPackageInfoClasses( CompilerConfiguration
compilerConfiguration,
+ SourceMapping sourceMapping,
+ Set sources )
+throws InclusionScanException, IOException
+{
+for ( File source : sources )
+{
+String path = source.toString();
+if ( path.endsWith( File.separator + "package-info.java" ) )
+{
+for ( String root : getCompileSourceRoots() )
+{
+root = root + File.separator;
+if ( path.startsWith( root ) )
+{
+String rel = path.substring( root.length() );
+Set files = sourceMapping.getTargetFiles(
getOutputDirectory(), rel );
Review comment:
#95
--
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] (MPOM-292) upgrade parent to ASF 25
[ https://issues.apache.org/jira/browse/MPOM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495704#comment-17495704 ] Hudson commented on MPOM-292: - Build succeeded in Jenkins: Maven » Maven TLP 2 » maven-parent » PR-47 #2 See https://ci-maven.apache.org/job/Maven/job/maven-github/job/maven-parent/job/PR-47/2/ > upgrade parent to ASF 25 > > > Key: MPOM-292 > URL: https://issues.apache.org/jira/browse/MPOM-292 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Affects Versions: MAVEN-34 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-35 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7418) Incorrect merging of snapshot versions in o.a.m.artifact.repository.metadata.Metadata.merge(...)
[
https://issues.apache.org/jira/browse/MNG-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-7418:
-
Description:
Given that I have two metadata on version level:
{code}
org.apache.jackrabbit.vault
org.apache.jackrabbit.vault
3.5.9-SNAPSHOT
...
jar
3.5.9-1
20220218143327
{code}
and
{code}
org.apache.jackrabbit.vault
org.apache.jackrabbit.vault
3.5.9-SNAPSHOT
...
jar
3.5.9-2
20220220143327
{code}
Merging both via
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L91
does not lead to two different snapshotVersions but only the one from the
original metadata.
On the other hand the merge in
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L72
does seem to do the merging correctly.
As IMHO the logic of merging should be agnostic of the resolver provider, those
versions should always be merged using all three fields from
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L315-L333
concatenated as ID.
was:
Given that I have two metadata on version level:
{code}
org.apache.jackrabbit.vault
org.apache.jackrabbit.vault
3.5.9-SNAPSHOT
...
jar
3.5.9-1
20220218143327
{code}
and
org.apache.jackrabbit.vault
org.apache.jackrabbit.vault
3.5.9-SNAPSHOT
...
jar
3.5.9-2
20220220143327
{code}
Merging both via
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L91
does not lead to two different snapshotVersions but only the one from the
original metadata.
On the other hand the merge in
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L72
does seem to do the merging correctly.
As IMHO the logic of merging should be agnostic of the resolver provider, those
versions should always be merged using all three fields from
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L315-L333
concatenated as ID.
> Incorrect merging of snapshot versions in
> o.a.m.artifact.repository.metadata.Metadata.merge(...)
>
>
> Key: MNG-7418
> URL: https://issues.apache.org/jira/browse/MNG-7418
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
>
> Given that I have two metadata on version level:
> {code}
>
> org.apache.jackrabbit.vault
> org.apache.jackrabbit.vault
> 3.5.9-SNAPSHOT
>
> ...
>
>
> jar
> 3.5.9-1
> 20220218143327
>
>
>
>
> {code}
> and
> {code}
>
> org.apache.jackrabbit.vault
> org.apache.jackrabbit.vault
> 3.5.9-SNAPSHOT
>
> ...
>
>
> jar
> 3.5.9-2
> 20220220143327
>
>
>
>
> {code}
> Merging both via
> https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L91
> does not lead to two different snapshotVersions but only the one from the
> original metadata.
> On the other hand the merge in
> https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L72
> does seem to do the merging correctly.
> As IMHO the logic of merging should be agnostic of the resolver provider,
> those versions should always be merged using all three fields from
> https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L315-L333
> concatenated as ID.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MNG-7418) Incorrect merging of snapshot versions in o.a.m.artifact.repository.metadata.Metadata.merge(...)
Konrad Windszus created MNG-7418:
Summary: Incorrect merging of snapshot versions in
o.a.m.artifact.repository.metadata.Metadata.merge(...)
Key: MNG-7418
URL: https://issues.apache.org/jira/browse/MNG-7418
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.8.4
Reporter: Konrad Windszus
Given that I have two metadata on version level:
{code}
org.apache.jackrabbit.vault
org.apache.jackrabbit.vault
3.5.9-SNAPSHOT
...
jar
3.5.9-1
20220218143327
{code}
and
org.apache.jackrabbit.vault
org.apache.jackrabbit.vault
3.5.9-SNAPSHOT
...
jar
3.5.9-2
20220220143327
{code}
Merging both via
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L91
does not lead to two different snapshotVersions but only the one from the
original metadata.
On the other hand the merge in
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L72
does seem to do the merging correctly.
As IMHO the logic of merging should be agnostic of the resolver provider, those
versions should always be merged using all three fields from
https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L315-L333
concatenated as ID.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MSHARED-1036) Project classes are analyzed many times
Slawomir Jaranowski created MSHARED-1036:
Summary: Project classes are analyzed many times
Key: MSHARED-1036
URL: https://issues.apache.org/jira/browse/MSHARED-1036
Project: Maven Shared Components
Issue Type: Bug
Components: maven-dependency-analyzer
Reporter: Slawomir Jaranowski
There are methods in {{DefaultProjectDependencyAnalyzer}} which collect classes
used by project
- buildDependencyClasses
- buildMainDependencyClasses
- buildTestDependencyClasses
In current implementation project output directory is analyzed three times and
test output directory two times.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MSHARED-1036) Project classes are analyzed many times
[
https://issues.apache.org/jira/browse/MSHARED-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MSHARED-1036:
Assignee: Slawomir Jaranowski
> Project classes are analyzed many times
> ---
>
> Key: MSHARED-1036
> URL: https://issues.apache.org/jira/browse/MSHARED-1036
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> There are methods in {{DefaultProjectDependencyAnalyzer}} which collect
> classes used by project
> - buildDependencyClasses
> - buildMainDependencyClasses
> - buildTestDependencyClasses
> In current implementation project output directory is analyzed three times
> and test output directory two times.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] asfgit closed pull request #306: [MNG-7417] Several classes do not set properties properly for building requests
asfgit closed pull request #306: URL: https://github.com/apache/maven/pull/306 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7417) Several classes do not set properties properly for building requests
[
https://issues.apache.org/jira/browse/MNG-7417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7417.
---
Fix Version/s: 4.0.0
4.0.0-alpha-1
3.8.5
(was: 4.0.x-candidate)
(was: 3.8.x-candidate)
Resolution: Fixed
Fixed with
[69d6c6d5a2886bd76fa9d0e922677d4654d1d90b|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=69d6c6d5a2886bd76fa9d0e922677d4654d1d90b]
and with
[395411fe3184b9692ed16bafa578b40cc0051784|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=395411fe3184b9692ed16bafa578b40cc0051784]
for {{maven-3.8.x}} branch.
> Several classes do not set properties properly for building requests
>
>
> Key: MNG-7417
> URL: https://issues.apache.org/jira/browse/MNG-7417
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Inheritance and Interpolation
>Affects Versions: 3.8.4
>Reporter: Michael Osipov
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
> Attachments: log.txt
>
>
> A sample case for this bug is {{DefaultArtifactDescriptorReader}}:
> When Resolver needs to resolve a transitive dependency it consults Maven
> Resolver Provider to create data. Here the properties of the repository
> system session are not properly passed with their respective scopes down to
> the model building request. When a POM now needs needs to be interpolated,
> the interpolation can fail.
> For long time Maven, unfortunately, promoted user properties to system
> properties making the available everywhere (expect this to be cleaned up in
> Maven 4). A prime example where this is broken:
> {{DefaultModelVersionProcessor}} uses for some strange reason system
> properties although CI Friendly Versions are user properties only. Fixing
> this component with:
> {noformat}
> ---
> a/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/DefaultModelVersionProcessor.java
> +++
> b/maven-model-builder/src/main/java/org/apache/maven/model/interpolation/DefaultModelVersionProcessor.java
> @@ -52,17 +52,17 @@ public boolean isValidProperty( String property )
> @Override
> public void overwriteModelProperties( Properties modelProperties,
> ModelBuildingRequest request )
> {
> -if ( request.getSystemProperties().containsKey( REVISION_PROPERTY ) )
> +if ( request.getUserProperties().containsKey( REVISION_PROPERTY ) )
> {
> -modelProperties.put( REVISION_PROPERTY,
> request.getSystemProperties().get( REVISION_PROPERTY ) );
> +modelProperties.put( REVISION_PROPERTY,
> request.getUserProperties().get( REVISION_PROPERTY ) );
> }
> -if ( request.getSystemProperties().containsKey( CHANGELIST_PROPERTY
> ) )
> +if ( request.getUserProperties().containsKey( CHANGELIST_PROPERTY ) )
> {
> -modelProperties.put( CHANGELIST_PROPERTY,
> request.getSystemProperties().get( CHANGELIST_PROPERTY ) );
> +modelProperties.put( CHANGELIST_PROPERTY,
> request.getUserProperties().get( CHANGELIST_PROPERTY ) );
> }
> -if ( request.getSystemProperties().containsKey( SHA1_PROPERTY ) )
> +if ( request.getUserProperties().containsKey( SHA1_PROPERTY ) )
> {
> -modelProperties.put( SHA1_PROPERTY,
> request.getSystemProperties().get( SHA1_PROPERTY ) );
> +modelProperties.put( SHA1_PROPERTY,
> request.getUserProperties().get( SHA1_PROPERTY ) );
> }
> }
> {noformat}
> and running ITs makes several of them fail:
> {noformat}
> ...
> mng6090 CIFriendly.itShouldResolveTheDependenciesWithBuildConsumer() FAILURE
> (10.4 s)
> mng6090 CIFriendly.itShouldResolveTheDependenciesWithoutBuildConsumer()
> FAILURE (1.2 s)
> ...
> mng5895
> CIFriendlyUsageWithProperty.itShouldResolveTheDependenciesWithBuildConsumer()
> FAILURE (0.5 s)
> mng5895
> CIFriendlyUsageWithProperty.itShouldResolveTheDependenciesWithoutBuildConsumer()
> FAILURE (0.5 s)
> ...
> {noformat}
> The reason is simple:
> {code:java}
> modelRequest.setSystemProperties( toProperties(
> session.getUserProperties(),
>
> session.getSystemProperties() ) );
> {code}
> Properties from user are not available. The are likely other usecases
> affected by this bug.
> Yet another problem is that plugins which resolve dependencies, e.g.,
> MASSEMBLY will also fail even if this bug is fixed since they rely on an old
> version of the Maven Resolver Provider and don't use provided scope to use
> the fixed one from Maven Core. This is a separate problem to be solved.
--
This mess
[jira] [Closed] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5982.
---
Fix Version/s: 4.0.0
4.0.0-alpha-1
3.8.5
(was: 4.0.x-candidate)
(was: 3.8.x-candidate)
Resolution: Fixed
Sixth anniversary, happy birthday!
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Assignee: Michael Osipov
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1, needs-attention
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5982:
Labels: needs-attention (was: must-be-in-4.0.0-alpha-1 needs-attention)
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Assignee: Michael Osipov
>Priority: Minor
> Labels: needs-attention
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7408) Explain reporting plugin version automatic selection (in Maven 3)
[ https://issues.apache.org/jira/browse/MNG-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7408: Summary: Explain reporting plugin version automatic selection (in Maven 3) (was: explain reporting plugin version automatic selection (in Maven 3)) > Explain reporting plugin version automatic selection (in Maven 3) > - > > Key: MNG-7408 > URL: https://issues.apache.org/jira/browse/MNG-7408 > Project: Maven > Issue Type: Improvement > Components: Sites & Reporting >Affects Versions: 3.8.4 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5 > > > reporting plugin version looks like normal version = you need to define a > version for build stability > https://maven.apache.org/ref/3.8.4/maven-model/maven.html#class_reporting > in Maven 2, it did not even benefit from pluginManagement version selection > but since Maven 3 MNG-4162, it benefits not only from pluginManagement > version but also from plugin: we need to make that clear, because versions of > report plugins are a pain for users who don't know about this, because it > force them to define a property that will be used both in > pluginManagement/plugin and reporting > and since Maven Site Plugin 3.4, it also benefits from pluginManagement > configuration > see https://maven.apache.org/shared/maven-reporting-exec/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] kwin opened a new pull request #680: [MNG-7418] Fix merging of snapshotVersions
kwin opened a new pull request #680: URL: https://github.com/apache/maven/pull/680 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/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] kwin commented on a change in pull request #680: [MNG-7418] Fix merging of snapshotVersions
kwin commented on a change in pull request #680:
URL: https://github.com/apache/maven/pull/680#discussion_r811367660
##
File path: maven-repository-metadata/src/main/mdo/metadata.mdo
##
@@ -141,6 +141,14 @@ under the License.
}
}
+for ( SnapshotVersion version : versioning.getSnapshotVersions() )
+{
+if ( !v.getSnapshotVersions().contains( version ) )
Review comment:
I guess this needs more refinement as IMHO only extension, version, and
classifier act as id. The `updated` value should always be taken from the newer
version I guess
--
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-7418) Incorrect merging of snapshot versions in o.a.m.artifact.repository.metadata.Metadata.merge(...)
[
https://issues.apache.org/jira/browse/MNG-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495715#comment-17495715
]
Michael Osipov commented on MNG-7418:
-
Is this a dup of MNG-5180?
> Incorrect merging of snapshot versions in
> o.a.m.artifact.repository.metadata.Metadata.merge(...)
>
>
> Key: MNG-7418
> URL: https://issues.apache.org/jira/browse/MNG-7418
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
>
> Given that I have two metadata on version level:
> {code}
>
> org.apache.jackrabbit.vault
> org.apache.jackrabbit.vault
> 3.5.9-SNAPSHOT
>
> ...
>
>
> jar
> 3.5.9-1
> 20220218143327
>
>
>
>
> {code}
> and
> {code}
>
> org.apache.jackrabbit.vault
> org.apache.jackrabbit.vault
> 3.5.9-SNAPSHOT
>
> ...
>
>
> jar
> 3.5.9-2
> 20220220143327
>
>
>
>
> {code}
> Merging both via
> https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L91
> does not lead to two different snapshotVersions but only the one from the
> original metadata.
> On the other hand the merge in
> https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L72
> does seem to do the merging correctly.
> As IMHO the logic of merging should be agnostic of the resolver provider,
> those versions should always be merged using all three fields from
> https://github.com/apache/maven/blob/03df5f7c639db744a3597c7175c92c8e2a27767b/maven-repository-metadata/src/main/mdo/metadata.mdo#L315-L333
> concatenated as ID.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MNG-7225) could not be resolved: com.sun:tools:jar:1.8, com.sun:jconsole:jar:1.8
[
https://issues.apache.org/jira/browse/MNG-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-7225.
Resolution: Won't Fix
Unfortunately no feedback.
> could not be resolved: com.sun:tools:jar:1.8, com.sun:jconsole:jar:1.8
> --
>
> Key: MNG-7225
> URL: https://issues.apache.org/jira/browse/MNG-7225
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.2
> Environment: Apache Maven 3.8.2
> Java version: 1.8.0_302
>Reporter: MichaelFreeman
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> Apache Maven 3.8.2
> Java version: 1.8.0_302
> when use mvn compile my project,
> {code:java}
> Failed to execute goal on project xxx, Could not resolve dependencies for
> project xxx: The following artifacts could not be resolved:
> com.sun:tools:jar:1.8, com.sun:jconsole:jar:1.8: Could not find artifact
> com.sun:tools:jar:1.8 at specified path
> xxx/.m2/repository/com/alibaba/druid/1.1.21/lib/openjdk-1.8-tools.jar
> {code}
> but when I use version 3.6.3, there is no error.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7225) could not be resolved: com.sun:tools:jar:1.8, com.sun:jconsole:jar:1.8
[
https://issues.apache.org/jira/browse/MNG-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7225:
Fix Version/s: (was: waiting-for-feedback)
(was: wontfix-candidate)
> could not be resolved: com.sun:tools:jar:1.8, com.sun:jconsole:jar:1.8
> --
>
> Key: MNG-7225
> URL: https://issues.apache.org/jira/browse/MNG-7225
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.2
> Environment: Apache Maven 3.8.2
> Java version: 1.8.0_302
>Reporter: MichaelFreeman
>Priority: Major
>
> Apache Maven 3.8.2
> Java version: 1.8.0_302
> when use mvn compile my project,
> {code:java}
> Failed to execute goal on project xxx, Could not resolve dependencies for
> project xxx: The following artifacts could not be resolved:
> com.sun:tools:jar:1.8, com.sun:jconsole:jar:1.8: Could not find artifact
> com.sun:tools:jar:1.8 at specified path
> xxx/.m2/repository/com/alibaba/druid/1.1.21/lib/openjdk-1.8-tools.jar
> {code}
> but when I use version 3.6.3, there is no error.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MNG-6606) Allow installation-wide parameter customization
[
https://issues.apache.org/jira/browse/MNG-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6606.
---
Fix Version/s: (was: waiting-for-feedback)
(was: wontfix-candidate)
Resolution: Incomplete
No valid feedback for almost three years.
> Allow installation-wide parameter customization
> ---
>
> Key: MNG-6606
> URL: https://issues.apache.org/jira/browse/MNG-6606
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.1.1
>Reporter: Paul Benedict
>Priority: Major
>
> In my use case, I would like to always print the version of Maven at every
> execution. I am not interested in a per-project case basis; nor interested in
> modifying the startup batch scripts. I want to drop in a standard
> configuration file to control all my Maven installations in the same manner.
> My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to
> also be recognized in the Maven installation root. I am not explicitly asking
> for {{${maven.root}/.mvn}} to be *the* solution, but it's the right place to
> start the problem solving.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (WAGON-616) Deprecate Wagon SSH Provider
[
https://issues.apache.org/jira/browse/WAGON-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495720#comment-17495720
]
Michael Osipov commented on WAGON-616:
--
Provider:
https://maven.apache.org/wagon/wagon-providers/wagon-ssh-external/index.html
Additionally to the issues in the description: I have been the sole maintainer
of Wagon for past four years, it requires a tremendous amount of time to
understand issues and properly fix them. Given that millions use it and almost
no one aids me, it pushes me into a position that it simply makes no sense to
support multiple providers for the same protocol if there is virtually no
benefit. SSH is here to stay, for whatehver reasons you are using it. The
OpenBSD team supports OpenSSH, we wrap it. Minimal effort. Given that a rewrite
to Apache MINA will require a lot of time, I won't do unless someone is willing
to pay for it. Most of the discussions happened internally that we don't want
to support multiple routes and need to minimize our effort. We also have this:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup
> Deprecate Wagon SSH Provider
>
>
> Key: WAGON-616
> URL: https://issues.apache.org/jira/browse/WAGON-616
> Project: Maven Wagon
> Issue Type: Task
> Components: wagon-ssh
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.0
>
>
> This provider has serious implications and implementation issues:
> - JSch http://www.jcraft.com/jsch/ failed to provide a source repository,
> accept contributions and address issues.
> - Too complex and low level.
> - It is disputed whether this is open source at all.
> The sshexe ({{scp}}) provider remains until someone wants to write something
> on top of Apache MINA SSHD.
> We are deprecating this provider to be removed in 4.0.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495722#comment-17495722 ] Michael Osipov commented on MNG-7401: - Unless you cannot provide a non-TLS approach this will likely be closed in the future. > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7401: Fix Version/s: waiting-for-feedback > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7402) BuildListCalculator never detaches the classloader
[ https://issues.apache.org/jira/browse/MNG-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495723#comment-17495723 ] Michael Osipov commented on MNG-7402: - Please propose a PR if you want to have it in 3.8.5. > BuildListCalculator never detaches the classloader > -- > > Key: MNG-7402 > URL: https://issues.apache.org/jira/browse/MNG-7402 > Project: Maven > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > https://github.com/apache/maven/blob/6b607109d3ce045106924139e96705fe7c42172e/maven-core/src/main/java/org/apache/maven/lifecycle/internal/BuildListCalculator.java#L63 > Her there is attachToThread called but never detached. This seems to be a > leak, at least the threads current contextclassloader is never restored. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7402) BuildListCalculator never detaches the classloader
[ https://issues.apache.org/jira/browse/MNG-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7402: Summary: BuildListCalculator never detaches the classloader (was: BuildListCalculator never detaches the classlaoder...) > BuildListCalculator never detaches the classloader > -- > > Key: MNG-7402 > URL: https://issues.apache.org/jira/browse/MNG-7402 > Project: Maven > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > https://github.com/apache/maven/blob/6b607109d3ce045106924139e96705fe7c42172e/maven-core/src/main/java/org/apache/maven/lifecycle/internal/BuildListCalculator.java#L63 > Her there is attachToThread called but never detached. This seems to be a > leak, at least the threads current contextclassloader is never restored. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7403) Support loading of ArtifactHandlers from project-scoped extensions
[
https://issues.apache.org/jira/browse/MNG-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495724#comment-17495724
]
Michael Osipov commented on MNG-7403:
-
Do you have a solution outline for this?
> Support loading of ArtifactHandlers from project-scoped extensions
> --
>
> Key: MNG-7403
> URL: https://issues.apache.org/jira/browse/MNG-7403
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> Currently new {{ArtifactHandlers}} are only take into account when provided
> as a core extension.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7403) Support loading of ArtifactHandlers from project-scoped extensions
[
https://issues.apache.org/jira/browse/MNG-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495725#comment-17495725
]
Christoph Läubrich commented on MNG-7403:
-
Not yet, as it is possible to define artifact handlers in the components.xml
this is a bit low priority at the moment.
> Support loading of ArtifactHandlers from project-scoped extensions
> --
>
> Key: MNG-7403
> URL: https://issues.apache.org/jira/browse/MNG-7403
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> Currently new {{ArtifactHandlers}} are only take into account when provided
> as a core extension.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7403) Support loading of ArtifactHandlers from project-scoped extensions
[
https://issues.apache.org/jira/browse/MNG-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495727#comment-17495727
]
Michael Osipov commented on MNG-7403:
-
Sure, no issue. Maybe for Maven 4 someday.
> Support loading of ArtifactHandlers from project-scoped extensions
> --
>
> Key: MNG-7403
> URL: https://issues.apache.org/jira/browse/MNG-7403
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> Currently new {{ArtifactHandlers}} are only take into account when provided
> as a core extension.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MPIR-414) Upgrade Maven Reporting API/Impl to 3.1.0
Michael Osipov created MPIR-414: --- Summary: Upgrade Maven Reporting API/Impl to 3.1.0 Key: MPIR-414 URL: https://issues.apache.org/jira/browse/MPIR-414 Project: Maven Project Info Reports Plugin Issue Type: Dependency upgrade Affects Versions: 3.2.1 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.2.2 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MPIR-414) Upgrade Maven Reporting API/Impl to 3.1.0
[ https://issues.apache.org/jira/browse/MPIR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-414. --- Resolution: Fixed Fixed with [99bfaef54bbff120317a7adfb7ca9cf0f883075c|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=99bfaef54bbff120317a7adfb7ca9cf0f883075c]. > Upgrade Maven Reporting API/Impl to 3.1.0 > - > > Key: MPIR-414 > URL: https://issues.apache.org/jira/browse/MPIR-414 > Project: Maven Project Info Reports Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.2.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.2 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPIR-414) Upgrade Maven Reporting API/Impl to 3.1.0
[ https://issues.apache.org/jira/browse/MPIR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495738#comment-17495738 ] Hudson commented on MPIR-414: - Build succeeded in Jenkins: Maven » Maven TLP "new" » maven-project-info-reports-plugin » master #2 See https://ci-maven.apache.org/job/Maven/job/maven-github/job/maven-project-info-reports-plugin/job/master/2/ > Upgrade Maven Reporting API/Impl to 3.1.0 > - > > Key: MPIR-414 > URL: https://issues.apache.org/jira/browse/MPIR-414 > Project: Maven Project Info Reports Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.2.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.2 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MPIR-413) Plugin repositories defined in project are not used by plugin-management report
[
https://issues.apache.org/jira/browse/MPIR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-413:
Fix Version/s: 3.2.2
> Plugin repositories defined in project are not used by plugin-management
> report
> ---
>
> Key: MPIR-413
> URL: https://issues.apache.org/jira/browse/MPIR-413
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: plugin-management
>Affects Versions: 3.2.1
>Reporter: Piotr Zygielo
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Given: project that defines pluginRepository != central and manages plugin
> available from such repository
> When plugin-management report is requested
> Then
> # not user-friendly stack trace from exception is logged at INFO level
> {quote}[INFO] Generating "Plugin Management" report ---
> maven-project-info-reports-plugin:3.2.1:plugin-management[INFO] Could not
> build project for: groovy-eclipse-compiler:Error resolving project artifact:
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1 was not found in
> https://repo.maven.apache.org/maven2 during a previous attempt. This failure
> was cached in the local repository and resolution is not reattempted until
> the update interval of central has elapsed or updates are forced for project
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1
> +ST{quote}
> # the plugin in produced report is not linked to its site url
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MPIR-413) Plugin repositories defined in project are not used by plugin-management report
[
https://issues.apache.org/jira/browse/MPIR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-413.
---
Resolution: Fixed
Fixed with
[d28e98b8cfedbe179a1017d1a221871919841415|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=d28e98b8cfedbe179a1017d1a221871919841415].
> Plugin repositories defined in project are not used by plugin-management
> report
> ---
>
> Key: MPIR-413
> URL: https://issues.apache.org/jira/browse/MPIR-413
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: plugin-management
>Affects Versions: 3.2.1
>Reporter: Piotr Zygielo
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Given: project that defines pluginRepository != central and manages plugin
> available from such repository
> When plugin-management report is requested
> Then
> # not user-friendly stack trace from exception is logged at INFO level
> {quote}[INFO] Generating "Plugin Management" report ---
> maven-project-info-reports-plugin:3.2.1:plugin-management[INFO] Could not
> build project for: groovy-eclipse-compiler:Error resolving project artifact:
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1 was not found in
> https://repo.maven.apache.org/maven2 during a previous attempt. This failure
> was cached in the local repository and resolution is not reattempted until
> the update interval of central has elapsed or updates are forced for project
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1
> +ST{quote}
> # the plugin in produced report is not linked to its site url
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-project-info-reports-plugin] asfgit closed pull request #32: [MPIR-413] Fix building project for plugins from plugin management
asfgit closed pull request #32: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/32 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MPIR-406) List dependencies in alphanumerical order to detect jar name colissions and missed exclusions
[ https://issues.apache.org/jira/browse/MPIR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-406. --- Resolution: Invalid If you think you have found a bug in a report, please report the bug and provide a simple reproducer for this. > List dependencies in alphanumerical order to detect jar name colissions and > missed exclusions > - > > Key: MPIR-406 > URL: https://issues.apache.org/jira/browse/MPIR-406 > Project: Maven Project Info Reports Plugin > Issue Type: New Feature > Components: dependencies >Reporter: Gwénaël Ruelland >Priority: Trivial > Attachments: image-2022-01-20-11-00-35-884.png, > image-2022-01-20-11-02-06-548.png, image-2022-01-21-09-54-53-919.png, > image-2022-01-21-12-52-18-463.png > > > Dependency tree in the HTML report has dependencies unsorted which is a pain > to search/check visually. > Here is a visual of the fix. > !image-2022-01-20-11-02-06-548.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MPIR-406) List dependencies in alphanumerical order to detect jar name colissions and missed exclusions
[ https://issues.apache.org/jira/browse/MPIR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495744#comment-17495744 ] Michael Osipov edited comment on MPIR-406 at 2/21/22, 8:27 PM: --- If you think you have found a bug in a report, please report the bug and provide a simple reproducer for this. The actual issue reported here is not targeted by MPIR. MDEP is the right one. was (Author: michael-o): If you think you have found a bug in a report, please report the bug and provide a simple reproducer for this. > List dependencies in alphanumerical order to detect jar name colissions and > missed exclusions > - > > Key: MPIR-406 > URL: https://issues.apache.org/jira/browse/MPIR-406 > Project: Maven Project Info Reports Plugin > Issue Type: New Feature > Components: dependencies >Reporter: Gwénaël Ruelland >Priority: Trivial > Attachments: image-2022-01-20-11-00-35-884.png, > image-2022-01-20-11-02-06-548.png, image-2022-01-21-09-54-53-919.png, > image-2022-01-21-12-52-18-463.png > > > Dependency tree in the HTML report has dependencies unsorted which is a pain > to search/check visually. > Here is a visual of the fix. > !image-2022-01-20-11-02-06-548.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPIR-413) Plugin repositories defined in project are not used by plugin-management report
[
https://issues.apache.org/jira/browse/MPIR-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495745#comment-17495745
]
Hudson commented on MPIR-413:
-
Build succeeded in Jenkins: Maven » Maven TLP "new" »
maven-project-info-reports-plugin » master #3
See
https://ci-maven.apache.org/job/Maven/job/maven-github/job/maven-project-info-reports-plugin/job/master/3/
> Plugin repositories defined in project are not used by plugin-management
> report
> ---
>
> Key: MPIR-413
> URL: https://issues.apache.org/jira/browse/MPIR-413
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: plugin-management
>Affects Versions: 3.2.1
>Reporter: Piotr Zygielo
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.2
>
>
> Given: project that defines pluginRepository != central and manages plugin
> available from such repository
> When plugin-management report is requested
> Then
> # not user-friendly stack trace from exception is logged at INFO level
> {quote}[INFO] Generating "Plugin Management" report ---
> maven-project-info-reports-plugin:3.2.1:plugin-management[INFO] Could not
> build project for: groovy-eclipse-compiler:Error resolving project artifact:
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1 was not found in
> https://repo.maven.apache.org/maven2 during a previous attempt. This failure
> was cached in the local repository and resolution is not reattempted until
> the update interval of central has elapsed or updates are forced for project
> org.codehaus.groovy:groovy-eclipse-compiler:pom:3.7.1
> +ST{quote}
> # the plugin in produced report is not linked to its site url
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPH-172) Allow expression to fetch a dependency given an artifactId
[
https://issues.apache.org/jira/browse/MPH-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPH-172:
---
Summary: Allow expression to fetch a dependency given an artifactId (was:
Allow expression to fetch a dependency given an artefactID)
> Allow expression to fetch a dependency given an artifactId
> --
>
> Key: MPH-172
> URL: https://issues.apache.org/jira/browse/MPH-172
> Project: Maven Help Plugin
> Issue Type: New Feature
> Components: expressions
>Reporter: Baubak Gandomi
>Priority: Major
>
> I would like to know the version of a dependency which is being used in the
> pom.
> Today if I want to do it, the only way I know is to:
> {code:java}
> mvn help:evaluate -Dexpression=project.dependencies[5].version
> -DforceStdout {code}
> The problem with this is that I need to know the order in which a dependency
> has been defined. What I would like is to do dependency map fetching. Example
> for an artefact with th artefactId "BBB", I should be able to get the used
> version by:
> {code:java}
> mvn help:evaluate -Dexpression=project.dependencies["BBB"].version
> -DforceStdout {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MPH-172) Allow expression to fetch a dependency given an artifactId
[
https://issues.apache.org/jira/browse/MPH-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPH-172.
--
Resolution: Information Provided
> Allow expression to fetch a dependency given an artifactId
> --
>
> Key: MPH-172
> URL: https://issues.apache.org/jira/browse/MPH-172
> Project: Maven Help Plugin
> Issue Type: New Feature
> Components: expressions
>Reporter: Baubak Gandomi
>Priority: Major
>
> I would like to know the version of a dependency which is being used in the
> pom.
> Today if I want to do it, the only way I know is to:
> {code:java}
> mvn help:evaluate -Dexpression=project.dependencies[5].version
> -DforceStdout {code}
> The problem with this is that I need to know the order in which a dependency
> has been defined. What I would like is to do dependency map fetching. Example
> for an artefact with th artefactId "BBB", I should be able to get the used
> version by:
> {code:java}
> mvn help:evaluate -Dexpression=project.dependencies["BBB"].version
> -DforceStdout {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] eolivelli commented on a change in pull request #635: [Experiment] Maven w/ transport-http
eolivelli commented on a change in pull request #635: URL: https://github.com/apache/maven/pull/635#discussion_r811425677 ## File path: pom.xml ## @@ -575,6 +562,7 @@ under the License. .asf.yaml + .mvn/ Review comment: I see. Makes sense -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] slawekjaranowski merged pull request #195: [MDEP-788] Upgrade maven-reporting-impl to version 3.1.0
slawekjaranowski merged pull request #195: URL: https://github.com/apache/maven-dependency-plugin/pull/195 -- 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-dependency-plugin] dependabot[bot] closed pull request #199: Bump maven-reporting-api from 3.0 to 3.1.0
dependabot[bot] closed pull request #199: URL: https://github.com/apache/maven-dependency-plugin/pull/199 -- 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-dependency-plugin] dependabot[bot] commented on pull request #199: Bump maven-reporting-api from 3.0 to 3.1.0
dependabot[bot] commented on pull request #199: URL: https://github.com/apache/maven-dependency-plugin/pull/199#issuecomment-1047246665 Looks like org.apache.maven.reporting:maven-reporting-api is no longer a dependency, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MDEP-788) Upgrade maven-reporting-impl to version 3.1.0
[ https://issues.apache.org/jira/browse/MDEP-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MDEP-788. Fix Version/s: 3.3.0 Resolution: Fixed > Upgrade maven-reporting-impl to version 3.1.0 > - > > Key: MDEP-788 > URL: https://issues.apache.org/jira/browse/MDEP-788 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.0 > > > * use maven-site-plugin in IT test > * remove dependency to doxia, it is transitive from maven-reporting-impl -- This message was sent by Atlassian Jira (v8.20.1#820001)
