On 01/08/2013, at 11:19 AM, Xavier Ducrohet <x...@google.com> wrote:
> OK I can hold off.
Great. I'll finish up the tooling API stuff I'm doing for Alex and then can
have a look at making the publishing stuff work better.
One way to tackle it would be something like:
1. Change project dependencies so that they resolve to a component.
2. Change dependency resolution so that a variant can be selected from a
component.
3. Add some replacement for `afterEvaluated { }` for the Android plugin to use
to create its tasks.
4. Change the new publishing DSL so that it can map a component with multiple
variants to a publication.
5. (Maybe) change the old publishing DSL so that it also understands
components. Might only be able to handle a single-variant component.
After #1 and #2 you'd be able to have project dependencies on an Android
library with multiple variants, but you wouldn't yet be able to publish those
variants to a repository.
After #3 and #4 you'd be able to use the new publishing DSL to publish an
Android library or application with multiple variants.
And #5 just rounds it out. If we've made enough progress by this point, it
could make more sense to un-incubate the new DSL instead of #5, so that you can
only publish Android stuff (and C++ stuff and multi-variant jvm stuff) via the
new DSL.
>
> I was mostly trying to make our plugin work with the new publishing stuff as
> some external devs asked for it.
>
>
> On Wed, Jul 31, 2013 at 6:04 PM, Adam Murdoch <adam.murd...@gradleware.com>
> wrote:
>
> On 01/08/2013, at 10:19 AM, Xavier Ducrohet <x...@google.com> wrote:
>
>> So I'm making progress but running into a evaluation issue.
>>
>> Since the android plugin needs to evaluate the whole project before creating
>> the variants and tasks, we create the tasks in afterEvaluate {}
>>
>> This means that putting this in build.gradle
>>
>> publishing {
>> publications {
>> test(MavenPublication) {
>> from components.android
>> }
>> }
>> }
>>
>> fails since the component doesn't exist yet. Not putting the component line
>> only publishes a pom but not the artifact even though I have this line in
>> the plugin:
>>
>>
>> project.getExtensions().getByType(DefaultArtifactPublicationSet.class).addCandidate(theComponent);
>>
>> Configuring the publishing extension in afterEvaluate fails with:
>>
>> A problem occurred configuring root project 'baseLibrary'.
>> > Failed to notify project evaluation listener.
>> > Cannot configure the 'publishing' extension after it has been accessed.
>>
>> At this point I'm not sure how to proceed.
>
> From my point of view, it would be best if you could wait until we've have a
> chance to get the publishing stuff a little closer to how we want it to be.
> It's just a bit too early to be trying to extend it. We can do this fairly
> soon, if you can hold off for a while. I think it will just be a less
> frustrating exercise for you.
>
>
>>
>>
>>
>>
>> On Wed, Jul 31, 2013 at 11:54 AM, Xavier Ducrohet <x...@google.com> wrote:
>>
>> On Wed, Jul 31, 2013 at 11:02 AM, Luke Daley <luke.da...@gradleware.com>
>> wrote:
>>
>> 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.
>>
>>
>> Hmm. I know it's a limitation of Maven, but what about Gradle's internal
>> representation of dependencies? (this loops back on my question about how
>> project to project publication/dependencies are handled).
>>
>> In my case, I'd like to have a library have variants when it's used in a
>> multi-project setup (so that it can have the same variants as the consumer
>> project), but when published for external usage on a repository, then
>> variant will probably not be allowed, or they'll have to be different
>> artifacts.
>>
>> For inter-project publication/consumption, what'd like is to be to able to
>> have the consumer queries the different publication of the library project
>> to choose the right one. Whether this is done by classifiers or not doesn't
>> really matter in the end I guess.
>>
>> > 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.
>>
>>
>> Good to know. Thanks. I think I'll have to have a DSL to allow devs to
>> choose how each variant gets published (as far as groupId, artifactId). Then
>> I can use the classifiers for extra components (proguard mapping for
>> instance).
>> >
>> >
>> >
>> >>> 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
>>
>>
>>
>>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
