Ok. The idea with this change is to treat things in Maven repositories more
like Maven does. Maven doesn’t use the packaging to decide what kind of
artefact to use for a given module. Instead, it uses the ‘type’ declared in the
dependency on the module. If you forget the type, you get a jar (more or less).
So, the change would mean that Gradle would make the same assumption for
modules in maven repositories, and always attempt to use the jar unless the
consumer says otherwise. You’d have to declare a dependency using the artefact
notation:
compile ‘org:lib:1.2@aar’
or:
compile (‘org:lib:1.2’) {
artifact { type ‘aar’ }
}
(the first option doesn’t include dependencies)
One question is whether this actually makes any sense. And I don’t think it
does. If you’re building against something that’s packaged as an aar, then you
want the aar (or you want the build to blow up because you were expecting
something else). Why should you have to tell Gradle this everywhere you use the
library, when it already knows?
The plan was to address this kind of thing with the component-based dependency
management we’re working on. What this would mean is 2 things:
1. A way for a consumer (usually a plugin) to define what kinds of things it
expects to find in a dependency graph. For example, the Android plugin would
declare that it can handle things packaged, say, as jars and aars (and
implicitly anything that can be transformed into those things). Gradle would
use this to decide what types of artefacts to use.
2. A way to fine-tune how Gradle maps a Maven module to Gradle's view of the
world. For example, the Android plugin might define how to take a Maven module
with packaging ‘aar’ and turn it into an ‘android library’ component ready to
use locally.
What to do for 2.0, then? We have a few options:
1. Make the change, so that we only look for a jar. This means that until we
implement the new stuff, everyone will need to use the different notations
above to use an aar from a Maven repo. Not so appealing.
2. Keep the current behaviour until we implement the new stuff and then remove
the behaviour in 3.0. We’d effectively un-deprecate it for now.
3. Make the change but add ‘aar’ as a hard-coded known exception to the rule.
We’d remove the exception in 3.0, after the new stuff is available.
I think we could go with #2.
On 10 Apr 2014, at 12:21 pm, Xavier Ducrohet <x...@google.com> wrote:
> It's in build.gradle. Though the compile configuration object.
>
> On Apr 9, 2014 4:21 PM, "Adam Murdoch" <adam.murd...@gradleware.com> wrote:
>
> On 10 Apr 2014, at 8:19 am, Xavier Ducrohet <x...@google.com> wrote:
>
>> it's an aar file. It seems to happen only when the dependencies is coming
>> from a maven repositories (vs another sub-project).
>>
>> The pom contains <packaging>aar</packaging>
>>
>> Any other details I can provide?
>
> What’s the dependency declaration look like? eg is it in a build.gradle or a
> pom?
>
>>
>>
>> On Wed, Apr 9, 2014 at 2:55 PM, Adam Murdoch <adam.murd...@gradleware.com>
>> wrote:
>>
>>
>> On 10 Apr 2014, at 1:19 am, Xavier Ducrohet <x...@google.com> wrote:
>>
>>> When building a project that depends on an aar artifact I see the warning:
>>>
>>> Relying on packaging to define the extension of the main artifact has been
>>> deprecated and is scheduled to be removed in Gradle 2.0
>>>
>>> I'd like to fix this ASAP since 2.0 will be coming soon, but I'm not sure
>>> how to do this.
>>>
>>> At first I thought it was due to querying ResolvedArtifact.getType() in my
>>> code but that doesn't seem to be it.
>>>
>>> The message seems to come from
>>> GradlePomModuleDescriptorBuilder.addMainArtifact, where it outputs the
>>> message whenever your artifact packaging value is different from pom and
>>> jar.
>>>
>>> Is there something I can/need to fix in preparation for 2.0? If so, how?
>>
>> Possibly. What does the dependency look like?
>>
>>
>> --
>> Adam Murdoch
>> Gradle Co-founder
>> http://www.gradle.org
>> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
>> http://www.gradleware.com
>>
>> Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
>> http://www.gradlesummit.com
>>
>>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
> Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
> http://www.gradlesummit.com
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
http://www.gradlesummit.com
