Have just tested using a custom "provided" configuration. This results in
any dependencies from this configuration not being added to the pom, instead
of being added with a <scope>provided</scope> configuration. While this does
keep the artifacts out of downstream builds, it means that downstream builds
will need to declare these in another "provided" configuration for runtime
classpaths.
configurations {
provided
}
dependencies {
provided "javax.servlet:servlet-api:2.5"
}
sourceSets {
main {
compileClasspath += configurations.provided
}
}
After configuring an uploadArchives task, the resulting pom has no reference
to servlet-api (which in a maven environment would load it onto the
classpath for compiliation, but not package it in a war / ear / etc. This
means that "provided" dependencies in upstream projects will need to be
re-declared as provided dependencies in downstream projects....
issue has been voted for.
On Fri, Mar 4, 2011 at 1:41 PM, Mathias Kalb <[email protected]>wrote:
> Hi,
>
> please read Adams answer to my similar problem.
>
>
> http://gradle.1045684.n5.nabble.com/providedCompile-for-Java-JAR-td3328327.html
>
> regards,
> Mathias Kalb
>
> Am 04.03.2011 12:22, schrieb Peter Niederwieser:
>
>
>> Yes, if the upstream project is a Jar project, you'd have to manually
>> introduce a "provided" configuration (in the upstream project!). However,
>> I
>> don't see the need for an exclude.
>>
>> I think that Gradle should automatically offer a
>> providedCompile/providedRuntime configuration for all projects, not just
>> for
>> those using the war plugin. Consider voting for
>> http://jira.codehaus.org/browse/GRADLE-784.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Brett Cave
Systems Architect
Jemstep, Inc
www.jemstep.com
