On Nov 19, 2012, at 11:31 PM, Adam Murdoch <[email protected]> wrote:
> > On 20/11/2012, at 6:22 AM, Luke Daley wrote: > >> Hi, >> >> I'm working on >> https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#customising-maven-descriptor-xml >> >> Some questions: >> >> 1. Multiple artifacts >> >> The spec says that: >> >>> When this MavenPublication instance is used for publishing, the following >>> defaults are used: >>> … >>> • All artifacts from public configurations are published. >> >> This strategy works for Ivy (kinda), but is problematic for Maven. There's a >> key difference between Maven and Ivy publication; Ivy can publish an >> arbitrary set of artifacts, Maven can publish one non-classified artifact >> and zero or more additional, classified, artifacts. If we use this “All >> artifacts from public configurations are published” strategy, all artifacts >> except one would need to have a classifier. Is this what we want at this >> stage? > > We have a few options: > > 1. Assert that artifact tuples (name, classifier, extension) do not contain > duplicates, that name == artefactId, and that there is exactly one artefact > with classifier == null. > > 2. As above, but use artifactId as the name for artefacts. > > 3. We add some concept of component (internal for now), that defines which > artefact is the main artefact, if any. For all other artefacts, map 'type' to > 'classifier' and assert as above. > > We might start with #2, and soon after start moving towards a higher-level > description, even if only used initially for our plugins to communicate > internally with the publishing plugins. Just to be sure. We want to be able to publish multiple artifacts per project which have different artifact names and different poms, don't we? > > >> >> 2. Only runtime dependencies? >> >> Spec: >> >>> When this MavenPublication instance is used for publishing, the following >>> defaults are used: >>> … >>> • No dependencies are included in the pom. >>> • When the java plugin is applied, the following dependencies are included >>> in the pom.xml: >>> • All dependencies specified in configurations.runtime are added with >>> runtime scope. >> >> Why only runtime scope? > > Because those are the only ones we know about. I know projects that make even use of the test scope when consuming other libraries (e.g. they want the -test classifier jar plus the dependencies in the test scope). I'm not saying we should include the test scope as the default but it should be possible to add it somehow. Hans > >> >> 3. Identifiers >> >> Spec: >> >>> When this MavenPublication instance is used for publishing, the following >>> defaults are used: >>> • groupId == project.group >>> • artifactId == project.name (_not_ archivesBaseName) >>> • version == project.version >>> • packaging == null >> >> This means that the settings on the artifact object itself will have no >> effect at all. Is this what we want ? (I'd say yes, but just checking) > > Yes. > >> >> 4. MavenPom type >> >> We already have a MavenPom class. We can't really use this for the new >> publication stuff. Is the plan to introduce a new one in parallel and then >> eventually remove what we have now? > > Yes. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com >
