Details

    • Type: New Feature
    • Status: Resolved
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None

      Description

      It would be cool if Gradle supported some notion of war overlays/compositing (http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html) out of the box (integrated with dependency management). We rely on this feature rather extensively to perform customizations of third party war files.

        Activity

        Hide
        davide.cavestro Davide Cavestro added a comment - - edited

        Really needed for customizing web applications (even home made) and getting a good IDE integration even for war projects (take a look at STS-1314 discussion).
        Maybe this could also benefit from GRADLE-1014?

        Show
        davide.cavestro Davide Cavestro added a comment - - edited Really needed for customizing web applications (even home made) and getting a good IDE integration even for war projects (take a look at STS-1314 discussion ). Maybe this could also benefit from GRADLE-1014 ?
        Hide
        davide.cavestro Davide Cavestro added a comment - - edited

        I hope this issue should not remain a minor priority RFE.
        I think here the focus doesn't lie as much in having any way to produce a war (we can still obtain it in several ways thanks to gradle flexibility) but rather in composing war artifacts based on dependencies between wars, with proper management for provided deps transitivity.
        In other words a war project by convention could get transient deps and web contents from other war projects/artifacts it depends upon.
        It would be great also having a way to obtain war overlay for gradle projects that enforces complete IDE integration i.e. a declarative approach that lets the tooling api expose enough info about merged resources in order to support the ide on reflecting the overlay as needed (we use eclipse/STS).
        I've opened a dedicated thread on the user mailing list.

        Show
        davide.cavestro Davide Cavestro added a comment - - edited I hope this issue should not remain a minor priority RFE. I think here the focus doesn't lie as much in having any way to produce a war (we can still obtain it in several ways thanks to gradle flexibility) but rather in composing war artifacts based on dependencies between wars, with proper management for provided deps transitivity. In other words a war project by convention could get transient deps and web contents from other war projects/artifacts it depends upon. It would be great also having a way to obtain war overlay for gradle projects that enforces complete IDE integration i.e. a declarative approach that lets the tooling api expose enough info about merged resources in order to support the ide on reflecting the overlay as needed (we use eclipse/STS). I've opened a dedicated thread on the user mailing list.
        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!
        Hide
        bmuschko Benjamin Muschko added a comment -

        From my perspective you should be able to achieve the same behavior with methods already exposed by AbstractCopyTask which effectively is being used by the War task. You can easily merge existing WARs into other WARs, filter files as you merge them and exclude any files you need to filter. I am going to mark this issue as "Won't fix". Please open an issue on GitHub if you feel like your use case isn't fulfilled.

        Show
        bmuschko Benjamin Muschko added a comment - From my perspective you should be able to achieve the same behavior with methods already exposed by AbstractCopyTask which effectively is being used by the War task. You can easily merge existing WARs into other WARs, filter files as you merge them and exclude any files you need to filter. I am going to mark this issue as "Won't fix". Please open an issue on GitHub if you feel like your use case isn't fulfilled.

          People

          • Assignee:
            Unassigned
            Reporter:
            ahamid Aaron Hamid
          • Votes:
            24 Vote for this issue
            Watchers:
            15 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development