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.
As far as the solution to the above goes, the plan is to give you a replacement
for afterEvaluate { } so that Gradle can make sure that your plugin has done
its work before `components.android` is used, but after your extension has been
configured.
This means that Gradle would sequence things so that:
1. The build script is executed.
2. The Android plugin defines the `android` extension
3. The `android` extension is configured.
4. The Android plugin uses the `android` extension to define tasks and
components.
5. The `publishing` extension is configured. It's not until this point that the
`from components.android` statement is executed, and the `android` component is
fully populated by this point.
At some point later, we'd bust up #4 into smaller pieces, so that the tasks are
defined only when required, and so on.
>
>
>
>
> 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
