On Nov 21, 2012, at 3:24 PM, Luke Daley <[email protected]> wrote:
> > On 21/11/2012, at 2:19 PM, [email protected] wrote: > >> >> 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? > > One publication = One pom. You will be able to have more than one publication. Got it. > >>>> 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. > > Long term this will definitely be possible, not in the short term. OK. Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com > >> >> 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 >>> >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
