Gradle
  1. Gradle
  2. GRADLE-784

Provide a 'provided' configuration

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None

      Description

      The intent of 'provided' configuration is to define dependencies which are needed for compilation, but which should not be "exported" (aka should not show up in runtime configuration)

        Activity

        Hide
        Ali Shafai
        added a comment -

        This seems not to work for android-library plugin. I tested it with android plugin and the jar classes could not be found in the dex file. but when I use provided for a jar file included in a library and the use that library in my app, the jar classes end up being present in the dex file.

        Show
        Ali Shafai
        added a comment - This seems not to work for android-library plugin. I tested it with android plugin and the jar classes could not be found in the dex file. but when I use provided for a jar file included in a library and the use that library in my app, the jar classes end up being present in the dex file.
        Hide
        Ryon Day
        added a comment - - edited

        The vigil continues. It's not in 1.12-rc1 either.

        Can we at least get a conversation started about this somewhere? The last time it was raised on the gradle-dev list, it was met with the forlorn sound of crickets.

        There is not even documentation on which of the many workarounds for this is the "official" one. That would be one thing if this it were some esoteric and exotic corner case. That's not what it is though. This is very basic, widely-used functionality (every single Java project I've ever worked on has used some sort of provided scope).

        As a result, users trying to migrate from Maven by reading the official documentation scratch their heads because they can't find a way to do something that is both very simple and very important. When they turn to Google searches they get more confused because they get back many conflicting workarounds just from the Gradle forums, not all of which work the same, or at all.

        In the end, EVERYONE loses because they end up with yucky, boilerplate code in all of their buildfiles.

        EDIT: I notice that this is the number one issue in terms of votes. Can this get some love?

        Show
        Ryon Day
        added a comment - - edited The vigil continues. It's not in 1.12-rc1 either. Can we at least get a conversation started about this somewhere? The last time it was raised on the gradle-dev list, it was met with the forlorn sound of crickets. There is not even documentation on which of the many workarounds for this is the "official" one. That would be one thing if this it were some esoteric and exotic corner case. That's not what it is though. This is very basic, widely-used functionality (every single Java project I've ever worked on has used some sort of provided scope). As a result, users trying to migrate from Maven by reading the official documentation scratch their heads because they can't find a way to do something that is both very simple and very important. When they turn to Google searches they get more confused because they get back many conflicting workarounds just from the Gradle forums, not all of which work the same, or at all. In the end, EVERYONE loses because they end up with yucky, boilerplate code in all of their buildfiles. EDIT: I notice that this is the number one issue in terms of votes. Can this get some love?
        Hide
        Brian Clozel
        added a comment -

        Hi Ryon Day, Spring's propdeps-plugins has been recently updated and important issues were fixed. Hopefully this will avoid some boilerplate code in your build files.

        Show
        Brian Clozel
        added a comment - Hi Ryon Day , Spring's propdeps-plugins has been recently updated and important issues were fixed . Hopefully this will avoid some boilerplate code in your build files.
        Hide
        Joern Huxhorn
        added a comment - - edited

        Thanks for the info, Brian Clozel.

        It's still very annoying that this isn't working out of the box. This is one of the last remaining pain points of Gradle... alongside GRADLE-2579 and GRADLE-1276. And Ryon Day is right: it's quite hard to find a proper workaround.

        Show
        Joern Huxhorn
        added a comment - - edited Thanks for the info, Brian Clozel . It's still very annoying that this isn't working out of the box. This is one of the last remaining pain points of Gradle... alongside GRADLE-2579 and GRADLE-1276 . And Ryon Day is right: it's quite hard to find a proper workaround.
        Hide
        Eric Deandrea
        added a comment -

        Agreed. We've implemented our own provided configuration in our custom distro. The only issue is it gets confusing when building web apps, since we now have provided alongside providedCompile & providedRuntime.

        Show
        Eric Deandrea
        added a comment - Agreed. We've implemented our own provided configuration in our custom distro. The only issue is it gets confusing when building web apps, since we now have provided alongside providedCompile & providedRuntime.

          People

          • Assignee:
            Unassigned
            Reporter:
            Steve Ebersole
          • Votes:
            148 Vote for this issue
            Watchers:
            123 Start watching this issue

            Dates

            • Created:
              Updated: