Details

    • Type: New Feature
    • Status: Open
    • Resolution: Unresolved
    • 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!

          People

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

            Dates

            • Created:
              Updated:

              Development