Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-3092

Resolution of version ranges with non-snapshot bounds can resolve to a snapshot version

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.x / Backlog
    • Component/s: Dependencies
    • Labels:
      None
    • Flags:
      Patch

      Description

      Contrary to the 2.0 design docs:

      "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary."
      – from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification

      The following is equates to true:

      VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new DefaultArtifactVersion( "1.1-SNAPSHOT" ) )

      The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

      1. MNG-3092.patch
        2 kB
        Kunalkumar Somani
      2. MNG-3092.patch
        4 kB
        Mark Hobson

        Issue Links

          Activity

          Hide
          batra.tanuj@gmail.com tanuj batra added a comment -

          Any update on this guys? I'm facing the same issue. Need help on this.

          Show
          batra.tanuj@gmail.com tanuj batra added a comment - Any update on this guys? I'm facing the same issue. Need help on this.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven-integration-testing/pull/14

          Relabelling commit from MNG-3092 to MNG-6049.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 Relabelling commit from MNG-3092 to MNG-6049 .
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven/pull/70

          Relabelling commit from MNG-3092 to MNG-6049.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven/pull/70 Relabelling commit from MNG-3092 to MNG-6049 .
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the issue:

          https://github.com/apache/maven/pull/70

          @barthel Perfect, already assigned. Just waiting for an updated PR and all will be merged.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the issue: https://github.com/apache/maven/pull/70 @barthel Perfect, already assigned. Just waiting for an updated PR and all will be merged.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67946906

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          + {
          + super( "[3.4.0-SNAPSHOT,)" );
          — End diff –

          Am 2016-06-21 um 22:28 schrieb barthel:
          >> + * <groupId>org.apache.maven.its.mng3092</groupId>
          >> + * <artifactId>a</artifactId>
          >> + * <version>[1.0,2.0)</version>
          >> + * </dependency>
          >> + * </dependencies>
          >> + * </pre>
          >> + *
          >> + * @author Benjamin Bentmann
          >> + */
          >> +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          >> + extends AbstractMavenIntegrationTestCase
          >> +{
          >> +
          >> + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          >> + {
          >> + super( "[3.4.0-SNAPSHOT,)" );
          >
          > So this test will not execute before 3.4.0 release. I thought I change that close after the 3.4.0 release?
          > If this is not a problem, I'll change this.

          It will, see:
          mng3099SettingsProfilesWithNoPom(it).................OK (1.2 s)
          mng3092VersionRangeResultFilterExtension(Default)....OK (1.4 s)

          Try it yourself. The -SNAPSHOT is ignored here because we mostly test
          snapshots.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67946906 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); — End diff – Am 2016-06-21 um 22:28 schrieb barthel: >> + * <groupId>org.apache.maven.its.mng3092</groupId> >> + * <artifactId>a</artifactId> >> + * <version>[1.0,2.0)</version> >> + * </dependency> >> + * </dependencies> >> + * </pre> >> + * >> + * @author Benjamin Bentmann >> + */ >> +public class MavenITmng3092VersionRangeResultFilterExtensionTest >> + extends AbstractMavenIntegrationTestCase >> +{ >> + >> + public MavenITmng3092VersionRangeResultFilterExtensionTest() >> + { >> + super( "[3.4.0-SNAPSHOT,)" ); > > So this test will not execute before 3.4.0 release. I thought I change that close after the 3.4.0 release? > If this is not a problem, I'll change this. It will, see: mng3099SettingsProfilesWithNoPom(it).................OK (1.2 s) mng3092VersionRangeResultFilterExtension(Default)....OK (1.4 s) Try it yourself. The -SNAPSHOT is ignored here because we mostly test snapshots.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven-integration-testing/pull/14

          @michael-o Done.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o Done.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67945228

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          + {
          + super( "[3.4.0-SNAPSHOT,)" );
          — End diff –

          So this test will not execute before 3.4.0 release. I thought I change that close after the 3.4.0 release?
          If this is not a problem, I'll change this.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67945228 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); — End diff – So this test will not execute before 3.4.0 release. I thought I change that close after the 3.4.0 release? If this is not a problem, I'll change this.
          Hide
          barthel Uwe Barthel added a comment -

          On part for a solution of this item.

          Show
          barthel Uwe Barthel added a comment - On part for a solution of this item.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven/pull/70

          @michael-o Please take a look at https://issues.apache.org/jira/browse/MNG-6049

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven/pull/70 @michael-o Please take a look at https://issues.apache.org/jira/browse/MNG-6049
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67942011

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          +

          { + super( "[3.4.0-SNAPSHOT,)" ); + }

          +
          + /**
          + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension.
          + */
          + public void testDefault()
          + throws Exception
          +

          { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + }

          +
          + /**
          + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot
          + * version will be used.
          + */
          + public void testVersionRangeResultFilterExtesionSystemProperties()
          — End diff –

          `Extesion` => `Extension`.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67942011 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); + } + + /** + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension. + */ + public void testDefault() + throws Exception + { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + } + + /** + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot + * version will be used. + */ + public void testVersionRangeResultFilterExtesionSystemProperties() — End diff – `Extesion` => `Extension`.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67941526

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          + {
          + super( "[3.4.0-SNAPSHOT,)" );
          — End diff –

          Again, make it 3.4.0.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67941526 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); — End diff – Again, make it 3.4.0.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the issue:

          https://github.com/apache/maven/pull/70

          @barthel ITs pass. I am now willing to merge both PRs. Just waiting for your comment on the previous message.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the issue: https://github.com/apache/maven/pull/70 @barthel ITs pass. I am now willing to merge both PRs. Just waiting for your comment on the previous message.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the issue:

          https://github.com/apache/maven/pull/70

          I am already working on your PRs. I think, committing this under MNG-3092 is wrong and will explain why. I we cannot close the issue, people won't see this in the changelog. They won't simply know that a simple extension can solve their problem. Can you create a separate issue for your solution and make MNG-3092 depend on your issue. People would then know that they can solve it by adding an extension. I will change the PR content according to the new issue id.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the issue: https://github.com/apache/maven/pull/70 I am already working on your PRs. I think, committing this under MNG-3092 is wrong and will explain why. I we cannot close the issue, people won't see this in the changelog. They won't simply know that a simple extension can solve their problem. Can you create a separate issue for your solution and make MNG-3092 depend on your issue. People would then know that they can solve it by adding an extension. I will change the PR content according to the new issue id.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven-integration-testing/pull/14

          @michael-o Done.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o Done.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven/pull/70

          @michael-o Done.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven/pull/70 @michael-o Done.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67776474

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,73 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          + </parent>
          +
          + <groupId>org.apache.maven.its.extensions</groupId>
          + <artifactId>versionrange-resultfilter-extension</artifactId>
          + <packaging>jar</packaging>
          +
          + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name>
          + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description>
          +
          + <properties>
          + <maven.version>3.4.0-SNAPSHOT</maven.version>
          + </properties>
          +
          + <dependencies>
          + <dependency>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven-core</artifactId>
          + <scope>provided</scope>
          + </dependency>
          + <dependency>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven-aether-provider</artifactId>
          — End diff –

          Already added.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67776474 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,73 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> + </parent> + + <groupId>org.apache.maven.its.extensions</groupId> + <artifactId>versionrange-resultfilter-extension</artifactId> + <packaging>jar</packaging> + + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name> + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description> + + <properties> + <maven.version>3.4.0-SNAPSHOT</maven.version> + </properties> + + <dependencies> + <dependency> + <groupId>org.apache.maven</groupId> + <artifactId>maven-core</artifactId> + <scope>provided</scope> + </dependency> + <dependency> + <groupId>org.apache.maven</groupId> + <artifactId>maven-aether-provider</artifactId> — End diff – Already added.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67776182

          — Diff: core-it-suite/src/test/resources/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom —
          @@ -23,8 +23,8 @@ under the License.
          <modelVersion>4.0.0</modelVersion>

          <groupId>org.apache.maven.its.mng3092</groupId>

          • <artifactId>b</artifactId>
          • <version>1.0-SNAPSHOT</version>
            + <artifactId>a</artifactId>
            + <version>2.0</version>
              • End diff –

          The ```SNAPSHOT``` is not required anymore and was replaced.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67776182 — Diff: core-it-suite/src/test/resources/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom — @@ -23,8 +23,8 @@ under the License. <modelVersion>4.0.0</modelVersion> <groupId>org.apache.maven.its.mng3092</groupId> <artifactId>b</artifactId> <version>1.0-SNAPSHOT</version> + <artifactId>a</artifactId> + <version>2.0</version> End diff – The ```SNAPSHOT``` is not required anymore and was replaced.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven-integration-testing/pull/14

          @michael-o Missing JARs added and changes included.

          Integration tests run successfully:
          ```
          […]
          -------------------------------------------------------
          T E S T S
          -------------------------------------------------------
          Running integration tests for Maven 3.4.0-SNAPSHOT
          using Maven executable: /Users/barthel/tmp/z-maven-with-pr-70/maven/apache-maven/target/apache-maven-3.4.0-SNAPSHOT/bin/mvn
          Running org.apache.maven.it.IntegrationTestSuite
          Running integration tests for Maven 3.4.0-SNAPSHOT
          using Maven executable: /Users/barthel/tmp/z-maven-with-pr-70/maven/apache-maven/target/apache-maven-3.4.0-SNAPSHOT/bin/mvn
          […]
          mng3092VersionRangeResultFilterExtension(Default)....OK (0.4 s)
          mng3092VersionRangeResultFilterExtension(VersionRangeResultFilterExtesionSystemProperties)OK (1.6 s)
          […]
          [INFO] Maven ITs .......................................... SUCCESS [08:43 min]
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD SUCCESS
          [INFO] ------------------------------------------------------------------------
          ```
          Checked with my adapted Maven PR validator:
          https://github.com/barthel/maven-utils/blob/master/maven-pr-validator.sh 70 14(https://github.com/barthel/maven-utils/blob/master/maven-pr-validator.sh)

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o Missing JARs added and changes included. Integration tests run successfully: ``` […] ------------------------------------------------------- T E S T S ------------------------------------------------------- Running integration tests for Maven 3.4.0-SNAPSHOT using Maven executable: /Users/barthel/tmp/z-maven-with-pr-70/maven/apache-maven/target/apache-maven-3.4.0-SNAPSHOT/bin/mvn Running org.apache.maven.it.IntegrationTestSuite Running integration tests for Maven 3.4.0-SNAPSHOT using Maven executable: /Users/barthel/tmp/z-maven-with-pr-70/maven/apache-maven/target/apache-maven-3.4.0-SNAPSHOT/bin/mvn […] mng3092VersionRangeResultFilterExtension(Default)....OK (0.4 s) mng3092VersionRangeResultFilterExtension(VersionRangeResultFilterExtesionSystemProperties)OK (1.6 s) […] [INFO] Maven ITs .......................................... SUCCESS [08:43 min] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ ``` Checked with my adapted Maven PR validator: https://github.com/barthel/maven-utils/blob/master/maven-pr-validator.sh 70 14 ( https://github.com/barthel/maven-utils/blob/master/maven-pr-validator.sh )
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven/pull/70

          @michael-o I'm working on integration tests right now.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven/pull/70 @michael-o I'm working on integration tests right now.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the issue:

          https://github.com/apache/maven/pull/70

          @barthel Very good. Did you have a chance to work on the other issues I have written?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the issue: https://github.com/apache/maven/pull/70 @barthel Very good. Did you have a chance to work on the other issues I have written?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven/pull/70

          @michael-o Indent changes reverted.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven/pull/70 @michael-o Indent changes reverted.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234444

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -290,7 +312,7 @@ private Versioning readVersions( RepositorySystemSession session, RequestTrace t
          }

          private void invalidMetadata( RepositorySystemSession session, RequestTrace trace, Metadata metadata,

          • ArtifactRepository repository, Exception exception )
            + ArtifactRepository repository, Exception exception )
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234444 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -290,7 +312,7 @@ private Versioning readVersions( RepositorySystemSession session, RequestTrace t } private void invalidMetadata( RepositorySystemSession session, RequestTrace trace, Metadata metadata, ArtifactRepository repository, Exception exception ) + ArtifactRepository repository, Exception exception ) End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234434

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -255,7 +277,7 @@ public VersionRangeResult resolveVersionRange( RepositorySystemSession session,
          }

          private Versioning readVersions( RepositorySystemSession session, RequestTrace trace, Metadata metadata,

          • ArtifactRepository repository, VersionRangeResult result )
            + ArtifactRepository repository, VersionRangeResult result )
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234434 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -255,7 +277,7 @@ public VersionRangeResult resolveVersionRange( RepositorySystemSession session, } private Versioning readVersions( RepositorySystemSession session, RequestTrace trace, Metadata metadata, ArtifactRepository repository, VersionRangeResult result ) + ArtifactRepository repository, VersionRangeResult result ) End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234423

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -193,19 +216,18 @@ public VersionRangeResult resolveVersionRange( RepositorySystemSession session,
          result.setVersions( versions );
          }

          • return result;
            + return versionRangeResultFilter.filterVersionRangeResult( result );
            }

          private Map<String, ArtifactRepository> getVersions( RepositorySystemSession session, VersionRangeResult result,

          • VersionRangeRequest request )
            + VersionRangeRequest request )
            {
            RequestTrace trace = RequestTrace.newChild( request.getTrace(), request );

          Map<String, ArtifactRepository> versionIndex = new HashMap<>();

          • Metadata metadata =
          • new DefaultMetadata( request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
          • MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );
            + Metadata metadata = new DefaultMetadata( request.getArtifact().getGroupId(),
            + request.getArtifact().getArtifactId(), MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234423 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -193,19 +216,18 @@ public VersionRangeResult resolveVersionRange( RepositorySystemSession session, result.setVersions( versions ); } return result; + return versionRangeResultFilter.filterVersionRangeResult( result ); } private Map<String, ArtifactRepository> getVersions( RepositorySystemSession session, VersionRangeResult result, VersionRangeRequest request ) + VersionRangeRequest request ) { RequestTrace trace = RequestTrace.newChild( request.getTrace(), request ); Map<String, ArtifactRepository> versionIndex = new HashMap<>(); Metadata metadata = new DefaultMetadata( request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(), MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT ); + Metadata metadata = new DefaultMetadata( request.getArtifact().getGroupId(), + request.getArtifact().getArtifactId(), MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT ); End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234380

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -193,19 +216,18 @@ public VersionRangeResult resolveVersionRange( RepositorySystemSession session,
          result.setVersions( versions );
          }

          • return result;
            + return versionRangeResultFilter.filterVersionRangeResult( result );
            }

          private Map<String, ArtifactRepository> getVersions( RepositorySystemSession session, VersionRangeResult result,

          • VersionRangeRequest request )
            + VersionRangeRequest request )
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234380 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -193,19 +216,18 @@ public VersionRangeResult resolveVersionRange( RepositorySystemSession session, result.setVersions( versions ); } return result; + return versionRangeResultFilter.filterVersionRangeResult( result ); } private Map<String, ArtifactRepository> getVersions( RepositorySystemSession session, VersionRangeResult result, VersionRangeRequest request ) + VersionRangeRequest request ) End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234360

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -136,15 +152,22 @@ public DefaultVersionRangeResolver setSyncContextFactory( SyncContextFactory syn
          }

          public DefaultVersionRangeResolver setRepositoryEventDispatcher(

          • RepositoryEventDispatcher repositoryEventDispatcher )
            + RepositoryEventDispatcher repositoryEventDispatcher ) { this.repositoryEventDispatcher = Validate.notNull( repositoryEventDispatcher, - "repositoryEventDispatcher cannot be null" ); + "repositoryEventDispatcher cannot be null" ); + return this; + }

            +
            + public DefaultVersionRangeResolver setVersionRangeResultFilter( VersionRangeResultFilter versionRangeResultFilter )
            +

            { + this.versionRangeResultFilter = Validate.notNull( versionRangeResultFilter, + "versionRangeResultFilter cannot be null" ); return this; }

          public VersionRangeResult resolveVersionRange( RepositorySystemSession session, VersionRangeRequest request )

          • throws VersionRangeResolutionException
            + throws VersionRangeResolutionException
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234360 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -136,15 +152,22 @@ public DefaultVersionRangeResolver setSyncContextFactory( SyncContextFactory syn } public DefaultVersionRangeResolver setRepositoryEventDispatcher( RepositoryEventDispatcher repositoryEventDispatcher ) + RepositoryEventDispatcher repositoryEventDispatcher ) { this.repositoryEventDispatcher = Validate.notNull( repositoryEventDispatcher, - "repositoryEventDispatcher cannot be null" ); + "repositoryEventDispatcher cannot be null" ); + return this; + } + + public DefaultVersionRangeResolver setVersionRangeResultFilter( VersionRangeResultFilter versionRangeResultFilter ) + { + this.versionRangeResultFilter = Validate.notNull( versionRangeResultFilter, + "versionRangeResultFilter cannot be null" ); return this; } public VersionRangeResult resolveVersionRange( RepositorySystemSession session, VersionRangeRequest request ) throws VersionRangeResolutionException + throws VersionRangeResolutionException End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234340

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -136,15 +152,22 @@ public DefaultVersionRangeResolver setSyncContextFactory( SyncContextFactory syn
          }

          public DefaultVersionRangeResolver setRepositoryEventDispatcher(

          • RepositoryEventDispatcher repositoryEventDispatcher )
            + RepositoryEventDispatcher repositoryEventDispatcher )
            {
            this.repositoryEventDispatcher = Validate.notNull( repositoryEventDispatcher,
          • "repositoryEventDispatcher cannot be null" );
            + "repositoryEventDispatcher cannot be null" );
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234340 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -136,15 +152,22 @@ public DefaultVersionRangeResolver setSyncContextFactory( SyncContextFactory syn } public DefaultVersionRangeResolver setRepositoryEventDispatcher( RepositoryEventDispatcher repositoryEventDispatcher ) + RepositoryEventDispatcher repositoryEventDispatcher ) { this.repositoryEventDispatcher = Validate.notNull( repositoryEventDispatcher, "repositoryEventDispatcher cannot be null" ); + "repositoryEventDispatcher cannot be null" ); End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234319

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -136,15 +152,22 @@ public DefaultVersionRangeResolver setSyncContextFactory( SyncContextFactory syn
          }

          public DefaultVersionRangeResolver setRepositoryEventDispatcher(

          • RepositoryEventDispatcher repositoryEventDispatcher )
            + RepositoryEventDispatcher repositoryEventDispatcher )
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234319 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -136,15 +152,22 @@ public DefaultVersionRangeResolver setSyncContextFactory( SyncContextFactory syn } public DefaultVersionRangeResolver setRepositoryEventDispatcher( RepositoryEventDispatcher repositoryEventDispatcher ) + RepositoryEventDispatcher repositoryEventDispatcher ) End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234272

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -88,19 +91,27 @@
          @Requirement
          private RepositoryEventDispatcher repositoryEventDispatcher;

          + @Requirement( role = VersionRangeResultFilter.class, optional = true )
          + private VersionRangeResultFilter versionRangeResultFilter = new DefaultVersionRangeResultFilter();
          +
          public DefaultVersionRangeResolver()

          { // enable default constructor }

          @Inject
          DefaultVersionRangeResolver( MetadataResolver metadataResolver, SyncContextFactory syncContextFactory,

          • RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory )
            + RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory,
            + @Nullable VersionRangeResultFilter versionRangeResultFilter )
              • End diff –

          Indent as above.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234272 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -88,19 +91,27 @@ @Requirement private RepositoryEventDispatcher repositoryEventDispatcher; + @Requirement( role = VersionRangeResultFilter.class, optional = true ) + private VersionRangeResultFilter versionRangeResultFilter = new DefaultVersionRangeResultFilter(); + public DefaultVersionRangeResolver() { // enable default constructor } @Inject DefaultVersionRangeResolver( MetadataResolver metadataResolver, SyncContextFactory syncContextFactory, RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory ) + RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory, + @Nullable VersionRangeResultFilter versionRangeResultFilter ) End diff – Indent as above.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234247

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -88,19 +91,27 @@
          @Requirement
          private RepositoryEventDispatcher repositoryEventDispatcher;

          + @Requirement( role = VersionRangeResultFilter.class, optional = true )
          + private VersionRangeResultFilter versionRangeResultFilter = new DefaultVersionRangeResultFilter();
          +
          public DefaultVersionRangeResolver()

          { // enable default constructor }

          @Inject
          DefaultVersionRangeResolver( MetadataResolver metadataResolver, SyncContextFactory syncContextFactory,

          • RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory )
            + RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory,
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234247 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -88,19 +91,27 @@ @Requirement private RepositoryEventDispatcher repositoryEventDispatcher; + @Requirement( role = VersionRangeResultFilter.class, optional = true ) + private VersionRangeResultFilter versionRangeResultFilter = new DefaultVersionRangeResultFilter(); + public DefaultVersionRangeResolver() { // enable default constructor } @Inject DefaultVersionRangeResolver( MetadataResolver metadataResolver, SyncContextFactory syncContextFactory, RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory ) + RepositoryEventDispatcher repositoryEventDispatcher, LoggerFactory loggerFactory, End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r67234207

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -63,14 +64,16 @@
          import java.util.HashMap;
          import java.util.List;
          import java.util.Map;
          +import javax.inject.Singleton;

          /**

          • @author Benjamin Bentmann
            */
            @Named
            -@Component( role = VersionRangeResolver.class )
            +@Singleton
            +@Component( role = VersionRangeResolver.class, hint = "default" )
            public class DefaultVersionRangeResolver
          • implements VersionRangeResolver, Service
            + implements VersionRangeResolver, Service
              • End diff –

          Unrelated change, revert!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r67234207 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -63,14 +64,16 @@ import java.util.HashMap; import java.util.List; import java.util.Map; +import javax.inject.Singleton; /** @author Benjamin Bentmann */ @Named -@Component( role = VersionRangeResolver.class ) +@Singleton +@Component( role = VersionRangeResolver.class, hint = "default" ) public class DefaultVersionRangeResolver implements VersionRangeResolver, Service + implements VersionRangeResolver, Service End diff – Unrelated change, revert!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233942

          — Diff: core-it-suite/src/test/resources/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom —
          @@ -23,8 +23,8 @@ under the License.
          <modelVersion>4.0.0</modelVersion>

          <groupId>org.apache.maven.its.mng3092</groupId>

          • <artifactId>b</artifactId>
          • <version>1.0-SNAPSHOT</version>
            + <artifactId>a</artifactId>
            + <version>2.0</version>
              • End diff –

          The `SNAPSHOT` got lost!

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233942 — Diff: core-it-suite/src/test/resources/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom — @@ -23,8 +23,8 @@ under the License. <modelVersion>4.0.0</modelVersion> <groupId>org.apache.maven.its.mng3092</groupId> <artifactId>b</artifactId> <version>1.0-SNAPSHOT</version> + <artifactId>a</artifactId> + <version>2.0</version> End diff – The `SNAPSHOT` got lost!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233825

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java —
          @@ -0,0 +1,76 @@
          +package org.apache.maven.its.extensions;
          +
          +/*
          + * 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 javax.inject.Named;
          +import java.util.Iterator;
          +import javax.inject.Inject;
          +import org.apache.maven.repository.internal.VersionRangeResultFilter;
          +import org.eclipse.aether.resolution.VersionRangeResolutionException;
          +import org.eclipse.aether.resolution.VersionRangeResult;
          +import org.eclipse.aether.spi.log.Logger;
          +import org.eclipse.aether.spi.log.LoggerFactory;
          +import org.eclipse.aether.spi.log.NullLoggerFactory;
          +import org.eclipse.aether.version.Version;
          +import org.eclipse.sisu.Nullable;
          +
          +/**
          + * Example implementation for use in ITs.
          + * <p>
          + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p>
          + * <p>
          + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>
          + * and only works with Maven >= 3.4.0</p>
          + */
          +@Named
          +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter
          +{
          +
          + private final Logger logger;
          +
          + @Inject
          + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory )
          +

          { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + }

          +
          + @Override
          + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult )
          + throws VersionRangeResolutionException
          + {
          + if ( !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) )
          +

          { + return versionRangeResult; + }

          + this.logger.debug( "[MAVEN-IT-CORE-MNG-3092] Version range result instance: " + versionRangeResult );
          + for ( Iterator<Version> it = versionRangeResult.getVersions().iterator(); it.hasNext(); )
          + {
          + // XXX: better way to identify a SNAPSHOT version
          + if ( String.valueOf( it.next() ).endsWith( "SNAPSHOT" ) )
          + {
          + this.logger.debug( "[MAVEN-IT-CORE-MNG-3092] Remove version: " + it.toString() );
          — End diff –

          use `version` here

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233825 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java — @@ -0,0 +1,76 @@ +package org.apache.maven.its.extensions; + +/* + * 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 javax.inject.Named; +import java.util.Iterator; +import javax.inject.Inject; +import org.apache.maven.repository.internal.VersionRangeResultFilter; +import org.eclipse.aether.resolution.VersionRangeResolutionException; +import org.eclipse.aether.resolution.VersionRangeResult; +import org.eclipse.aether.spi.log.Logger; +import org.eclipse.aether.spi.log.LoggerFactory; +import org.eclipse.aether.spi.log.NullLoggerFactory; +import org.eclipse.aether.version.Version; +import org.eclipse.sisu.Nullable; + +/** + * Example implementation for use in ITs. + * <p> + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p> + * <p> + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a> + * and only works with Maven >= 3.4.0</p> + */ +@Named +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter +{ + + private final Logger logger; + + @Inject + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory ) + { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + } + + @Override + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult ) + throws VersionRangeResolutionException + { + if ( !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) ) + { + return versionRangeResult; + } + this.logger.debug( " [MAVEN-IT-CORE-MNG-3092] Version range result instance: " + versionRangeResult ); + for ( Iterator<Version> it = versionRangeResult.getVersions().iterator(); it.hasNext(); ) + { + // XXX: better way to identify a SNAPSHOT version + if ( String.valueOf( it.next() ).endsWith( "SNAPSHOT" ) ) + { + this.logger.debug( " [MAVEN-IT-CORE-MNG-3092] Remove version: " + it.toString() ); — End diff – use `version` here
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233789

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java —
          @@ -0,0 +1,76 @@
          +package org.apache.maven.its.extensions;
          +
          +/*
          + * 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 javax.inject.Named;
          +import java.util.Iterator;
          +import javax.inject.Inject;
          +import org.apache.maven.repository.internal.VersionRangeResultFilter;
          +import org.eclipse.aether.resolution.VersionRangeResolutionException;
          +import org.eclipse.aether.resolution.VersionRangeResult;
          +import org.eclipse.aether.spi.log.Logger;
          +import org.eclipse.aether.spi.log.LoggerFactory;
          +import org.eclipse.aether.spi.log.NullLoggerFactory;
          +import org.eclipse.aether.version.Version;
          +import org.eclipse.sisu.Nullable;
          +
          +/**
          + * Example implementation for use in ITs.
          + * <p>
          + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p>
          + * <p>
          + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>
          + * and only works with Maven >= 3.4.0</p>
          + */
          +@Named
          +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter
          +{
          +
          + private final Logger logger;
          +
          + @Inject
          + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory )
          +

          { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + }

          +
          + @Override
          + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult )
          + throws VersionRangeResolutionException
          + {
          + if ( !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) )
          +

          { + return versionRangeResult; + }

          + this.logger.debug( "[MAVEN-IT-CORE-MNG-3092] Version range result instance: " + versionRangeResult );
          + for ( Iterator<Version> it = versionRangeResult.getVersions().iterator(); it.hasNext(); )
          + {
          + // XXX: better way to identify a SNAPSHOT version
          + if ( String.valueOf( it.next() ).endsWith( "SNAPSHOT" ) )
          — End diff –

          Move `it.next()` to `Version version = it.next()`

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233789 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java — @@ -0,0 +1,76 @@ +package org.apache.maven.its.extensions; + +/* + * 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 javax.inject.Named; +import java.util.Iterator; +import javax.inject.Inject; +import org.apache.maven.repository.internal.VersionRangeResultFilter; +import org.eclipse.aether.resolution.VersionRangeResolutionException; +import org.eclipse.aether.resolution.VersionRangeResult; +import org.eclipse.aether.spi.log.Logger; +import org.eclipse.aether.spi.log.LoggerFactory; +import org.eclipse.aether.spi.log.NullLoggerFactory; +import org.eclipse.aether.version.Version; +import org.eclipse.sisu.Nullable; + +/** + * Example implementation for use in ITs. + * <p> + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p> + * <p> + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a> + * and only works with Maven >= 3.4.0</p> + */ +@Named +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter +{ + + private final Logger logger; + + @Inject + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory ) + { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + } + + @Override + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult ) + throws VersionRangeResolutionException + { + if ( !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) ) + { + return versionRangeResult; + } + this.logger.debug( " [MAVEN-IT-CORE-MNG-3092] Version range result instance: " + versionRangeResult ); + for ( Iterator<Version> it = versionRangeResult.getVersions().iterator(); it.hasNext(); ) + { + // XXX: better way to identify a SNAPSHOT version + if ( String.valueOf( it.next() ).endsWith( "SNAPSHOT" ) ) — End diff – Move `it.next()` to `Version version = it.next()`
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233439

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,73 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          + </parent>
          +
          + <groupId>org.apache.maven.its.extensions</groupId>
          + <artifactId>versionrange-resultfilter-extension</artifactId>
          + <packaging>jar</packaging>
          +
          + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name>
          + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description>
          +
          + <properties>
          + <maven.version>3.4.0-SNAPSHOT</maven.version>
          + </properties>
          +
          + <dependencies>
          + <dependency>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven-core</artifactId>
          + <scope>provided</scope>
          + </dependency>
          + <dependency>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven-aether-provider</artifactId>
          — End diff –

          Add `<version>$

          {maven.version}

          </version>`

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233439 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,73 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> + </parent> + + <groupId>org.apache.maven.its.extensions</groupId> + <artifactId>versionrange-resultfilter-extension</artifactId> + <packaging>jar</packaging> + + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name> + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description> + + <properties> + <maven.version>3.4.0-SNAPSHOT</maven.version> + </properties> + + <dependencies> + <dependency> + <groupId>org.apache.maven</groupId> + <artifactId>maven-core</artifactId> + <scope>provided</scope> + </dependency> + <dependency> + <groupId>org.apache.maven</groupId> + <artifactId>maven-aether-provider</artifactId> — End diff – Add `<version>$ {maven.version} </version>`
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233418

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,73 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          + </parent>
          +
          + <groupId>org.apache.maven.its.extensions</groupId>
          + <artifactId>versionrange-resultfilter-extension</artifactId>
          + <packaging>jar</packaging>
          +
          + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name>
          + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description>
          +
          + <properties>
          + <maven.version>3.4.0-SNAPSHOT</maven.version>
          + </properties>
          +
          + <dependencies>
          + <dependency>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven-core</artifactId>
          + <scope>provided</scope>
          — End diff –

          Add `<version>$

          {maven.version}

          </version>`

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233418 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,73 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> + </parent> + + <groupId>org.apache.maven.its.extensions</groupId> + <artifactId>versionrange-resultfilter-extension</artifactId> + <packaging>jar</packaging> + + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name> + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description> + + <properties> + <maven.version>3.4.0-SNAPSHOT</maven.version> + </properties> + + <dependencies> + <dependency> + <groupId>org.apache.maven</groupId> + <artifactId>maven-core</artifactId> + <scope>provided</scope> — End diff – Add `<version>$ {maven.version} </version>`
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233328

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,73 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          + </parent>
          +
          + <groupId>org.apache.maven.its.extensions</groupId>
          + <artifactId>versionrange-resultfilter-extension</artifactId>
          + <packaging>jar</packaging>
          +
          + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name>
          + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description>
          +
          + <properties>
          + <maven.version>3.4.0-SNAPSHOT</maven.version>
          + </properties>
          — End diff –

          Remove this block completely.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233328 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,73 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> + </parent> + + <groupId>org.apache.maven.its.extensions</groupId> + <artifactId>versionrange-resultfilter-extension</artifactId> + <packaging>jar</packaging> + + <name>Maven IT Plugin :: MNG-3092 :: VersionRangeResultFilter extension</name> + <description>This extension provides an very easy VersionRangeResultFilter for use in Maven ITs.</description> + + <properties> + <maven.version>3.4.0-SNAPSHOT</maven.version> + </properties> — End diff – Remove this block completely.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233290

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,73 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          + </parent>
          +
          + <groupId>org.apache.maven.its.extensions</groupId>
          + <artifactId>versionrange-resultfilter-extension</artifactId>
          — End diff –

          Add version `1.0-SNAPSHOT`.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233290 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,73 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> + </parent> + + <groupId>org.apache.maven.its.extensions</groupId> + <artifactId>versionrange-resultfilter-extension</artifactId> — End diff – Add version `1.0-SNAPSHOT`.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233223

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,74 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          — End diff –

          Remove the parent completely.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233223 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> — End diff – Remove the parent completely.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233139

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          +

          { + super( "[3.4.0-SNAPSHOT,)" ); + }

          +
          + /**
          + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension.
          + */
          + public void testDefault()
          + throws Exception
          +

          { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + }

          +
          + /**
          + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot
          + * version will be used.
          + */
          + public void testVersionRangeResultFilterExtesionSystemproperties()
          + throws Exception
          + {
          + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" );
          + File extensionDir = new File( testDir, "filter-extension" );
          +
          + final Map<String, String> filterProperties = new HashMap<>();
          + filterProperties.put( "@baseurl@", "file://" + testDir.getAbsolutePath() );
          +
          + Verifier verifier;
          + verifier = newVerifier( testDir.getAbsolutePath() );
          + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", filterProperties );
          + verifier.filterFile( "extension.xml", ".mvn/extension.xml", "UTF-8", filterProperties );
          +
          + // install the test extension
          + verifier = newVerifier( extensionDir.getAbsolutePath(), "remote" );
          + verifier.filterFile( "pom.xml", "pom.xml", "UTF-8", filterProperties );
          + verifier.addCliOption( "-f" );
          + verifier.addCliOption( extensionDir.getAbsolutePath() + "/pom.xml" );
          + verifier.addCliOption( "-Drat.skip=true" );
          + verifier.setLogFileName( "install-extension.log" );
          +
          + verifier.executeGoal( "install" );
          + verifier.resetStreams();
          + verifier.verifyErrorFreeLog();
          +
          + // validate the test project
          + verifier = newVerifier( testDir.getAbsolutePath() );
          + verifier.setAutoclean( true );
          + verifier.setDebug( true );
          + verifier.setMavenDebug( true );
          + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", filterProperties );
          +
          + verifier.addCliOption( "--settings" );
          + verifier.addCliOption( testDir.getAbsolutePath() + "/settings.xml" );
          +
          + verifier.addCliOption( "-Dmaven.ext.class.path="
          + + verifier.getArtifactPath( "org.apache.maven.its.extensions", "versionrange-resultfilter-extension",
          + "3.4.0-SNAPSHOT", "jar" ) );
          — End diff –

          Make it `1.0-SNAPSHOT`

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233139 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); + } + + /** + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension. + */ + public void testDefault() + throws Exception + { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + } + + /** + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot + * version will be used. + */ + public void testVersionRangeResultFilterExtesionSystemproperties() + throws Exception + { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + File extensionDir = new File( testDir, "filter-extension" ); + + final Map<String, String> filterProperties = new HashMap<>(); + filterProperties.put( "@baseurl@", "file://" + testDir.getAbsolutePath() ); + + Verifier verifier; + verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", filterProperties ); + verifier.filterFile( "extension.xml", ".mvn/extension.xml", "UTF-8", filterProperties ); + + // install the test extension + verifier = newVerifier( extensionDir.getAbsolutePath(), "remote" ); + verifier.filterFile( "pom.xml", "pom.xml", "UTF-8", filterProperties ); + verifier.addCliOption( "-f" ); + verifier.addCliOption( extensionDir.getAbsolutePath() + "/pom.xml" ); + verifier.addCliOption( "-Drat.skip=true" ); + verifier.setLogFileName( "install-extension.log" ); + + verifier.executeGoal( "install" ); + verifier.resetStreams(); + verifier.verifyErrorFreeLog(); + + // validate the test project + verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( true ); + verifier.setDebug( true ); + verifier.setMavenDebug( true ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", filterProperties ); + + verifier.addCliOption( "--settings" ); + verifier.addCliOption( testDir.getAbsolutePath() + "/settings.xml" ); + + verifier.addCliOption( "-Dmaven.ext.class.path=" + + verifier.getArtifactPath( "org.apache.maven.its.extensions", "versionrange-resultfilter-extension", + "3.4.0-SNAPSHOT", "jar" ) ); — End diff – Make it `1.0-SNAPSHOT`
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233084

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          +

          { + super( "[3.4.0-SNAPSHOT,)" ); + }

          +
          + /**
          + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension.
          + */
          + public void testDefault()
          + throws Exception
          +

          { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + }

          +
          + /**
          + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot
          + * version will be used.
          + */
          + public void testVersionRangeResultFilterExtesionSystemproperties()
          — End diff –

          `testVersionRangeResultFilterExtesionSystemproperties` => `testVersionRangeResultFilterExtensionSystemProperties`

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233084 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); + } + + /** + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension. + */ + public void testDefault() + throws Exception + { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + } + + /** + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot + * version will be used. + */ + public void testVersionRangeResultFilterExtesionSystemproperties() — End diff – `testVersionRangeResultFilterExtesionSystemproperties` => `testVersionRangeResultFilterExtensionSystemProperties`
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233015

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          + {
          + super( "[3.4.0-SNAPSHOT,)" );
          — End diff –

          Make that 3.4.0 and it will work.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233015 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); — End diff – Make that 3.4.0 and it will work.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the issue:

          https://github.com/apache/maven-integration-testing/pull/14

          This merge cannot be accepted. See comments inline as well as:

          • the It does not pass because the repo is oncomplete. Several JARs are missing and Maven complains about it:

          [INFO] ------------------------------------------------------------------------
          [INFO] Building Maven Integration Test :: MNG-3092 0.1
          [INFO] ------------------------------------------------------------------------
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/maven-metadata.xml
          [INFO] Downloading: file:target/null/org/apache/maven/its/mng3092/a/maven-metadata.xml
          [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/maven-metadata.xml (453 B at 32 kB/s)
          [INFO] Downloading: file:target/null/org/apache/maven/its/mng3092/a/1.1/a-1.1.pom
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.1/a-1.1.pom
          [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.1/a-1.1.pom (1.2 kB at 398 kB/s)
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/maven-metadata.xml
          [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/maven-metadata.xml (376 B at 94 kB/s)
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/a-1.2-20100408.111215-1.pom
          [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/a-1.2-20100408.111215-1.pom (1.2 kB at 401 kB/s)
          [INFO] Downloading: file:target/null/org/apache/maven/its/mng3092/a/1.2/a-1.2.pom
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2/a-1.2.pom
          [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2/a-1.2.pom (1.2 kB at 1.2 MB/s)
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/maven-metadata.xml
          [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/maven-metadata.xml (376 B at 94 kB/s)
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom
          [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom (1.2 kB at 241 kB/s)
          [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.jar
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD FAILURE
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 0.377 s
          [INFO] Finished at: 2016-06-15T21:18:47+02:00
          [INFO] Final Memory: 9M/241M
          [INFO] ------------------------------------------------------------------------
          [ERROR] Failed to execute goal on project test-mng3092: Could not resolve dependencies for project org.apache.maven.its.mng3092:test-mng3092:jar:0.1: Could not find artifact org.apache.maven.its.mng3092:a:jar:2.0-20100408.111215-1 in maven-core-it (file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo) -> [Help 1]
          org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project test-mng3092: Could not resolve dependencies for project org.apache.maven.its.mng3092:test-mng3092:jar:0.1: Could not find artifact org.apache.maven.its.mng3092:a:jar:2.0-20100408.111215-1 in maven-core-it (file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo)

          Please double check the repo and add the missing JARs.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 This merge cannot be accepted. See comments inline as well as: the It does not pass because the repo is oncomplete. Several JARs are missing and Maven complains about it: [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Integration Test :: MNG-3092 0.1 [INFO] ------------------------------------------------------------------------ [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/maven-metadata.xml [INFO] Downloading: file:target/null/org/apache/maven/its/mng3092/a/maven-metadata.xml [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/maven-metadata.xml (453 B at 32 kB/s) [INFO] Downloading: file:target/null/org/apache/maven/its/mng3092/a/1.1/a-1.1.pom [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.1/a-1.1.pom [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.1/a-1.1.pom (1.2 kB at 398 kB/s) [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/maven-metadata.xml [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/maven-metadata.xml (376 B at 94 kB/s) [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/a-1.2-20100408.111215-1.pom [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2-SNAPSHOT/a-1.2-20100408.111215-1.pom (1.2 kB at 401 kB/s) [INFO] Downloading: file:target/null/org/apache/maven/its/mng3092/a/1.2/a-1.2.pom [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2/a-1.2.pom [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/1.2/a-1.2.pom (1.2 kB at 1.2 MB/s) [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/maven-metadata.xml [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/maven-metadata.xml (376 B at 94 kB/s) [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom [INFO] Downloaded: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom (1.2 kB at 241 kB/s) [INFO] Downloading: file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.377 s [INFO] Finished at: 2016-06-15T21:18:47+02:00 [INFO] Final Memory: 9M/241M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project test-mng3092: Could not resolve dependencies for project org.apache.maven.its.mng3092:test-mng3092:jar:0.1: Could not find artifact org.apache.maven.its.mng3092:a:jar:2.0-20100408.111215-1 in maven-core-it ( file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo ) -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project test-mng3092: Could not resolve dependencies for project org.apache.maven.its.mng3092:test-mng3092:jar:0.1: Could not find artifact org.apache.maven.its.mng3092:a:jar:2.0-20100408.111215-1 in maven-core-it ( file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3092/repo ) Please double check the repo and add the missing JARs.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven-integration-testing/pull/14

          @michael-o I changed something based on your comments.

          • Duplication of version number removed in ```mng-3092/filter-extensionpom.xml```
          • Version number changed in JavaDoc of ```MavenITVersionRangeResultFilter.java```
          • Use only one exclamation mark

          Of course, the version number in ```MavenITmng3092VersionRangeResultFilterExtensionTest.java``` and ```mng-3092/filter-extension/pom.xml``` has to adapt as soon as possible after the 3.4.0 release.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o I changed something based on your comments. Duplication of version number removed in ```mng-3092/filter-extensionpom.xml``` Version number changed in JavaDoc of ```MavenITVersionRangeResultFilter.java``` Use only one exclamation mark Of course, the version number in ```MavenITmng3092VersionRangeResultFilterExtensionTest.java``` and ```mng-3092/filter-extension/pom.xml``` has to adapt as soon as possible after the 3.4.0 release.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67101198

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,74 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          — End diff –

          Of course, the version number has to change as soon as possible after the 3.4.0 release.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67101198 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> — End diff – Of course, the version number has to change as soon as possible after the 3.4.0 release.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67099834

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java —
          @@ -0,0 +1,76 @@
          +package org.apache.maven.its.extensions;
          +
          +/*
          + * 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 javax.inject.Named;
          +import java.util.Iterator;
          +import javax.inject.Inject;
          +import org.apache.maven.repository.internal.VersionRangeResultFilter;
          +import org.eclipse.aether.resolution.VersionRangeResolutionException;
          +import org.eclipse.aether.resolution.VersionRangeResult;
          +import org.eclipse.aether.spi.log.Logger;
          +import org.eclipse.aether.spi.log.LoggerFactory;
          +import org.eclipse.aether.spi.log.NullLoggerFactory;
          +import org.eclipse.aether.version.Version;
          +import org.eclipse.sisu.Nullable;
          +
          +/**
          + * Example implementation for use in ITs.
          + * <p>
          + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p>
          + * <p>
          + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a> and only works with Maven
          + * >= 3.4.0-SNAPSHOT</p>
          + */
          +@Named
          +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter
          +{
          +
          + private final Logger logger;
          +
          + @Inject
          + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory )
          +

          { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + }

          +
          + @Override
          + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult )
          + throws VersionRangeResolutionException
          + {
          + if ( ! ! !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) )
          — End diff –

          The Apache Aries project use this patterns for a better readability.
          No problem to change that.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67099834 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java — @@ -0,0 +1,76 @@ +package org.apache.maven.its.extensions; + +/* + * 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 javax.inject.Named; +import java.util.Iterator; +import javax.inject.Inject; +import org.apache.maven.repository.internal.VersionRangeResultFilter; +import org.eclipse.aether.resolution.VersionRangeResolutionException; +import org.eclipse.aether.resolution.VersionRangeResult; +import org.eclipse.aether.spi.log.Logger; +import org.eclipse.aether.spi.log.LoggerFactory; +import org.eclipse.aether.spi.log.NullLoggerFactory; +import org.eclipse.aether.version.Version; +import org.eclipse.sisu.Nullable; + +/** + * Example implementation for use in ITs. + * <p> + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p> + * <p> + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a> and only works with Maven + * >= 3.4.0-SNAPSHOT</p> + */ +@Named +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter +{ + + private final Logger logger; + + @Inject + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory ) + { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + } + + @Override + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult ) + throws VersionRangeResolutionException + { + if ( ! ! !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) ) — End diff – The Apache Aries project use this patterns for a better readability. No problem to change that.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67063784

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java —
          @@ -0,0 +1,76 @@
          +package org.apache.maven.its.extensions;
          +
          +/*
          + * 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 javax.inject.Named;
          +import java.util.Iterator;
          +import javax.inject.Inject;
          +import org.apache.maven.repository.internal.VersionRangeResultFilter;
          +import org.eclipse.aether.resolution.VersionRangeResolutionException;
          +import org.eclipse.aether.resolution.VersionRangeResult;
          +import org.eclipse.aether.spi.log.Logger;
          +import org.eclipse.aether.spi.log.LoggerFactory;
          +import org.eclipse.aether.spi.log.NullLoggerFactory;
          +import org.eclipse.aether.version.Version;
          +import org.eclipse.sisu.Nullable;
          +
          +/**
          + * Example implementation for use in ITs.
          + * <p>
          + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p>
          + * <p>
          + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a> and only works with Maven
          + * >= 3.4.0-SNAPSHOT</p>
          + */
          +@Named
          +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter
          +{
          +
          + private final Logger logger;
          +
          + @Inject
          + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory )
          +

          { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + }

          +
          + @Override
          + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult )
          + throws VersionRangeResolutionException
          + {
          + if ( ! ! !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) )
          — End diff –

          Three exclamation marks???

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67063784 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java — @@ -0,0 +1,76 @@ +package org.apache.maven.its.extensions; + +/* + * 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 javax.inject.Named; +import java.util.Iterator; +import javax.inject.Inject; +import org.apache.maven.repository.internal.VersionRangeResultFilter; +import org.eclipse.aether.resolution.VersionRangeResolutionException; +import org.eclipse.aether.resolution.VersionRangeResult; +import org.eclipse.aether.spi.log.Logger; +import org.eclipse.aether.spi.log.LoggerFactory; +import org.eclipse.aether.spi.log.NullLoggerFactory; +import org.eclipse.aether.version.Version; +import org.eclipse.sisu.Nullable; + +/** + * Example implementation for use in ITs. + * <p> + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p> + * <p> + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a> and only works with Maven + * >= 3.4.0-SNAPSHOT</p> + */ +@Named +public class MavenITVersionRangeResultFilter implements VersionRangeResultFilter +{ + + private final Logger logger; + + @Inject + public MavenITVersionRangeResultFilter( @Nullable LoggerFactory loggerfactory ) + { + this.logger = ( ( null == loggerfactory ) ? NullLoggerFactory.LOGGER : loggerfactory.getLogger( + VersionRangeResultFilter.class.getName() ) ); + } + + @Override + public VersionRangeResult filterVersionRangeResult( VersionRangeResult versionRangeResult ) + throws VersionRangeResolutionException + { + if ( ! ! !"org.apache.maven.its.mng3092".equals( versionRangeResult.getRequest().getArtifact().getGroupId() ) ) — End diff – Three exclamation marks???
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059400

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java —
          @@ -0,0 +1,76 @@
          +package org.apache.maven.its.extensions;
          +
          +/*
          + * 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 javax.inject.Named;
          +import java.util.Iterator;
          +import javax.inject.Inject;
          +import org.apache.maven.repository.internal.VersionRangeResultFilter;
          +import org.eclipse.aether.resolution.VersionRangeResolutionException;
          +import org.eclipse.aether.resolution.VersionRangeResult;
          +import org.eclipse.aether.spi.log.Logger;
          +import org.eclipse.aether.spi.log.LoggerFactory;
          +import org.eclipse.aether.spi.log.NullLoggerFactory;
          +import org.eclipse.aether.version.Version;
          +import org.eclipse.sisu.Nullable;
          +
          +/**
          + * Example implementation for use in ITs.
          + * <p>
          + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p>
          + * <p>
          + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a> and only works with Maven
          + * >= 3.4.0-SNAPSHOT</p>
          — End diff –

          I have changed that already locally to 3.4.0.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059400 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultFilter.java — @@ -0,0 +1,76 @@ +package org.apache.maven.its.extensions; + +/* + * 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 javax.inject.Named; +import java.util.Iterator; +import javax.inject.Inject; +import org.apache.maven.repository.internal.VersionRangeResultFilter; +import org.eclipse.aether.resolution.VersionRangeResolutionException; +import org.eclipse.aether.resolution.VersionRangeResult; +import org.eclipse.aether.spi.log.Logger; +import org.eclipse.aether.spi.log.LoggerFactory; +import org.eclipse.aether.spi.log.NullLoggerFactory; +import org.eclipse.aether.version.Version; +import org.eclipse.sisu.Nullable; + +/** + * Example implementation for use in ITs. + * <p> + * This implementation removes <b>all</b> SNAPSHOT dependencies.</p> + * <p> + * Part of the test set <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a> and only works with Maven + * >= 3.4.0-SNAPSHOT</p> — End diff – I have changed that already locally to 3.4.0.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059367

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,74 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          + </parent>
          +
          + <groupId>org.apache.maven.its.extensions</groupId>
          + <artifactId>versionrange-resultfilter-extension</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          — End diff –

          This duplicates the parent version.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059367 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> + </parent> + + <groupId>org.apache.maven.its.extensions</groupId> + <artifactId>versionrange-resultfilter-extension</artifactId> + <version>3.4.0-SNAPSHOT</version> — End diff – This duplicates the parent version.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059339

          — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml —
          @@ -0,0 +1,74 @@
          +<?xml version="1.0" encoding="UTF-8"?>
          +
          +<!--
          +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.
          +-->
          +
          +<project xmlns="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">
          + <modelVersion>4.0.0</modelVersion>
          +
          + <parent>
          + <groupId>org.apache.maven</groupId>
          + <artifactId>maven</artifactId>
          + <version>3.4.0-SNAPSHOT</version>
          — End diff –

          I am not certain wether relying on a snapshot version which will vanish with 3.4.1 is a good idea. This should be stable and reproducible. Maybe a followup commit as soon as 3.4 is released?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059339 — Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml — @@ -0,0 +1,74 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!-- +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. +--> + +<project xmlns="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 "> + <modelVersion>4.0.0</modelVersion> + + <parent> + <groupId>org.apache.maven</groupId> + <artifactId>maven</artifactId> + <version>3.4.0-SNAPSHOT</version> — End diff – I am not certain wether relying on a snapshot version which will vanish with 3.4.1 is a good idea. This should be stable and reproducible. Maybe a followup commit as soon as 3.4 is released?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059081

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          +

          { + super( "[3.4.0-SNAPSHOT,)" ); + }

          +
          + /**
          + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension.
          + */
          + public void testDefault()
          + throws Exception
          +

          { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + }

          +
          + /**
          + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot
          + * version will be used.
          + */
          + public void testVersionRangeResultFilterExtesionSystemproperties()
          + throws Exception
          + {
          + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" );
          + File extensionDir = new File( testDir, "filter-extension" );
          +
          + final Map<String, String> filterProperties = new HashMap<>();
          + filterProperties.put( "@baseurl@", "file://" + testDir.getAbsolutePath() );
          +
          + Verifier verifier;
          + verifier = newVerifier( testDir.getAbsolutePath() );
          + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", filterProperties );
          + verifier.filterFile( "extension.xml", ".mvn/extension.xml", "UTF-8", filterProperties );
          +
          + // install the test extension
          + verifier = newVerifier( extensionDir.getAbsolutePath(), "remote" );
          + verifier.filterFile( "pom.xml", "pom.xml", "UTF-8", filterProperties );
          + verifier.addCliOption( "-f" );
          + verifier.addCliOption( extensionDir.getAbsolutePath() + "/pom.xml" );
          + verifier.addCliOption( "-Drat.skip=true" );
          + verifier.setLogFileName( "install-extension.log" );
          +
          + verifier.executeGoal( "install" );
          + verifier.resetStreams();
          + verifier.verifyErrorFreeLog();
          +
          + // validate the test project
          + verifier = newVerifier( testDir.getAbsolutePath() );
          + verifier.setAutoclean( true );
          + verifier.setDebug( true );
          + verifier.setMavenDebug( true );
          + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", filterProperties );
          +
          + verifier.addCliOption( "--settings" );
          + verifier.addCliOption( testDir.getAbsolutePath() + "/settings.xml" );
          +
          + verifier.addCliOption( "-Dmaven.ext.class.path="
          + + verifier.getArtifactPath( "org.apache.maven.its.extensions", "versionrange-resultfilter-extension",
          + "3.4.0-SNAPSHOT", "jar" ) );
          — End diff –

          Problamatic, see below.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67059081 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); + } + + /** + * Verify that the Maven default behavior will be used without a VersionRangeResultFilter extension. + */ + public void testDefault() + throws Exception + { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + + Verifier verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( false ); + verifier.deleteDirectory( "target" ); + verifier.deleteArtifacts( "org.apache.maven.its.mng3092" ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", verifier.newDefaultFilterProperties() ); + verifier.addCliOption( "--settings" ); + verifier.addCliOption( "settings.xml" ); + verifier.executeGoal( "validate" ); + verifier.verifyErrorFreeLog(); + verifier.resetStreams(); + + List<String> classpath = verifier.loadLines( "target/classpath.txt", "UTF-8" ); + assertTrue( classpath.toString(), classpath.contains( "a-2.0-SNAPSHOT.jar" ) ); + } + + /** + * Verify that the Maven VersionRangeResultFilter extension behavior is active and checks that non snapshot + * version will be used. + */ + public void testVersionRangeResultFilterExtesionSystemproperties() + throws Exception + { + File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-3092" ); + File extensionDir = new File( testDir, "filter-extension" ); + + final Map<String, String> filterProperties = new HashMap<>(); + filterProperties.put( "@baseurl@", "file://" + testDir.getAbsolutePath() ); + + Verifier verifier; + verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.filterFile( "settings-template.xml", "settings.xml", "UTF-8", filterProperties ); + verifier.filterFile( "extension.xml", ".mvn/extension.xml", "UTF-8", filterProperties ); + + // install the test extension + verifier = newVerifier( extensionDir.getAbsolutePath(), "remote" ); + verifier.filterFile( "pom.xml", "pom.xml", "UTF-8", filterProperties ); + verifier.addCliOption( "-f" ); + verifier.addCliOption( extensionDir.getAbsolutePath() + "/pom.xml" ); + verifier.addCliOption( "-Drat.skip=true" ); + verifier.setLogFileName( "install-extension.log" ); + + verifier.executeGoal( "install" ); + verifier.resetStreams(); + verifier.verifyErrorFreeLog(); + + // validate the test project + verifier = newVerifier( testDir.getAbsolutePath() ); + verifier.setAutoclean( true ); + verifier.setDebug( true ); + verifier.setMavenDebug( true ); + verifier.filterFile( "pom-mng-3092.xml", "pom.xml", "UTF-8", filterProperties ); + + verifier.addCliOption( "--settings" ); + verifier.addCliOption( testDir.getAbsolutePath() + "/settings.xml" ); + + verifier.addCliOption( "-Dmaven.ext.class.path=" + + verifier.getArtifactPath( "org.apache.maven.its.extensions", "versionrange-resultfilter-extension", + "3.4.0-SNAPSHOT", "jar" ) ); — End diff – Problamatic, see below.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven-integration-testing/pull/14#discussion_r67058999

          — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java —
          @@ -0,0 +1,132 @@
          +package org.apache.maven.it;
          +
          +/*
          + * 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 org.apache.maven.it.Verifier;
          +import org.apache.maven.it.util.ResourceExtractor;
          +
          +import java.io.File;
          +import java.util.HashMap;
          +import java.util.List;
          +import java.util.Map;
          +
          +/**
          + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092">MNG-3092</a>.
          + *
          + * <pre>
          + * <dependencies>
          + * <dependency>
          + * <groupId>org.apache.maven.its.mng3092</groupId>
          + * <artifactId>a</artifactId>
          + * <version>[1.0,2.0)</version>
          + * </dependency>
          + * </dependencies>
          + * </pre>
          + *
          + * @author Benjamin Bentmann
          + */
          +public class MavenITmng3092VersionRangeResultFilterExtensionTest
          + extends AbstractMavenIntegrationTestCase
          +{
          +
          + public MavenITmng3092VersionRangeResultFilterExtensionTest()
          + {
          + super( "[3.4.0-SNAPSHOT,)" );
          — End diff –

          I have changed that already locally.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67058999 — Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java — @@ -0,0 +1,132 @@ +package org.apache.maven.it; + +/* + * 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 org.apache.maven.it.Verifier; +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; +import java.util.HashMap; +import java.util.List; +import java.util.Map; + +/** + * This is a test set for <a href="https://issues.apache.org/jira/browse/MNG-3092"> MNG-3092 </a>. + * + * <pre> + * <dependencies> + * <dependency> + * <groupId>org.apache.maven.its.mng3092</groupId> + * <artifactId>a</artifactId> + * <version>[1.0,2.0)</version> + * </dependency> + * </dependencies> + * </pre> + * + * @author Benjamin Bentmann + */ +public class MavenITmng3092VersionRangeResultFilterExtensionTest + extends AbstractMavenIntegrationTestCase +{ + + public MavenITmng3092VersionRangeResultFilterExtensionTest() + { + super( "[3.4.0-SNAPSHOT,)" ); — End diff – I have changed that already locally.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the issue:

          https://github.com/apache/maven/pull/70

          I would like to look at ```ContextualSnapshotVersionFilter``` solution, if the Aether code was moved back to Apache Maven.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the issue: https://github.com/apache/maven/pull/70 I would like to look at ```ContextualSnapshotVersionFilter``` solution, if the Aether code was moved back to Apache Maven.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-198910133

          @dinoboy197: Sorry, I haven't had time to look at @ChristianSchulte suggestion until now.
          @jvanzyl @michael-o: Suggestion: Merge this solution. I'll evaluate the ```ContextualSnapshotVersionFilter``` way in a separate task. If this solution is a equivalent or a better one, I'll start a new pull request for use the way @ChristianSchulte suggested and removing my solution.

          WDYT?

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-198910133 @dinoboy197: Sorry, I haven't had time to look at @ChristianSchulte suggestion until now. @jvanzyl @michael-o: Suggestion: Merge this solution. I'll evaluate the ```ContextualSnapshotVersionFilter``` way in a separate task. If this solution is a equivalent or a better one, I'll start a new pull request for use the way @ChristianSchulte suggested and removing my solution. WDYT?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user dinoboy197 commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-198031554

          @michael-o @jvanzyl @barthel - just checking in to see if any progress has been made on reviewing this.

          Show
          githubbot ASF GitHub Bot added a comment - Github user dinoboy197 commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-198031554 @michael-o @jvanzyl @barthel - just checking in to see if any progress has been made on reviewing this.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user ChristianSchulte commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-188009400

          @barthel: See [c31be833a6f8d9266990a708efe624d09fa06dec](https://github.com/ChristianSchulte/maven/commit/c31be833a6f8d9266990a708efe624d09fa06dec)

          Show
          githubbot ASF GitHub Bot added a comment - Github user ChristianSchulte commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-188009400 @barthel: See [c31be833a6f8d9266990a708efe624d09fa06dec] ( https://github.com/ChristianSchulte/maven/commit/c31be833a6f8d9266990a708efe624d09fa06dec )
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-187570913

          @ChristianSchulte : Sounds interesting. I'll take a look on it at the end of this week.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-187570913 @ChristianSchulte : Sounds interesting. I'll take a look on it at the end of this week.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-185895693

          @barthel much but I won't be able to take a closer at it before next week. @jvanzyl if you can do it sooner, just go again and do it.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-185895693 @barthel much but I won't be able to take a closer at it before next week. @jvanzyl if you can do it sooner, just go again and do it.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-185894318

          @dinoboy197 : Fantastic. Thanks for your help. After reading your post, it sounds so logical.

          @michael-o , @jvanzyl : Now the merge comes true? :-D

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-185894318 @dinoboy197 : Fantastic. Thanks for your help. After reading your post, it sounds so logical. @michael-o , @jvanzyl : Now the merge comes true? :-D
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user dinoboy197 commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-185839435

          @barthel - I think all you should need to do is to rebase your feature branch (MNG-3092) against upstream/master.

          Something like this should do it (assuming that in your git clone, upstream is configured to point to apache/maven and origin is configured to point to barthel/maven):

          • `git fetch upstream`
          • `git checkout MNG-3092`
          • `git rebase upstream/master`
          • `git push -f origin MNG-3092`
          Show
          githubbot ASF GitHub Bot added a comment - Github user dinoboy197 commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-185839435 @barthel - I think all you should need to do is to rebase your feature branch ( MNG-3092 ) against upstream/master. Something like this should do it (assuming that in your git clone, upstream is configured to point to apache/maven and origin is configured to point to barthel/maven): `git fetch upstream` `git checkout MNG-3092 ` `git rebase upstream/master` `git push -f origin MNG-3092 `
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-184374596

          @michael-o Sorry I've no idea how to remove the merge 'noise' from this really old branch. The only change of mine is ```28fd43d```.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-184374596 @michael-o Sorry I've no idea how to remove the merge 'noise' from this really old branch. The only change of mine is ```28fd43d```.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-184350865

          This commit is huge and has a lot of merge noise. Do you think you can squeeze it down to your changes only?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-184350865 This commit is huge and has a lot of merge noise. Do you think you can squeeze it down to your changes only?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-184328357

          @jvanzyl @michael-o : Read to merge.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-184328357 @jvanzyl @michael-o : Read to merge.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-184327161

          Integration test pull request: https://github.com/apache/maven-integration-testing/pull/14

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-184327161 Integration test pull request: https://github.com/apache/maven-integration-testing/pull/14
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user barthel opened a pull request:

          https://github.com/apache/maven-integration-testing/pull/14

          MNG-3092: Adds integration tests for version range result filter behaviour

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/barthel/maven-integration-testing MNG-3092

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/maven-integration-testing/pull/14.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #14


          commit 162504d0b116a866b972aa49d3d573473292c740
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2016-02-15T17:31:38Z

          MNG-3092: Adds integration tests for version range result filter behaviour


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user barthel opened a pull request: https://github.com/apache/maven-integration-testing/pull/14 MNG-3092 : Adds integration tests for version range result filter behaviour You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/maven-integration-testing MNG-3092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-integration-testing/pull/14.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #14 commit 162504d0b116a866b972aa49d3d573473292c740 Author: barthel <barthel@users.noreply.github.com> Date: 2016-02-15T17:31:38Z MNG-3092 : Adds integration tests for version range result filter behaviour
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-184308767

          Use JSR 330 annotation instead of the Plexus annotation.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-184308767 Use JSR 330 annotation instead of the Plexus annotation.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-184304203

          @jvanzyl : Thanks for your tip. Now it works. :-D

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-184304203 @jvanzyl : Thanks for your tip. Now it works. :-D
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-183894970

          I suggest looking at more recent integration tests which are similar to yours where there is a default implementation and new implementations can be used. Take a look at MavenITmng5591WorkspaceReader.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-183894970 I suggest looking at more recent integration tests which are similar to yours where there is a default implementation and new implementations can be used. Take a look at MavenITmng5591WorkspaceReader.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-183661203

          @jvanzyl , @michael-o : I start working on the integration tests. It's more complicated than I thought.

          The default handling works but I have difficulties to inject the filter into the ```DefaultVersionRangeResolver```.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-183661203 @jvanzyl , @michael-o : I start working on the integration tests. It's more complicated than I thought. The default handling works but I have difficulties to inject the filter into the ```DefaultVersionRangeResolver```.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-180506499

          Not critical, I can add the annotations later. More important are integration tests if you haven't started those yet. If you have, great!

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-180506499 Not critical, I can add the annotations later. More important are integration tests if you haven't started those yet. If you have, great!
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-180504355

          It's an old branch. So I merged the actual master into it and use Maven 3.4.0-SNAPSHOT instead.

          Only the last commit reflects the MNG-3092 solution.

          @jvanzyl : I'll start to work on JSR 330.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-180504355 It's an old branch. So I merged the actual master into it and use Maven 3.4.0-SNAPSHOT instead. Only the last commit reflects the MNG-3092 solution. @jvanzyl : I'll start to work on JSR 330.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-178390879

          @jvanzyl , @michael-o : Sorry for the delay. I'm busy right now. I will try to do the change to Maven 3.4 (and JSR330) and add a integration test. But not before friday this week.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-178390879 @jvanzyl , @michael-o : Sorry for the delay. I'm busy right now. I will try to do the change to Maven 3.4 (and JSR330) and add a integration test. But not before friday this week.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-174671286

          This is what I have expected you to say
          @barthel or anyone else, can you craft up an IT for that?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-174671286 This is what I have expected you to say @barthel or anyone else, can you craft up an IT for that?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-174668942

          For a feature like that there should be an integration test as well.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-174668942 For a feature like that there should be an integration test as well.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-174666838

          @jvanzyl There are unit tests in the commit. Isn't that enough? Otherwise, I'd ask @barthel for it.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-174666838 @jvanzyl There are unit tests in the commit. Isn't that enough? Otherwise, I'd ask @barthel for it.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-174664828

          If there are integration tests don't wait for me.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-174664828 If there are integration tests don't wait for me.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user pSub commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-174664718

          I would appreciate a merge, too.

          Show
          githubbot ASF GitHub Bot added a comment - Github user pSub commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-174664718 I would appreciate a merge, too.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-174656884

          Can we make any progress here?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-174656884 Can we make any progress here?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-160451976

          We're looking at the new year for the next core release so you have time. I might have my JSR330 changes done by then. I have 15 super nasty uses of Plexus to get around but doable over the holidays.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-160451976 We're looking at the new year for the next core release so you have time. I might have my JSR330 changes done by then. I have 15 super nasty uses of Plexus to get around but doable over the holidays.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-160448962

          I'm busy the next few days. But I will give it a try if these changes have a chance to merge in 3.3.10.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-160448962 I'm busy the next few days. But I will give it a try if these changes have a chance to merge in 3.3.10.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159774308

          @barthel I ask this to be done because with some recent changes in Sisu I actually have a chance to land my JSR330 branch which entirely removes Plexus from Maven. @mcculls added support for @PostConstruct and @PreDestroy which allows me to replace all uses of the Disposable interface which gets me another chunk of the way.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159774308 @barthel I ask this to be done because with some recent changes in Sisu I actually have a chance to land my JSR330 branch which entirely removes Plexus from Maven. @mcculls added support for @PostConstruct and @PreDestroy which allows me to replace all uses of the Disposable interface which gets me another chunk of the way.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159774014

          @barthel I mean using the JSR330 equivalents for @Component and @Requirement. For @Component we replace them with @Named and @Singleton used together at the class level, and we replace @Requirement with @Inject at the field or constructor level. Generally I think using private final fields and using @Inject on the constructor is the better option. One we do not have with Plexus annotations. An example of a newer component that uses these are:

          https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/extension/internal/CoreExportsProvider.java

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159774014 @barthel I mean using the JSR330 equivalents for @Component and @Requirement. For @Component we replace them with @Named and @Singleton used together at the class level, and we replace @Requirement with @Inject at the field or constructor level. Generally I think using private final fields and using @Inject on the constructor is the better option. One we do not have with Plexus annotations. An example of a newer component that uses these are: https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/extension/internal/CoreExportsProvider.java
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159743197

          @barthel While I am not a Git expert. I extract a patch/stash fo the work. Branch master, apply stash and commit again. [This](http://stackoverflow.com/q/16358418/696632) is probably worth reading.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159743197 @barthel While I am not a Git expert. I extract a patch/stash fo the work. Branch master, apply stash and commit again. [This] ( http://stackoverflow.com/q/16358418/696632 ) is probably worth reading.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159729295

          @jvanzyl Did you mean ```@Requirement``` and ```@Component```?
          I'm following the coding style found in the classes around.

          Please point me to the replacements for these annotations.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159729295 @jvanzyl Did you mean ```@Requirement``` and ```@Component```? I'm following the coding style found in the classes around. Please point me to the replacements for these annotations.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159728334

          @michael-o Indent size and inside issues solved. Commits squashed and amend on last commit in branch.
          What can I do to avoid the merge commit? If I merge the master into this branch a lot more commits are involved here.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159728334 @michael-o Indent size and inside issues solved. Commits squashed and amend on last commit in branch. What can I do to avoid the merge commit? If I merge the master into this branch a lot more commits are involved here.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159585971

          Just looking through here and you also switch these to use JSR330 annotations instead of the plexus annotations. Any additions I'd like to see use JSR330 which is what we typically do now. I have a large branch which is a mass conversion of everything to JSR330 and it will help if when rebasing that I don't have to convert components again while merging which is what I've been doing for the last year with this branch. I don't mind doing this myself, just let me know.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159585971 Just looking through here and you also switch these to use JSR330 annotations instead of the plexus annotations. Any additions I'd like to see use JSR330 which is what we typically do now. I have a large branch which is a mass conversion of everything to JSR330 and it will help if when rebasing that I don't have to convert components again while merging which is what I've been doing for the last year with this branch. I don't mind doing this myself, just let me know.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159546743

          There are still some issues with the branch. You did not replay on top of master. It is creating a merge commit which I'd like to avoid. Some other issues will be commented inline.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159546743 There are still some issues with the branch. You did not replay on top of master. It is creating a merge commit which I'd like to avoid. Some other issues will be commented inline.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159399815

          Organize import in ```DefaultVersionRangeResolver``` and squash commit.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159399815 Organize import in ```DefaultVersionRangeResolver``` and squash commit.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159366801

          @barthel Git gives me:

          > git merge --no-commit barthel/MNG-3092
          Auto-merging maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java
          CONFLICT (content): Merge conflict in maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java
          Automatic merge failed; fix conflicts and then commit the result.

          Can you resolve and push again to this branch?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159366801 @barthel Git gives me: > git merge --no-commit barthel/ MNG-3092 Auto-merging maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java CONFLICT (content): Merge conflict in maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java Automatic merge failed; fix conflicts and then commit the result. Can you resolve and push again to this branch?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159078734

          Thanks, I will test and merge tomorrow.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159078734 Thanks, I will test and merge tomorrow.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159076106

          POM file adapted. Use parent version 3.3.10-SNAPSHOT and remove ```commons-lang``` dependency.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159076106 POM file adapted. Use parent version 3.3.10-SNAPSHOT and remove ```commons-lang``` dependency.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159062461

          @barthel See my inline comments. Then I will take it from there.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159062461 @barthel See my inline comments. Then I will take it from there.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159059568

          @michael-o see my comment Oct 19:
          > Please remove version property for commons-lang when merging into the master.

          That's the rework you suggest with working on https://issues.apache.org/jira/browse/MNG-5649.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159059568 @michael-o see my comment Oct 19: > Please remove version property for commons-lang when merging into the master. That's the rework you suggest with working on https://issues.apache.org/jira/browse/MNG-5649 .
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159045732

          @barthel GitHub tells me that this branch has conflicts. Can you kindly check if rebase on top of master if necessary?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159045732 @barthel GitHub tells me that this branch has conflicts. Can you kindly check if rebase on top of master if necessary?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-159011269

          I would like to see this changes in the next Maven (3.3.10) release.
          @michael-o @jvanzyl Please don't forget to merge

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-159011269 I would like to see this changes in the next Maven (3.3.10) release. @michael-o @jvanzyl Please don't forget to merge
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-151499565

          Then I don’t see an issue with merging it.

          > On Oct 27, 2015, at 4:38 AM, barthel <notifications@github.com> wrote:
          >
          > The default behavior is do nothing. The ITs doesn't show any errors at this modifications.
          >
          > —
          > Reply to this email directly or view it on GitHub.
          >

          Thanks,

          Jason

          ----------------------------------------------------------
          Jason van Zyl
          Founder, Takari and Apache Maven
          http://twitter.com/jvanzyl
          http://twitter.com/takari_io
          ---------------------------------------------------------

          A man enjoys his work when he understands the whole and when he
          is responsible for the quality of the whole

          – Christopher Alexander, A Pattern Language

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151499565 Then I don’t see an issue with merging it. > On Oct 27, 2015, at 4:38 AM, barthel <notifications@github.com> wrote: > > The default behavior is do nothing. The ITs doesn't show any errors at this modifications. > > — > Reply to this email directly or view it on GitHub. > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole – Christopher Alexander, A Pattern Language
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-151463857

          The default behavior is ``do nothing``. The ITs doesn't show any errors at this modifications.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151463857 The default behavior is ``do nothing``. The ITs doesn't show any errors at this modifications.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-151415114

          @jvanzyl Are you saying that you dislike to change the default behavior, i.e., no merge? @barthel Did you run the ITs before and after your change?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151415114 @jvanzyl Are you saying that you dislike to change the default behavior, i.e., no merge? @barthel Did you run the ITs before and after your change?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-151395866

          Can I do anything to support the merge?

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-151395866 Can I do anything to support the merge?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-150489457

          @michael-o @jvanzyl Let's go merging?

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-150489457 @michael-o @jvanzyl Let's go merging?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-149485116

          @jvanzyl Can a I merge this PR into master? Are you OK with that?

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-149485116 @jvanzyl Can a I merge this PR into master? Are you OK with that?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-149484847

          @barthel Thanks for the update. If you rebase against current master you don't need that property at all. I have added Commons Lang to dependency management already.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-149484847 @barthel Thanks for the update. If you rebase against current master you don't need that property at all. I have added Commons Lang to dependency management already.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-149349259

          @michael-o Your review comments are integrated.
          .gitignore cleaned up.
          Apache Commons Lang used instead of ``IllegalArgumentException``.
          Please remove version property for commons-lang when merging into the master.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-149349259 @michael-o Your review comments are integrated. .gitignore cleaned up. Apache Commons Lang used instead of ``IllegalArgumentException``. Please remove version property for commons-lang when merging into the master.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r42421348

          — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java —
          @@ -152,6 +154,16 @@ public DefaultVersionRangeResolver setRepositoryEventDispatcher( RepositoryEvent
          return this;
          }

          + public DefaultVersionRangeResolver setVersionRangeResultFilter( VersionRangeResultFilter versionRangeResultFilter )
          + {
          + if ( versionRangeResultFilter == null )
          +

          { + throw new IllegalArgumentException( "version range result filter has not been specified" ); + }

          — End diff –

          Please use Commons Lang as I have done it recently on other modules in Maven.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r42421348 — Diff: maven-aether-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java — @@ -152,6 +154,16 @@ public DefaultVersionRangeResolver setRepositoryEventDispatcher( RepositoryEvent return this; } + public DefaultVersionRangeResolver setVersionRangeResultFilter( VersionRangeResultFilter versionRangeResultFilter ) + { + if ( versionRangeResultFilter == null ) + { + throw new IllegalArgumentException( "version range result filter has not been specified" ); + } — End diff – Please use Commons Lang as I have done it recently on other modules in Maven.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on a diff in the pull request:

          https://github.com/apache/maven/pull/70#discussion_r42421297

          — Diff: .gitignore —
          @@ -13,3 +13,5 @@ out/
          /bootstrap
          /dependencies.xml
          .java-version
          +nb-configuration.xml
          +
          — End diff –

          Not related to the PR, please remove.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven/pull/70#discussion_r42421297 — Diff: .gitignore — @@ -13,3 +13,5 @@ out/ /bootstrap /dependencies.xml .java-version +nb-configuration.xml + — End diff – Not related to the PR, please remove.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-148898986

          This solution could also be usable for MNG-5353(https://issues.apache.org/jira/browse/MNG-5353).

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-148898986 This solution could also be usable for MNG-5353 ( https://issues.apache.org/jira/browse/MNG-5353 ).
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-148704373

          @ChristianSchulte Typo fixed. Thanks for looking into it.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-148704373 @ChristianSchulte Typo fixed. Thanks for looking into it.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-148659197

          @michael-o Your comment on 'old' commit b6d72699c8b0089351f797e217d635424c1ae5a2:
          > Don't! Always through a NPE if null is passed.

          :+1: But, I'm oriented on the current used pattern like in #setRepositoryEventDispatcher or #setSyncContextFactory.

          > Right, see my ongoing effort on this: https://issues.apache.org/jira/browse/MNG-5649

          Should I adapt the other methods? It's not the original intention of this PR.
          Maybe I create a branch and/or new commit with these changes only.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-148659197 @michael-o Your comment on 'old' commit b6d72699c8b0089351f797e217d635424c1ae5a2: > Don't! Always through a NPE if null is passed. :+1: But, I'm oriented on the current used pattern like in #setRepositoryEventDispatcher or #setSyncContextFactory. > Right, see my ongoing effort on this: https://issues.apache.org/jira/browse/MNG-5649 Should I adapt the other methods? It's not the original intention of this PR. Maybe I create a branch and/or new commit with these changes only.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-148653328

          @michael-o There is a typo and not a hidden statement. :-D

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-148653328 @michael-o There is a typo and not a hidden statement. :-D
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-148634870

          @ChristianSchulte Maybe `Rage` is intentional

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-148634870 @ChristianSchulte Maybe `Rage` is intentional
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-148556469

          @jvanzyl @michael-o : Ready for easier review.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-148556469 @jvanzyl @michael-o : Ready for easier review.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/70#issuecomment-148553852

          This PR replaced the PR (#68) and based on master and re-created branch MNG-3092. This branch contains the cherry picked b6d7269.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/70#issuecomment-148553852 This PR replaced the PR (#68) and based on master and re-created branch MNG-3092 . This branch contains the cherry picked b6d7269.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel closed the pull request at:

          https://github.com/apache/maven/pull/68

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel closed the pull request at: https://github.com/apache/maven/pull/68
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/68#issuecomment-148553491

          I've open a new PR (#70) based on master and re-created branch MNG-3092. This branch contains the cherry picked b6d7269.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/68#issuecomment-148553491 I've open a new PR (#70) based on master and re-created branch MNG-3092 . This branch contains the cherry picked b6d7269.
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user barthel opened a pull request:

          https://github.com/apache/maven/pull/70

          MNG-3092: Adds version range result filter behaviour

          The discussion on issue MNG-3092(https://issues.apache.org/jira/browse/MNG-3092) shows the seriously needs of different kinds of version range resolving in Maven.

          I know about the risk on changing the resolving mechanism in Maven.
          I always had the backward compatibility in mind, if I have something changed.
          I added some basic tests for the default version range resolver before I've started with the refactoring.

          This pull request contains the basic tests and a less invasive solution based on a filter works with resolved version range results.

          The actual version range resolving algorithm *wasn't changed* and the internal used default filter implementation don't filter anything.

          The goal:
          Provide a hook for Maven extensions/plugins to change the list of resolved version range results as required.

          These changes are only placed in maven-aether-provider.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/barthel/maven MNG-3092

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/maven/pull/70.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #70


          commit cf86c2c4c8e0c070cd800f8a7d2787b3b56d687b
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-04-30T12:37:52Z

          MNG-3092: Adds version range result filter behaviour

          The ```DefaultVersionRangeResolver``` will be extends with a filter for
          version range results.

          This commit adds a new interfaces ```VersionRangeResultFilter``` and a
          non filtering ```DefaultVersionRangeResultFilter```.


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user barthel opened a pull request: https://github.com/apache/maven/pull/70 MNG-3092 : Adds version range result filter behaviour The discussion on issue MNG-3092 ( https://issues.apache.org/jira/browse/MNG-3092 ) shows the seriously needs of different kinds of version range resolving in Maven. I know about the risk on changing the resolving mechanism in Maven. I always had the backward compatibility in mind, if I have something changed. I added some basic tests for the default version range resolver before I've started with the refactoring. This pull request contains the basic tests and a less invasive solution based on a filter works with resolved version range results. The actual version range resolving algorithm * wasn't changed * and the internal used default filter implementation don't filter anything. The goal: Provide a hook for Maven extensions/plugins to change the list of resolved version range results as required. These changes are only placed in maven-aether-provider . You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/maven MNG-3092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/70.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #70 commit cf86c2c4c8e0c070cd800f8a7d2787b3b56d687b Author: barthel <barthel@users.noreply.github.com> Date: 2015-04-30T12:37:52Z MNG-3092 : Adds version range result filter behaviour The ```DefaultVersionRangeResolver``` will be extends with a filter for version range results. This commit adds a new interfaces ```VersionRangeResultFilter``` and a non filtering ```DefaultVersionRangeResultFilter```.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user michael-o commented on the pull request:

          https://github.com/apache/maven/pull/68#issuecomment-148540247

          Create a branch named by the issue on top of master and put a single commit onto it.

          Show
          githubbot ASF GitHub Bot added a comment - Github user michael-o commented on the pull request: https://github.com/apache/maven/pull/68#issuecomment-148540247 Create a branch named by the issue on top of master and put a single commit onto it.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/68#issuecomment-148537300

          Only b6d7269 is the relevant commit. All other commits are merged from master into my feature branch.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/68#issuecomment-148537300 Only b6d7269 is the relevant commit. All other commits are merged from master into my feature branch.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/68#issuecomment-148531172

          Squash it please.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/68#issuecomment-148531172 Squash it please.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/68#issuecomment-148528528

          Is there anything else I can do to help to merge this change or make/explain it better?

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/68#issuecomment-148528528 Is there anything else I can do to help to merge this change or make/explain it better?
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/68#issuecomment-144997575

          Only b6d72699c8b0089351f797e217d635424c1ae5a2 contains the enhancements.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/68#issuecomment-144997575 Only b6d72699c8b0089351f797e217d635424c1ae5a2 contains the enhancements.
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user barthel opened a pull request:

          https://github.com/apache/maven/pull/68

          MNG-3092: Filter Version Range Result

          The discussion on issue MNG-3092(https://issues.apache.org/jira/browse/MNG-3092) shows the seriously needs of different kinds of version range resolving in Maven.

          I know about the risk on changing the resolving mechanism in Maven.
          I always had the backward compatibility in mind, if I have something changed.
          I added some basic tests for the default version range resolver before I've started with the refactoring.

          This pull request contains the basic tests and a less invasive solution based on a filter works with resolved version range results.

          The actual version range resolving algorithm *wasn't changed* and the internal used default filter implementation don't filter anything.

          The goal:
          Provide a hook for Maven extensions/plugins to change the list of resolved version range results as required.

          These changes are only placed in maven-aether-provider.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/barthel/maven MNG-3092-filter

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/maven/pull/68.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #68


          commit fa8daaea046ff3acc7d78ad4bb92d4ada49c3eaa
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-06-23T18:04:41Z

          Merge pull request #1 from apache/master

          Merge all commits from apache/master into barthel/master.

          commit 9010f79b76e1ca97742d1cf095e7aa5fd309d657
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-05T20:33:26Z

          Merge pull request #2 from apache/master

          MNG-5813 pass debug-opts from mvnDebug to mvn script in the additio…

          commit d77335c159d12a2d6fdeaead612017fec681cd1a
          Author: tssp <tssp@web.de>
          Date: 2015-04-29T08:22:38Z

          MNG-5816 Empy maven.config cause Maven to exit with failure

          Avoid adding non empty configuration argument that causes exception.

          Signed-off-by: Karl Heinz Marbaise <khmarbaise@apache.org>

          commit ffc25a7ccdfc79ecf5cce4ee719505e343017e2c
          Author: Jason van Zyl <jason@tesla.io>
          Date: 2015-07-17T18:05:46Z

          [maven-release-plugin] prepare release maven-3.3.4

          commit cff46e46e474372b90c1e64fa2e23868922feb7f
          Author: Jason van Zyl <jason@tesla.io>
          Date: 2015-07-17T18:06:03Z

          [maven-release-plugin] prepare for next development iteration

          commit 387946320ad98a0336cfe4e2761efc042b67f2bf
          Author: Karl Heinz Marbaise <khmarbaise@apache.org>
          Date: 2015-07-18T18:59:29Z

          Fixed wrong URL to Maven Issue Tracker after
          transition to Apache Software Foundation.

          commit 65d6452d3a918fbd4455264cc20f72f469290399
          Author: Karl Heinz Marbaise <khmarbaise@apache.org>
          Date: 2015-07-19T07:53:50Z

          Fixed URL's to issue tracking after transition to
          Apache Software Foundation.

          commit 999edf7d9a3dda202235db4bb8d933c8ce9743e6
          Author: Anton Tanasenko <atg.sleepless@gmail.com>
          Date: 2015-07-19T21:01:50Z

          MNG-5805: Restore binary compatibility

          Signed-off-by: Jason van Zyl <jason@tesla.io>

          commit 6e5e5865c3b532949c88a111c3c7813b402bcea3
          Author: Jason van Zyl <jason@tesla.io>
          Date: 2015-07-20T18:05:06Z

          [maven-release-plugin] prepare release maven-3.3.5

          commit 1a46e29d365fcb815dff2ca3bcadacc46c3ed489
          Author: Jason van Zyl <jason@tesla.io>
          Date: 2015-07-20T18:05:24Z

          [maven-release-plugin] prepare for next development iteration

          commit 6e00e6d415b56a0cdeb742d015c96372ab429336
          Author: Stephen Connolly <stephen.alan.connolly@gmail.com>
          Date: 2015-07-22T07:38:05Z

          MNG-5840 The fix for parent version validation caused a regression in the parent version range

          • With this change we basically unwind MNG-5840 for the rumoured validation in the workspace resolver
            when dealing with a parent version range. Not ideal but only way for now to retain the version range feature

          commit 6be2b36bd304d1eb658c717864f60d8831578bf1
          Author: Stephen Connolly <stephen.alan.connolly@gmail.com>
          Date: 2015-07-22T08:09:31Z

          curses upon you IDE for screwing up the formatting

          commit 9590195891448d0f930ee56243b286318ee6dbd6
          Author: Stephen Connolly <stephen.alan.connolly@gmail.com>
          Date: 2015-07-22T08:52:01Z

          MNG-5840 The fix for parent version validation caused a regression in the parent version range

          • With this change we basically unwind MNG-5840 for the rumoured validation in the workspace resolver
            when dealing with a parent version range. Not ideal but only way for now to retain the version range feature

          commit 37f9529fae81cb74dc576725eecddf6d29dce993
          Author: Jason van Zyl <jason@tesla.io>
          Date: 2015-07-31T02:25:36Z

          [maven-release-plugin] prepare release maven-3.3.6

          commit 601b3aad9dfe698f73e7f99cd75486f7e31765b7
          Author: Jason van Zyl <jason@tesla.io>
          Date: 2015-07-31T02:25:55Z

          [maven-release-plugin] prepare for next development iteration

          commit d9ce68aa243d432957e8c865c8c28046a0d13e6e
          Author: Hervé Boutemy <hboutemy@apache.org>
          Date: 2015-08-02T22:14:51Z

          updated wiki content link: docs.codehaus.org has shut down

          commit aca247f09ed881dfb796aaffb1ec5115e74c7d54
          Author: Hervé Boutemy <hboutemy@apache.org>
          Date: 2015-08-02T22:23:39Z

          Plexus is now at github

          commit b6d72699c8b0089351f797e217d635424c1ae5a2
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-04-30T12:37:52Z

          MNG-3092: Adds version range result filter behaviour

          The ```DefaultVersionRangeResolver``` will be extends with a filter for
          version range results.

          This commit adds a new interfaces ```VersionRangeResultFilter``` and a
          non filtering ```DefaultVersionRangeResultFilter```.


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user barthel opened a pull request: https://github.com/apache/maven/pull/68 MNG-3092 : Filter Version Range Result The discussion on issue MNG-3092 ( https://issues.apache.org/jira/browse/MNG-3092 ) shows the seriously needs of different kinds of version range resolving in Maven. I know about the risk on changing the resolving mechanism in Maven. I always had the backward compatibility in mind, if I have something changed. I added some basic tests for the default version range resolver before I've started with the refactoring. This pull request contains the basic tests and a less invasive solution based on a filter works with resolved version range results. The actual version range resolving algorithm * wasn't changed * and the internal used default filter implementation don't filter anything. The goal: Provide a hook for Maven extensions/plugins to change the list of resolved version range results as required. These changes are only placed in maven-aether-provider . You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/maven MNG-3092 -filter Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/68.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #68 commit fa8daaea046ff3acc7d78ad4bb92d4ada49c3eaa Author: barthel <barthel@users.noreply.github.com> Date: 2015-06-23T18:04:41Z Merge pull request #1 from apache/master Merge all commits from apache/master into barthel/master. commit 9010f79b76e1ca97742d1cf095e7aa5fd309d657 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-05T20:33:26Z Merge pull request #2 from apache/master MNG-5813 pass debug-opts from mvnDebug to mvn script in the additio… commit d77335c159d12a2d6fdeaead612017fec681cd1a Author: tssp <tssp@web.de> Date: 2015-04-29T08:22:38Z MNG-5816 Empy maven.config cause Maven to exit with failure Avoid adding non empty configuration argument that causes exception. Signed-off-by: Karl Heinz Marbaise <khmarbaise@apache.org> commit ffc25a7ccdfc79ecf5cce4ee719505e343017e2c Author: Jason van Zyl <jason@tesla.io> Date: 2015-07-17T18:05:46Z [maven-release-plugin] prepare release maven-3.3.4 commit cff46e46e474372b90c1e64fa2e23868922feb7f Author: Jason van Zyl <jason@tesla.io> Date: 2015-07-17T18:06:03Z [maven-release-plugin] prepare for next development iteration commit 387946320ad98a0336cfe4e2761efc042b67f2bf Author: Karl Heinz Marbaise <khmarbaise@apache.org> Date: 2015-07-18T18:59:29Z Fixed wrong URL to Maven Issue Tracker after transition to Apache Software Foundation. commit 65d6452d3a918fbd4455264cc20f72f469290399 Author: Karl Heinz Marbaise <khmarbaise@apache.org> Date: 2015-07-19T07:53:50Z Fixed URL's to issue tracking after transition to Apache Software Foundation. commit 999edf7d9a3dda202235db4bb8d933c8ce9743e6 Author: Anton Tanasenko <atg.sleepless@gmail.com> Date: 2015-07-19T21:01:50Z MNG-5805 : Restore binary compatibility Signed-off-by: Jason van Zyl <jason@tesla.io> commit 6e5e5865c3b532949c88a111c3c7813b402bcea3 Author: Jason van Zyl <jason@tesla.io> Date: 2015-07-20T18:05:06Z [maven-release-plugin] prepare release maven-3.3.5 commit 1a46e29d365fcb815dff2ca3bcadacc46c3ed489 Author: Jason van Zyl <jason@tesla.io> Date: 2015-07-20T18:05:24Z [maven-release-plugin] prepare for next development iteration commit 6e00e6d415b56a0cdeb742d015c96372ab429336 Author: Stephen Connolly <stephen.alan.connolly@gmail.com> Date: 2015-07-22T07:38:05Z MNG-5840 The fix for parent version validation caused a regression in the parent version range With this change we basically unwind MNG-5840 for the rumoured validation in the workspace resolver when dealing with a parent version range. Not ideal but only way for now to retain the version range feature commit 6be2b36bd304d1eb658c717864f60d8831578bf1 Author: Stephen Connolly <stephen.alan.connolly@gmail.com> Date: 2015-07-22T08:09:31Z curses upon you IDE for screwing up the formatting commit 9590195891448d0f930ee56243b286318ee6dbd6 Author: Stephen Connolly <stephen.alan.connolly@gmail.com> Date: 2015-07-22T08:52:01Z MNG-5840 The fix for parent version validation caused a regression in the parent version range With this change we basically unwind MNG-5840 for the rumoured validation in the workspace resolver when dealing with a parent version range. Not ideal but only way for now to retain the version range feature commit 37f9529fae81cb74dc576725eecddf6d29dce993 Author: Jason van Zyl <jason@tesla.io> Date: 2015-07-31T02:25:36Z [maven-release-plugin] prepare release maven-3.3.6 commit 601b3aad9dfe698f73e7f99cd75486f7e31765b7 Author: Jason van Zyl <jason@tesla.io> Date: 2015-07-31T02:25:55Z [maven-release-plugin] prepare for next development iteration commit d9ce68aa243d432957e8c865c8c28046a0d13e6e Author: Hervé Boutemy <hboutemy@apache.org> Date: 2015-08-02T22:14:51Z updated wiki content link: docs.codehaus.org has shut down commit aca247f09ed881dfb796aaffb1ec5115e74c7d54 Author: Hervé Boutemy <hboutemy@apache.org> Date: 2015-08-02T22:23:39Z Plexus is now at github commit b6d72699c8b0089351f797e217d635424c1ae5a2 Author: barthel <barthel@users.noreply.github.com> Date: 2015-04-30T12:37:52Z MNG-3092 : Adds version range result filter behaviour The ```DefaultVersionRangeResolver``` will be extends with a filter for version range results. This commit adds a new interfaces ```VersionRangeResultFilter``` and a non filtering ```DefaultVersionRangeResultFilter```.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/57#issuecomment-144993151

          I closed this pull request and I come back soon with a less invasive filter solution.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/57#issuecomment-144993151 I closed this pull request and I come back soon with a less invasive filter solution.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel closed the pull request at:

          https://github.com/apache/maven/pull/57

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel closed the pull request at: https://github.com/apache/maven/pull/57
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/57#issuecomment-120431206

          My preferred strategy is to resolve only released versions within a version range (```"onlyReleases"```). If a developer needs a SNAPSHOT version, it is possible to insert the SNAPSHOT version directly without version range.
          But that is my case so I would like to give a more flexible way to react on the needs.

          For now it isn't possible to change the strategy in a plugin or something like that. At the first time the strategies shipped with the Maven core (maven-aether-provider) are the only once.

          Maybe it is a more clear solution to implement a filter around the hard defined version range resolver. That's what the new strategies internally really are.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/57#issuecomment-120431206 My preferred strategy is to resolve only released versions within a version range (```"onlyReleases"```). If a developer needs a SNAPSHOT version, it is possible to insert the SNAPSHOT version directly without version range. But that is my case so I would like to give a more flexible way to react on the needs. For now it isn't possible to change the strategy in a plugin or something like that. At the first time the strategies shipped with the Maven core (maven-aether-provider) are the only once. Maybe it is a more clear solution to implement a filter around the hard defined version range resolver. That's what the new strategies internally really are.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/57#issuecomment-120428315

          And so what strategy are you going to implement? I realized you've made it a strategy but that doesn't negate potential for problematic issues. I'm just trying to determine whether what you really want is what we eventually want to move to. Proper semantic versioning in this case.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/57#issuecomment-120428315 And so what strategy are you going to implement? I realized you've made it a strategy but that doesn't negate potential for problematic issues. I'm just trying to determine whether what you really want is what we eventually want to move to. Proper semantic versioning in this case.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/57#issuecomment-120420443

          The `org.eclipse.aether.resolution.VersionRangeRequest` contains the artifact .

          If you implement an odd/even version range resolver strategy only for your artifact, you have to check the artifact at `VersionRangeRequest` instead.

          It is possible to write tests to ensure that only your artifacts are handled by the new strategy and third party artifacts are provided to default version range resolver.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/57#issuecomment-120420443 The `org.eclipse.aether.resolution.VersionRangeRequest` contains the artifact . If you implement an odd/even version range resolver strategy only for your artifact, you have to check the artifact at `VersionRangeRequest` instead. It is possible to write tests to ensure that only your artifacts are handled by the new strategy and third party artifacts are provided to default version range resolver.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user ifedorenko commented on the pull request:

          https://github.com/apache/maven/pull/57#issuecomment-120415902

          What will happen when projects using new/custom version range resolution strategy are deployed to shared repository like Central? Won't this break consumers of project artifacts?

          For example, say my project uses odd/even versioning convention to distinguish between developer and stable versions and I implemented custom range resolver to enforce this convention. Since consumers of my project's artifacts will have no knowledge of the versioning scheme I use, they may resolve wrong transitive dependencies.

          Show
          githubbot ASF GitHub Bot added a comment - Github user ifedorenko commented on the pull request: https://github.com/apache/maven/pull/57#issuecomment-120415902 What will happen when projects using new/custom version range resolution strategy are deployed to shared repository like Central? Won't this break consumers of project artifacts? For example, say my project uses odd/even versioning convention to distinguish between developer and stable versions and I implemented custom range resolver to enforce this convention. Since consumers of my project's artifacts will have no knowledge of the versioning scheme I use, they may resolve wrong transitive dependencies.
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user barthel opened a pull request:

          https://github.com/apache/maven/pull/57

          MNG-3092: Add strategy based version range resolver.

          The discussion on issue MNG-3092(https://issues.apache.org/jira/browse/MNG-3092) shows the seriously needs of different kinds of version range resolving in Maven.

          I know about the risk on changing the resolving mechanism in Maven.
          I always had the backward compatibility in mind, if I have something changed.
          I added some basic tests for the default version range resolver (strategy) before I've started with the refactoring.

          This pull request contains a solution based on the strategy pattern.

          The actual version range resolving algorithm *wasn't change* but moved into a strategy.
          The provided other strategies are, more or less, only result filter around the result of the default version range strategy.

          These changes are only placed in maven-aether-provider.


          The original ```DefaultVersionRangeResolver``` will be replaced by the
          new strategy pattern based version range resolver.

          The actual version range resolving algorithm, formerly located in
          ```DefaultVersionRangeResolver```, is moved into a new strategy class
          ```MavenDefaultVersionRangeResolver``` with the name/hint ```"mavenDefault"```.
          The resolving algorithm *WAS NOT CHANGED*.

          The new ```StrategyVersionRangeResolver``` will be registered as new
          default version range resolver (without name/hint).
          Additional strategies are registered as ```VersionRangeResolver``` with a
          unique name/hint.

          The used strategy will be configured in ```StrategyVersionRangeResolver```
          via the Maven system parameter ```-Dmaven.versionRangeResolver.strategy=...```.

          If no strategy is configured or the strategy is unknown, the Maven
          default version range resolver ```"mavenDefault"``` will be used.
          Otherwise the named strategy will be used.

          The following strategies are available:

          • ```MavenDefaultVersionRangeResolver``` ```"mavenDefault"```
          • the actual UNTOUCHED default
          • resolves all versions including all SNAPSHOT versions.
          • ```ReleaseOnBoundariesVersionRangeResolver``` ```"releaseOnBoundaries"```
          • Used the ```MavenDefaultVersionRangeResolver``` internally and filters
            the result. Removes all SNAPSHOT versions at the begin and the end of
            the resolved versions list until to a released version.
          • ```OnlyReleaseVersionRangeResolver``` ```"onlyReleases"```
          • Used the ```MavenDefaultVersionRangeResolver``` internally and filters
            the result. Removes all SNAPSHOT versions at the resolved versions list.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/barthel/maven MNG-3092

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/maven/pull/57.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #57


          commit c7454d1a3275ba865e010d0fc016b711450907fb
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-04-30T12:37:52Z

          MNG-3092: Add basic tests for DefaultVersionRangeResolver.

          commit bc45cb41d1e7651f537304bdce2a7f82fcaa9215
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-02T22:06:00Z

          MNG-3092: Add strategy based version range resolver.

          The original ```DefaultVersionRangeResolver``` will be replaced by the
          new strategy pattern based version range resolver.

          The actual version range resolving algorithm, formerly located in
          ```DefaultVersionRangeResolver```, is moved into a new strategy class
          ```MavenDefaultVersionRangeResolver``` with the name/hint ```"mavenDefault"```.
          The resolving algorithm WAS NOT CHANGED.

          The new ```StrategyVersionRangeResolver``` will be registered as new
          default version range resolver (without name/hint).
          Additional strategies are registered as ```VersionRangeResolver``` with a
          unique name/hint.

          The used strategy will be configured in ```StrategyVersionRangeResolver```
          via the Maven system parameter ```-Dmaven.versionRangeResolver.strategy=...```.

          If no strategy is configured or the strategy is unknown, the Maven
          default version range resolver ```"mavenDefault"``` will be used.
          Otherwise the named strategy will be used.

          The following strategies are available:

          • ```MavenDefaultVersionRangeResolver``` ```"mavenDefault"```
            • the actual UNTOUCHED default
            • resolves all versions including all SNAPSHOT versions.
          • ```ReleaseOnBoundariesVersionRangeResolver``` ```"releaseOnBoundaries"```
            • Used the ```MavenDefaultVersionRangeResolver``` internally and filters
              the result. Removes all SNAPSHOT versions at the begin and the end of
              the resolved versions list until to a released version.
          • ```OnlyReleaseVersionRangeResolver``` ```"onlyReleases"```
            • Used the ```MavenDefaultVersionRangeResolver``` internally and filters
              the result. Removes all SNAPSHOT versions at the resolved versions list.

          Show
          githubbot ASF GitHub Bot added a comment - GitHub user barthel opened a pull request: https://github.com/apache/maven/pull/57 MNG-3092 : Add strategy based version range resolver. The discussion on issue MNG-3092 ( https://issues.apache.org/jira/browse/MNG-3092 ) shows the seriously needs of different kinds of version range resolving in Maven. I know about the risk on changing the resolving mechanism in Maven. I always had the backward compatibility in mind, if I have something changed. I added some basic tests for the default version range resolver (strategy) before I've started with the refactoring. This pull request contains a solution based on the strategy pattern. The actual version range resolving algorithm * wasn't change * but moved into a strategy. The provided other strategies are, more or less, only result filter around the result of the default version range strategy. These changes are only placed in maven-aether-provider . The original ```DefaultVersionRangeResolver``` will be replaced by the new strategy pattern based version range resolver. The actual version range resolving algorithm, formerly located in ```DefaultVersionRangeResolver```, is moved into a new strategy class ```MavenDefaultVersionRangeResolver``` with the name/hint ```"mavenDefault"```. The resolving algorithm * WAS NOT CHANGED *. The new ```StrategyVersionRangeResolver``` will be registered as new default version range resolver (without name/hint). Additional strategies are registered as ```VersionRangeResolver``` with a unique name/hint. The used strategy will be configured in ```StrategyVersionRangeResolver``` via the Maven system parameter ```-Dmaven.versionRangeResolver.strategy=...```. If no strategy is configured or the strategy is unknown, the Maven default version range resolver ```"mavenDefault"``` will be used. Otherwise the named strategy will be used. The following strategies are available: ```MavenDefaultVersionRangeResolver``` ```"mavenDefault"``` the actual UNTOUCHED default resolves all versions including all SNAPSHOT versions. ```ReleaseOnBoundariesVersionRangeResolver``` ```"releaseOnBoundaries"``` Used the ```MavenDefaultVersionRangeResolver``` internally and filters the result. Removes all SNAPSHOT versions at the begin and the end of the resolved versions list until to a released version. ```OnlyReleaseVersionRangeResolver``` ```"onlyReleases"``` Used the ```MavenDefaultVersionRangeResolver``` internally and filters the result. Removes all SNAPSHOT versions at the resolved versions list. You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/maven MNG-3092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/57.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #57 commit c7454d1a3275ba865e010d0fc016b711450907fb Author: barthel <barthel@users.noreply.github.com> Date: 2015-04-30T12:37:52Z MNG-3092 : Add basic tests for DefaultVersionRangeResolver. commit bc45cb41d1e7651f537304bdce2a7f82fcaa9215 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-02T22:06:00Z MNG-3092 : Add strategy based version range resolver. The original ```DefaultVersionRangeResolver``` will be replaced by the new strategy pattern based version range resolver. The actual version range resolving algorithm, formerly located in ```DefaultVersionRangeResolver```, is moved into a new strategy class ```MavenDefaultVersionRangeResolver``` with the name/hint ```"mavenDefault"```. The resolving algorithm WAS NOT CHANGED. The new ```StrategyVersionRangeResolver``` will be registered as new default version range resolver (without name/hint). Additional strategies are registered as ```VersionRangeResolver``` with a unique name/hint. The used strategy will be configured in ```StrategyVersionRangeResolver``` via the Maven system parameter ```-Dmaven.versionRangeResolver.strategy=...```. If no strategy is configured or the strategy is unknown, the Maven default version range resolver ```"mavenDefault"``` will be used. Otherwise the named strategy will be used. The following strategies are available: ```MavenDefaultVersionRangeResolver``` ```"mavenDefault"``` the actual UNTOUCHED default resolves all versions including all SNAPSHOT versions. ```ReleaseOnBoundariesVersionRangeResolver``` ```"releaseOnBoundaries"``` Used the ```MavenDefaultVersionRangeResolver``` internally and filters the result. Removes all SNAPSHOT versions at the begin and the end of the resolved versions list until to a released version. ```OnlyReleaseVersionRangeResolver``` ```"onlyReleases"``` Used the ```MavenDefaultVersionRangeResolver``` internally and filters the result. Removes all SNAPSHOT versions at the resolved versions list.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel closed the pull request at:

          https://github.com/apache/maven/pull/56

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel closed the pull request at: https://github.com/apache/maven/pull/56
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user barthel commented on the pull request:

          https://github.com/apache/maven/pull/56#issuecomment-120301859

          I'll open a new pull request with a stashed commit and more explanation.

          Show
          githubbot ASF GitHub Bot added a comment - Github user barthel commented on the pull request: https://github.com/apache/maven/pull/56#issuecomment-120301859 I'll open a new pull request with a stashed commit and more explanation.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user jvanzyl commented on the pull request:

          https://github.com/apache/maven/pull/56#issuecomment-120199784

          I'm generally against changing anything to do with resolving strategies and it has the potential for breaking everything because it's not just what you might use, but what you might publish using your differences and others being exposed to what your assumptions are. So you'll have provide some reasoning. Also note most of this is controlled in Aether. Also, please squash your changes into a single commit.

          Show
          githubbot ASF GitHub Bot added a comment - Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/56#issuecomment-120199784 I'm generally against changing anything to do with resolving strategies and it has the potential for breaking everything because it's not just what you might use, but what you might publish using your differences and others being exposed to what your assumptions are. So you'll have provide some reasoning. Also note most of this is controlled in Aether. Also, please squash your changes into a single commit.
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user barthel opened a pull request:

          https://github.com/apache/maven/pull/56

          MNG-3092: strategy based version resolver

          These changes replaces the default version range resolver with a strategy based version range resolver.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/barthel/maven MNG-3092

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/maven/pull/56.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #56


          commit fa8daaea046ff3acc7d78ad4bb92d4ada49c3eaa
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-06-23T18:04:41Z

          Merge pull request #1 from apache/master

          Merge all commits from apache/master into barthel/master.

          commit 136073cca113b13aa3b5ca09d35c37b99b47a6ce
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-04-30T12:37:52Z

          MNG-3092: Add basal tests for DefaultVersionRangeResolver.

          commit 9a5635e05611b5910b490eccce8f8c58fdef7607
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-02T22:06:00Z

          MNG-3092: Add copy of Maven default version range behaviour.

          Copy the DefaultVersionRangeResolver and add with the new name
          MavenDefaultVersionRangeResolver.
          First step to insert the strategy pattern for different version range
          resolver.

          commit da16089672eaa1f1ee9c6d0fe3349f0aff4cce5f
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-02T22:18:18Z

          MNG-3092: Add release only version range resolver strategy.

          This strategy resolves only released versions within the version range.

          commit f084f6fdd27b805b54c47a821f34221b29179966
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-02T22:23:19Z

          MNG-3092: Add new only released version on boundaries strategy.

          This strategy resolves all versions in version range but only released
          version at the lowest and highest boundary.

          commit 7986e21a2f730ad3af431aa213ff3c280f4c853d
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-03T23:28:36Z

          MNG-3092: Use strategy version range resolver as default.

          Add a new strategy based version range resolver and use
          as default resolver.
          Leave DefaultVersionRangeResolver for backward compatibility
          only.

          commit 62bee372fac0b3bc2a81a2d88971361bba817199
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-04T00:06:38Z

          MNG-3092: Make AbstractVersionRangeTestCase abstract.

          commit 984435cdcbf56447d33f0db2cc00038a422a0e37
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-04T01:32:36Z

          MNG-3092: Configure strategy version range resolver in Guice module

          Replace the DefaultVersionRangeResolver with
          StrategyVersionRangeResolver in MavenAetherModule as default.
          Lazy initialize the version range resolver strategy instance.

          commit 08f6d223d5df64c8c21a522484ad9d5c7969d6fe
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-05T20:17:23Z

          MNG-3092: Add final's and extends JavaDoc.

          Add some final at variables and parameters.
          Add or extend JavaDoc on modified/added classes.

          commit 9010f79b76e1ca97742d1cf095e7aa5fd309d657
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-05T20:33:26Z

          Merge pull request #2 from apache/master

          MNG-5813 pass debug-opts from mvnDebug to mvn script in the additio…

          commit e3ff2d62d3927ee1098dfeee12aa7a0a0f81cd99
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-06T19:44:57Z

          Merge branch 'MNG-3092'

          commit 967ff00b32403b25c5eb16c41d4d91b5fb53f93b
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-06T19:45:08Z

          Merge branch 'master' into MNG-3092

          commit e0ff7b6c23a71f261760d56e2c392158c5f0b575
          Author: barthel <barthel@users.noreply.github.com>
          Date: 2015-07-06T22:18:34Z

          Use RepositorySystemSession#getSystemProperties instead of System#getProperties


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user barthel opened a pull request: https://github.com/apache/maven/pull/56 MNG-3092 : strategy based version resolver These changes replaces the default version range resolver with a strategy based version range resolver. You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/maven MNG-3092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/56.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #56 commit fa8daaea046ff3acc7d78ad4bb92d4ada49c3eaa Author: barthel <barthel@users.noreply.github.com> Date: 2015-06-23T18:04:41Z Merge pull request #1 from apache/master Merge all commits from apache/master into barthel/master. commit 136073cca113b13aa3b5ca09d35c37b99b47a6ce Author: barthel <barthel@users.noreply.github.com> Date: 2015-04-30T12:37:52Z MNG-3092 : Add basal tests for DefaultVersionRangeResolver. commit 9a5635e05611b5910b490eccce8f8c58fdef7607 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-02T22:06:00Z MNG-3092 : Add copy of Maven default version range behaviour. Copy the DefaultVersionRangeResolver and add with the new name MavenDefaultVersionRangeResolver. First step to insert the strategy pattern for different version range resolver. commit da16089672eaa1f1ee9c6d0fe3349f0aff4cce5f Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-02T22:18:18Z MNG-3092 : Add release only version range resolver strategy. This strategy resolves only released versions within the version range. commit f084f6fdd27b805b54c47a821f34221b29179966 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-02T22:23:19Z MNG-3092 : Add new only released version on boundaries strategy. This strategy resolves all versions in version range but only released version at the lowest and highest boundary. commit 7986e21a2f730ad3af431aa213ff3c280f4c853d Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-03T23:28:36Z MNG-3092 : Use strategy version range resolver as default. Add a new strategy based version range resolver and use as default resolver. Leave DefaultVersionRangeResolver for backward compatibility only. commit 62bee372fac0b3bc2a81a2d88971361bba817199 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-04T00:06:38Z MNG-3092 : Make AbstractVersionRangeTestCase abstract. commit 984435cdcbf56447d33f0db2cc00038a422a0e37 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-04T01:32:36Z MNG-3092 : Configure strategy version range resolver in Guice module Replace the DefaultVersionRangeResolver with StrategyVersionRangeResolver in MavenAetherModule as default. Lazy initialize the version range resolver strategy instance. commit 08f6d223d5df64c8c21a522484ad9d5c7969d6fe Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-05T20:17:23Z MNG-3092 : Add final's and extends JavaDoc. Add some final at variables and parameters. Add or extend JavaDoc on modified/added classes. commit 9010f79b76e1ca97742d1cf095e7aa5fd309d657 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-05T20:33:26Z Merge pull request #2 from apache/master MNG-5813 pass debug-opts from mvnDebug to mvn script in the additio… commit e3ff2d62d3927ee1098dfeee12aa7a0a0f81cd99 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-06T19:44:57Z Merge branch ' MNG-3092 ' commit 967ff00b32403b25c5eb16c41d4d91b5fb53f93b Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-06T19:45:08Z Merge branch 'master' into MNG-3092 commit e0ff7b6c23a71f261760d56e2c392158c5f0b575 Author: barthel <barthel@users.noreply.github.com> Date: 2015-07-06T22:18:34Z Use RepositorySystemSession#getSystemProperties instead of System#getProperties
          Hide
          barthel Uwe Barthel added a comment - - edited

          I tried to replace the original DefaultVersionRangeResolver with a version range resolver based on strategy pattern.

          See: https://github.com/barthel/maven/commit/f1918f133f88add280fb8901d843b6c36e4e4be7

          I will create a github pull request to provide my solution.
          (https://issues.apache.org/jira/browse/MNG-3092?focusedCommentId=14622282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14622282)
          Feedback is very welcome.

          Show
          barthel Uwe Barthel added a comment - - edited I tried to replace the original DefaultVersionRangeResolver with a version range resolver based on strategy pattern. See: https://github.com/barthel/maven/commit/f1918f133f88add280fb8901d843b6c36e4e4be7 I will create a github pull request to provide my solution. ( https://issues.apache.org/jira/browse/MNG-3092?focusedCommentId=14622282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14622282 ) Feedback is very welcome.
          Hide
          jonenst Jon Harper added a comment -

          Hi,
          I'm new to this discussion. A first objective is to get the documentation to match the implementation.

          The link (http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution) in the original description of this issue seems to be the only documentation of version ranges. But it is not documentation, it's a design document. People are turning to it because the real documentation is missing. I think that if we fix the real documentation, it will prevent more confusion.

          So I think we need to add documentation to "http://maven.apache.org/pom.html". Right now, it has a section on dependencies stating:

          groupId, artifactId, version:
          These elements are self-explanatory

          I think this is the root of all the pain and frustration in this thread. It's incredibly frustrating and upsetting that this huge issue was being dismissed as "self-explanatory" in the docs the whole time.

          I would be willing to spend time to work and collaborate on improving the documentation.
          Does anyone know who can be contacted to change http://maven.apache.org/pom.html ?

          Show
          jonenst Jon Harper added a comment - Hi, I'm new to this discussion. A first objective is to get the documentation to match the implementation. The link ( http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution ) in the original description of this issue seems to be the only documentation of version ranges. But it is not documentation, it's a design document. People are turning to it because the real documentation is missing. I think that if we fix the real documentation, it will prevent more confusion. So I think we need to add documentation to "http://maven.apache.org/pom.html". Right now, it has a section on dependencies stating: groupId, artifactId, version: These elements are self-explanatory I think this is the root of all the pain and frustration in this thread . It's incredibly frustrating and upsetting that this huge issue was being dismissed as "self-explanatory" in the docs the whole time. I would be willing to spend time to work and collaborate on improving the documentation. Does anyone know who can be contacted to change http://maven.apache.org/pom.html ?
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          Well, at the moment releasing a large cross-cutting change requires some self-discipline, because Maven is not really helping us there. The only safeguard we have is a release CI build that will reject any incompatible changes that rely on the latest snapshots. But working with snapshots locally is often the only way to test a large change before slowly committing the changes in the dependency order and feeding them into the release process.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - Well, at the moment releasing a large cross-cutting change requires some self-discipline, because Maven is not really helping us there. The only safeguard we have is a release CI build that will reject any incompatible changes that rely on the latest snapshots. But working with snapshots locally is often the only way to test a large change before slowly committing the changes in the dependency order and feeding them into the release process.
          Hide
          rvowles Richard Vowles added a comment -

          Yes @Sergei, however you are releasing that snapshot are you not? If we manage to get this plugin working then it would solve your problem as well, but I certainly wouldn't recommend doing so.

          @Casper - I am just one person speaking up about this. Thats what the argument was - too many people rely on the functionality as it is right now, if you change it, you'll break all these and then they'll come complaining on this ticket and we'll get the reverse.

          Show
          rvowles Richard Vowles added a comment - Yes @Sergei, however you are releasing that snapshot are you not? If we manage to get this plugin working then it would solve your problem as well, but I certainly wouldn't recommend doing so. @Casper - I am just one person speaking up about this. Thats what the argument was - too many people rely on the functionality as it is right now, if you change it, you'll break all these and then they'll come complaining on this ticket and we'll get the reverse.
          Hide
          earcam Caspar MacRae added a comment -

          @Richard, I don't want to troll but you've said a lot here from your own perspective, which while entirely valid for your own flavour of version ranges, simply does not work for the semantic versioning most people were implementing before this mess began.

          The way it used to work was specified - supporting semantic versioning without any tricks, purging, double repos or otherwise.

          I agree with you completely on changing the specification, at an absolute minimum consistency should be maintained.

          http://semver.org/
          http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

          Show
          earcam Caspar MacRae added a comment - @Richard, I don't want to troll but you've said a lot here from your own perspective, which while entirely valid for your own flavour of version ranges, simply does not work for the semantic versioning most people were implementing before this mess began. The way it used to work was specified - supporting semantic versioning without any tricks, purging, double repos or otherwise. I agree with you completely on changing the specification, at an absolute minimum consistency should be maintained. http://semver.org/ http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          If you are making cross-cutting changes across multiple projects, you might want to temporarily allow snapshots locally. Likewise, if you load two dependent projects into an IDE, you typically want one of them to resolve to the other, which effectively means resolving to a snapshot.
          What I am missing is simply a command-line switch that would globally allow or disallow resolution of version ranges to snapshots. That'd have eliminated most of the workarounds that we had to implement.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - If you are making cross-cutting changes across multiple projects, you might want to temporarily allow snapshots locally. Likewise, if you load two dependent projects into an IDE, you typically want one of them to resolve to the other, which effectively means resolving to a snapshot. What I am missing is simply a command-line switch that would globally allow or disallow resolution of version ranges to snapshots. That'd have eliminated most of the workarounds that we had to implement.
          Hide
          rvowles Richard Vowles added a comment -

          @Sergei - disk space is cheap - and its a build server, so its even cheaper. We do exactly this and have zero problem.

          On your own machine, you want snapshots to be failing your build with the enforcer plugin, that is a warning to your developers that you might be doing something you didn't intend. If you are releasing something that relies on a snapshot, that snapshot should be released first or purged.

          Show
          rvowles Richard Vowles added a comment - @Sergei - disk space is cheap - and its a build server, so its even cheaper. We do exactly this and have zero problem. On your own machine, you want snapshots to be failing your build with the enforcer plugin, that is a warning to your developers that you might be doing something you didn't intend. If you are releasing something that relies on a snapshot, that snapshot should be released first or purged.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Richard:
          Regarding your yesterday's comment "setting up HEAD builds where snapshots are included (and you want them included) vs a stable build where you aren't including snapshot builds and where you don't want them to be without changing your pom". This is exactly what is not possible now. The whole premise of version ranges is to reduce the amount of POM changes due to shifting dependency versions. Typically you only change your POM if you need to upgrade to the next version range. I do not want to change my settings.xml or keep two alternative versions either.

          At the moment the only way to keep snapshots away from release builds without changing the POMs is to have two separate settings.xml files pointing to different local repositories for snapshot and release builds. You end up downloading the internet twice, but it is a price you pay for build stability. While it is certainly doable in the CI environment, you are still stuffed in your local development if you accidentally pick up or install a snapshot that spoils your version range. Having 1.1.2 and 1.1.3-SNAPSHOT in the local repo will always resolve [1.1, 1.2) to 1.1.3-SNAPSHOT and there is no way around it apart from purging the offending version from the local repo manually.

          Probably worth mentioning that some core plugins still occasionally fail on version ranges, see for example MDEP-364 and MDEP-373. Or MRRESOURCES-58, which is fixed now, but took almost 1.5 years to apply the patch.

          I agree that in fluid projects version ranges work pretty well, as long as you avoid the trip wires (and know what to look out for). I guess, I could also write a small book dedicated to all the various workarounds we had to implement, but I would never be brave enough to claim that "dependency ranges in Maven work beautifully out of the box", because that is a lie.

          @Scott: apologies, my earlier comment about this issue having become a feature was lacking a <sarcasm> tag. I do remember that you and I are viewing this issue from completely different perspectives, but I guess we both hoped that the core Maven team would contribute their insights to this discussion. Which alas never happened.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Richard: Regarding your yesterday's comment "setting up HEAD builds where snapshots are included (and you want them included) vs a stable build where you aren't including snapshot builds and where you don't want them to be without changing your pom " . This is exactly what is not possible now. The whole premise of version ranges is to reduce the amount of POM changes due to shifting dependency versions. Typically you only change your POM if you need to upgrade to the next version range. I do not want to change my settings.xml or keep two alternative versions either. At the moment the only way to keep snapshots away from release builds without changing the POMs is to have two separate settings.xml files pointing to different local repositories for snapshot and release builds. You end up downloading the internet twice, but it is a price you pay for build stability. While it is certainly doable in the CI environment, you are still stuffed in your local development if you accidentally pick up or install a snapshot that spoils your version range. Having 1.1.2 and 1.1.3-SNAPSHOT in the local repo will always resolve [1.1, 1.2) to 1.1.3-SNAPSHOT and there is no way around it apart from purging the offending version from the local repo manually. Probably worth mentioning that some core plugins still occasionally fail on version ranges, see for example MDEP-364 and MDEP-373 . Or MRRESOURCES-58 , which is fixed now, but took almost 1.5 years to apply the patch. I agree that in fluid projects version ranges work pretty well, as long as you avoid the trip wires (and know what to look out for). I guess, I could also write a small book dedicated to all the various workarounds we had to implement, but I would never be brave enough to claim that "dependency ranges in Maven work beautifully out of the box", because that is a lie. @Scott: apologies, my earlier comment about this issue having become a feature was lacking a <sarcasm> tag. I do remember that you and I are viewing this issue from completely different perspectives, but I guess we both hoped that the core Maven team would contribute their insights to this discussion. Which alas never happened.
          Hide
          rvowles Richard Vowles added a comment -

          We use, and many others use Maven version ranges with pleasure. They work exactly as they should, snapshots come into ranges just as they should. As long as you know how they work, you can build easily and cleanly with them. There is no problem here.

          However, Mark and I are doing a spike on a version range resolver plugin that uses the LifecycleParticipant model to change how artifacts are resolved (compile always lowest in a range, test and release always highest). Perhaps you can fork it once its done (if we can get it to work).

          Show
          rvowles Richard Vowles added a comment - We use, and many others use Maven version ranges with pleasure. They work exactly as they should, snapshots come into ranges just as they should. As long as you know how they work, you can build easily and cleanly with them. There is no problem here. However, Mark and I are doing a spike on a version range resolver plugin that uses the LifecycleParticipant model to change how artifacts are resolved (compile always lowest in a range, test and release always highest). Perhaps you can fork it once its done (if we can get it to work).
          Hide
          dahoffer David Hoffer added a comment -

          Yeah I get the idea. Impossible to do so but it would be interesting to know the set of users so turned off by this debacle they stopped/didn't use Maven vs the set of users using the broken feature, but I suspect the former is a much larger size. That being said I concur that Maven shouldn't break builds in existing versions, but that is easily handled. They should fix it now but put the fix behind some optional flag, e.g. command line/settings.xml/etc. Then in a subsequent Maven version upgrade that move that to the default behavior. When they went to 3.0 would have been the ideal time to make the fix but any non-bug fix version change is fine. And...if the Maven devs want to support the 'legacy' broken behavior with an optional flag that is fine too.

          Show
          dahoffer David Hoffer added a comment - Yeah I get the idea. Impossible to do so but it would be interesting to know the set of users so turned off by this debacle they stopped/didn't use Maven vs the set of users using the broken feature, but I suspect the former is a much larger size. That being said I concur that Maven shouldn't break builds in existing versions, but that is easily handled. They should fix it now but put the fix behind some optional flag, e.g. command line/settings.xml/etc. Then in a subsequent Maven version upgrade that move that to the default behavior. When they went to 3.0 would have been the ideal time to make the fix but any non-bug fix version change is fine. And...if the Maven devs want to support the 'legacy' broken behavior with an optional flag that is fine too.
          Hide
          scsosna99 Scott Sosna added a comment -

          Lacking any attempt at a solution, my suggestion to rollback the changes was met with a "can't, projects are already using it" and then later "can't, my projects are already using it." [Am too tired of this debacle to track down complete wording, but you get the idea.]

          Show
          scsosna99 Scott Sosna added a comment - Lacking any attempt at a solution, my suggestion to rollback the changes was met with a "can't, projects are already using it" and then later "can't, my projects are already using it." [Am too tired of this debacle to track down complete wording, but you get the idea.]
          Hide
          dahoffer David Hoffer added a comment -

          Scott, wow I didn't know the reasons why this is still lacking attention after all those years..totally mishandled is an understatement indeed. But what I still don't understand is why did they not think it was in their best interest to take action? Are they trying to kill Maven? I know Maven is loosing interest in the companies & departments I work in because there are too many things, like this, that either don't work or have so many warts that folks just get frustrated and swear they will never use Maven again...is that what the Maven team is looking for?

          Show
          dahoffer David Hoffer added a comment - Scott, wow I didn't know the reasons why this is still lacking attention after all those years..totally mishandled is an understatement indeed. But what I still don't understand is why did they not think it was in their best interest to take action? Are they trying to kill Maven? I know Maven is loosing interest in the companies & departments I work in because there are too many things, like this, that either don't work or have so many warts that folks just get frustrated and swear they will never use Maven again...is that what the Maven team is looking for?
          Hide
          scsosna99 Scott Sosna added a comment -

          Sergei, it's a feature because the Maven3 team abdicated their responsibility and refused - yes, refused - to take action because it wasn't in their best interest. Many suggestions have been made, all were shot down, and the team refused to back out the feature (which, in my opinion and others, would have been appropriate lacking a solution). Now the spec is being changed to fit the bug, and books are being written to formalize it?!? Totally mishandled. Total BS.

          Show
          scsosna99 Scott Sosna added a comment - Sergei, it's a feature because the Maven3 team abdicated their responsibility and refused - yes, refused - to take action because it wasn't in their best interest. Many suggestions have been made, all were shot down, and the team refused to back out the feature (which, in my opinion and others, would have been appropriate lacking a solution). Now the spec is being changed to fit the bug, and books are being written to formalize it?!? Totally mishandled. Total BS.
          Hide
          dahoffer David Hoffer added a comment -

          You can spin this anyway you want but the bottom line is 'The current functionality works fine' is a false statement and 'change the spec' is a horrible idea. As with any software library or tool you want a 'no surprises' implementation, e.g. you want folks that use this feature to walk away saying yeah that worked great...just the way I expected it to work. To say that now the Maven ecosystem can only work with subsets of the possible version numbers that folks will want to use...and yes they all will want to use version 1.0...is a horrible idea.

          If your writing a book or documenting this...I suggest that honesty is the best policy. The spec as stated both makes logical sense and we can agree it has high practical usefulness. So just be honest and tell folks Maven didn't make it on this issue (yet), you might have workarounds but at best they are just that...a hack or workaround...until this issue gets resolved in Maven (if ever).

          ...just a couple more points...if the hack/workaround involves a lot of system configuration changes just to get this to work...that's going to turn off a lot of folks...e.g. give voice to the why is Maven so difficult to work with/etc statements. Also I doubt that your example of [1,2) works in all cases (or lets make it less trivial [1.2.3,4) )...I know it didn't exclude snapshots within that range when I looked at using version ranges several years ago, not sure if it's gotten any better.

          Show
          dahoffer David Hoffer added a comment - You can spin this anyway you want but the bottom line is 'The current functionality works fine' is a false statement and 'change the spec' is a horrible idea. As with any software library or tool you want a 'no surprises' implementation, e.g. you want folks that use this feature to walk away saying yeah that worked great...just the way I expected it to work. To say that now the Maven ecosystem can only work with subsets of the possible version numbers that folks will want to use...and yes they all will want to use version 1.0...is a horrible idea. If your writing a book or documenting this...I suggest that honesty is the best policy. The spec as stated both makes logical sense and we can agree it has high practical usefulness. So just be honest and tell folks Maven didn't make it on this issue (yet), you might have workarounds but at best they are just that...a hack or workaround...until this issue gets resolved in Maven (if ever). ...just a couple more points...if the hack/workaround involves a lot of system configuration changes just to get this to work...that's going to turn off a lot of folks...e.g. give voice to the why is Maven so difficult to work with/etc statements. Also I doubt that your example of [1,2) works in all cases (or lets make it less trivial [1.2.3,4) )...I know it didn't exclude snapshots within that range when I looked at using version ranges several years ago, not sure if it's gotten any better.
          Hide
          rvowles Richard Vowles added a comment -

          Excuse me if I am not understand you here Sergei. Are you saying that you are following good CI build practice by setting up HEAD builds where snapshots are included (and you want them included) vs a stable build where you aren't including snapshot builds and where you don't want them to be without changing your pom?

          I'm not entirely sure I see the problem here? I must be misunderstanding.

          Show
          rvowles Richard Vowles added a comment - Excuse me if I am not understand you here Sergei. Are you saying that you are following good CI build practice by setting up HEAD builds where snapshots are included (and you want them included) vs a stable build where you aren't including snapshot builds and where you don't want them to be without changing your pom? I'm not entirely sure I see the problem here? I must be misunderstanding.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          Yes, it is possible to work around snapshots creeping in at the boundary of version ranges by changing version ranges from e.g. [1.1.0,1.2.0) to [1.1.1, 1.1.999], and this is precisely what our team had been doing in the last three years. That does not mean that "the current functionality works fine". It only means that there is a workaround for one of the cases where it does not work fine. As Mark correctly pointed out, it still does not solve the problem of snapshots creeping in inside the version ranges, and we had to set up a separate local repository for release builds to make sure it was not contaminated with snapshots.

          But in a way it is true that this bug has almost become a feature by now. Given that it's recently reached a mature age of seven without any hint of a resolution, we may as well give up waiting.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - Yes, it is possible to work around snapshots creeping in at the boundary of version ranges by changing version ranges from e.g. [1.1.0,1.2.0) to [1.1.1, 1.1.999], and this is precisely what our team had been doing in the last three years. That does not mean that "the current functionality works fine". It only means that there is a workaround for one of the cases where it does not work fine. As Mark correctly pointed out, it still does not solve the problem of snapshots creeping in inside the version ranges, and we had to set up a separate local repository for release builds to make sure it was not contaminated with snapshots. But in a way it is true that this bug has almost become a feature by now. Given that it's recently reached a mature age of seven without any hint of a resolution, we may as well give up waiting.
          Hide
          mark@talios.com Mark Derricutt added a comment -

          As mentioned in Aether release notes, since 0.9 ( http://wiki.eclipse.org/Aether/New_and_Noteworthy ) Aether has support using 2.* which would resolve anything from 2.0 up to 2.99999999 but NOT 3.0-SNAPSHOT or 3.0. If this was support by maven itself then Richards convention would no longer been needed - correct?

          The other side of the question is ( and I think this has been discussed here and elsewhere ) is that its not that the resolution of "the range" that shouldn't include the SNAPSHOTs but what it chosen from the range. Maven already supports basic filtering of this with snapshot enabled/disabled repositories, but sadly the local repository contains both - I'd rather see SNAPSHOTs be installed into a different localRepository than releases, that would make a) cleaning up snapshots easier b) filtering like we want in this ticket ( this does eventually run off into the question of upper/lower bound resolution as well, but thats a large can with a LOT of worms ).

          Show
          mark@talios.com Mark Derricutt added a comment - As mentioned in Aether release notes, since 0.9 ( http://wiki.eclipse.org/Aether/New_and_Noteworthy ) Aether has support using 2.* which would resolve anything from 2.0 up to 2.99999999 but NOT 3.0-SNAPSHOT or 3.0. If this was support by maven itself then Richards convention would no longer been needed - correct? The other side of the question is ( and I think this has been discussed here and elsewhere ) is that its not that the resolution of "the range" that shouldn't include the SNAPSHOTs but what it chosen from the range. Maven already supports basic filtering of this with snapshot enabled/disabled repositories, but sadly the local repository contains both - I'd rather see SNAPSHOTs be installed into a different localRepository than releases, that would make a) cleaning up snapshots easier b) filtering like we want in this ticket ( this does eventually run off into the question of upper/lower bound resolution as well, but thats a large can with a LOT of worms ).
          Hide
          rvowles Richard Vowles added a comment -

          Its not an easy fix when so many people work perfectly well with it. Change the spec, it is easier. Its going to get worse for you, we are documenting this as a best practice in our new upcoming book

          Show
          rvowles Richard Vowles added a comment - Its not an easy fix when so many people work perfectly well with it. Change the spec, it is easier. Its going to get worse for you, we are documenting this as a best practice in our new upcoming book
          Hide
          dahoffer David Hoffer added a comment -

          It's things like this that give Maven a bad rap. Your explanation precisely explains why this must be fixed. Can you imaging documenting this feature as you describe it? Not sure if that is really all the edge cases that don't work...I doubt it...but even if that were...everyone that read the spec would be asking why did Maven guys do something crazy like that? It would drive every one nuts. Not to mention all the customers of products wondering why there is no 1.0 version (and most likely others). Lets just fix this...then it works like you expect...and you get 1.0 too. (And if that is the only issue...seems an easy fix.)

          Show
          dahoffer David Hoffer added a comment - It's things like this that give Maven a bad rap. Your explanation precisely explains why this must be fixed. Can you imaging documenting this feature as you describe it? Not sure if that is really all the edge cases that don't work...I doubt it...but even if that were...everyone that read the spec would be asking why did Maven guys do something crazy like that? It would drive every one nuts. Not to mention all the customers of products wondering why there is no 1.0 version (and most likely others). Lets just fix this...then it works like you expect...and you get 1.0 too. (And if that is the only issue...seems an easy fix.)
          Hide
          rvowles Richard Vowles added a comment -

          No, of course I am not being sarcastic. We use version ranges all the time everywhere, and it works perfectly well. You always release from 1.1 and never, ever release a 1.0 version. Then [1,2) works entirely as expected. I have used version ranges in my last two major jobs and if you stick that that simple rule, there is absolutely zero problem. We use the bounds plugin to auto pull-up lower bounds, we just released the Maven Tiles plugin and it uses and supports version ranges (http://github.com/repaint-io/maven-tiles), the Groovydoc plugin uses it, the Karma plugin uses it. Version ranges just simply work perfectly well, just start at 1.1.

          Show
          rvowles Richard Vowles added a comment - No, of course I am not being sarcastic. We use version ranges all the time everywhere, and it works perfectly well. You always release from 1.1 and never, ever release a 1.0 version. Then [1,2) works entirely as expected. I have used version ranges in my last two major jobs and if you stick that that simple rule, there is absolutely zero problem. We use the bounds plugin to auto pull-up lower bounds, we just released the Maven Tiles plugin and it uses and supports version ranges ( http://github.com/repaint-io/maven-tiles ), the Groovydoc plugin uses it, the Karma plugin uses it. Version ranges just simply work perfectly well, just start at 1.1.
          Hide
          dahoffer David Hoffer added a comment -

          I'm assuming that's just a sarcastic comment...the feature only works fine if not used. This feature, as specified, would be very useful and a big boost for Maven...not sure if the other newer build systems solve this problem or not...seems Maven should.

          Show
          dahoffer David Hoffer added a comment - I'm assuming that's just a sarcastic comment...the feature only works fine if not used. This feature, as specified, would be very useful and a big boost for Maven...not sure if the other newer build systems solve this problem or not...seems Maven should.
          Hide
          rvowles Richard Vowles added a comment -

          The current functionality works fine, change the spec, that makes it all easier.

          Show
          rvowles Richard Vowles added a comment - The current functionality works fine, change the spec, that makes it all easier.
          Hide
          mkarg Markus Karg added a comment -

          I'd like to subscribe to that. Please lead an active and public discussion on this topic. It feels as if Jason just is ignoring this issue, which is hopefully not the case. So Jason, please chime in, and give us a recap of the work done so far, why this needs seven years, and neither there is a solution, nor a public discussion. If you do not find a solution, at least do not give others the impression that they can rely on you coming up with a solution hence holding back with their ideas due to that.

          Show
          mkarg Markus Karg added a comment - I'd like to subscribe to that. Please lead an active and public discussion on this topic. It feels as if Jason just is ignoring this issue, which is hopefully not the case. So Jason, please chime in, and give us a recap of the work done so far, why this needs seven years, and neither there is a solution, nor a public discussion. If you do not find a solution, at least do not give others the impression that they can rely on you coming up with a solution hence holding back with their ideas due to that.
          Hide
          dahoffer David Hoffer added a comment -

          I concur with Scott, once folks start building systems around the 'bug' it makes it really hard to ever fix. It should have been quickly fixed 7 years ago when first discussed. Now I don't have high hopes for a fix ever. I can't speak about the 3.2.1 speed differences, I haven't noticed much of a difference in build speed across Maven versions. I'm currently using 3.0.5. IMHO, the only downside to the upgrade is you loose the ability to turn off timestamped snapshots which just complicates the whole snapshot issue...but that's a different topic.)

          Show
          dahoffer David Hoffer added a comment - I concur with Scott, once folks start building systems around the 'bug' it makes it really hard to ever fix. It should have been quickly fixed 7 years ago when first discussed. Now I don't have high hopes for a fix ever. I can't speak about the 3.2.1 speed differences, I haven't noticed much of a difference in build speed across Maven versions. I'm currently using 3.0.5. IMHO, the only downside to the upgrade is you loose the ability to turn off timestamped snapshots which just complicates the whole snapshot issue...but that's a different topic.)
          Hide
          scsosna99 Scott Sosna added a comment -

          Yes, you've stated before that the incorrect behavior is a "feature" for you, but in fact it's a backwards-regression "bug" for other and should never have been accepted into the work stream. So regardless of your and other's proposals, until a solution is agreed upon, the incorrect behavior that violates the spec should have been removed years ago; of course, after 7 years it is truly a feature and we are stuck in an unworkable situation.

          My question is what are you going to do when the problem is fixed, evaluates versions based on spec, and likely break your current projects?

          In the meantime, I had someone incorrectly install Maven 3.2.1 today and getting artifacts took substantially longer than with Maven 2.2.1 (not within an IDE).

          Show
          scsosna99 Scott Sosna added a comment - Yes, you've stated before that the incorrect behavior is a "feature" for you, but in fact it's a backwards-regression "bug" for other and should never have been accepted into the work stream. So regardless of your and other's proposals, until a solution is agreed upon, the incorrect behavior that violates the spec should have been removed years ago; of course, after 7 years it is truly a feature and we are stuck in an unworkable situation. My question is what are you going to do when the problem is fixed, evaluates versions based on spec, and likely break your current projects? In the meantime, I had someone incorrectly install Maven 3.2.1 today and getting artifacts took substantially longer than with Maven 2.2.1 (not within an IDE).
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          There is no 'right' way to fix this issue in a sense of choosing one and only one option. Implementing it "as the spec says" will make it totally unusable for other people (including us), who rely on certain aspects of the current behaviour. That is why I am saying that we need a proper solution that will allow a greater degree of configuration. I stand by my opinion that the control of snapshot resolution should be external to the POM. In that way, one could use different resolution strategies in different environments (within IDE, on CI server, for release builds) without the need to make changes to the POM itself. For reference, let me link it back to one of my previous posts here:
          https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=323570&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-323570

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - There is no 'right' way to fix this issue in a sense of choosing one and only one option. Implementing it "as the spec says" will make it totally unusable for other people (including us), who rely on certain aspects of the current behaviour. That is why I am saying that we need a proper solution that will allow a greater degree of configuration. I stand by my opinion that the control of snapshot resolution should be external to the POM. In that way, one could use different resolution strategies in different environments (within IDE, on CI server, for release builds) without the need to make changes to the POM itself. For reference, let me link it back to one of my previous posts here: https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=323570&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-323570
          Hide
          dahoffer David Hoffer added a comment -

          We tried to use version ranges but found it to be impossible to get it to work properly so had to abandon all use of the feature. The 'right' way to fix this is to implement it exactly as the spec says, I've never understood why that is so hard to do.

          Show
          dahoffer David Hoffer added a comment - We tried to use version ranges but found it to be impossible to get it to work properly so had to abandon all use of the feature. The 'right' way to fix this is to implement it exactly as the spec says, I've never understood why that is so hard to do.
          Hide
          scsosna99 Scott Sosna added a comment -

          Certain projects have a work-around, others don't.

          While IntelliJ is my IDE of choice, my shop has a big Eclipse contingent that I can't abandon, so speed still continues to be an issue.

          Show
          scsosna99 Scott Sosna added a comment - Certain projects have a work-around, others don't. While IntelliJ is my IDE of choice, my shop has a big Eclipse contingent that I can't abandon, so speed still continues to be an issue.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          Judging by the comments, we must be the only team that has successfully implemented and used version ranges in a set of 100+ active projects on the back of Maven 3 for the last two years. Yes, MNG-3092 raises its ugly head from time to time, but we managed to work around it. Don't get me wrong, I would love MNG-3092 to be fixed, but only if it is fixed properly. Any band-aid solution will likely cause even more grief and frustration. I cannot see any compelling reason to stay on Maven 2 though, this is effectively a dead end, and I reckon plugin authors will soon start dropping support for Maven 2. By the way (commenting on the earlier reported speed issues), I do not know what happened under the hood in the latest version of IntelliJ IDEA 13, but refreshing and resolving Maven 3 projects is blazing fast now.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - Judging by the comments, we must be the only team that has successfully implemented and used version ranges in a set of 100+ active projects on the back of Maven 3 for the last two years. Yes, MNG-3092 raises its ugly head from time to time, but we managed to work around it. Don't get me wrong, I would love MNG-3092 to be fixed, but only if it is fixed properly. Any band-aid solution will likely cause even more grief and frustration. I cannot see any compelling reason to stay on Maven 2 though, this is effectively a dead end, and I reckon plugin authors will soon start dropping support for Maven 2. By the way (commenting on the earlier reported speed issues), I do not know what happened under the hood in the latest version of IntelliJ IDEA 13, but refreshing and resolving Maven 3 projects is blazing fast now.
          Hide
          earcam Caspar MacRae added a comment - - edited

          I had slim hope that this would soon be closed when I saw this https://github.com/jeluard/semantic-versioning/pull/12 a while back, but the duration and silence on this issue indicate a sizeable whack-a-mole.

          I'd reckon Maven 4 will at least bring a pluggable resolver (as per Andrei Pozolotin's 2nd comment 6Apr13), the parts are available (aether).

          Show
          earcam Caspar MacRae added a comment - - edited I had slim hope that this would soon be closed when I saw this https://github.com/jeluard/semantic-versioning/pull/12 a while back, but the duration and silence on this issue indicate a sizeable whack-a-mole. I'd reckon Maven 4 will at least bring a pluggable resolver (as per Andrei Pozolotin's 2nd comment 6Apr13), the parts are available (aether).
          Hide
          brunojcm Bruno Medeiros added a comment -

          I sadly agree with Scott, the time for hope has gone.

          I use maven as it has no version range feature, I simply pretend it doesn't exist. I tried to use version ranges, migrated a lot of projects, and suddenly, ignoring the spec, the maven team changed the behaviour, with no feasible workaround. I spend days rolling back my changes.

          I'd love to trust and use maven version ranges again, but I face it as dream: if it happens, great. If it doesn't... Well, maybe one day I can have some free time and fork maven to do it right.

          Show
          brunojcm Bruno Medeiros added a comment - I sadly agree with Scott, the time for hope has gone. I use maven as it has no version range feature, I simply pretend it doesn't exist. I tried to use version ranges, migrated a lot of projects, and suddenly, ignoring the spec, the maven team changed the behaviour, with no feasible workaround. I spend days rolling back my changes. I'd love to trust and use maven version ranges again, but I face it as dream: if it happens, great. If it doesn't... Well, maybe one day I can have some free time and fork maven to do it right.
          Hide
          scsosna99 Scott Sosna added a comment -

          EOL'ed or not, we can't migrate as it stands. And after seven years unresolved, I don't understand why you think that passing the buck to the Maven4 team means anything will change: break the spec, refuse to rollback the change that broke the spec, trash most recommendations made, and pass it on. Great.

          Time to consider other options.

          Show
          scsosna99 Scott Sosna added a comment - EOL'ed or not, we can't migrate as it stands. And after seven years unresolved, I don't understand why you think that passing the buck to the Maven4 team means anything will change: break the spec, refuse to rollback the change that broke the spec, trash most recommendations made, and pass it on. Great. Time to consider other options.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Scott: You are probably out of luck, as last month Maven 2.x was unanimously voted to be EOL-ed. See the following thread:
          http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3CCA%2BnPnMyTkdW5atYgDovh2BdHs6O%3DGiNbSzOo0ZMJds6ooWRPkQ%40mail.gmail.com%3E

          I doubt that this issue is going to be resolved in any 3.x builds either, because 3.x seems to be moving into a maintenance mode now (this is my personal impression though). However, I do hope that Jason&Co. will consider this as a high priority for Maven4. I have an impression that Maven4 will bring model changes about, and that may help solving this problem in an elegant way. I would prefer to see a proper solution rather that an attempt to shoehorn some terrible kludge into the existing model. We managed to work around the issue so far by setting up our CI and dev environment in a specific way (see above). Provided that this issue is on the hit list for Maven4, our team can wait.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Scott: You are probably out of luck, as last month Maven 2.x was unanimously voted to be EOL-ed. See the following thread: http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3CCA%2BnPnMyTkdW5atYgDovh2BdHs6O%3DGiNbSzOo0ZMJds6ooWRPkQ%40mail.gmail.com%3E I doubt that this issue is going to be resolved in any 3.x builds either, because 3.x seems to be moving into a maintenance mode now (this is my personal impression though). However, I do hope that Jason&Co. will consider this as a high priority for Maven4. I have an impression that Maven4 will bring model changes about, and that may help solving this problem in an elegant way. I would prefer to see a proper solution rather that an attempt to shoehorn some terrible kludge into the existing model. We managed to work around the issue so far by setting up our CI and dev environment in a specific way (see above). Provided that this issue is on the hit list for Maven4, our team can wait.
          Hide
          dahoffer David Hoffer added a comment -

          I concur with Scott's comment, it was and still is the most critical Maven issue to resolve yet no action. Maven lost an important part of it's functionality because this was not implemented per the spec, it would be a big boost to Maven if it had this feature.

          Show
          dahoffer David Hoffer added a comment - I concur with Scott's comment, it was and still is the most critical Maven issue to resolve yet no action. Maven lost an important part of it's functionality because this was not implemented per the spec, it would be a big boost to Maven if it had this feature.
          Hide
          scsosna99 Scott Sosna added a comment -

          Since the last comments almost a year ago, two new versions have been released (3.1.1 and 3.2.1). Wondering if there's been any other offline discussions about this bug.

          I'll also point out that this bug is 7 years old in July, it's time for someone empowered to get this resolved so those of us still on Maven 2.1.1 can move forward.

          Show
          scsosna99 Scott Sosna added a comment - Since the last comments almost a year ago, two new versions have been released (3.1.1 and 3.2.1). Wondering if there's been any other offline discussions about this bug. I'll also point out that this bug is 7 years old in July, it's time for someone empowered to get this resolved so those of us still on Maven 2.1.1 can move forward.
          Hide
          andrei.pozolotin Andrei Pozolotin added a comment -
          Show
          andrei.pozolotin Andrei Pozolotin added a comment - What do think abut this proposal: RFP: Version Range Policy http://mail-archives.apache.org/mod_mbox/maven-dev/201304.mbox/%3C5165A10F.50107@gmail.com%3E
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Nils: thanks for reminding of MNG-4751. I do actually remember now that I came across that ill-fated attempt to alter version resolution behaviour a few years ago. What is of particular relevance to our current discussion here is the e-mail thread that is linked from MNG-4751. If you read through the entire e-mail discussion, you'll come across a proposed solution that is astonishingly similar to what I suggested above. Only that the original participants thought it up 2.5 years ago. And it does also look like Benjamin's proposal was driven by the same or very similar use case.
          What I do like even more is a separate new ~/.m2/resolutions.xml descriptor proposed by Mark. For one thing, it fits well with the other concepts, e.g. settings or toolchains, where an alternative descriptor can be specified on mvn command line. And additionally, it solves a whole bunch of problems at once:

          • there is no need to modify POM file model or introduce new semantics into version range definitions
          • there is no need to modify settings.xml model
          • there is no need to modify version ranges in the project POM to achieve different resolution behaviour
          • complete flexibility to mix and match snapshot/release resolution behaviour for different groups of upstream dependencies
          • and also (looking a bit ahead) the same file could be used to specify alternative pluggable version ordering rules for artifacts that deviate from the standard versioning pattern (cf rule definitions in versions-maven-plugin)
          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Nils: thanks for reminding of MNG-4751 . I do actually remember now that I came across that ill-fated attempt to alter version resolution behaviour a few years ago. What is of particular relevance to our current discussion here is the e-mail thread that is linked from MNG-4751 . If you read through the entire e-mail discussion, you'll come across a proposed solution that is astonishingly similar to what I suggested above. Only that the original participants thought it up 2.5 years ago. And it does also look like Benjamin's proposal was driven by the same or very similar use case . What I do like even more is a separate new ~/.m2/resolutions.xml descriptor proposed by Mark . For one thing, it fits well with the other concepts, e.g. settings or toolchains, where an alternative descriptor can be specified on mvn command line. And additionally, it solves a whole bunch of problems at once: there is no need to modify POM file model or introduce new semantics into version range definitions there is no need to modify settings.xml model there is no need to modify version ranges in the project POM to achieve different resolution behaviour complete flexibility to mix and match snapshot/release resolution behaviour for different groups of upstream dependencies and also (looking a bit ahead) the same file could be used to specify alternative pluggable version ordering rules for artifacts that deviate from the standard versioning pattern (cf rule definitions in versions-maven-plugin )
          Hide
          Nils Nils Christian Ehmke added a comment -

          I digged through the Maven Code last week and I'm surprised that no one has mentioned MNG-4751 in any comment of this issue.
          On 8/Apr/2010, there was a change by Benjamin Bentmann with MNG-3092 in the commit comment. The change modified the Restriction-class so that SNAPSHOTS would only be allowed if a boundary contained a SNAPSHOT.
          The change was reverted on 15/Sep/2010 because of MNG-4751 ("Even with a snapshot dependency in the pom, a release version is included in the classpath for compilation", if another dependency contains a version range with release-boundaries for this artifact).

          I therefore think, this issues (MNG-3092) can only be solved by some kind of soft restriction. A range with release-boundary must be able to include SNAPSHOT-dependencies, but release-dependencies should have preference.

          Show
          Nils Nils Christian Ehmke added a comment - I digged through the Maven Code last week and I'm surprised that no one has mentioned MNG-4751 in any comment of this issue. On 8/Apr/2010, there was a change by Benjamin Bentmann with MNG-3092 in the commit comment. The change modified the Restriction-class so that SNAPSHOTS would only be allowed if a boundary contained a SNAPSHOT. The change was reverted on 15/Sep/2010 because of MNG-4751 ("Even with a snapshot dependency in the pom, a release version is included in the classpath for compilation", if another dependency contains a version range with release-boundaries for this artifact). I therefore think, this issues ( MNG-3092 ) can only be solved by some kind of soft restriction. A range with release-boundary must be able to include SNAPSHOT-dependencies, but release-dependencies should have preference.
          Hide
          scsosna99 Scott Sosna added a comment -

          @Mark Hobson
          Glad you're also seeing performance issues. Do we have any idea in what situations we're seeing degredation? Would rather not just open an issue that says "maven slow, fix please" without any direction. I don't know enough about the aether library to know what it's trying to do or why it was integrated in. But if not, I can just open an issue.

          Show
          scsosna99 Scott Sosna added a comment - @Mark Hobson Glad you're also seeing performance issues. Do we have any idea in what situations we're seeing degredation? Would rather not just open an issue that says "maven slow, fix please" without any direction. I don't know enough about the aether library to know what it's trying to do or why it was integrated in. But if not, I can just open an issue.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Mark:

          The workflow with version ranges should be the same as with soft versions (snapshot, release, snapshot), only now we're changing the upper bound instead. The release plugin helps automate this currently and there's no reason why it couldn't also help with version ranges too.

          I may be missing the point, but please explain to me how the release plugin is supposed to manage dependencies in downstream projects. The release plugin only does update the artifact version in the project that is being released. It does not update dependency versions in the dependent projects (unless they are modules in the same reactor) and never did. Moreover, if project A depends on a snapshot version of project B, the release plugin will fail to release project A until the dependency on B is changed to release version. One of the reasons we are using version ranges is to avoid unnecessary switching between snapshot and release dependencies through editing the POM files.

          At the moment, suppose we have the following dependency chain (-> means "depends on"):
          A -> B:[2.0,3.0) -> C:[1.3,1.4) -> D:[3.5,4.0)

          Suppose one makes a trivial bug fix to upstream library D and wants to test its effect locally in downstream project A before releasing both D and A. At the moment, any change in D is automatically picked up by version resolution in A, as long as the snapshot version of D stays in the defined range.
          If we go down the route you are suggesting, does that mean that one would need to change the whole chain of dependencies to the following, and build local snapshots of all 4 projects in the reverse order?
          A -> B:[2.0-SNAPSHOT,3.0) -> C:[1.3-SHAPSHOT,1.4) -> D:[3.5-SNAPSHOT,4.0)

          Suppose it is not a chain, but a graph of dependencies, which is more like we typically have in the real world. Imagine a typical developer working through the graph, updating dependency versions in POMs to snapshots along the effective dependency path? This is where blind hatred of Maven starts. And how will version resolution work if one branch of the graph allows snapshots in ranges and the other does not?

          Again, I apologise if I am missing the point, but can somebody please provide an example of a detailed development and release workflow if we go down the route of explicitly specifying snapshots in version ranges.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @ Mark : The workflow with version ranges should be the same as with soft versions (snapshot, release, snapshot), only now we're changing the upper bound instead. The release plugin helps automate this currently and there's no reason why it couldn't also help with version ranges too. I may be missing the point, but please explain to me how the release plugin is supposed to manage dependencies in downstream projects. The release plugin only does update the artifact version in the project that is being released. It does not update dependency versions in the dependent projects (unless they are modules in the same reactor) and never did. Moreover, if project A depends on a snapshot version of project B, the release plugin will fail to release project A until the dependency on B is changed to release version. One of the reasons we are using version ranges is to avoid unnecessary switching between snapshot and release dependencies through editing the POM files. At the moment, suppose we have the following dependency chain (-> means "depends on"): A -> B:[2.0,3.0) -> C:[1.3,1.4) -> D:[3.5,4.0) Suppose one makes a trivial bug fix to upstream library D and wants to test its effect locally in downstream project A before releasing both D and A. At the moment, any change in D is automatically picked up by version resolution in A, as long as the snapshot version of D stays in the defined range. If we go down the route you are suggesting, does that mean that one would need to change the whole chain of dependencies to the following, and build local snapshots of all 4 projects in the reverse order? A -> B:[2.0-SNAPSHOT,3.0) -> C:[1.3-SHAPSHOT,1.4) -> D:[3.5-SNAPSHOT,4.0) Suppose it is not a chain, but a graph of dependencies, which is more like we typically have in the real world. Imagine a typical developer working through the graph, updating dependency versions in POMs to snapshots along the effective dependency path? This is where blind hatred of Maven starts. And how will version resolution work if one branch of the graph allows snapshots in ranges and the other does not? Again, I apologise if I am missing the point, but can somebody please provide an example of a detailed development and release workflow if we go down the route of explicitly specifying snapshots in version ranges.
          Hide
          kunalsomani Kunalkumar Somani added a comment - - edited

          @Andrei Pozolotin, I have already attached the patch in this thread.

          Show
          kunalsomani Kunalkumar Somani added a comment - - edited @Andrei Pozolotin, I have already attached the patch in this thread.
          Hide
          mihobson Mark Hobson added a comment -

          Hi all, good to see some discussion on this long-standing issue! This is not currently a pressing issue for me, hence my absence, but it's a big thorn in Maven's side that I'd love to see removed.

          Re-reading the comments here, I see three main issues:

          1) The original problem of not being able to control version ranges resolving to snapshots
          2) How to perform CI with projects that use version ranges
          3) A degradation of performance in Maven3 when resolving version ranges

          The latter performance problem (3) should be raised as a separate issue if one does not exist already. I have witnessed this and doubt that there would be any objections to fixing it.

          The CI problem (2) appears orthogonal to the original issue. How to build the latest versions of projects against each other in CI is a problem that currently exists without version ranges. A mechanism to support real continuous integration between project builds sounds like a separate feature request, whether they use soft versions or version ranges.

          I don't buy the argument that a flag is required to change version range resolution behaviour just because updating dependency versions in POMs takes too much time. The workflow with version ranges should be the same as with soft versions (snapshot, release, snapshot), only now we're changing the upper bound instead. The release plugin helps automate this currently and there's no reason why it couldn't also help with version ranges too.

          This leaves us with the original issue which I believe just needs to be fixed. I'm happy to help discuss this particular issue with the rest of the development team so we can close this long-standing bug. Satisfying everyone's particular workflow is going to be out of scope for this issue, so I'd suggest raising new issues for your specific use-cases.

          Show
          mihobson Mark Hobson added a comment - Hi all, good to see some discussion on this long-standing issue! This is not currently a pressing issue for me, hence my absence, but it's a big thorn in Maven's side that I'd love to see removed. Re-reading the comments here, I see three main issues: 1) The original problem of not being able to control version ranges resolving to snapshots 2) How to perform CI with projects that use version ranges 3) A degradation of performance in Maven3 when resolving version ranges The latter performance problem (3) should be raised as a separate issue if one does not exist already. I have witnessed this and doubt that there would be any objections to fixing it. The CI problem (2) appears orthogonal to the original issue. How to build the latest versions of projects against each other in CI is a problem that currently exists without version ranges. A mechanism to support real continuous integration between project builds sounds like a separate feature request, whether they use soft versions or version ranges. I don't buy the argument that a flag is required to change version range resolution behaviour just because updating dependency versions in POMs takes too much time. The workflow with version ranges should be the same as with soft versions (snapshot, release, snapshot), only now we're changing the upper bound instead. The release plugin helps automate this currently and there's no reason why it couldn't also help with version ranges too. This leaves us with the original issue which I believe just needs to be fixed. I'm happy to help discuss this particular issue with the rest of the development team so we can close this long-standing bug. Satisfying everyone's particular workflow is going to be out of scope for this issue, so I'd suggest raising new issues for your specific use-cases.
          Hide
          zour Sascha Becher added a comment -

          Putting the version range resolver into a user plugin sounds great. Is this feasable?

          Show
          zour Sascha Becher added a comment - Putting the version range resolver into a user plugin sounds great. Is this feasable?
          Hide
          andrei.pozolotin Andrei Pozolotin added a comment -

          @Jason

          1) do you think maven should follow OSGI semantic version model more closely?
          http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
          that could be a base ground for maven ranges rules.

          2) do you think version range resolver could be made into an extension
          which could be replaced via user plugin?

          thank you.

          Show
          andrei.pozolotin Andrei Pozolotin added a comment - @Jason 1) do you think maven should follow OSGI semantic version model more closely? http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf that could be a base ground for maven ranges rules. 2) do you think version range resolver could be made into an extension which could be replaced via user plugin? thank you.
          Hide
          andrei.pozolotin Andrei Pozolotin added a comment -

          @Kunalkumar re: your changed maven code

          • can you please share where is it?
          • can we collaborate on releasing it?
          • can it be incorporated in a form of "extension" (so there is no need for maven 3 re-install)?
            thank you.
          Show
          andrei.pozolotin Andrei Pozolotin added a comment - @Kunalkumar re: your changed maven code can you please share where is it? can we collaborate on releasing it? can it be incorporated in a form of "extension" (so there is no need for maven 3 re-install)? thank you.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Scott:

          45 minutes is clearly abnormal: it takes me about 5 minutes to refresh all our 100+ Maven3 projects configured within an uber-project in IDEA, or 10 minutes if IDEA needs to rebuild indexes. Either M2E is going around in circles and trying to resolve dependencies thousands of times, or there is something in your environment that causes massive delays.

          Please make sure that your settings.xml file has a mirror section that redirects all requests to 'central' to your Artifactory instance. Otherwise Maven may attempt to fall back to looking any missing artifacts in central (it's hardcoded in Maven and cannot be switched off!). If you are behind a proxy server, these requests will be blocked, if you happen to have direct access to the internet, then you'll be hammering central with requests for your internal artifacts, which is bad news for both you (it takes considerable time and creates a security risk) and maven central (it has to handle all those unnecessary requests). Try to activate debug logging in both Artifactory and Maven/M2E and make sure it is not attempting to do any silly things.

          For reference, we have got the following sections in settings.xml (all names changed to protect the innocent):

              <mirrors>
                  <mirror>
                      <id>internal-mirror</id>
                      <name>Internal Maven repo, proxying to external repos, including central</name>
                      <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
                      <mirrorOf>external:*,our-artifact-releases,our-plugin-releases,!our-artifact-snapshots</mirrorOf>
                  </mirror>
              </mirrors>
          
              <profiles>
                  <profile>
                      <id>our-releases</id>
                      <repositories>
                          <repository>
                              <id>our-artifact-releases</id>
                              <name>Our Release Repository</name>
                              <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
                              <releases>
                                  <enabled>true</enabled>
                              </releases>
                              <snapshots>
                                  <enabled>false</enabled>
                              </snapshots>
                          </repository>
                      </repositories>
                      <pluginRepositories>
                          <pluginRepository>
                              <id>our-plugin-releases</id>
                              <name>Our Release Repository</name>
                              <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
                              <releases>
                                  <enabled>true</enabled>
                              </releases>
                              <snapshots>
                                  <enabled>false</enabled>
                              </snapshots>
                          </pluginRepository>
                      </pluginRepositories>
                  </profile>
                  <profile>
                      <id>our-snapshots</id>
                      <repositories>
                          <repository>
                              <id>our-artifact-snapshots</id>
                              <name>Our Snapshot Repository</name>
                              <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/repositories/snapshots</url>
                              <releases>
                                  <enabled>false</enabled>
                              </releases>
                              <snapshots>
                                  <enabled>true</enabled>
                              </snapshots>
                          </repository>
                      </repositories>
                  </profile>
              </profiles>
              <activeProfiles>
                  <activeProfile>our-releases</activeProfile>
              </activeProfiles>
          

          Please note that the our-snapshots profile is not active by default. This is to block remote shapshots if one does not want to download them.

          @Jesse:

          Please keep in mind that Maven3 creates a number of maven-metadata.xml files in the local repo:

          1. At groupId/artifactId level it creates a maven-metadata-<repo/mirror name>.xml file for every remote repo or a mirror that is configured in POM or settings.xml. Additionally, it creates maven-metadata-local.xml file that reflects local artifact installs.
          2. At groupId/artifactId/version level it creates maven-metadata-local.xml file for local artifact installs only.

          Deleting all locally cached snapshot directories under groupId/artifactId directory without updating or purging the top-level metadata files is a recipe for trouble. Stale version references in metadata files will make Maven believe that those snapshots still exist, and it will desperately try to download metadata and artifacts for the "missing" snapshot versions.

          I suspect that you may have a cron job that purges snapshots from the local repo daily, but does not do it in a clean way. As a result, "one build per day spends a chunk of time" attempting to fetch these missing snapshots from elsewhere.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Scott: 45 minutes is clearly abnormal: it takes me about 5 minutes to refresh all our 100+ Maven3 projects configured within an uber-project in IDEA, or 10 minutes if IDEA needs to rebuild indexes. Either M2E is going around in circles and trying to resolve dependencies thousands of times, or there is something in your environment that causes massive delays. Please make sure that your settings.xml file has a mirror section that redirects all requests to 'central' to your Artifactory instance. Otherwise Maven may attempt to fall back to looking any missing artifacts in central (it's hardcoded in Maven and cannot be switched off!). If you are behind a proxy server, these requests will be blocked, if you happen to have direct access to the internet, then you'll be hammering central with requests for your internal artifacts, which is bad news for both you (it takes considerable time and creates a security risk) and maven central (it has to handle all those unnecessary requests). Try to activate debug logging in both Artifactory and Maven/M2E and make sure it is not attempting to do any silly things. For reference, we have got the following sections in settings.xml (all names changed to protect the innocent): <mirrors> <mirror> <id> internal-mirror </id> <name> Internal Maven repo, proxying to external repos, including central </name> <url> http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public </url> <mirrorOf> external:*,our-artifact-releases,our-plugin-releases,!our-artifact-snapshots </mirrorOf> </mirror> </mirrors> <profiles> <profile> <id> our-releases </id> <repositories> <repository> <id> our-artifact-releases </id> <name> Our Release Repository </name> <url> http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public </url> <releases> <enabled> true </enabled> </releases> <snapshots> <enabled> false </enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id> our-plugin-releases </id> <name> Our Release Repository </name> <url> http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public </url> <releases> <enabled> true </enabled> </releases> <snapshots> <enabled> false </enabled> </snapshots> </pluginRepository> </pluginRepositories> </profile> <profile> <id> our-snapshots </id> <repositories> <repository> <id> our-artifact-snapshots </id> <name> Our Snapshot Repository </name> <url> http://our-repo.fm.rbsgrp.net:8081/nexus/content/repositories/snapshots </url> <releases> <enabled> false </enabled> </releases> <snapshots> <enabled> true </enabled> </snapshots> </repository> </repositories> </profile> </profiles> <activeProfiles> <activeProfile> our-releases </activeProfile> </activeProfiles> Please note that the our-snapshots profile is not active by default. This is to block remote shapshots if one does not want to download them. @Jesse: Please keep in mind that Maven3 creates a number of maven-metadata.xml files in the local repo: At groupId/artifactId level it creates a maven-metadata-<repo/mirror name>.xml file for every remote repo or a mirror that is configured in POM or settings.xml . Additionally, it creates maven-metadata-local.xml file that reflects local artifact installs. At groupId/artifactId/version level it creates maven-metadata-local.xml file for local artifact installs only. Deleting all locally cached snapshot directories under groupId/artifactId directory without updating or purging the top-level metadata files is a recipe for trouble. Stale version references in metadata files will make Maven believe that those snapshots still exist, and it will desperately try to download metadata and artifacts for the "missing" snapshot versions. I suspect that you may have a cron job that purges snapshots from the local repo daily, but does not do it in a clean way. As a result, "one build per day spends a chunk of time" attempting to fetch these missing snapshots from elsewhere.
          Hide
          jglick Jesse Glick added a comment -

          An example using Maven 3.0.5: https://github.com/stapler/stapler-adjunct-codemirror/commit/da995b03a1f165fef7c9d34eadb15797f58399cd shows the workaround for what I take to be this issue. In versions of Jenkins using stapler-adjunct-codemirror 1.1 prior to this change?and plugins depending on those versions of Jenkins?at least one build per day spends a chunk of time (10?20s?) looking for nonexistent SNAPSHOT versions of a transitive dependency.

          (Where it gets these version numbers from, I have no idea?the Artifactory mirror makes no mention of such versions in maven-metadata.xml, and the occurrences in my local repo are all freshly created resolver-status.properties and stapler-1.176-SNAPSHOT.pom.lastUpdated files which list only ?errors? and soon get recreated if I delete them.)

          Maven 2.2.1 also downloads 1.208-SNAPSHOT, which does exist, but none of these intermediate versions.

          I have also encountered builds that failed trying to find one of these nonexistent snapshots, though I cannot now reproduce this problem.

          Show
          jglick Jesse Glick added a comment - An example using Maven 3.0.5: https://github.com/stapler/stapler-adjunct-codemirror/commit/da995b03a1f165fef7c9d34eadb15797f58399cd shows the workaround for what I take to be this issue. In versions of Jenkins using stapler-adjunct-codemirror 1.1 prior to this change?and plugins depending on those versions of Jenkins?at least one build per day spends a chunk of time (10?20s?) looking for nonexistent SNAPSHOT versions of a transitive dependency. (Where it gets these version numbers from, I have no idea?the Artifactory mirror makes no mention of such versions in maven-metadata.xml , and the occurrences in my local repo are all freshly created resolver-status.properties and stapler-1.176-SNAPSHOT.pom.lastUpdated files which list only ?errors? and soon get recreated if I delete them.) Maven 2.2.1 also downloads 1.208-SNAPSHOT, which does exist, but none of these intermediate versions. I have also encountered builds that failed trying to find one of these nonexistent snapshots, though I cannot now reproduce this problem.
          Hide
          scsosna99 Scott Sosna added a comment -

          We use Artifactory, I've looked before and saw nothing in the logs but I'll review again. Regardless, the time spent resolving via Maven2 is substantially less than through Maven3, and what I notice is that on a version range it seems to continually pull down/review all metadata rather than the latest version. For the m2e Eclipse plugin, it can cause simple projects (A depends on B depends on C) to take 45+ minutes to update.

          The project dependency graph is fairly simple, no circular loops, just a simple tree (at most 4 levels deep, but mostly 2 or 3). At minimum we have 1 new snapshot per day, but often more than that, each with its own build number. I've tried deleting decently-old snapshots, but hasn't helped performance much. This shouldn't be considered too complex by any stretch of the imagination.

          Show
          scsosna99 Scott Sosna added a comment - We use Artifactory, I've looked before and saw nothing in the logs but I'll review again. Regardless, the time spent resolving via Maven2 is substantially less than through Maven3, and what I notice is that on a version range it seems to continually pull down/review all metadata rather than the latest version. For the m2e Eclipse plugin, it can cause simple projects (A depends on B depends on C) to take 45+ minutes to update. The project dependency graph is fairly simple, no circular loops, just a simple tree (at most 4 levels deep, but mostly 2 or 3). At minimum we have 1 new snapshot per day, but often more than that, each with its own build number. I've tried deleting decently-old snapshots, but hasn't helped performance much. This shouldn't be considered too complex by any stretch of the imagination.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Scott:

          I have never seen dependency resolution under Maven3 taking minutes in our environment, even though we are using version ranges for internal dependencies quite extensively (both deep and wide, about 100+ internal applications/libraries in our project all in all). From what we have seen, metadata update is the real performance killer, especially if one runs Maven with -U option to force it checking for new versions in the remote repo. And with version ranges in a fluid environment we are effectively forced to use -U aggressively, otherwise we end up relying on Maven's metadata caching strategies, which introduces an element of uncertainty.

          A number of times we ended up with really slow metadata update and dependency resolution. Every time we checked Nexus logs and found out that it was (a) trying to download metadata for internal artifacts from external repos (which is also pretty bad from security point of view), or (b) that some external repos got reconfigured/relocated (happened recently to Netbeans repo), or (c) that some artifacts got relocated or were not accessible anymore. Each time, after fixing repo configuration, routing rules, blacklisting/whitelisting or caching strategies we managed to bring performance of the dependency resolution back to acceptable levels.

          If you have not already done so, may I suggest that you analyse the behaviour of your repo manager, and try to make sure that the metadata update checks for your artifacts are not being slowed down by unnecessarily proxying those metadata requests to e.g. Maven Central. If repo manager is not your bottleneck, then it may still be the case that you have genuinely reached the point where performance of Maven3 went downhill because of the complexity of your system.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Scott: I have never seen dependency resolution under Maven3 taking minutes in our environment, even though we are using version ranges for internal dependencies quite extensively (both deep and wide, about 100+ internal applications/libraries in our project all in all). From what we have seen, metadata update is the real performance killer, especially if one runs Maven with -U option to force it checking for new versions in the remote repo. And with version ranges in a fluid environment we are effectively forced to use -U aggressively, otherwise we end up relying on Maven's metadata caching strategies, which introduces an element of uncertainty. A number of times we ended up with really slow metadata update and dependency resolution. Every time we checked Nexus logs and found out that it was (a) trying to download metadata for internal artifacts from external repos (which is also pretty bad from security point of view), or (b) that some external repos got reconfigured/relocated (happened recently to Netbeans repo), or (c) that some artifacts got relocated or were not accessible anymore. Each time, after fixing repo configuration, routing rules, blacklisting/whitelisting or caching strategies we managed to bring performance of the dependency resolution back to acceptable levels. If you have not already done so, may I suggest that you analyse the behaviour of your repo manager, and try to make sure that the metadata update checks for your artifacts are not being slowed down by unnecessarily proxying those metadata requests to e.g. Maven Central. If repo manager is not your bottleneck, then it may still be the case that you have genuinely reached the point where performance of Maven3 went downhill because of the complexity of your system.
          Hide
          scsosna99 Scott Sosna added a comment -

          @Sergei Our experience with Maven3 and version ranges is substantially, exponentially slower - going from seconds to minutes, depending on the depth and breadth of versions involved. Straight dependency resolution with absolute version numbers appears normal.

          Agree with @Sergei about Eclipse/Maven integration, I actually refuse to use Eclipse but there are some team members who live and die by it, even though IntelliJ Community Version does everything necessary - with absolutely rockin' Maven integration.

          Show
          scsosna99 Scott Sosna added a comment - @Sergei Our experience with Maven3 and version ranges is substantially, exponentially slower - going from seconds to minutes, depending on the depth and breadth of versions involved. Straight dependency resolution with absolute version numbers appears normal. Agree with @Sergei about Eclipse/Maven integration, I actually refuse to use Eclipse but there are some team members who live and die by it, even though IntelliJ Community Version does everything necessary - with absolutely rockin' Maven integration.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Scott, Joniec, Kunalkumar and other recent contributors to the discussion

          Setting the differences aside, we have got two things in common:

          1. all of us want this issue to be resolved in some way
          2. none of us are Maven committers

          I would like to join Scott in his plea to hear at least something from people who are responsible for pushing Maven forward. The latest comments from Jason were submitted more than 4 months ago, and nothing has been heard since. MNG-3092 probably holds a number of records: as the longest-standing, the most watched and the most voted for issue. It is frustrating to see that nothing is being done about it.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Scott, Joniec, Kunalkumar and other recent contributors to the discussion Setting the differences aside, we have got two things in common: all of us want this issue to be resolved in some way none of us are Maven committers I would like to join Scott in his plea to hear at least something from people who are responsible for pushing Maven forward. The latest comments from Jason were submitted more than 4 months ago, and nothing has been heard since. MNG-3092 probably holds a number of records: as the longest-standing, the most watched and the most voted for issue. It is frustrating to see that nothing is being done about it.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          Our experience was that Maven2 resolved dependencies in a rather unpredictable way when faced a combination of version ranges, transitive dependencies with their own version ranges and dependency management. As far as I remember, the whole idea of Aether was to provide a more correct and deterministic dependency resolution for Maven3. This is not an easy undertaking, and OSGi folks (who are using version ranges a lot) faced it as well: I vaguely remember reading an article that claimed that dependency resolution in OSGi is an NP-complete task. That is, you have to trade speed for correctness.

          We have never had problems with dependency resolution in Maven3, and I am not finding it much slower than Maven2, although I must admit I haven't run Maven2 for ages. Most of our in-house maven plugins require features from Maven3, thus we cannot go back to Maven2 even if we wanted to.

          Another thing to mention is that we are not using Eclipse in the team. All our team members moved from Eclipse to IntelliJ IDEA simply because Maven support in Eclipse was rubbish, while everything worked out of the box in IDEA. Based on that prior experience, I still do not trust M2E, and I won't be surprised to learn that it may be introducing more problems in addition to the one we are discussing here.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - Our experience was that Maven2 resolved dependencies in a rather unpredictable way when faced a combination of version ranges, transitive dependencies with their own version ranges and dependency management. As far as I remember, the whole idea of Aether was to provide a more correct and deterministic dependency resolution for Maven3. This is not an easy undertaking, and OSGi folks (who are using version ranges a lot) faced it as well: I vaguely remember reading an article that claimed that dependency resolution in OSGi is an NP-complete task. That is, you have to trade speed for correctness. We have never had problems with dependency resolution in Maven3, and I am not finding it much slower than Maven2, although I must admit I haven't run Maven2 for ages. Most of our in-house maven plugins require features from Maven3, thus we cannot go back to Maven2 even if we wanted to. Another thing to mention is that we are not using Eclipse in the team. All our team members moved from Eclipse to IntelliJ IDEA simply because Maven support in Eclipse was rubbish, while everything worked out of the box in IDEA. Based on that prior experience, I still do not trust M2E, and I won't be surprised to learn that it may be introducing more problems in addition to the one we are discussing here.
          Hide
          scsosna99 Scott Sosna added a comment -

          @Sergei
          I realize there's a new dependency management library, I also know it flat-out does not perform, and from aether's introduction there were problems. From what I can tell, it was prematurely introduced, some bugs have been fixed, but performance with ranges bites. I don't agree about Maven2, I heavily rely on version ranges with SNAPSHOTs and have no problems, whereas Maven3 is absolutely unusable in its current form. Sure, it appears that reverting to Maven2 is going to be a lot of work, but fixing Maven3 might be more. Don't know how an issue as substantial as this was not addressed prior to the new dependency management library and related changes being released.

          To make our projects work in Eclipse, developers run maven outside of Eclipse to resolve the ranges, go back into Eclipse and refresh dependencies. And when they want to get latest/greatest, they have to get a fresh pom.xml and repeat. Royal PITA. And because the m2e project insists that an embedded Maven3 is required for resolving dependencies, there's no workaround other than rewriting the plugin myself (not trivial, do not have the time), and in the meantime I'm dealing with upset developers

          Without the issue being resolved soon, I don't believe I'm the only one who will need to consider options outside of Maven.

          Show
          scsosna99 Scott Sosna added a comment - @Sergei I realize there's a new dependency management library, I also know it flat-out does not perform, and from aether's introduction there were problems. From what I can tell, it was prematurely introduced, some bugs have been fixed, but performance with ranges bites. I don't agree about Maven2, I heavily rely on version ranges with SNAPSHOTs and have no problems, whereas Maven3 is absolutely unusable in its current form. Sure, it appears that reverting to Maven2 is going to be a lot of work, but fixing Maven3 might be more. Don't know how an issue as substantial as this was not addressed prior to the new dependency management library and related changes being released. To make our projects work in Eclipse, developers run maven outside of Eclipse to resolve the ranges, go back into Eclipse and refresh dependencies. And when they want to get latest/greatest, they have to get a fresh pom.xml and repeat. Royal PITA. And because the m2e project insists that an embedded Maven3 is required for resolving dependencies, there's no workaround other than rewriting the plugin myself (not trivial, do not have the time), and in the meantime I'm dealing with upset developers Without the issue being resolved soon, I don't believe I'm the only one who will need to consider options outside of Maven.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          Joniec,

          We have already waited for 6 long years and this issue is still unsolved. If we have a solution that works with command line maven and can be used in CI tools, I'll be happy to wait until IDEs catch up. We have already been in such situation with incompatible changes in tools and libraries, and it's part of software evolution.

          To your question. Whenever I want to release a SNAPSHOT of one of our projects, I open our Jenkins page, find the release build for the project and press a "Perform Maven Release" button. This in turn kicks off command line maven with the equivalent of mvn -B release:prepare-with-pom release:perform command, with a couple of additional options specific to our build environment.

          I do not have to edit the project's POM before release, because for our release builds version ranges are resolved from release repositories only, and the release builds are configured with a separate local repo. I have already described our set-up above. All this hassle is to circumvent this very MNG-3092 and avoid unnecessary editing of POM files.

          Neither do I have to constantly edit version ranges in the dependent downstream projects, save for the cases when a major release of upstream dependency is produced and the whole version range needs to be shifted.

          I understand that there may be use cases where e.g. project A has version ranges for projects B and C, is happy to use snapshots of B, but only wants releases of C. In that case the project needs finer-grained control over snapshot dependencies, and this may require:

          1. changes to the POM model, or
          2. changes to the way ranges are defined, or
          3. re-interpretation of dependency ranges (as in Kunalkumar's suggestion)

          Having thought about that, perhaps we do really need to split this issue in two:

          1. Have a master switch that will disable all snapshots in all ranges. Use it by default in maven-release-plugin when starting forked executions. That will solve integration and CI issues for a large group of users, including us.
          2. Have a fine-grained control over inclusion of snapshots in ranges, on the level of each individual dependency. That will cover more specific cases like you are describing.
          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - Joniec, We have already waited for 6 long years and this issue is still unsolved. If we have a solution that works with command line maven and can be used in CI tools, I'll be happy to wait until IDEs catch up. We have already been in such situation with incompatible changes in tools and libraries, and it's part of software evolution. To your question. Whenever I want to release a SNAPSHOT of one of our projects, I open our Jenkins page, find the release build for the project and press a "Perform Maven Release" button. This in turn kicks off command line maven with the equivalent of mvn -B release:prepare-with-pom release:perform command, with a couple of additional options specific to our build environment. I do not have to edit the project's POM before release, because for our release builds version ranges are resolved from release repositories only, and the release builds are configured with a separate local repo. I have already described our set-up above . All this hassle is to circumvent this very MNG-3092 and avoid unnecessary editing of POM files. Neither do I have to constantly edit version ranges in the dependent downstream projects, save for the cases when a major release of upstream dependency is produced and the whole version range needs to be shifted. I understand that there may be use cases where e.g. project A has version ranges for projects B and C, is happy to use snapshots of B, but only wants releases of C. In that case the project needs finer-grained control over snapshot dependencies, and this may require: changes to the POM model , or changes to the way ranges are defined , or re-interpretation of dependency ranges (as in Kunalkumar's suggestion ) Having thought about that, perhaps we do really need to split this issue in two: Have a master switch that will disable all snapshots in all ranges. Use it by default in maven-release-plugin when starting forked executions. That will solve integration and CI issues for a large group of users, including us. Have a fine-grained control over inclusion of snapshots in ranges, on the level of each individual dependency. That will cover more specific cases like you are describing.
          Hide
          joniec Joniec Jacek added a comment -

          Sergei, Suppose I have two dependency defined with version range in my project and one of them I want to use SNAPSHOT and second release, this is again valid use case because many project has on going work for many library and they need SNAPSHOT version of those.

          Show
          joniec Joniec Jacek added a comment - Sergei, Suppose I have two dependency defined with version range in my project and one of them I want to use SNAPSHOT and second release, this is again valid use case because many project has on going work for many library and they need SNAPSHOT version of those.
          Hide
          joniec Joniec Jacek added a comment - - edited

          Sergei, To solve this problem you are expecting IDE verndors needs to change their implementation and then everyone has to use that IDE to implement this feature..?

          This is a bug and not a new feature due to which they need to change this.

          Give me answer of below question...

          when you want to release your SNAPSHOT what do you do?

          And same artifact when you want to release without SNAPSHOT what you do?

          Show
          joniec Joniec Jacek added a comment - - edited Sergei, To solve this problem you are expecting IDE verndors needs to change their implementation and then everyone has to use that IDE to implement this feature..? This is a bug and not a new feature due to which they need to change this. Give me answer of below question... when you want to release your SNAPSHOT what do you do? And same artifact when you want to release without SNAPSHOT what you do?
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          Joniec,

          Firstly, I do not see any point in asking IDE vendors for permission. It is their job to follow the trends and changes in the software landscape and constantly adapting to the changes. Can you imagine people from Spring or Hibernate projects begging IDE vendors for permission to make changes in their products? This would be plain silly.

          Secondly, if an organisation has a complicated web of project dependencies and they are not willing to invest in a proper repository set-up and management, then they are not doing themselves any favour. I am myself working in a large organisation, and we have tens of teams, lots of projects, and we do maintain many separate Maven repositories. Suppose our team is responsible for a financial application that handles transactions worth £1bn daily, then we would want a complete control over the artifacts that we integrate from other teams, would not we?

          I firmly believe that the use case you described can be (and perhaps should be) handled through proper repository set-up. If your project C depends on A:[1.0,1.1) and B:[2.3,2.4), and you do actually need to include snapshots for A, but not for B, then my proposal will not work for you with a vanilla repository set-up. In that case you will need a fine-grained resolution policy on the individual dependency level. And that does not solve the problem with releasing projects when snapshot dependencies are present. If we are forced to edit POM files before release, then what is the point in having version ranges?

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - Joniec, Firstly, I do not see any point in asking IDE vendors for permission. It is their job to follow the trends and changes in the software landscape and constantly adapting to the changes. Can you imagine people from Spring or Hibernate projects begging IDE vendors for permission to make changes in their products? This would be plain silly. Secondly, if an organisation has a complicated web of project dependencies and they are not willing to invest in a proper repository set-up and management, then they are not doing themselves any favour. I am myself working in a large organisation, and we have tens of teams, lots of projects, and we do maintain many separate Maven repositories. Suppose our team is responsible for a financial application that handles transactions worth £1bn daily, then we would want a complete control over the artifacts that we integrate from other teams, would not we? I firmly believe that the use case you described can be (and perhaps should be) handled through proper repository set-up. If your project C depends on A:[1.0,1.1) and B:[2.3,2.4), and you do actually need to include snapshots for A, but not for B, then my proposal will not work for you with a vanilla repository set-up. In that case you will need a fine-grained resolution policy on the individual dependency level. And that does not solve the problem with releasing projects when snapshot dependencies are present. If we are forced to edit POM files before release, then what is the point in having version ranges?
          Hide
          joniec Joniec Jacek added a comment -

          @Sergei, you are making so complicate here.... when you are working with big company it's very difficult to separate out repo team by team.... if Same team is working on different project and want SNAPSHOT version of team C thn.... and more over in same project it self if they want SNAPSHOT version of C and release version of A then this is valid use case.... We can not separate out repo team base we have common repo in entire organization one for SNAPSHOT and one for RELEASE and many company they have only one repo which contain release and SNAPSHOT...
          We want to solve this problem for everyone with minimal change.

          If you are saying "Yes obviously" to IDE vendors to change their implementation thn please ask them first, are they ready to change?

          If we have problem in Maven feature then first we need to solve the problem in Maven without depending on other tools to support us...

          Sorry, but I'm not agree with you.

          Show
          joniec Joniec Jacek added a comment - @Sergei, you are making so complicate here.... when you are working with big company it's very difficult to separate out repo team by team.... if Same team is working on different project and want SNAPSHOT version of team C thn.... and more over in same project it self if they want SNAPSHOT version of C and release version of A then this is valid use case.... We can not separate out repo team base we have common repo in entire organization one for SNAPSHOT and one for RELEASE and many company they have only one repo which contain release and SNAPSHOT... We want to solve this problem for everyone with minimal change. If you are saying "Yes obviously" to IDE vendors to change their implementation thn please ask them first, are they ready to change? If we have problem in Maven feature then first we need to solve the problem in Maven without depending on other tools to support us... Sorry, but I'm not agree with you.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Joniec

          To your first comment.
          I know it may be difficult to explain, that is why I am asking for detailed examples or use cases, so that we all can be sure we understand the problem in the same way.
          If team B never wants to pick up snapshots of team A, then this problem can be solved pretty easily without changing Maven a bit. All they need to do is to segregate their repositories (which is generally not a bad idea anyway):
          1. Team A sets up separate release and snapshot repositories for their artifacts.
          2. Team B sets up a repository group for themselves that only includes the release repo of team A.
          This way, team B will only ever see the released versions of artifacts from team A. Done.
          As a matter of fact, both teams can even share the same release repository, it is only the snapshot repositories that need to be segregated.

          To your second comment.
          Yes, obviously if we are going to introduce changes into Maven, IDE vendors will have to support the new functionality eventually. Our implementation choice does not really matter here. By default, however, everything should continue to work the way it is now.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Joniec To your first comment . I know it may be difficult to explain, that is why I am asking for detailed examples or use cases, so that we all can be sure we understand the problem in the same way. If team B never wants to pick up snapshots of team A, then this problem can be solved pretty easily without changing Maven a bit. All they need to do is to segregate their repositories (which is generally not a bad idea anyway): 1. Team A sets up separate release and snapshot repositories for their artifacts. 2. Team B sets up a repository group for themselves that only includes the release repo of team A. This way, team B will only ever see the released versions of artifacts from team A. Done. As a matter of fact, both teams can even share the same release repository, it is only the snapshot repositories that need to be segregated. To your second comment . Yes, obviously if we are going to introduce changes into Maven, IDE vendors will have to support the new functionality eventually. Our implementation choice does not really matter here. By default, however, everything should continue to work the way it is now.
          Hide
          joniec Joniec Jacek added a comment -

          @Sergei, what do you mean by "Are you concerned about the way it is going to be handled in IDEs? I personally don't see that being a problem, although IDE vendors may need to implement the equivalent of a command line option for embedded Maven engines."

          Are you saying IDE vendors need to change their implementation?

          Show
          joniec Joniec Jacek added a comment - @Sergei, what do you mean by "Are you concerned about the way it is going to be handled in IDEs? I personally don't see that being a problem, although IDE vendors may need to implement the equivalent of a command line option for embedded Maven engines." Are you saying IDE vendors need to change their implementation?
          Hide
          joniec Joniec Jacek added a comment -

          @Sergei, It's very difficult to explain you... Please understand the problem, First of all Team B does not want to use SNAPSHOT and want to use only release version of A. Whenever team A release incremental version it should picked up by team B without changing anything. But this is very common that team A is also adding new feature and creating SNAPSHOT version before release. In between if team B also working on their app and at that time they will get SNAPSHOT... this is very common situation please understand it.

          You two CI model is going to work as it's more work we need to do so please leave that option.

          Show
          joniec Joniec Jacek added a comment - @Sergei, It's very difficult to explain you... Please understand the problem, First of all Team B does not want to use SNAPSHOT and want to use only release version of A. Whenever team A release incremental version it should picked up by team B without changing anything. But this is very common that team A is also adding new feature and creating SNAPSHOT version before release. In between if team B also working on their app and at that time they will get SNAPSHOT... this is very common situation please understand it. You two CI model is going to work as it's more work we need to do so please leave that option.
          Hide
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment -

          @Scott
          Reverting to dependency management from Maven2 is not an option. Firstly, because Maven3 uses an entirely new dependency management library. Secondly, because dependency resolution that involves ranges is broken in Maven2, and we went through really hard time when we had to adapt our Maven3 project to be usable by another team, who are still on Maven2. Effectively, we ended up providing them with an alternative POM, where all version ranges were removed and versions locked down.

          @Joniec
          No, the default behaviour of IDEs will not change. Neither will change the default behaviour of Maven. One will need to override it with the new switch to exclude snapshots.
          If the team of project B does not override the default behaviour, they will be both building and developing against 1.0.1-SNAPSHOT. If project B starts using features from A:1.0.1-SNAPSHOT that are not available in A:1.0.0, then they will not be able to release (or build with the switch turned on) until project A releases 1.0.1.
          They can set up (like we do) two CI builds, one of which will verify that project B still builds against the latest released version of project A (1.0.0), and the other one will check that project B builds against the latest snapshot of project A(1.0.1-SNAPSHOT).
          If team B never want to build or develop against snapshots of A, they can control it via repository management. Or they should perhaps not use ranges in the first place (which is probably a good idea if the teams are developing at different paces and want to have better control of their dependencies).
          All in all, they will not be worse off than they are now.

          @Paul
          In an ideal world, yes we'd be able to extend Maven POM model and carry on. Unfortunately, this has a potential to break projects that are still using previous Maven versions. This is the reason why Maven core team are so reluctant to introduce any changes to the model.
          I agree, we may want to control it in a finer-grained way. Like specifying the default resolution strategy on the <project> level, and posiibly overriding in on the individual <dependency> level.
          In a real world, this MNG-3092 saga has been going on for ages, and the only alternative proposed solution involves modifying the POMs on a regular basis to achieve the desired behaviour. Personally, I do not want to go through tens of related POMs in my project and introduce snapshots in ranges so that I could use them in my IDE, and then revert the changes when I want to release them. This would completely negate any benefits of version ranges. I am proposing a solution that (1) will not break backward compatibility of maven builds by default, (2) will not require changes to POM model, (3) will allow to use the new behaviour without the need to edit POM files (essentially, you can switch between the old and the new behaviour when using the same POM file). I do also desperately want a concrete solution to this six year old problem, and I want a solution that I will be able to start using within my own lifespan.

          Show
          sergei_ivanov@mail.ru Sergei S. Ivanov added a comment - @Scott Reverting to dependency management from Maven2 is not an option. Firstly, because Maven3 uses an entirely new dependency management library . Secondly, because dependency resolution that involves ranges is broken in Maven2, and we went through really hard time when we had to adapt our Maven3 project to be usable by another team, who are still on Maven2. Effectively, we ended up providing them with an alternative POM, where all version ranges were removed and versions locked down. @Joniec No, the default behaviour of IDEs will not change. Neither will change the default behaviour of Maven. One will need to override it with the new switch to exclude snapshots. If the team of project B does not override the default behaviour, they will be both building and developing against 1.0.1-SNAPSHOT. If project B starts using features from A:1.0.1-SNAPSHOT that are not available in A:1.0.0, then they will not be able to release (or build with the switch turned on) until project A releases 1.0.1. They can set up (like we do) two CI builds, one of which will verify that project B still builds against the latest released version of project A (1.0.0), and the other one will check that project B builds against the latest snapshot of project A(1.0.1-SNAPSHOT). If team B never want to build or develop against snapshots of A, they can control it via repository management. Or they should perhaps not use ranges in the first place (which is probably a good idea if the teams are developing at different paces and want to have better control of their dependencies). All in all, they will not be worse off than they are now. @Paul In an ideal world, yes we'd be able to extend Maven POM model and carry on. Unfortunately, this has a potential to break projects that are still using previous Maven versions. This is the reason why Maven core team are so reluctant to introduce any changes to the model. I agree, we may want to control it in a finer-grained way. Like specifying the default resolution strategy on the <project> level, and posiibly overriding in on the individual <dependency> level. In a real world, this MNG-3092 saga has been going on for ages, and the only alternative proposed solution involves modifying the POMs on a regular basis to achieve the desired behaviour. Personally, I do not want to go through tens of related POMs in my project and introduce snapshots in ranges so that I could use them in my IDE, and then revert the changes when I want to release them. This would completely negate any benefits of version ranges. I am proposing a solution that (1) will not break backward compatibility of maven builds by default, (2) will not require changes to POM model, (3) will allow to use the new behaviour without the need to edit POM files (essentially, you can switch between the old and the new behaviour when using the same POM file). I do also desperately want a concrete solution to this six year old problem, and I want a solution that I will be able to start using within my own lifespan.
          Hide
          scsosna99 Scott Sosna added a comment -

          @Joniec
          Agreed, it needs to be solved ASAP.

          But if it isn't resolved - and it's 3 months short of 6 years - the second possibility listed is to "leave range resolution behaving as it is, then use profiles to enable or disable snapshot repositories at build time." The history on this issue does not lend confidence in trying to implement the design docs as defined, and if we can't then the original Maven2 behavior should be restored.

          Show
          scsosna99 Scott Sosna added a comment - @Joniec Agreed, it needs to be solved ASAP. But if it isn't resolved - and it's 3 months short of 6 years - the second possibility listed is to "leave range resolution behaving as it is, then use profiles to enable or disable snapshot repositories at build time." The history on this issue does not lend confidence in trying to implement the design docs as defined, and if we can't then the original Maven2 behavior should be restored.
          Hide
          joniec Joniec Jacek added a comment - - edited

          @Scott, that is what I'm asking to all if you go with http://www.mail-archive.com/dev@maven.apache.org/msg68512.html it simply says "We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary"

          We need this to be resolve ASAP with simple solution until new design finalize

          Show
          joniec Joniec Jacek added a comment - - edited @Scott, that is what I'm asking to all if you go with http://www.mail-archive.com/dev@maven.apache.org/msg68512.html it simply says "We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary" We need this to be resolve ASAP with simple solution until new design finalize
          Hide
          scsosna99 Scott Sosna added a comment -

          I'm in the other 50% who require snapshots to be included in ranges for development, and changing that breaks previous behavior. Sure, I can make the change, that's fine, but 50% of the populations going to be inconvenienced, and if they haven't been following this, they'll have no idea why. Potentially dangerous.

          Also, I cannot wait n months until all the IDEs support behavior that I'm not convinced could be decently explained to them. We've had almost 6 years to scope this out, and nothing's happened, why does anyone believe it's going to happen now. Let's restore the behavior from Maven2 - regardless of how right or wrong anyone feels it is - and start with a clean slate. At least it was understood and usable, what we have now in Maven3 is neither.

          Show
          scsosna99 Scott Sosna added a comment - I'm in the other 50% who require snapshots to be included in ranges for development, and changing that breaks previous behavior. Sure, I can make the change, that's fine, but 50% of the populations going to be inconvenienced, and if they haven't been following this, they'll have no idea why. Potentially dangerous. Also, I cannot wait n months until all the IDEs support behavior that I'm not convinced could be decently explained to them. We've had almost 6 years to scope this out, and nothing's happened, why does anyone believe it's going to happen now. Let's restore the behavior from Maven2 - regardless of how right or wrong anyone feels it is - and start with a clean slate. At least it was understood and usable, what we have now in Maven3 is neither.
          Hide
          joniec Joniec Jacek added a comment -

          Ok so in that case you need to change POM file for release and SNAPSHOT, then what is problem with putting and removing -SNAPSHOT from range and here you don't required more attribute as well and it easy to understand

          Show
          joniec Joniec Jacek added a comment - Ok so in that case you need to change POM file for release and SNAPSHOT, then what is problem with putting and removing -SNAPSHOT from range and here you don't required more attribute as well and it easy to understand
          Hide
          pmv Paul Vonnahme added a comment -

          How many maven command line options exist that affect the build without a corresponding XML element? You can put <skipTests>true</skipTests> in your surefire configuration. Since this cuts across <dependencies> and <dependencyManagement>, it seems to me if this were to be an attribute it would have to be at the top level: http://maven.apache.org/pom.html#Quick_Overview

          It seems about 50% of the people on this thread believe a range should never contain a SNAPSHOT. If that's the case it would be nice to put <enableSnapshotsInRanges>false</enableSnapshotsInRanges> in your topmost corporate pom and not have to worry about it going on the command line of every build.

          If the solution also needed to cover MNG-5353, it feels like you would need additional options. So maybe
          <rangeResolutionAdvice>noSnapshots</rangeResolutionAdvice>
          or
          <rangeResolutionAdvice>noPreRelease</rangeResolutionAdvice>
          or
          <rangeResolutionAdvice>...?</rangeResolutionAdvice>

          If you wanted different advice for different stages of development, you could put this attribute in a profile you could activate from the command line.

          I'm not sure of the technical hurdles to something like <rangeResolutionAdvice>, but in my opinion it seems like the most complete solution. I'm not heavily invested in version ranges at the moment, but thought I'd throw in my $0.02.

          Show
          pmv Paul Vonnahme added a comment - How many maven command line options exist that affect the build without a corresponding XML element? You can put <skipTests>true</skipTests> in your surefire configuration. Since this cuts across <dependencies> and <dependencyManagement>, it seems to me if this were to be an attribute it would have to be at the top level: http://maven.apache.org/pom.html#Quick_Overview It seems about 50% of the people on this thread believe a range should never contain a SNAPSHOT. If that's the case it would be nice to put <enableSnapshotsInRanges>false</enableSnapshotsInRanges> in your topmost corporate pom and not have to worry about it going on the command line of every build. If the solution also needed to cover MNG-5353 , it feels like you would need additional options. So maybe <rangeResolutionAdvice>noSnapshots</rangeResolutionAdvice> or <rangeResolutionAdvice>noPreRelease</rangeResolutionAdvice> or <rangeResolutionAdvice>...?</rangeResolutionAdvice> If you wanted different advice for different stages of development, you could put this attribute in a profile you could activate from the command line. I'm not sure of the technical hurdles to something like <rangeResolutionAdvice>, but in my opinion it seems like the most complete solution. I'm not heavily invested in version ranges at the moment, but thought I'd throw in my $0.02.
          Hide
          joniec Joniec Jacek added a comment - - edited

          @Sergei, you believe we need to change the default behavior of IDE, right? According to you we need to change the IDE behavior first to solve this simple problem.

          Here is the example suppose I have project A 1.0.0 and 1.0.1-SNAPSHOT from one Team.

          Project B different team is depending on A.

          Project B is developing their project and using range [1.0.0,1.1.0] of A, development time you will get 1.0.1-SNAPSHOT but build time you will get 1.0.0 because you are passing parameter.

          If you think we need to fix IDE first then we should stop commenting here and ask all IDE to fix it first. Pls don't take it personally.

          Show
          joniec Joniec Jacek added a comment - - edited @Sergei, you believe we need to change the default behavior of IDE, right? According to you we need to change the IDE behavior first to solve this simple problem. Here is the example suppose I have project A 1.0.0 and 1.0.1-SNAPSHOT from one Team. Project B different team is depending on A. Project B is developing their project and using range [1.0.0,1.1.0] of A, development time you will get 1.0.1-SNAPSHOT but build time you will get 1.0.0 because you are passing parameter. If you think we need to fix IDE first then we should stop commenting here and ask all IDE to fix it first. Pls don't take it personally.
          Hide
          scsosna99 Scott Sosna added a comment -

          My questions are: will the Maven core team accept a patch that only addresses a portion of this discussion? And if not addressed, how do we avoid extending discussions on this issue another 6 years?!?

          I fully agree with wanting to take incremental steps, and hopefully this is acceptable. I also know that the current implementation resolves dependencies magnitudes slower than what was in Maven2. Locking down the behavior is fine, but it doesn't help me if the overall performance doesn't increase as well. I have Eclipse users breathing down my back who want to flat-out ditch Maven because of the Eclipse plug-in problem (the plug-in insists on embedding Maven3 with no way to override it for dependency resolution).

          So dealing with just a subset may not be enough, for me, for others, for the core team. And if it's not, the previous functionality of Maven2 (and very early Maven3) should be restored.