Gradle
  1. Gradle
  2. GRADLE-784

Provide a 'provided' configuration

    Details

    • Type: Improvement Improvement
    • Status: 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
        Paul Michael Reilly added a comment -

        No. If there is a "provided" feature, then at least one has a fighting chance to solve problems that the lack of it creates. And, worse, there is a normal compilation provided scope but not a test compilation provided scope. I am simply after consistency so that Dex does for test builds what it does for product builds — not clutter the apk with class files that should not be there.

        Show
        Paul Michael Reilly added a comment - No. If there is a "provided" feature, then at least one has a fighting chance to solve problems that the lack of it creates. And, worse, there is a normal compilation provided scope but not a test compilation provided scope. I am simply after consistency so that Dex does for test builds what it does for product builds — not clutter the apk with class files that should not be there.
        Hide
        Rick-Rainer Ludwig added a comment -

        I am evaluating Gradle for usage as build system for JavaEE development with OSGi frontend. Unfortunately, the dependency scope provided is crucial for such projects, because a lot of dependencies are provided by the containers and are only needed during compile time. All the arguments for a provided scope are mentioned above and the vote counter is up to 207 (with me). What will happen to this issue? If it is not going to be implemented, is there a reasonable explanation?

        I agree also on the the comments above, that an 'optional' scope is not needed and is in Maven builds a 'bad smell'.

        Show
        Rick-Rainer Ludwig added a comment - I am evaluating Gradle for usage as build system for JavaEE development with OSGi frontend. Unfortunately, the dependency scope provided is crucial for such projects, because a lot of dependencies are provided by the containers and are only needed during compile time. All the arguments for a provided scope are mentioned above and the vote counter is up to 207 (with me). What will happen to this issue? If it is not going to be implemented, is there a reasonable explanation? I agree also on the the comments above, that an 'optional' scope is not needed and is in Maven builds a 'bad smell'.
        Hide
        Yaneeve Shekel added a comment -

        I would like to back up @Rick-Rainer Ludwig by saying that not only is it an issue with JEE + OSGI, we encounter likewise issues in the bigdata domain especially within the hadoop ecosystem. We use the nebula plugin, but it would have been better had it been supported out-of-the-box

        Show
        Yaneeve Shekel added a comment - I would like to back up @Rick-Rainer Ludwig by saying that not only is it an issue with JEE + OSGI, we encounter likewise issues in the bigdata domain especially within the hadoop ecosystem. We use the nebula plugin, but it would have been better had it been supported out-of-the-box
        Hide
        Richard Richter added a comment -

        I can't find anything about Gradle's plan or strategy how to solve this "provided" problem. I tried some answers, but many of them didn't work anymore (shooting on a moving target) or just proved a bit more complicated than a single word "provided" we are used to in Maven builds. I'd like to move to Gradle, but even such a silly thing like "provided" is nearly showstopper for me. Reportedly it makes only sense in WAR, but that's far from truth. Virtually any project I worked on used this dependency scope - probably because they were using some managed environment that provided the dependency. We use it often for JARs, because we don't want to put all the classes into WEB-INF/classes every time and we rely on the fact that provided does not drag these dependencies into WEB-INF/lib.

        Provided (or providedCompile, however it would be named) out of the box would be definitely more than welcome addition. It is not just cherry on some icecream. Is there anywhere some summary why modelling this takes so long? While I had problems with many Maven's things, "provided" worked absolutely smooth and never surprised me as a concept.

        Show
        Richard Richter added a comment - I can't find anything about Gradle's plan or strategy how to solve this "provided" problem. I tried some answers, but many of them didn't work anymore (shooting on a moving target) or just proved a bit more complicated than a single word "provided" we are used to in Maven builds. I'd like to move to Gradle, but even such a silly thing like "provided" is nearly showstopper for me. Reportedly it makes only sense in WAR, but that's far from truth. Virtually any project I worked on used this dependency scope - probably because they were using some managed environment that provided the dependency. We use it often for JARs, because we don't want to put all the classes into WEB-INF/classes every time and we rely on the fact that provided does not drag these dependencies into WEB-INF/lib. Provided (or providedCompile, however it would be named) out of the box would be definitely more than welcome addition. It is not just cherry on some icecream. Is there anywhere some summary why modelling this takes so long? While I had problems with many Maven's things, "provided" worked absolutely smooth and never surprised me as a concept.
        Hide
        Morgan Creighton added a comment - - edited

        Another use case... It's nice to add the findbugs annotation jar to providedCompile scope. These annotations are class level, and therefore ignored by the JVM. If the provided scope were added to Gradle, then there would be a standard way to suppress spurious findbugs warnings without polluting production code with test tool jars.

        Show
        Morgan Creighton added a comment - - edited Another use case... It's nice to add the findbugs annotation jar to providedCompile scope. These annotations are class level, and therefore ignored by the JVM. If the provided scope were added to Gradle, then there would be a standard way to suppress spurious findbugs warnings without polluting production code with test tool jars.

          People

          • Assignee:
            Unassigned
            Reporter:
            Steve Ebersole
          • Votes:
            219 Vote for this issue
            Watchers:
            160 Start watching this issue

            Dates

            • Created:
              Updated:

              Development