On 21/06/2013, at 3:53 AM, Xavier Ducrohet <x...@google.com> wrote:
> If I map the two gradle configurations though I won't really be mapping to
> the resolved artifacts, it's going to map to both.
>
> So for instance if foo uses Guava 13 and bar uses Guava 14, and the resolving
> decide to use Guava 14, my published artifact should just declare that it
> needs 14.
Right, this is different to the prevailing paradigm with POMs in that they
declare what the requested dependencies were.
> Does the new publishing stuff offer more flexibility there?
It provides a low level hook to build the XML. You'd have to write your own
logic to inspect the _resolved_ configuration and generate the POM
dependencies. You can also do the same with the old stuff though. There's
nothing built in in either to map resolved dependencies.
This will be very slightly easier with the old stuff as it gives you a typed
model to mess with, but I don't think it's a significant factor.
> For my own use I still need to have it offer signing before I can switch to
> it, but for tests that could work. Actually does the supporting the new
> publishing mechanism will require me to update my plugin code to setup the
> dependencies differently?
The dependencies are declared the same way in both.
Adam will be able to provide some insight on if there are plans to provide any
out of the box support for watch you need any time soonish.
> On Thu, Jun 20, 2013 at 6:37 PM, Luke Daley <luke.da...@gradle.biz> wrote:
>
>
> On 21/06/2013, at 1:07, Xavier Ducrohet <x...@google.com> wrote:
>
> > I was going to file a bug but since this is a private API, maybe it's
> > easier to post here.
> > (I tried using this API from a build.gradle to make a repeatable project
> > but it fails to interpret the build.gradle)
> >
> >
> > In the android plugin, for library project we call
> >
> > project.plugins.withType(MavenPlugin) {
> > project.conf2ScopeMappings.addMapping(300, foo, "compile")
> > project.conf2ScopeMappings.addMapping(300, bar, "compile")
> > }
> >
> > to set proper dependencies in the pom. We are mostly doing this because we
> > have more than one configuration. This works fine.
> >
> > I'm doing some clean up work in the way we resolve our dependencies as we
> > don't want to resolve foo and bar separately but instead we want to resolve
> > the combination of foo and bar, so I started using composite configuration.
> >
> > Doing this:
> >
> > Configuration foobar = project.configurations.create("foobar")
> > foobar.setExtendsFrom(project.configurations.foo)
> > foobar.setExtendsFrom(project.configurations.bar)
> > project.plugins.withType(MavenPlugin) {
> > project.conf2ScopeMappings.addMapping(300, foobar, "compile")
> > }
> >
> > will create a pom file with no dependencies.
> >
> > Am I missing something? I really want the pom to contain the same
> > dependencies that we are using for compilation.
>
> Only the declared dependencies are used, not dependencies that are part of
> the config from configuration extension.
>
> You need to map both "foo" and "bar" configs separately. You can map two
> Gradle configurations to the same Maven scope.
>
> Have you considered using the new (still incubating) publishing stuff?
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
