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'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
