On 24/06/2013, at 0:43, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > On 24/06/2013, at 9:38 AM, Luke Daley <luke.da...@gradle.biz> wrote: > >> >> >> On 24/06/2013, at 0:04, Adam Murdoch <adam.murd...@gradleware.com> wrote: >> >>> >>> On 24/06/2013, at 8:28 AM, Luke Daley <luke.da...@gradle.biz> wrote: >>> >>>> >>>> >>>> On 23/06/2013, at 23:12, Adam Murdoch <adam.murd...@gradleware.com> wrote: >>>> >>>>> >>>>> On 22/06/2013, at 12:37 AM, Luke Daley <luke.da...@gradleware.com> wrote: >>>>> >>>>>> Forum issue: >>>>>> http://forums.gradle.org/gradle/topics/tooling_api_declares_only_runtime_dependency_on_slf4j >>>>>> >>>>>> Given Maven semantics, it does not seem correct to me that we publish >>>>>> with a runtime dependency on slf4j-api when it is actually a compile >>>>>> time dependency of ours. >>>>> >>>>> It's not a compile time dependency. None of the slf4j-api classes are >>>>> visible from our API. >>>> >>>> So you're saying that this means it's not a compile time dependency of the >>>> tooling api code? >>> >>> >>> It's required to compile the tooling API. It's not required to compile code >>> that uses the tooling API. >> >> This is my point. We are distorting the semantics of Maven scopes. > > Maybe for maven-the-build-tool, but not for maven-the-repository-format. It is completely legitimate for downstream tooling to make no distinction between these two things. We can't expect any different. >> It's legitimate for tooling to expect the Maven semantics. >> >> I'm not sure how serious the implication is in this particular case nor am I >> saying we necessarily need to change it. We do need to be watchful for such >> divergence from the established semantics going forward as we try to squeeze >> what we can out of the POM. >> >> I'm not sure what to do about the particular raised issue. > > I'd say that's probably Netbeans' problem to solve. It should be bundling the > runtime dependencies of a thing if it needs to load the thing's classes. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > >
