On 04/05/2013, at 3:07 AM, Peter Niederwieser <[email protected]> wrote:
> I'm trying to come up with a sensibly way to model sources and Javadoc > artifacts in Ivy/Gradle. Some options: > > 1. Only list main artifacts in module descriptor, but additionally publish > sources and Javadoc artifacts with `-sources` and `-javadoc` classifiers. > > In a way this is cheating, but on the other hand it works fairly well with > current Gradle. A regular module dependency will resolve to the module's > main artifacts (which is what one typically wants), and the IDE plugins will > successfully resolve and configure sources and Javadoc Jars for the artifact > that's named after the module (if any). However, for any other artifacts > sources and Javadoc Jars won't currently be configured successfully. See: > http://forums.gradle.org/gradle/topics/eclipse_classpath_jars_and_source_attachments_from_ivy_dependencies > http://issues.gradle.org/browse/GRADLE-2320 > > 2. List main, sources, and Javadoc artifacts in module descriptor, and > distinguish them by their artifact type. > > This is what some public Ivy repos (e.g. SpringSource Enterprise Bundle > repo) seem to be doing. However, it doesn't work well with current Gradle. > The main problem is that without a good/easy way to declare a dependency > that resolves to all module artifacts but those of type `sources` and > `javadoc`, sources and Javadoc artifacts will show up in the wrong places > (e.g. compile class paths). > > 3. Have separate configurations for sources and Javadoc artifacts. > > Either have one `sources` and `javadoc` configuration per module, or one > `sources` and `javadoc` configuration per other configuration in the module. > This solves the problem of accidentally bringing in sources and Javadoc > artifacts, and could be made to work with Gradle's IDE support. However, it > doesn't seem quite right to me, as conceptually sources and Javadoc > artifacts are closely related to their "main" artifact. Not sure if it > matters. > > 4. Have separate modules for sources and Javadoc artifacts. > > Seems like the least desirable option to me, but mentioning it for > completeness. > > Any opinions on which options make sense? Any other options that come to > mind? Do we need to support more than one option? For me, options 2 and 3 are the only contenders. Option 1 means we can't attach any meta-data to the artefacts (in the ivy.xml) and we need to do an additional http request to probe for the artefact if we need to know what the source artefacts will be. I'd go with option 3. It's good enough, simpler and more likely to work in various places. It also allow us to say something about the source as a whole (eg 'there is no source'). The downside is that it may not describe reality accurately enough, where different source artefacts are required based on whatever it is you're doing with the module. For backwards compatibility, we should also fall back to option 1 if there is no source declared in the ivy descriptor (but not if 'there is no source' is declared in the ivy descriptor). I don't think we need to support multiple options as this stage. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
