Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-646

Support custom version conflict strategies

    Details

    • Type: New Feature
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: 0.2, 0.3, 0.4, 0.5, 0.5.1, 0.5.2, 0.6, 0.6.1, 0.7, 0.8
    • Fix Version/s: None

      Description

      All the user to create their own version conflict resolution strategies. Mailing list reference: http://www.nabble.com/Force-two-versions-of-a-jar--td25367885.html

        Activity

        Hide
        szczepiq Szczepan Faber added a comment -

        First step in improving management of version conflicts: GRADLE-1899

        Show
        szczepiq Szczepan Faber added a comment - First step in improving management of version conflicts: GRADLE-1899
        Hide
        jaleksynas Jacob Aleksynas added a comment -

        I'd love to see one additional conflict manager... The "all" manager from Ivy.

        The main use-case is an upgrade from one library to another.. jmock 1 to 2 or even Junit 3.X -> 4.X where BOTH jars can happily live on the classpath and allow for incremental migration of test cases

        I have quite a bit of this in my codeline and have had a heck of a time working around it.

        Show
        jaleksynas Jacob Aleksynas added a comment - I'd love to see one additional conflict manager... The "all" manager from Ivy. The main use-case is an upgrade from one library to another.. jmock 1 to 2 or even Junit 3.X -> 4.X where BOTH jars can happily live on the classpath and allow for incremental migration of test cases I have quite a bit of this in my codeline and have had a heck of a time working around it.
        Hide
        szczepiq Szczepan Faber added a comment -

        Thanks for feedback - very interesting (and legitimate) use case. How did you work around it? Separate configurations and changing the test.classpath property?

        Show
        szczepiq Szczepan Faber added a comment - Thanks for feedback - very interesting (and legitimate) use case. How did you work around it? Separate configurations and changing the test.classpath property?
        Hide
        jaleksynas Jacob Aleksynas added a comment -

        Yes, separate config and updating classpaths. This approach gets nasty with transitive dependencies and with extended configurations. so i could only use this approach effectively (read "cleanly") with the test use case above. With other runtime focused issues of this nature; I have to upgrade code and fix the necessity for "all" modules.

        Show
        jaleksynas Jacob Aleksynas added a comment - Yes, separate config and updating classpaths. This approach gets nasty with transitive dependencies and with extended configurations. so i could only use this approach effectively (read "cleanly") with the test use case above. With other runtime focused issues of this nature; I have to upgrade code and fix the necessity for "all" modules.
        Hide
        bmuschko Benjamin Muschko added a comment -

        As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

        We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

        Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

        • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
        • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

        We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

        Show
        bmuschko Benjamin Muschko added a comment - As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub. We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to. Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by: Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines . Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete. We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

          People

          • Assignee:
            Unassigned
            Reporter:
            lightguard Jason Porter
          • Votes:
            8 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated:

              Development