[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15790713#comment-15790713 ] Christian Schulte commented on MNG-6141: FYI, that fix to MNG-5761 also fixes MNG-5708. > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-6139) Addition of command line option 'legacy-dependency-management'.
[ https://issues.apache.org/jira/browse/MNG-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-6139. -- Resolution: Won't Fix Assignee: (was: Christian Schulte) Fix Version/s: (was: 3.4.0) > Addition of command line option 'legacy-dependency-management'. > --- > > Key: MNG-6139 > URL: https://issues.apache.org/jira/browse/MNG-6139 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Critical > > See the issues this issue is linked to. The command line option will simply > allow users to disable the bugfixes and get the former incorrect behaviour. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MNG-6139) Addition of command line option 'legacy-dependency-management'.
[ https://issues.apache.org/jira/browse/MNG-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reopened MNG-6139: > Addition of command line option 'legacy-dependency-management'. > --- > > Key: MNG-6139 > URL: https://issues.apache.org/jira/browse/MNG-6139 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Fix For: 3.4.0 > > > See the issues this issue is linked to. The command line option will simply > allow users to disable the bugfixes and get the former incorrect behaviour. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://issues.apache.org/jira/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte reassigned MNG-5708: -- Assignee: Christian Schulte (was: Michael Osipov) > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://issues.apache.org/jira/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen >Assignee: Christian Schulte > Fix For: 3.4.0 > > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MRELEASE-974) https in project tag
Jeremy Landis created MRELEASE-974: -- Summary: https in project tag Key: MRELEASE-974 URL: https://issues.apache.org/jira/browse/MRELEASE-974 Project: Maven Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.5.3 Reporter: Jeremy Landis Priority: Minor In the pom on the tag, I'd like to use https as they are available for the xmlns, xmlns:xsi, and xsi:schemaLocation locations. When I run other plugins it's fine but if I try to release it fails. It initially fails with xmlns:xsi issue. If I set that back to http, then it flags tags all with http throughout and crashes. What I have to use now... ``` http://maven.apache.org/POM/4.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;> ``` What I would like to use... ``` https://maven.apache.org/POM/4.0.0; xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="https://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd;> ``` Is this possible? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6025) Add a ProjectArtifactsCache similar to PluginArtifactsCache
[ https://issues.apache.org/jira/browse/MNG-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6025: Fix Version/s: 3.4.0 > Add a ProjectArtifactsCache similar to PluginArtifactsCache > --- > > Key: MNG-6025 > URL: https://issues.apache.org/jira/browse/MNG-6025 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.3.9 >Reporter: Anton Tanasenko >Assignee: Jason van Zyl >Priority: Minor > Fix For: 3.4.0 > > > Every mojo execution, if it specifies dependency resolution other than > 'none', will cause a resolution to be performed. > There is a guard in MojoExecutor's DependencyContext which guards against > performing this resolution multiple times by looking at the changes to > dependencyArtifacts list. > However, during a build in an incremental/interactive environment, like > eclipse m2e or maven console, those mojos might be executed at an arbitrary > time and will not benefit from that DependencyContext check. > I propose having a ProjectArtifactsCache (very similar to > PluginArtifactsCache) that will cache artifact set as returned by > LifecycleDependencyResolver#getDependencies(). > While it does not improve cli builds, incremental/interactive builds will > receive a huge performance boost between pom changes. > I've been able to get build of a project with a lot of dependencies (jenkins > plugin) and a number of (fully incremental) mojo executions from 7 seconds to > around 1.5 on a single java file change in eclipse m2e after introducing this > cache. > I will provide a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MNG-6025) Add a ProjectArtifactsCache similar to PluginArtifactsCache
[ https://issues.apache.org/jira/browse/MNG-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6025. --- Resolution: Fixed Fixed with [7277a8464ba453aeacb82b22ffd966c9fb17c620|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=7277a8464ba453aeacb82b22ffd966c9fb17c620]. > Add a ProjectArtifactsCache similar to PluginArtifactsCache > --- > > Key: MNG-6025 > URL: https://issues.apache.org/jira/browse/MNG-6025 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.3.9 >Reporter: Anton Tanasenko >Assignee: Jason van Zyl >Priority: Minor > Fix For: 3.4.0 > > > Every mojo execution, if it specifies dependency resolution other than > 'none', will cause a resolution to be performed. > There is a guard in MojoExecutor's DependencyContext which guards against > performing this resolution multiple times by looking at the changes to > dependencyArtifacts list. > However, during a build in an incremental/interactive environment, like > eclipse m2e or maven console, those mojos might be executed at an arbitrary > time and will not benefit from that DependencyContext check. > I propose having a ProjectArtifactsCache (very similar to > PluginArtifactsCache) that will cache artifact set as returned by > LifecycleDependencyResolver#getDependencies(). > While it does not improve cli builds, incremental/interactive builds will > receive a huge performance boost between pom changes. > I've been able to get build of a project with a lot of dependencies (jenkins > plugin) and a number of (fully incremental) mojo executions from 7 seconds to > around 1.5 on a single java file change in eclipse m2e after introducing this > cache. > I will provide a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-6025) Add a ProjectArtifactsCache similar to PluginArtifactsCache
[ https://issues.apache.org/jira/browse/MNG-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6025: Assignee: Jason van Zyl > Add a ProjectArtifactsCache similar to PluginArtifactsCache > --- > > Key: MNG-6025 > URL: https://issues.apache.org/jira/browse/MNG-6025 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.3.9 >Reporter: Anton Tanasenko >Assignee: Jason van Zyl >Priority: Minor > > Every mojo execution, if it specifies dependency resolution other than > 'none', will cause a resolution to be performed. > There is a guard in MojoExecutor's DependencyContext which guards against > performing this resolution multiple times by looking at the changes to > dependencyArtifacts list. > However, during a build in an incremental/interactive environment, like > eclipse m2e or maven console, those mojos might be executed at an arbitrary > time and will not benefit from that DependencyContext check. > I propose having a ProjectArtifactsCache (very similar to > PluginArtifactsCache) that will cache artifact set as returned by > LifecycleDependencyResolver#getDependencies(). > While it does not improve cli builds, incremental/interactive builds will > receive a huge performance boost between pom changes. > I've been able to get build of a project with a lot of dependencies (jenkins > plugin) and a number of (fully incremental) mojo executions from 7 seconds to > around 1.5 on a single java file change in eclipse m2e after introducing this > cache. > I will provide a patch shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6049) Add behavior to filter resolved version ranges of an artifact
[
https://issues.apache.org/jira/browse/MNG-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15790230#comment-15790230
]
Michael Osipov commented on MNG-6049:
-
[~schulte77], do you think this is something for you for master cleanup? I just
merged this and it seems like your field of strong expertise.
> Add behavior to filter resolved version ranges of an artifact
> -
>
> Key: MNG-6049
> URL: https://issues.apache.org/jira/browse/MNG-6049
> Project: Maven
> Issue Type: Improvement
> Components: core, Dependencies
>Reporter: Uwe Barthel
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.4.0
>
>
> The discussion on issue MNG-3092 shows the seriously needs of different kinds
> of version range resolving in Maven.
> This solution provides a hook for Maven extensions/plugins to change the list
> of resolved version range results as required.
> The {{DefaultVersionRangeResolver}} will be extended with a filter for
> version range results. A new interface {{VersionRangeResultFilter}} is added
> and a non-filtering {{DefaultVersionRangeResultFilter}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://issues.apache.org/jira/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15790227#comment-15790227 ] Michael Osipov commented on MNG-5708: - [~schulte77], can I reassign this issue to you? Due to master cleanup, I cannot really say which of your commit really fixed this issue. You should know best. It works now on current master. > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://issues.apache.org/jira/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen >Assignee: Michael Osipov > Fix For: 3.4.0 > > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6043) Colorization is disabled too late in batch mode
[ https://issues.apache.org/jira/browse/MNG-6043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15790222#comment-15790222 ] Michael Osipov commented on MNG-6043: - [~hboutemy], can we meld this into MNG-3507 during master cleanup? This issue could be ultimately removed from 3.4.0 because it is a SNAPSHOT regression. > Colorization is disabled too late in batch mode > --- > > Key: MNG-6043 > URL: https://issues.apache.org/jira/browse/MNG-6043 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Michael Osipov >Assignee: Michael Osipov > Fix For: 3.4.0 > > > See > [discussion|https://mail-archives.apache.org/mod_mbox/maven-dev/201606.mbox/%3Cc3b896b1-db25-9861-6fc0-a1e25afad710%40apache.org%3E]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15790023#comment-15790023
]
Hudson commented on MNG-6135:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1479 (See
[https://builds.apache.org/job/maven-3.x/1479/])
[MNG-6135] Maven plugins and core extensions are not dependencies, they
(schulte:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=859651acfc73af2a2afcd044306eaa0e5e5ac51a])
* (edit)
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.4.0
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6139) Addition of command line option 'legacy-dependency-management'.
[ https://issues.apache.org/jira/browse/MNG-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15789896#comment-15789896 ] Hudson commented on MNG-6139: - SUCCESS: Integrated in Jenkins build maven-3.x #1478 (See [https://builds.apache.org/job/maven-3.x/1478/]) [MNG-6139] Addition of command line option (schulte: [http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=ae9c2269e41c37bfa9e3aae711e827d6efbb6da7]) * (edit) maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java * (edit) maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java * (edit) maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java * (edit) maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuildingRequest.java * (edit) maven-core/src/main/java/org/apache/maven/RepositoryUtils.java * (edit) maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingRequest.java * (edit) maven-model-builder/src/main/java/org/apache/maven/model/building/FilterModelBuildingRequest.java * (edit) maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java * (edit) maven-model-builder/src/main/java/org/apache/maven/model/management/DefaultDependencyManagementInjector.java * (edit) maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/ArtifactDescriptorReaderDelegate.java * (edit) maven-core/src/main/java/org/apache/maven/project/ProjectBuildingRequest.java * (edit) maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java * (edit) maven-core/src/main/java/org/apache/maven/DefaultMaven.java * (edit) maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java > Addition of command line option 'legacy-dependency-management'. > --- > > Key: MNG-6139 > URL: https://issues.apache.org/jira/browse/MNG-6139 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Fix For: 3.4.0 > > > See the issues this issue is linked to. The command line option will simply > allow users to disable the bugfixes and get the former incorrect behaviour. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15789897#comment-15789897
]
Hudson commented on MNG-6135:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1478 (See
[https://builds.apache.org/job/maven-3.x/1478/])
[MNG-6135] Maven plugins and core extensions are not dependencies, they
(schulte:
[http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=6d68777c7ed6de2ad8fca6495b65b138bc1f7085])
* (edit)
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.4.0
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRESOLVER-9) DefaultDependencyCollector does not correctly handle dependency management.
[ https://issues.apache.org/jira/browse/MRESOLVER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15789889#comment-15789889 ] Hudson commented on MRESOLVER-9: SUCCESS: Integrated in Jenkins build maven-resolver #32 (See [https://builds.apache.org/job/maven-resolver/32/]) [MRESOLVER-9] DefaultDependencyCollector does not correctly handle (schulte: [http://git-wip-us.apache.org/repos/asf/?p=maven-resolver.git=commit=8cec8a788c59fd62a2c8486073412f5b3efd47a5]) * (edit) maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDependencyCollector.java > DefaultDependencyCollector does not correctly handle dependency management. > --- > > Key: MRESOLVER-9 > URL: https://issues.apache.org/jira/browse/MRESOLVER-9 > Project: Maven Resolver > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Fix For: Maven Artifact Resolver 1.2.0 > > > During dependency processing the 'DependencySelector' is called to decide if > a dependency is to be selected. The call to > 'DependencySelector.selectDependency( dependency )' is performed with the > unmanagement dependency but needs to be performed with the managed > dependency. With the fix applied, the result no longer contains dependencies > whose scope or optionality has been managed to not be part of the result > (correct behaviour). Without the fix applied, the result contains > dependencies with a managed scope or optionality not filtered out by the > 'DependencySelector' in use (incorrect behaviour). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6142) Support for additional coordinate to identify branches, editions, private builds, etc.
[ https://issues.apache.org/jira/browse/MNG-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15789605#comment-15789605 ] Robert Scholte commented on MNG-6142: - Since this is about extending the Maven coordinate, is seems related to the platform proposal from [~stephenc] ( see https://s.apache.org/pom5 ) > Support for additional coordinate to identify branches, editions, > private builds, etc. > > > Key: MNG-6142 > URL: https://issues.apache.org/jira/browse/MNG-6142 > Project: Maven > Issue Type: Wish > Components: core >Reporter: Markus Karg > > Often development teams work on parallel variants (a.k.a branches) ontop of > the same base version. Maven currently has no support for such scenarios, > which is problematic, as the following example describes: > A team of three developers just released version "1.0.0" of a library, which > is used by a larger application. The version was now set to 1.1.0-SNAPSHOT > for the master branch, and 1.0.1-SNAPSHOT for the Long-Term-Support branch. > Now in that team, programmer A started to work on feature A. In the same > team, programmer B started to work on feature B, which is concurrent (!) to > feature A. The team lead, programmer C, will later decide which (!) of both > features (A _or_ B) he wants to get in the final release 1.0.0. To try out > each of the features, he sets 1.1.0-SNAPSHOT as the dependency version in his > test application, to pull in the latest version of the library. The problem > is: How (by means of POM coordinates) to decide which proposed feature to > pull, A or B? > Similar scenarios often happen whilst the development of large systems. There > is no real solution here, as group, artifact, and version are the same for > all variants of the next development iteration, but only the _variant_ (a.k.a > "branch") of the artifact is different. > Why not simply reusing the existing coordinatest? > - groupdId: A variant is a different timeline within an artifact, so changing > the group is irrational. > - artifactId: Variants are, just like versions, changes _of_ artifacts, not > _different_ artifacts. Certainly, this is the most rational workaround. > - version: Existing tools depend on the major.minor.build-qualifier schema, > and rely upon semantic interpretation that qualifiers are _sorted_, so > feature A would become "older" than feature "B", which is completely weird, > as both have the same age. > - classifier: Classifiers are needed in addition to variants, for example > both A and B shall publish javadoc and sources, so this would break existing > features. > To sum up, using the existing coordinates implies major drawbacks or even > breaks existing features. Also, it is counterintuitive, as a variant implies > a separate timeline, neither a new group or artifact, nor a sequence on one > shared same timeline. > Hence, to improve actual current workflow scenarios, I'd like to propose the > addition of an optional coordinate. The interpretation should be > like this: > * is optional. > * , if existing, is added to the default file name between > and (e. g. mylib-featureB-1.0.0-SNAPSHOT-javadoc.jar). > * , if given, implies that a dependency with variant V of artifact > A, will can only be satisfied with exact that coordinates, neither with > artifact "A-V", nor with A having no version. On the other hand, just as with > versions, a dependency not having a variant, is happy with _any_ variant of > the same artifact, unless the variant is marked as "exactly this" using > brackets [V]. > Adding support using these rules would allow tool / plugin vendors to greatly > support dealing with branches, e. g. in git and subversion, by better > understand dependencies on features, differences between branches, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-6142) Support for additional coordinate to identify branches, editions, private builds, etc.
Markus Karg created MNG-6142: Summary: Support for additional coordinate to identify branches, editions, private builds, etc. Key: MNG-6142 URL: https://issues.apache.org/jira/browse/MNG-6142 Project: Maven Issue Type: Wish Components: core Reporter: Markus Karg Often development teams work on parallel variants (a.k.a branches) ontop of the same base version. Maven currently has no support for such scenarios, which is problematic, as the following example describes: A team of three developers just released version "1.0.0" of a library, which is used by a larger application. The version was now set to 1.1.0-SNAPSHOT for the master branch, and 1.0.1-SNAPSHOT for the Long-Term-Support branch. Now in that team, programmer A started to work on feature A. In the same team, programmer B started to work on feature B, which is concurrent (!) to feature A. The team lead, programmer C, will later decide which (!) of both features (A _or_ B) he wants to get in the final release 1.0.0. To try out each of the features, he sets 1.1.0-SNAPSHOT as the dependency version in his test application, to pull in the latest version of the library. The problem is: How (by means of POM coordinates) to decide which proposed feature to pull, A or B? Similar scenarios often happen whilst the development of large systems. There is no real solution here, as group, artifact, and version are the same for all variants of the next development iteration, but only the _variant_ (a.k.a "branch") of the artifact is different. Why not simply reusing the existing coordinatest? - groupdId: A variant is a different timeline within an artifact, so changing the group is irrational. - artifactId: Variants are, just like versions, changes _of_ artifacts, not _different_ artifacts. Certainly, this is the most rational workaround. - version: Existing tools depend on the major.minor.build-qualifier schema, and rely upon semantic interpretation that qualifiers are _sorted_, so feature A would become "older" than feature "B", which is completely weird, as both have the same age. - classifier: Classifiers are needed in addition to variants, for example both A and B shall publish javadoc and sources, so this would break existing features. To sum up, using the existing coordinates implies major drawbacks or even breaks existing features. Also, it is counterintuitive, as a variant implies a separate timeline, neither a new group or artifact, nor a sequence on one shared same timeline. Hence, to improve actual current workflow scenarios, I'd like to propose the addition of an optional coordinate. The interpretation should be like this: * is optional. * , if existing, is added to the default file name between and (e. g. mylib-featureB-1.0.0-SNAPSHOT-javadoc.jar). * , if given, implies that a dependency with variant V of artifact A, will can only be satisfied with exact that coordinates, neither with artifact "A-V", nor with A having no version. On the other hand, just as with versions, a dependency not having a variant, is happy with _any_ variant of the same artifact, unless the variant is marked as "exactly this" using brackets [V]. Adding support using these rules would allow tool / plugin vendors to greatly support dealing with branches, e. g. in git and subversion, by better understand dependencies on features, differences between branches, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1322) Surefire and Failsafe should dump critical errors in dump file and console
[ https://issues.apache.org/jira/browse/SUREFIRE-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15789291#comment-15789291 ] Hudson commented on SUREFIRE-1322: -- SUCCESS: Integrated in Jenkins build maven-surefire #1663 (See [https://builds.apache.org/job/maven-surefire/1663/]) [SUREFIRE-1322] Surefire and Failsafe should dump critical errors in (tibor17: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=66bc4c0839ba11af7a8915930f76abf3cd58ee53]) * (edit) surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire735ForkFailWithRedirectConsoleOutputIT.java * (edit) surefire-api/src/main/java/org/apache/maven/surefire/util/internal/DumpFileUtils.java > Surefire and Failsafe should dump critical errors in dump file and console > -- > > Key: SUREFIRE-1322 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1322 > Project: Maven Surefire > Issue Type: Bug >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > Both plugins, Surefire and Failsafe, dump stack trace and error messages and > lost commands in dump file or in console: > [date]-jvmRun[N].dump, > [date].dumpstream and > [date]-jvmRun[N].dumpstream > IN previous versions the plugins threw exceptions like, > MojoExecutionException and MojoFailureException, but the user could not see > any message of error which killed the plugin internally. > Since now this is possible and the user can see the dump files in target > target/failsafe-reports and target/surefire-reports. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNGSITE-297) typo in properties example
don fong created MNGSITE-297:
Summary: typo in properties example
Key: MNGSITE-297
URL: https://issues.apache.org/jira/browse/MNGSITE-297
Project: Maven Project Web Site
Issue Type: Bug
Reporter: don fong
Priority: Trivial
on this page,
https://maven.apache.org/pom.html#Properties
in item 5, the following text appears:
{code}
value
{code}
"properies" should be "properties".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
