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.

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

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


Reply via email to