On 20/11/2012, at 9:40 AM, Luke Daley wrote:
>
> On 19/11/2012, at 10:31 PM, Adam Murdoch 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.
>
> Name is irrelevant here because it's imposed as the pom's artifactId. IIRC
> extension doesn't come in to play here. You can't have two artifacts with the
> same classifier and with different extensions.
You can, Maven uses the artefact packaging for this. So, the problem we have is
to take a set of Gradle artefacts with (name, type, extension, classifier) and
map them to a set of Maven artefacts with (classifier, packaging). We need to
assert that there are no duplicates. We don't (as it turns out) need to assert
that there is exactly one with no classifier - just the duplicate check is fine.
We want to do something like the following:
1. Start with classifier = the declared classifier, and packaging = the
declared type.
2. Take the artefact type and use it to adjust the classifier
* When type is 'source', add '-source' to the classifier.
* When type is 'javadoc', add '-javadoc' to the classifier.
* There's probably some other mappings we need to do here.
3. If the Maven publication has a main artefact, include its classifier and
packaging in the generated pom.
We might also think about mapping artefact name that matches
"$artifactId-$suffix" to classifier $suffix between steps 1 and 2.
So, this means
(mylib, jar, jar, null) -> (null, jar) -> mylib-1.2.jar
(mylib, source, jar, null) -> (source, jar) -> mylib-1.2-source.jar
(mylib, jar, jar, api) -> (api, jar) -> mylib-1.2-api.jar
(mylib, source, jar, api) -> (api-source, jar) -> mylib-1.2-api-source.jar
With the name mapping, we'd have:
(mylib-api, jar, jar, null) -> (api, jar) -> mylib-1.2-api.jar
(mylib-api, source, jar, null) -> (api-source, jar) -> mylib-1.2-api-source.jar
>
>> 2. As above, but use artifactId as the name for artefacts.
>
> If it's one publication = one pom (and it should be) then this is the only
> option.
>
>> 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.
>>
>>> 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.
>
> Care to expand on that? How do we know about them?
When you apply the 'java' plugin, we know what the runtime dependencies of the
component are, and that we need to let the consumer know about them, so they
need to go into the pom under runtime scope.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
