On 31/07/2013, at 1:01 AM, Xavier Ducrohet <x...@google.com> wrote:
> On Tue, Jul 30, 2013 at 4:47 PM, Daz DeBoer
> <darrell.deb...@gradleware.com>wrote:
>
>> On 30 July 2013 17:23, Xavier Ducrohet <x...@google.com> wrote:
>>
>>> Makes sense. Right now I do want to add support for it so I'm going to
>>> use the internal stuff. We are aware that this might mean we are only
>>> compatible with a given version of Gradle and this is fine pre-1.0
>>>
>>> I'm also going to start creating components for each variants, but only
>>> add one candidate to the DefaultArtifactPublicationSet so this should work
>>> by default like the old publication.
>>>
>>
>> Are you planning to publish multiple variants to the same GAV
>> (publication), with variants differentiated by classifier? In that case,
>> I'm not sure why you wouldn't just create a single component, with multiple
>> artifacts. Each PublishArtifact can define a classifier, and all artifacts
>> will be published.
>>
>
> My variants can have different dependencies for libraries.
Which rules out the classifier approach.
> I guess when uploading application packages, I could have a single
> component. However I'm also thinking about letting developers upload side
> files besides their app (for instance ProGuard mapping file). I guess that
> I could use the same classifier as the matching app with a different
> type/extension?
This is unlikely to work. There are no clear rules on what should happen here.
My experience is that type/extension do not contribute to an artifact's
identity. That is, you can't have an artifact with the same
(name,group,version,classifier) but different type/extension. I've not tried
this with Gradle, but have with other Maven Repository tooling and it's not
worked.
>
>
>
>>> Quick question: what's the name of the Usage instances used for?
>>>
>>
>> For Maven publication, it's not currently used. For ivy, it provides the
>> configuration that contains the published artifacts. The mapping of
>> SoftwareComponent/Usage => Maven/Ivy model is pretty brain-dead at the
>> moment, and we'd be very willing to extend enhance this with more use cases.
>>
>>
> Are you talking about org.gradle.api.artifacts.Configuration here? I
> noticed that in JavaLibrary, the returned Usage object is called "runtime".
>
> How is all of this related to inter-project dependencies by the way? Right
> now we use project.artifacts.add("default", someAbstractArchiveTask) for
> both the old publication stuff and this seems to work.
> When looking at the JavaPlugin I saw those two lines:
>
>
> project.getExtensions().getByType(DefaultArtifactPublicationSet.class).addCandidate(jarArtifact);
> project.getComponents().add(new JavaLibrary(jarArtifact,
> runtimeConfiguration.getAllDependencies()));
>
> The 2nd one makes sense to me when I see the 'from components.java' section
> of a publication sample. I've been wondering if the 2nd one was for
> inter-project dependencies, but it takes an artifact instead of a Usage
> object, so there's not associated dependencies?
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
