On 31/07/2013, at 10: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.
>
> 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?
>
>
>
> 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?
Currently, project dependencies use the same stuff as the old publication DSL,
which means they use the dependencies declared in the configurations and the
artefacts attached to them.
The plan is to shift project dependencies to use the components of the target
project instead. Making this work in a backwards-compatible way will be a
little tricky, but I think we can solve that.
The result will be that you describe whatever it is you produce as a component,
then this can be used to publish via the old and new DSL, and between projects
via project dependencies, and within the same project, too, so that a component
produced by a project can be used as an input for something else in the same
project (for example, having the test app use the library as input).
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
