You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by William Ferguson <wi...@xandar.com.au> on 2014/12/08 01:25:06 UTC
Re: problem with AAR dependency
## Cross posting to Maven Dev list
One solution to this would be to change the POM specification to require
the type element for dependencies.
That would allow Maven and MavenCentral to immediately fail POMs based upon
dependencies that are missing the type element.
Yes, it goes against convention over configuration, but Maven is now used
by many more build types than just plain Java builds so maybe we need to
consider that the convention is no longer to assume jar dependencies.
I would rather require a little more configuration to ensure that builds
are more deterministic.
If we want to shrink the size of the POM then the new POM format is a
better solution.
William
On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach wrote:
>
> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got troubles
> declaring an aar dependency. Here is the pom.xml declaration:
>
> <dependency>
> <groupId>com.android.support</groupId>
> <artifactId>support-v13</artifactId>
> <version>21.0.2</version>
> <type>aar</type>
> </dependency>
>
> Just about any Maven command, even "mvn dependency:tree" yields:
>
> [ERROR] Failed to execute goal on project wallet: Could not resolve
> dependencies for project de.schildbach.wallet:wallet:apk:4.13-test: Failure
> to find com.android.support:support-v4:jar:21.0.2 in
> file:///home/aschildbach/dev/android-sdk/extras/android/m2repository was
> cached in the local repository, resolution will not be reattempted until
> the update interval of android-support has elapsed or updates are forced ->
> [Help 1]
>
> Where does that .jar type in the error message stem from? I declared aar.
>
>
Re: problem with AAR dependency
Posted by William Ferguson <wi...@xandar.com.au>.
Well, at the moment it's the Android SDK team, but in the future it could
be anybody.
I look at the deployed POMs are as form of contract between the deployed
artifact and it's consumers. So when the contract isn't explicit (eg
dependency type info) then its open to misinterpretation.
Maven convention is 'jar' as the dependency type and that's convenient when
declaring a POM as it makes it smaller (when there are mainly jar
dependencies) and easier for a human to get their head around.
But it's inconvenient in a generated POM (which is machine constructed and
largely machine read) because it creates ambiguity. Especially as
more/different tools make use of Maven repositories and as other artifacts
types dilute the existing high concentration of Java artifacts.
And being too Java centric is one of the reasons that Maven adoption
hasn't been more widespread.
For what it's worth, I think dependency type should only be the first plank
of the deployed POM that we should lock down better.
ᐧ
On Thu, Jan 22, 2015 at 12:13 PM, Jason van Zyl <ja...@takari.io> wrote:
>
> On Jan 20, 2015, at 6:03 PM, William Ferguson <
> william.ferguson@xandar.com.au> wrote:
>
> > Been thinking about this a little more.
> >
> > The TLDR version: I am suggesting that we provide more information and
> > place a stricter syntax requirement of the POM *generated* by the build.
> > This allows the generated POM to be a clear contract between the deployed
> > artifact and it's consumers, regardless of which build system is
> consuming
> > the artifact.
> >
> > ...
> >
> > Our problem: POMs provided by the Android support repo contain
> dependencies
> > that have no type information which is syntactically valid. But the
> > dependencies are assumed to be 'aar' resources by Gradle but not by
> Maven.
> >
> > We need the correct type information to be provided with the dependency.
> >
>
> We have to make a strict requirement for type information because the
> Android SDK team isn't going to help the Maven community have POMs that are
> correct? Really?
>
> >
> > We don't actually need the *source* POM syntax to change to require types
> > to be specified for all dependencies. We would just need the POM that is
> > generated as part of the build (ie output POM) include type for each
> > dependency.
> >
> > For Maven this would mean adding a type of 'jar' for any missing types
> into
> > the generated POM.
> >
> > In our use case this would mean that the POMs being generated by the
> > Android team could be identified as being invalid as they are missing
> type
> > information. And the Android team were to fix them up and include type
> > information then they would include the correct type info 'aar' and we
> > could build our projects without needing to manually hack 2 dozen POMs
> they
> > are providing.
> >
> > It would also allow us to confirm that the generated POM is valid during
> >
> > - dependency consumption
> > - deployment to Maven central
> >
> >
> > @Jason where is the generated POM (think you had another name for it)
> > concept at?
>
> We called it the consumer POM in the hangout.
>
> > Does this suggestion fit in with your thoughts on it?
> >
>
> Can we not just make a tool that corrects all the POMs by augmenting the
> tool that already exists?
>
> > William
> > ᐧ
> >
> > On Sat, Dec 20, 2014 at 11:59 AM, William Ferguson <
> > william.ferguson@xandar.com.au> wrote:
> >
> >> It's not the repository layout that Google is not honouring. It's the
> >> semantics of the unspecified dependency type in the POMs in that
> repository.
> >> If the POM syntax were changed to require that deps had a type then
> Maven
> >> itself could fail the build because it could determine that the inputs
> were
> >> invalid.
> >> And yes, this wouldn't stop Google from publishing a POM that had
> >> incorrect dependency types (eg explicitly specifying jar type when no
> such
> >> artifact exists), but at that point it is an explicit choice during
> >> construction and it is clear where the fault lies.
> >>
> >>
> >> NB this is all caused by a bug in Gradle
> >>
> http://forums.gradle.org/gradle/topics/missing-in-deployed-pom-files-if-different-than-jar-artifact-is-used
> >> Here is the report against AOSP
> >> https://code.google.com/p/android/issues/detail?id=72807
> >>
> >> While this isn't a bug in Maven, Maven owns the POM format. By not
> placing
> >> stricter controls around the ecosystem we are letting that ecosystem
> >> deteriorate. I don't want to see Maven slide into oblivion because new
> >> tools/processes are pissing into the common pot.
> >>
> >> At the very least it would help if the community starred the Gradle
> issue
> >> to try to get them to fix their problem.
> >>
> >>
> >> [image: photo]
> >> *William Ferguson*
> >> Founder and CEO, XandarMob
> >> m:+61 425 716 870 <+61%20425%20716%20870> | e:
> >> william.ferguson@xandar.com.au | w:https://wylas-timing.com
> >> http://lexathon.com
> >> ᐧ
> >>
> >> On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko <ig...@ifedorenko.com>
> >> wrote:
> >>>
> >>> On 2014-12-19, 17:40, William Ferguson wrote:
> >>>
> >>>> I'd love to go the first route, but unfortunately Google is only
> making
> >>>> the
> >>>> Android libraries available via a repository that is downloaded (and
> >>>> updated) via the Android SDK. So they are not visible on Maven Central
> >>>> and
> >>>> Maven Central obviously couldn't vet them.
> >>>>
> >>>
> >>> If Google deploys these artifacts to a separate repository and does not
> >>> honour current Maven repository layout, why do you think they will
> treat
> >>> the new layout differently?
> >>>
> >>>
> >>>> The second option would work, but I'd argue that it lends itself to
> >>>> convention clouding the expected behaviour as you'd need a map to know
> >>>> how
> >>>> each packaging type impacted the behaviour of unspecified dependency
> >>>> types.
> >>>> UNLESS the convention was that all dependencies with no type
> information
> >>>> get the packaging type of their project. But this would massively
> break
> >>>> existing build (think of all the war POMs).
> >>>>
> >>>>
> >>> No, I didn't mean to use project packaging type as default type for all
> >>> dependencies. I meant to associate default dependency type with project
> >>> packaging type. Packaging type, or, rather, build extension that
> defines
> >>> the packaging type, can provide the default value. Theoretically, Maven
> >>> could use components from the build extensions to during dependency
> >>> resolution.
> >>>
> >>> Another option, if all these funny artifacts come from the same
> >>> repository, you may be able to do implement custom repository layout to
> >>> do the mapping. Or the mapping can be done with a script and "fixed"
> >>> artifacts provided from another repository.
> >>>
> >>> --
> >>> Regards,
> >>> Igor
> >>>
> >>>
> >>>
> >>>> [image: photo]
> >>>> *William Ferguson*
> >>>> Founder and CEO, XandarMob
> >>>> m:+61 425 716 870 | e:william.ferguson@xandar.com.au |
> >>>> w:https://wylas-timing.com
> >>>> http://lexathon.com <http://wylas-timing.com http://lexathon.com>
> >>>>
> >>>> ᐧ
> >>>>
> >>>> On Fri, Dec 19, 2014 at 10:54 PM, Igor Fedorenko <igor@ifedorenko.com
> >
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> Ok, I understand the problem now, but I don't think forcing
> everything
> >>>>> to explicitly state dependency type is the right solution here.
> >>>>> "Convention over configuration" is one of fundamental Maven
> principals,
> >>>>> and by convention dependencies are assumed to have type=jar.
> >>>>>
> >>>>> I see two possible ways to improve here.
> >>>>>
> >>>>> I think Maven Central can be more strict about artifacts it accepts.
> It
> >>>>> should not be too difficult to validate all dependencies are present
> in
> >>>>> Central, for example, or present in Central or <repositories>
> configured
> >>>>> in pom.xml.
> >>>>>
> >>>>> Alternatively, we can also extend Maven to support different
> conventions
> >>>>> for different packaging types. This will be much more work and I
> didn't
> >>>>> think about implications of this change, but, in theory, it should be
> >>>>> possible to assume dependencies of artifacts with packaging=aar use
> >>>>> dependency type=aar by default.
> >>>>>
> >>>>> --
> >>>>> Regards,
> >>>>> Igor
> >>>>>
> >>>>>
> >>>>> On 2014-12-17, 17:20, William Ferguson wrote:
> >>>>>
> >>>>> Sorry Igor, I see now I omitted a chunk of context.
> >>>>>>
> >>>>>> The reason for the error is that this component :
> >>>>>>
> >>>>>> <dependency>
> >>>>>> <groupId>com.android.support</groupId>
> >>>>>> <artifactId>support-v13</artifactId>
> >>>>>> <version>21.0.2</version>
> >>>>>> <type>aar</type>
> >>>>>> </dependency>
> >>>>>>
> >>>>>> has a dependency upon
> >>>>>>
> >>>>>> <dependency>
> >>>>>> <groupId>com.android.support</groupId>
> >>>>>> <artifactId>support-v4</artifactId>
> >>>>>> <version>21.0.2</version>
> >>>>>> <type>aar</type>
> >>>>>> </dependency>
> >>>>>>
> >>>>>> But when the Android team packaged up support-v13, they declared the
> >>>>>> dependency on support-v4 as:
> >>>>>> <dependency>
> >>>>>> <groupId>com.android.support</groupId>
> >>>>>> <artifactId>support-v4</artifactId>
> >>>>>> <version>21.0.2</version>
> >>>>>> </dependency>
> >>>>>>
> >>>>>> which is a valid definition syntactically, may well be valid inside
> the
> >>>>>> Android dev team, and is parsed by the Android Gradle plugin (which
> >>>>>> makes
> >>>>>> gross assumptions about artifact type).
> >>>>>>
> >>>>>> But from a standard Maven perspective, that dependency definition is
> >>>>>> not
> >>>>>> valid. Which is why tools like the dependency-plugin (and anything
> that
> >>>>>> introspects deps) with fail with that dependency definition.
> >>>>>>
> >>>>>> We are pushing back on the Android guys to generate Maven POMs that
> are
> >>>>>> consumable by everyone, but the fact that the syntax allows them to
> >>>>>> generate an underspecified dependency could be eliminated. I think
> >>>>>> this is
> >>>>>> especially important as Maven is used by a wider and wider
> community.
> >>>>>> While
> >>>>>> it stemmed from Java builds, it is now used much more widely than
> pure
> >>>>>> Java
> >>>>>> libraries.
> >>>>>>
> >>>>>> William
> >>>>>>
> >>>>>>
> >>>>>> ᐧ
> >>>>>>
> >>>>>> On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <igor@ifedorenko.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> I am not sure I follow. Can you explain what actually happens and
> how
> >>>>>>> forcing <type> element for all projects dependencies is expected to
> >>>>>>> help
> >>>>>>> the problem?
> >>>>>>>
> >>>>>>> --
> >>>>>>> Regards,
> >>>>>>> Igor
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2014-12-07, 19:25, William Ferguson wrote:
> >>>>>>>
> >>>>>>> ## Cross posting to Maven Dev list
> >>>>>>>
> >>>>>>>>
> >>>>>>>> One solution to this would be to change the POM specification to
> >>>>>>>> require
> >>>>>>>> the type element for dependencies.
> >>>>>>>> That would allow Maven and MavenCentral to immediately fail POMs
> >>>>>>>> based
> >>>>>>>> upon dependencies that are missing the type element.
> >>>>>>>>
> >>>>>>>> Yes, it goes against convention over configuration, but Maven is
> now
> >>>>>>>> used by many more build types than just plain Java builds so
> maybe we
> >>>>>>>> need to consider that the convention is no longer to assume jar
> >>>>>>>> dependencies.
> >>>>>>>>
> >>>>>>>> I would rather require a little more configuration to ensure that
> >>>>>>>> builds
> >>>>>>>> are more deterministic.
> >>>>>>>> If we want to shrink the size of the POM then the new POM format
> is a
> >>>>>>>> better solution.
> >>>>>>>>
> >>>>>>>> William
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas
> Schildbach
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've
> got
> >>>>>>>> troubles declaring an aar dependency. Here is the pom.xml
> >>>>>>>> declaration:
> >>>>>>>>
> >>>>>>>> |
> >>>>>>>> <dependency>
> >>>>>>>> <groupId>com.android.support</groupId>
> >>>>>>>> <artifactId>support-v13</artifactId>
> >>>>>>>> <version>21.0.2</version>
> >>>>>>>> <type>aar</type>
> >>>>>>>> </dependency>
> >>>>>>>> |
> >>>>>>>>
> >>>>>>>> Just about any Maven command, even "mvn dependency:tree"
> >>>>>>>> yields:
> >>>>>>>>
> >>>>>>>> [ERROR] Failed to execute goal on project wallet: Could not
> >>>>>>>> resolve
> >>>>>>>> dependencies for project de.schildbach.wallet:wallet:
> >>>>>>>> apk:4.13-test:
> >>>>>>>> Failure to find com.android.support:support-v4:jar:21.0.2 in
> >>>>>>>> file:///home/aschildbach/dev/android-sdk/extras/android/
> >>>>>>>> m2repository
> >>>>>>>> was cached in the local repository, resolution will not be
> >>>>>>>> reattempted until the update interval of android-support has
> >>>>>>>> elapsed
> >>>>>>>> or updates are forced -> [Help 1]
> >>>>>>>>
> >>>>>>>> Where does that .jar type in the error message stem from? I
> >>>>>>>> declared
> >>>>>>>> aar.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ------------------------------------------------------------
> >>>>>>>> ---------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ------------------------------------------------------------
> >>>>>>>> ---------
> >>>>>>>>
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
>
> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: problem with AAR dependency
Posted by Jason van Zyl <ja...@takari.io>.
On Jan 20, 2015, at 6:03 PM, William Ferguson <wi...@xandar.com.au> wrote:
> Been thinking about this a little more.
>
> The TLDR version: I am suggesting that we provide more information and
> place a stricter syntax requirement of the POM *generated* by the build.
> This allows the generated POM to be a clear contract between the deployed
> artifact and it's consumers, regardless of which build system is consuming
> the artifact.
>
> ...
>
> Our problem: POMs provided by the Android support repo contain dependencies
> that have no type information which is syntactically valid. But the
> dependencies are assumed to be 'aar' resources by Gradle but not by Maven.
>
> We need the correct type information to be provided with the dependency.
>
We have to make a strict requirement for type information because the Android SDK team isn't going to help the Maven community have POMs that are correct? Really?
>
> We don't actually need the *source* POM syntax to change to require types
> to be specified for all dependencies. We would just need the POM that is
> generated as part of the build (ie output POM) include type for each
> dependency.
>
> For Maven this would mean adding a type of 'jar' for any missing types into
> the generated POM.
>
> In our use case this would mean that the POMs being generated by the
> Android team could be identified as being invalid as they are missing type
> information. And the Android team were to fix them up and include type
> information then they would include the correct type info 'aar' and we
> could build our projects without needing to manually hack 2 dozen POMs they
> are providing.
>
> It would also allow us to confirm that the generated POM is valid during
>
> - dependency consumption
> - deployment to Maven central
>
>
> @Jason where is the generated POM (think you had another name for it)
> concept at?
We called it the consumer POM in the hangout.
> Does this suggestion fit in with your thoughts on it?
>
Can we not just make a tool that corrects all the POMs by augmenting the tool that already exists?
> William
> ᐧ
>
> On Sat, Dec 20, 2014 at 11:59 AM, William Ferguson <
> william.ferguson@xandar.com.au> wrote:
>
>> It's not the repository layout that Google is not honouring. It's the
>> semantics of the unspecified dependency type in the POMs in that repository.
>> If the POM syntax were changed to require that deps had a type then Maven
>> itself could fail the build because it could determine that the inputs were
>> invalid.
>> And yes, this wouldn't stop Google from publishing a POM that had
>> incorrect dependency types (eg explicitly specifying jar type when no such
>> artifact exists), but at that point it is an explicit choice during
>> construction and it is clear where the fault lies.
>>
>>
>> NB this is all caused by a bug in Gradle
>> http://forums.gradle.org/gradle/topics/missing-in-deployed-pom-files-if-different-than-jar-artifact-is-used
>> Here is the report against AOSP
>> https://code.google.com/p/android/issues/detail?id=72807
>>
>> While this isn't a bug in Maven, Maven owns the POM format. By not placing
>> stricter controls around the ecosystem we are letting that ecosystem
>> deteriorate. I don't want to see Maven slide into oblivion because new
>> tools/processes are pissing into the common pot.
>>
>> At the very least it would help if the community starred the Gradle issue
>> to try to get them to fix their problem.
>>
>>
>> [image: photo]
>> *William Ferguson*
>> Founder and CEO, XandarMob
>> m:+61 425 716 870 <+61%20425%20716%20870> | e:
>> william.ferguson@xandar.com.au | w:https://wylas-timing.com
>> http://lexathon.com
>> ᐧ
>>
>> On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>>
>>> On 2014-12-19, 17:40, William Ferguson wrote:
>>>
>>>> I'd love to go the first route, but unfortunately Google is only making
>>>> the
>>>> Android libraries available via a repository that is downloaded (and
>>>> updated) via the Android SDK. So they are not visible on Maven Central
>>>> and
>>>> Maven Central obviously couldn't vet them.
>>>>
>>>
>>> If Google deploys these artifacts to a separate repository and does not
>>> honour current Maven repository layout, why do you think they will treat
>>> the new layout differently?
>>>
>>>
>>>> The second option would work, but I'd argue that it lends itself to
>>>> convention clouding the expected behaviour as you'd need a map to know
>>>> how
>>>> each packaging type impacted the behaviour of unspecified dependency
>>>> types.
>>>> UNLESS the convention was that all dependencies with no type information
>>>> get the packaging type of their project. But this would massively break
>>>> existing build (think of all the war POMs).
>>>>
>>>>
>>> No, I didn't mean to use project packaging type as default type for all
>>> dependencies. I meant to associate default dependency type with project
>>> packaging type. Packaging type, or, rather, build extension that defines
>>> the packaging type, can provide the default value. Theoretically, Maven
>>> could use components from the build extensions to during dependency
>>> resolution.
>>>
>>> Another option, if all these funny artifacts come from the same
>>> repository, you may be able to do implement custom repository layout to
>>> do the mapping. Or the mapping can be done with a script and "fixed"
>>> artifacts provided from another repository.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>>
>>>> [image: photo]
>>>> *William Ferguson*
>>>> Founder and CEO, XandarMob
>>>> m:+61 425 716 870 | e:william.ferguson@xandar.com.au |
>>>> w:https://wylas-timing.com
>>>> http://lexathon.com <http://wylas-timing.com http://lexathon.com>
>>>>
>>>> ᐧ
>>>>
>>>> On Fri, Dec 19, 2014 at 10:54 PM, Igor Fedorenko <ig...@ifedorenko.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Ok, I understand the problem now, but I don't think forcing everything
>>>>> to explicitly state dependency type is the right solution here.
>>>>> "Convention over configuration" is one of fundamental Maven principals,
>>>>> and by convention dependencies are assumed to have type=jar.
>>>>>
>>>>> I see two possible ways to improve here.
>>>>>
>>>>> I think Maven Central can be more strict about artifacts it accepts. It
>>>>> should not be too difficult to validate all dependencies are present in
>>>>> Central, for example, or present in Central or <repositories> configured
>>>>> in pom.xml.
>>>>>
>>>>> Alternatively, we can also extend Maven to support different conventions
>>>>> for different packaging types. This will be much more work and I didn't
>>>>> think about implications of this change, but, in theory, it should be
>>>>> possible to assume dependencies of artifacts with packaging=aar use
>>>>> dependency type=aar by default.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>>
>>>>> On 2014-12-17, 17:20, William Ferguson wrote:
>>>>>
>>>>> Sorry Igor, I see now I omitted a chunk of context.
>>>>>>
>>>>>> The reason for the error is that this component :
>>>>>>
>>>>>> <dependency>
>>>>>> <groupId>com.android.support</groupId>
>>>>>> <artifactId>support-v13</artifactId>
>>>>>> <version>21.0.2</version>
>>>>>> <type>aar</type>
>>>>>> </dependency>
>>>>>>
>>>>>> has a dependency upon
>>>>>>
>>>>>> <dependency>
>>>>>> <groupId>com.android.support</groupId>
>>>>>> <artifactId>support-v4</artifactId>
>>>>>> <version>21.0.2</version>
>>>>>> <type>aar</type>
>>>>>> </dependency>
>>>>>>
>>>>>> But when the Android team packaged up support-v13, they declared the
>>>>>> dependency on support-v4 as:
>>>>>> <dependency>
>>>>>> <groupId>com.android.support</groupId>
>>>>>> <artifactId>support-v4</artifactId>
>>>>>> <version>21.0.2</version>
>>>>>> </dependency>
>>>>>>
>>>>>> which is a valid definition syntactically, may well be valid inside the
>>>>>> Android dev team, and is parsed by the Android Gradle plugin (which
>>>>>> makes
>>>>>> gross assumptions about artifact type).
>>>>>>
>>>>>> But from a standard Maven perspective, that dependency definition is
>>>>>> not
>>>>>> valid. Which is why tools like the dependency-plugin (and anything that
>>>>>> introspects deps) with fail with that dependency definition.
>>>>>>
>>>>>> We are pushing back on the Android guys to generate Maven POMs that are
>>>>>> consumable by everyone, but the fact that the syntax allows them to
>>>>>> generate an underspecified dependency could be eliminated. I think
>>>>>> this is
>>>>>> especially important as Maven is used by a wider and wider community.
>>>>>> While
>>>>>> it stemmed from Java builds, it is now used much more widely than pure
>>>>>> Java
>>>>>> libraries.
>>>>>>
>>>>>> William
>>>>>>
>>>>>>
>>>>>> ᐧ
>>>>>>
>>>>>> On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> I am not sure I follow. Can you explain what actually happens and how
>>>>>>> forcing <type> element for all projects dependencies is expected to
>>>>>>> help
>>>>>>> the problem?
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Igor
>>>>>>>
>>>>>>>
>>>>>>> On 2014-12-07, 19:25, William Ferguson wrote:
>>>>>>>
>>>>>>> ## Cross posting to Maven Dev list
>>>>>>>
>>>>>>>>
>>>>>>>> One solution to this would be to change the POM specification to
>>>>>>>> require
>>>>>>>> the type element for dependencies.
>>>>>>>> That would allow Maven and MavenCentral to immediately fail POMs
>>>>>>>> based
>>>>>>>> upon dependencies that are missing the type element.
>>>>>>>>
>>>>>>>> Yes, it goes against convention over configuration, but Maven is now
>>>>>>>> used by many more build types than just plain Java builds so maybe we
>>>>>>>> need to consider that the convention is no longer to assume jar
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>> I would rather require a little more configuration to ensure that
>>>>>>>> builds
>>>>>>>> are more deterministic.
>>>>>>>> If we want to shrink the size of the POM then the new POM format is a
>>>>>>>> better solution.
>>>>>>>>
>>>>>>>> William
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
>>>>>>>> troubles declaring an aar dependency. Here is the pom.xml
>>>>>>>> declaration:
>>>>>>>>
>>>>>>>> |
>>>>>>>> <dependency>
>>>>>>>> <groupId>com.android.support</groupId>
>>>>>>>> <artifactId>support-v13</artifactId>
>>>>>>>> <version>21.0.2</version>
>>>>>>>> <type>aar</type>
>>>>>>>> </dependency>
>>>>>>>> |
>>>>>>>>
>>>>>>>> Just about any Maven command, even "mvn dependency:tree"
>>>>>>>> yields:
>>>>>>>>
>>>>>>>> [ERROR] Failed to execute goal on project wallet: Could not
>>>>>>>> resolve
>>>>>>>> dependencies for project de.schildbach.wallet:wallet:
>>>>>>>> apk:4.13-test:
>>>>>>>> Failure to find com.android.support:support-v4:jar:21.0.2 in
>>>>>>>> file:///home/aschildbach/dev/android-sdk/extras/android/
>>>>>>>> m2repository
>>>>>>>> was cached in the local repository, resolution will not be
>>>>>>>> reattempted until the update interval of android-support has
>>>>>>>> elapsed
>>>>>>>> or updates are forced -> [Help 1]
>>>>>>>>
>>>>>>>> Where does that .jar type in the error message stem from? I
>>>>>>>> declared
>>>>>>>> aar.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: problem with AAR dependency
Posted by William Ferguson <wi...@xandar.com.au>.
Been thinking about this a little more.
The TLDR version: I am suggesting that we provide more information and
place a stricter syntax requirement of the POM *generated* by the build.
This allows the generated POM to be a clear contract between the deployed
artifact and it's consumers, regardless of which build system is consuming
the artifact.
...
Our problem: POMs provided by the Android support repo contain dependencies
that have no type information which is syntactically valid. But the
dependencies are assumed to be 'aar' resources by Gradle but not by Maven.
We need the correct type information to be provided with the dependency.
We don't actually need the *source* POM syntax to change to require types
to be specified for all dependencies. We would just need the POM that is
generated as part of the build (ie output POM) include type for each
dependency.
For Maven this would mean adding a type of 'jar' for any missing types into
the generated POM.
In our use case this would mean that the POMs being generated by the
Android team could be identified as being invalid as they are missing type
information. And the Android team were to fix them up and include type
information then they would include the correct type info 'aar' and we
could build our projects without needing to manually hack 2 dozen POMs they
are providing.
It would also allow us to confirm that the generated POM is valid during
- dependency consumption
- deployment to Maven central
@Jason where is the generated POM (think you had another name for it)
concept at?
Does this suggestion fit in with your thoughts on it?
William
ᐧ
On Sat, Dec 20, 2014 at 11:59 AM, William Ferguson <
william.ferguson@xandar.com.au> wrote:
> It's not the repository layout that Google is not honouring. It's the
> semantics of the unspecified dependency type in the POMs in that repository.
> If the POM syntax were changed to require that deps had a type then Maven
> itself could fail the build because it could determine that the inputs were
> invalid.
> And yes, this wouldn't stop Google from publishing a POM that had
> incorrect dependency types (eg explicitly specifying jar type when no such
> artifact exists), but at that point it is an explicit choice during
> construction and it is clear where the fault lies.
>
>
> NB this is all caused by a bug in Gradle
> http://forums.gradle.org/gradle/topics/missing-in-deployed-pom-files-if-different-than-jar-artifact-is-used
> Here is the report against AOSP
> https://code.google.com/p/android/issues/detail?id=72807
>
> While this isn't a bug in Maven, Maven owns the POM format. By not placing
> stricter controls around the ecosystem we are letting that ecosystem
> deteriorate. I don't want to see Maven slide into oblivion because new
> tools/processes are pissing into the common pot.
>
> At the very least it would help if the community starred the Gradle issue
> to try to get them to fix their problem.
>
>
> [image: photo]
> *William Ferguson*
> Founder and CEO, XandarMob
> m:+61 425 716 870 <+61%20425%20716%20870> | e:
> william.ferguson@xandar.com.au | w:https://wylas-timing.com
> http://lexathon.com
> ᐧ
>
> On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko <ig...@ifedorenko.com>
> wrote:
>>
>> On 2014-12-19, 17:40, William Ferguson wrote:
>>
>>> I'd love to go the first route, but unfortunately Google is only making
>>> the
>>> Android libraries available via a repository that is downloaded (and
>>> updated) via the Android SDK. So they are not visible on Maven Central
>>> and
>>> Maven Central obviously couldn't vet them.
>>>
>>
>> If Google deploys these artifacts to a separate repository and does not
>> honour current Maven repository layout, why do you think they will treat
>> the new layout differently?
>>
>>
>>> The second option would work, but I'd argue that it lends itself to
>>> convention clouding the expected behaviour as you'd need a map to know
>>> how
>>> each packaging type impacted the behaviour of unspecified dependency
>>> types.
>>> UNLESS the convention was that all dependencies with no type information
>>> get the packaging type of their project. But this would massively break
>>> existing build (think of all the war POMs).
>>>
>>>
>> No, I didn't mean to use project packaging type as default type for all
>> dependencies. I meant to associate default dependency type with project
>> packaging type. Packaging type, or, rather, build extension that defines
>> the packaging type, can provide the default value. Theoretically, Maven
>> could use components from the build extensions to during dependency
>> resolution.
>>
>> Another option, if all these funny artifacts come from the same
>> repository, you may be able to do implement custom repository layout to
>> do the mapping. Or the mapping can be done with a script and "fixed"
>> artifacts provided from another repository.
>>
>> --
>> Regards,
>> Igor
>>
>>
>>
>>> [image: photo]
>>> *William Ferguson*
>>> Founder and CEO, XandarMob
>>> m:+61 425 716 870 | e:william.ferguson@xandar.com.au |
>>> w:https://wylas-timing.com
>>> http://lexathon.com <http://wylas-timing.com http://lexathon.com>
>>>
>>> ᐧ
>>>
>>> On Fri, Dec 19, 2014 at 10:54 PM, Igor Fedorenko <ig...@ifedorenko.com>
>>> wrote:
>>>
>>>>
>>>> Ok, I understand the problem now, but I don't think forcing everything
>>>> to explicitly state dependency type is the right solution here.
>>>> "Convention over configuration" is one of fundamental Maven principals,
>>>> and by convention dependencies are assumed to have type=jar.
>>>>
>>>> I see two possible ways to improve here.
>>>>
>>>> I think Maven Central can be more strict about artifacts it accepts. It
>>>> should not be too difficult to validate all dependencies are present in
>>>> Central, for example, or present in Central or <repositories> configured
>>>> in pom.xml.
>>>>
>>>> Alternatively, we can also extend Maven to support different conventions
>>>> for different packaging types. This will be much more work and I didn't
>>>> think about implications of this change, but, in theory, it should be
>>>> possible to assume dependencies of artifacts with packaging=aar use
>>>> dependency type=aar by default.
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>> On 2014-12-17, 17:20, William Ferguson wrote:
>>>>
>>>> Sorry Igor, I see now I omitted a chunk of context.
>>>>>
>>>>> The reason for the error is that this component :
>>>>>
>>>>> <dependency>
>>>>> <groupId>com.android.support</groupId>
>>>>> <artifactId>support-v13</artifactId>
>>>>> <version>21.0.2</version>
>>>>> <type>aar</type>
>>>>> </dependency>
>>>>>
>>>>> has a dependency upon
>>>>>
>>>>> <dependency>
>>>>> <groupId>com.android.support</groupId>
>>>>> <artifactId>support-v4</artifactId>
>>>>> <version>21.0.2</version>
>>>>> <type>aar</type>
>>>>> </dependency>
>>>>>
>>>>> But when the Android team packaged up support-v13, they declared the
>>>>> dependency on support-v4 as:
>>>>> <dependency>
>>>>> <groupId>com.android.support</groupId>
>>>>> <artifactId>support-v4</artifactId>
>>>>> <version>21.0.2</version>
>>>>> </dependency>
>>>>>
>>>>> which is a valid definition syntactically, may well be valid inside the
>>>>> Android dev team, and is parsed by the Android Gradle plugin (which
>>>>> makes
>>>>> gross assumptions about artifact type).
>>>>>
>>>>> But from a standard Maven perspective, that dependency definition is
>>>>> not
>>>>> valid. Which is why tools like the dependency-plugin (and anything that
>>>>> introspects deps) with fail with that dependency definition.
>>>>>
>>>>> We are pushing back on the Android guys to generate Maven POMs that are
>>>>> consumable by everyone, but the fact that the syntax allows them to
>>>>> generate an underspecified dependency could be eliminated. I think
>>>>> this is
>>>>> especially important as Maven is used by a wider and wider community.
>>>>> While
>>>>> it stemmed from Java builds, it is now used much more widely than pure
>>>>> Java
>>>>> libraries.
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>> ᐧ
>>>>>
>>>>> On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> I am not sure I follow. Can you explain what actually happens and how
>>>>>> forcing <type> element for all projects dependencies is expected to
>>>>>> help
>>>>>> the problem?
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Igor
>>>>>>
>>>>>>
>>>>>> On 2014-12-07, 19:25, William Ferguson wrote:
>>>>>>
>>>>>> ## Cross posting to Maven Dev list
>>>>>>
>>>>>>>
>>>>>>> One solution to this would be to change the POM specification to
>>>>>>> require
>>>>>>> the type element for dependencies.
>>>>>>> That would allow Maven and MavenCentral to immediately fail POMs
>>>>>>> based
>>>>>>> upon dependencies that are missing the type element.
>>>>>>>
>>>>>>> Yes, it goes against convention over configuration, but Maven is now
>>>>>>> used by many more build types than just plain Java builds so maybe we
>>>>>>> need to consider that the convention is no longer to assume jar
>>>>>>> dependencies.
>>>>>>>
>>>>>>> I would rather require a little more configuration to ensure that
>>>>>>> builds
>>>>>>> are more deterministic.
>>>>>>> If we want to shrink the size of the POM then the new POM format is a
>>>>>>> better solution.
>>>>>>>
>>>>>>> William
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
>>>>>>> troubles declaring an aar dependency. Here is the pom.xml
>>>>>>> declaration:
>>>>>>>
>>>>>>> |
>>>>>>> <dependency>
>>>>>>> <groupId>com.android.support</groupId>
>>>>>>> <artifactId>support-v13</artifactId>
>>>>>>> <version>21.0.2</version>
>>>>>>> <type>aar</type>
>>>>>>> </dependency>
>>>>>>> |
>>>>>>>
>>>>>>> Just about any Maven command, even "mvn dependency:tree"
>>>>>>> yields:
>>>>>>>
>>>>>>> [ERROR] Failed to execute goal on project wallet: Could not
>>>>>>> resolve
>>>>>>> dependencies for project de.schildbach.wallet:wallet:
>>>>>>> apk:4.13-test:
>>>>>>> Failure to find com.android.support:support-v4:jar:21.0.2 in
>>>>>>> file:///home/aschildbach/dev/android-sdk/extras/android/
>>>>>>> m2repository
>>>>>>> was cached in the local repository, resolution will not be
>>>>>>> reattempted until the update interval of android-support has
>>>>>>> elapsed
>>>>>>> or updates are forced -> [Help 1]
>>>>>>>
>>>>>>> Where does that .jar type in the error message stem from? I
>>>>>>> declared
>>>>>>> aar.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Re: problem with AAR dependency
Posted by William Ferguson <wi...@xandar.com.au>.
It's not the repository layout that Google is not honouring. It's the
semantics of the unspecified dependency type in the POMs in that repository.
If the POM syntax were changed to require that deps had a type then Maven
itself could fail the build because it could determine that the inputs were
invalid.
And yes, this wouldn't stop Google from publishing a POM that had incorrect
dependency types (eg explicitly specifying jar type when no such artifact
exists), but at that point it is an explicit choice during construction and
it is clear where the fault lies.
NB this is all caused by a bug in Gradle
http://forums.gradle.org/gradle/topics/missing-in-deployed-pom-files-if-different-than-jar-artifact-is-used
Here is the report against AOSP
https://code.google.com/p/android/issues/detail?id=72807
While this isn't a bug in Maven, Maven owns the POM format. By not placing
stricter controls around the ecosystem we are letting that ecosystem
deteriorate. I don't want to see Maven slide into oblivion because new
tools/processes are pissing into the common pot.
At the very least it would help if the community starred the Gradle issue
to try to get them to fix their problem.
[image: photo]
*William Ferguson*
Founder and CEO, XandarMob
m:+61 425 716 870 | e:william.ferguson@xandar.com.au |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>
ᐧ
On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
> On 2014-12-19, 17:40, William Ferguson wrote:
>
>> I'd love to go the first route, but unfortunately Google is only making
>> the
>> Android libraries available via a repository that is downloaded (and
>> updated) via the Android SDK. So they are not visible on Maven Central and
>> Maven Central obviously couldn't vet them.
>>
>
> If Google deploys these artifacts to a separate repository and does not
> honour current Maven repository layout, why do you think they will treat
> the new layout differently?
>
>
>> The second option would work, but I'd argue that it lends itself to
>> convention clouding the expected behaviour as you'd need a map to know how
>> each packaging type impacted the behaviour of unspecified dependency
>> types.
>> UNLESS the convention was that all dependencies with no type information
>> get the packaging type of their project. But this would massively break
>> existing build (think of all the war POMs).
>>
>>
> No, I didn't mean to use project packaging type as default type for all
> dependencies. I meant to associate default dependency type with project
> packaging type. Packaging type, or, rather, build extension that defines
> the packaging type, can provide the default value. Theoretically, Maven
> could use components from the build extensions to during dependency
> resolution.
>
> Another option, if all these funny artifacts come from the same
> repository, you may be able to do implement custom repository layout to
> do the mapping. Or the mapping can be done with a script and "fixed"
> artifacts provided from another repository.
>
> --
> Regards,
> Igor
>
>
>
>> [image: photo]
>> *William Ferguson*
>> Founder and CEO, XandarMob
>> m:+61 425 716 870 | e:william.ferguson@xandar.com.au |
>> w:https://wylas-timing.com
>> http://lexathon.com <http://wylas-timing.com http://lexathon.com>
>>
>> ᐧ
>>
>> On Fri, Dec 19, 2014 at 10:54 PM, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>
>>>
>>> Ok, I understand the problem now, but I don't think forcing everything
>>> to explicitly state dependency type is the right solution here.
>>> "Convention over configuration" is one of fundamental Maven principals,
>>> and by convention dependencies are assumed to have type=jar.
>>>
>>> I see two possible ways to improve here.
>>>
>>> I think Maven Central can be more strict about artifacts it accepts. It
>>> should not be too difficult to validate all dependencies are present in
>>> Central, for example, or present in Central or <repositories> configured
>>> in pom.xml.
>>>
>>> Alternatively, we can also extend Maven to support different conventions
>>> for different packaging types. This will be much more work and I didn't
>>> think about implications of this change, but, in theory, it should be
>>> possible to assume dependencies of artifacts with packaging=aar use
>>> dependency type=aar by default.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>> On 2014-12-17, 17:20, William Ferguson wrote:
>>>
>>> Sorry Igor, I see now I omitted a chunk of context.
>>>>
>>>> The reason for the error is that this component :
>>>>
>>>> <dependency>
>>>> <groupId>com.android.support</groupId>
>>>> <artifactId>support-v13</artifactId>
>>>> <version>21.0.2</version>
>>>> <type>aar</type>
>>>> </dependency>
>>>>
>>>> has a dependency upon
>>>>
>>>> <dependency>
>>>> <groupId>com.android.support</groupId>
>>>> <artifactId>support-v4</artifactId>
>>>> <version>21.0.2</version>
>>>> <type>aar</type>
>>>> </dependency>
>>>>
>>>> But when the Android team packaged up support-v13, they declared the
>>>> dependency on support-v4 as:
>>>> <dependency>
>>>> <groupId>com.android.support</groupId>
>>>> <artifactId>support-v4</artifactId>
>>>> <version>21.0.2</version>
>>>> </dependency>
>>>>
>>>> which is a valid definition syntactically, may well be valid inside the
>>>> Android dev team, and is parsed by the Android Gradle plugin (which
>>>> makes
>>>> gross assumptions about artifact type).
>>>>
>>>> But from a standard Maven perspective, that dependency definition is not
>>>> valid. Which is why tools like the dependency-plugin (and anything that
>>>> introspects deps) with fail with that dependency definition.
>>>>
>>>> We are pushing back on the Android guys to generate Maven POMs that are
>>>> consumable by everyone, but the fact that the syntax allows them to
>>>> generate an underspecified dependency could be eliminated. I think this
>>>> is
>>>> especially important as Maven is used by a wider and wider community.
>>>> While
>>>> it stemmed from Java builds, it is now used much more widely than pure
>>>> Java
>>>> libraries.
>>>>
>>>> William
>>>>
>>>>
>>>> ᐧ
>>>>
>>>> On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>>> wrote:
>>>>
>>>>
>>>>> I am not sure I follow. Can you explain what actually happens and how
>>>>> forcing <type> element for all projects dependencies is expected to
>>>>> help
>>>>> the problem?
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>>
>>>>> On 2014-12-07, 19:25, William Ferguson wrote:
>>>>>
>>>>> ## Cross posting to Maven Dev list
>>>>>
>>>>>>
>>>>>> One solution to this would be to change the POM specification to
>>>>>> require
>>>>>> the type element for dependencies.
>>>>>> That would allow Maven and MavenCentral to immediately fail POMs based
>>>>>> upon dependencies that are missing the type element.
>>>>>>
>>>>>> Yes, it goes against convention over configuration, but Maven is now
>>>>>> used by many more build types than just plain Java builds so maybe we
>>>>>> need to consider that the convention is no longer to assume jar
>>>>>> dependencies.
>>>>>>
>>>>>> I would rather require a little more configuration to ensure that
>>>>>> builds
>>>>>> are more deterministic.
>>>>>> If we want to shrink the size of the POM then the new POM format is a
>>>>>> better solution.
>>>>>>
>>>>>> William
>>>>>>
>>>>>>
>>>>>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach
>>>>>> wrote:
>>>>>>
>>>>>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
>>>>>> troubles declaring an aar dependency. Here is the pom.xml
>>>>>> declaration:
>>>>>>
>>>>>> |
>>>>>> <dependency>
>>>>>> <groupId>com.android.support</groupId>
>>>>>> <artifactId>support-v13</artifactId>
>>>>>> <version>21.0.2</version>
>>>>>> <type>aar</type>
>>>>>> </dependency>
>>>>>> |
>>>>>>
>>>>>> Just about any Maven command, even "mvn dependency:tree" yields:
>>>>>>
>>>>>> [ERROR] Failed to execute goal on project wallet: Could not
>>>>>> resolve
>>>>>> dependencies for project de.schildbach.wallet:wallet:
>>>>>> apk:4.13-test:
>>>>>> Failure to find com.android.support:support-v4:jar:21.0.2 in
>>>>>> file:///home/aschildbach/dev/android-sdk/extras/android/
>>>>>> m2repository
>>>>>> was cached in the local repository, resolution will not be
>>>>>> reattempted until the update interval of android-support has
>>>>>> elapsed
>>>>>> or updates are forced -> [Help 1]
>>>>>>
>>>>>> Where does that .jar type in the error message stem from? I
>>>>>> declared
>>>>>> aar.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: problem with AAR dependency
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
On 2014-12-19, 17:40, William Ferguson wrote:
> I'd love to go the first route, but unfortunately Google is only making the
> Android libraries available via a repository that is downloaded (and
> updated) via the Android SDK. So they are not visible on Maven Central and
> Maven Central obviously couldn't vet them.
If Google deploys these artifacts to a separate repository and does not
honour current Maven repository layout, why do you think they will treat
the new layout differently?
>
> The second option would work, but I'd argue that it lends itself to
> convention clouding the expected behaviour as you'd need a map to know how
> each packaging type impacted the behaviour of unspecified dependency types.
> UNLESS the convention was that all dependencies with no type information
> get the packaging type of their project. But this would massively break
> existing build (think of all the war POMs).
>
No, I didn't mean to use project packaging type as default type for all
dependencies. I meant to associate default dependency type with project
packaging type. Packaging type, or, rather, build extension that defines
the packaging type, can provide the default value. Theoretically, Maven
could use components from the build extensions to during dependency
resolution.
Another option, if all these funny artifacts come from the same
repository, you may be able to do implement custom repository layout to
do the mapping. Or the mapping can be done with a script and "fixed"
artifacts provided from another repository.
--
Regards,
Igor
>
> [image: photo]
> *William Ferguson*
> Founder and CEO, XandarMob
> m:+61 425 716 870 | e:william.ferguson@xandar.com.au |
> w:https://wylas-timing.com
> http://lexathon.com <http://wylas-timing.com http://lexathon.com>
> ᐧ
>
> On Fri, Dec 19, 2014 at 10:54 PM, Igor Fedorenko <ig...@ifedorenko.com>
> wrote:
>>
>> Ok, I understand the problem now, but I don't think forcing everything
>> to explicitly state dependency type is the right solution here.
>> "Convention over configuration" is one of fundamental Maven principals,
>> and by convention dependencies are assumed to have type=jar.
>>
>> I see two possible ways to improve here.
>>
>> I think Maven Central can be more strict about artifacts it accepts. It
>> should not be too difficult to validate all dependencies are present in
>> Central, for example, or present in Central or <repositories> configured
>> in pom.xml.
>>
>> Alternatively, we can also extend Maven to support different conventions
>> for different packaging types. This will be much more work and I didn't
>> think about implications of this change, but, in theory, it should be
>> possible to assume dependencies of artifacts with packaging=aar use
>> dependency type=aar by default.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2014-12-17, 17:20, William Ferguson wrote:
>>
>>> Sorry Igor, I see now I omitted a chunk of context.
>>>
>>> The reason for the error is that this component :
>>>
>>> <dependency>
>>> <groupId>com.android.support</groupId>
>>> <artifactId>support-v13</artifactId>
>>> <version>21.0.2</version>
>>> <type>aar</type>
>>> </dependency>
>>>
>>> has a dependency upon
>>>
>>> <dependency>
>>> <groupId>com.android.support</groupId>
>>> <artifactId>support-v4</artifactId>
>>> <version>21.0.2</version>
>>> <type>aar</type>
>>> </dependency>
>>>
>>> But when the Android team packaged up support-v13, they declared the
>>> dependency on support-v4 as:
>>> <dependency>
>>> <groupId>com.android.support</groupId>
>>> <artifactId>support-v4</artifactId>
>>> <version>21.0.2</version>
>>> </dependency>
>>>
>>> which is a valid definition syntactically, may well be valid inside the
>>> Android dev team, and is parsed by the Android Gradle plugin (which makes
>>> gross assumptions about artifact type).
>>>
>>> But from a standard Maven perspective, that dependency definition is not
>>> valid. Which is why tools like the dependency-plugin (and anything that
>>> introspects deps) with fail with that dependency definition.
>>>
>>> We are pushing back on the Android guys to generate Maven POMs that are
>>> consumable by everyone, but the fact that the syntax allows them to
>>> generate an underspecified dependency could be eliminated. I think this is
>>> especially important as Maven is used by a wider and wider community.
>>> While
>>> it stemmed from Java builds, it is now used much more widely than pure
>>> Java
>>> libraries.
>>>
>>> William
>>>
>>>
>>> ᐧ
>>>
>>> On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <ig...@ifedorenko.com>
>>> wrote:
>>>
>>>>
>>>> I am not sure I follow. Can you explain what actually happens and how
>>>> forcing <type> element for all projects dependencies is expected to help
>>>> the problem?
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>> On 2014-12-07, 19:25, William Ferguson wrote:
>>>>
>>>> ## Cross posting to Maven Dev list
>>>>>
>>>>> One solution to this would be to change the POM specification to require
>>>>> the type element for dependencies.
>>>>> That would allow Maven and MavenCentral to immediately fail POMs based
>>>>> upon dependencies that are missing the type element.
>>>>>
>>>>> Yes, it goes against convention over configuration, but Maven is now
>>>>> used by many more build types than just plain Java builds so maybe we
>>>>> need to consider that the convention is no longer to assume jar
>>>>> dependencies.
>>>>>
>>>>> I would rather require a little more configuration to ensure that builds
>>>>> are more deterministic.
>>>>> If we want to shrink the size of the POM then the new POM format is a
>>>>> better solution.
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach
>>>>> wrote:
>>>>>
>>>>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
>>>>> troubles declaring an aar dependency. Here is the pom.xml
>>>>> declaration:
>>>>>
>>>>> |
>>>>> <dependency>
>>>>> <groupId>com.android.support</groupId>
>>>>> <artifactId>support-v13</artifactId>
>>>>> <version>21.0.2</version>
>>>>> <type>aar</type>
>>>>> </dependency>
>>>>> |
>>>>>
>>>>> Just about any Maven command, even "mvn dependency:tree" yields:
>>>>>
>>>>> [ERROR] Failed to execute goal on project wallet: Could not resolve
>>>>> dependencies for project de.schildbach.wallet:wallet:
>>>>> apk:4.13-test:
>>>>> Failure to find com.android.support:support-v4:jar:21.0.2 in
>>>>> file:///home/aschildbach/dev/android-sdk/extras/android/
>>>>> m2repository
>>>>> was cached in the local repository, resolution will not be
>>>>> reattempted until the update interval of android-support has
>>>>> elapsed
>>>>> or updates are forced -> [Help 1]
>>>>>
>>>>> Where does that .jar type in the error message stem from? I
>>>>> declared
>>>>> aar.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: problem with AAR dependency
Posted by William Ferguson <wi...@xandar.com.au>.
I'd love to go the first route, but unfortunately Google is only making the
Android libraries available via a repository that is downloaded (and
updated) via the Android SDK. So they are not visible on Maven Central and
Maven Central obviously couldn't vet them.
The second option would work, but I'd argue that it lends itself to
convention clouding the expected behaviour as you'd need a map to know how
each packaging type impacted the behaviour of unspecified dependency types.
UNLESS the convention was that all dependencies with no type information
get the packaging type of their project. But this would massively break
existing build (think of all the war POMs).
[image: photo]
*William Ferguson*
Founder and CEO, XandarMob
m:+61 425 716 870 | e:william.ferguson@xandar.com.au |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>
ᐧ
On Fri, Dec 19, 2014 at 10:54 PM, Igor Fedorenko <ig...@ifedorenko.com>
wrote:
>
> Ok, I understand the problem now, but I don't think forcing everything
> to explicitly state dependency type is the right solution here.
> "Convention over configuration" is one of fundamental Maven principals,
> and by convention dependencies are assumed to have type=jar.
>
> I see two possible ways to improve here.
>
> I think Maven Central can be more strict about artifacts it accepts. It
> should not be too difficult to validate all dependencies are present in
> Central, for example, or present in Central or <repositories> configured
> in pom.xml.
>
> Alternatively, we can also extend Maven to support different conventions
> for different packaging types. This will be much more work and I didn't
> think about implications of this change, but, in theory, it should be
> possible to assume dependencies of artifacts with packaging=aar use
> dependency type=aar by default.
>
> --
> Regards,
> Igor
>
>
> On 2014-12-17, 17:20, William Ferguson wrote:
>
>> Sorry Igor, I see now I omitted a chunk of context.
>>
>> The reason for the error is that this component :
>>
>> <dependency>
>> <groupId>com.android.support</groupId>
>> <artifactId>support-v13</artifactId>
>> <version>21.0.2</version>
>> <type>aar</type>
>> </dependency>
>>
>> has a dependency upon
>>
>> <dependency>
>> <groupId>com.android.support</groupId>
>> <artifactId>support-v4</artifactId>
>> <version>21.0.2</version>
>> <type>aar</type>
>> </dependency>
>>
>> But when the Android team packaged up support-v13, they declared the
>> dependency on support-v4 as:
>> <dependency>
>> <groupId>com.android.support</groupId>
>> <artifactId>support-v4</artifactId>
>> <version>21.0.2</version>
>> </dependency>
>>
>> which is a valid definition syntactically, may well be valid inside the
>> Android dev team, and is parsed by the Android Gradle plugin (which makes
>> gross assumptions about artifact type).
>>
>> But from a standard Maven perspective, that dependency definition is not
>> valid. Which is why tools like the dependency-plugin (and anything that
>> introspects deps) with fail with that dependency definition.
>>
>> We are pushing back on the Android guys to generate Maven POMs that are
>> consumable by everyone, but the fact that the syntax allows them to
>> generate an underspecified dependency could be eliminated. I think this is
>> especially important as Maven is used by a wider and wider community.
>> While
>> it stemmed from Java builds, it is now used much more widely than pure
>> Java
>> libraries.
>>
>> William
>>
>>
>> ᐧ
>>
>> On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>
>>>
>>> I am not sure I follow. Can you explain what actually happens and how
>>> forcing <type> element for all projects dependencies is expected to help
>>> the problem?
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>> On 2014-12-07, 19:25, William Ferguson wrote:
>>>
>>> ## Cross posting to Maven Dev list
>>>>
>>>> One solution to this would be to change the POM specification to require
>>>> the type element for dependencies.
>>>> That would allow Maven and MavenCentral to immediately fail POMs based
>>>> upon dependencies that are missing the type element.
>>>>
>>>> Yes, it goes against convention over configuration, but Maven is now
>>>> used by many more build types than just plain Java builds so maybe we
>>>> need to consider that the convention is no longer to assume jar
>>>> dependencies.
>>>>
>>>> I would rather require a little more configuration to ensure that builds
>>>> are more deterministic.
>>>> If we want to shrink the size of the POM then the new POM format is a
>>>> better solution.
>>>>
>>>> William
>>>>
>>>>
>>>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach
>>>> wrote:
>>>>
>>>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
>>>> troubles declaring an aar dependency. Here is the pom.xml
>>>> declaration:
>>>>
>>>> |
>>>> <dependency>
>>>> <groupId>com.android.support</groupId>
>>>> <artifactId>support-v13</artifactId>
>>>> <version>21.0.2</version>
>>>> <type>aar</type>
>>>> </dependency>
>>>> |
>>>>
>>>> Just about any Maven command, even "mvn dependency:tree" yields:
>>>>
>>>> [ERROR] Failed to execute goal on project wallet: Could not resolve
>>>> dependencies for project de.schildbach.wallet:wallet:
>>>> apk:4.13-test:
>>>> Failure to find com.android.support:support-v4:jar:21.0.2 in
>>>> file:///home/aschildbach/dev/android-sdk/extras/android/
>>>> m2repository
>>>> was cached in the local repository, resolution will not be
>>>> reattempted until the update interval of android-support has
>>>> elapsed
>>>> or updates are forced -> [Help 1]
>>>>
>>>> Where does that .jar type in the error message stem from? I
>>>> declared
>>>> aar.
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: problem with AAR dependency
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Ok, I understand the problem now, but I don't think forcing everything
to explicitly state dependency type is the right solution here.
"Convention over configuration" is one of fundamental Maven principals,
and by convention dependencies are assumed to have type=jar.
I see two possible ways to improve here.
I think Maven Central can be more strict about artifacts it accepts. It
should not be too difficult to validate all dependencies are present in
Central, for example, or present in Central or <repositories> configured
in pom.xml.
Alternatively, we can also extend Maven to support different conventions
for different packaging types. This will be much more work and I didn't
think about implications of this change, but, in theory, it should be
possible to assume dependencies of artifacts with packaging=aar use
dependency type=aar by default.
--
Regards,
Igor
On 2014-12-17, 17:20, William Ferguson wrote:
> Sorry Igor, I see now I omitted a chunk of context.
>
> The reason for the error is that this component :
>
> <dependency>
> <groupId>com.android.support</groupId>
> <artifactId>support-v13</artifactId>
> <version>21.0.2</version>
> <type>aar</type>
> </dependency>
>
> has a dependency upon
>
> <dependency>
> <groupId>com.android.support</groupId>
> <artifactId>support-v4</artifactId>
> <version>21.0.2</version>
> <type>aar</type>
> </dependency>
>
> But when the Android team packaged up support-v13, they declared the
> dependency on support-v4 as:
> <dependency>
> <groupId>com.android.support</groupId>
> <artifactId>support-v4</artifactId>
> <version>21.0.2</version>
> </dependency>
>
> which is a valid definition syntactically, may well be valid inside the
> Android dev team, and is parsed by the Android Gradle plugin (which makes
> gross assumptions about artifact type).
>
> But from a standard Maven perspective, that dependency definition is not
> valid. Which is why tools like the dependency-plugin (and anything that
> introspects deps) with fail with that dependency definition.
>
> We are pushing back on the Android guys to generate Maven POMs that are
> consumable by everyone, but the fact that the syntax allows them to
> generate an underspecified dependency could be eliminated. I think this is
> especially important as Maven is used by a wider and wider community. While
> it stemmed from Java builds, it is now used much more widely than pure Java
> libraries.
>
> William
>
>
> ᐧ
>
> On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>>
>> I am not sure I follow. Can you explain what actually happens and how
>> forcing <type> element for all projects dependencies is expected to help
>> the problem?
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2014-12-07, 19:25, William Ferguson wrote:
>>
>>> ## Cross posting to Maven Dev list
>>>
>>> One solution to this would be to change the POM specification to require
>>> the type element for dependencies.
>>> That would allow Maven and MavenCentral to immediately fail POMs based
>>> upon dependencies that are missing the type element.
>>>
>>> Yes, it goes against convention over configuration, but Maven is now
>>> used by many more build types than just plain Java builds so maybe we
>>> need to consider that the convention is no longer to assume jar
>>> dependencies.
>>>
>>> I would rather require a little more configuration to ensure that builds
>>> are more deterministic.
>>> If we want to shrink the size of the POM then the new POM format is a
>>> better solution.
>>>
>>> William
>>>
>>>
>>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach wrote:
>>>
>>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
>>> troubles declaring an aar dependency. Here is the pom.xml declaration:
>>>
>>> |
>>> <dependency>
>>> <groupId>com.android.support</groupId>
>>> <artifactId>support-v13</artifactId>
>>> <version>21.0.2</version>
>>> <type>aar</type>
>>> </dependency>
>>> |
>>>
>>> Just about any Maven command, even "mvn dependency:tree" yields:
>>>
>>> [ERROR] Failed to execute goal on project wallet: Could not resolve
>>> dependencies for project de.schildbach.wallet:wallet:apk:4.13-test:
>>> Failure to find com.android.support:support-v4:jar:21.0.2 in
>>> file:///home/aschildbach/dev/android-sdk/extras/android/m2repository
>>> was cached in the local repository, resolution will not be
>>> reattempted until the update interval of android-support has elapsed
>>> or updates are forced -> [Help 1]
>>>
>>> Where does that .jar type in the error message stem from? I declared
>>> aar.
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: problem with AAR dependency
Posted by William Ferguson <wi...@xandar.com.au>.
Sorry Igor, I see now I omitted a chunk of context.
The reason for the error is that this component :
<dependency>
<groupId>com.android.support</groupId>
<artifactId>support-v13</artifactId>
<version>21.0.2</version>
<type>aar</type>
</dependency>
has a dependency upon
<dependency>
<groupId>com.android.support</groupId>
<artifactId>support-v4</artifactId>
<version>21.0.2</version>
<type>aar</type>
</dependency>
But when the Android team packaged up support-v13, they declared the
dependency on support-v4 as:
<dependency>
<groupId>com.android.support</groupId>
<artifactId>support-v4</artifactId>
<version>21.0.2</version>
</dependency>
which is a valid definition syntactically, may well be valid inside the
Android dev team, and is parsed by the Android Gradle plugin (which makes
gross assumptions about artifact type).
But from a standard Maven perspective, that dependency definition is not
valid. Which is why tools like the dependency-plugin (and anything that
introspects deps) with fail with that dependency definition.
We are pushing back on the Android guys to generate Maven POMs that are
consumable by everyone, but the fact that the syntax allows them to
generate an underspecified dependency could be eliminated. I think this is
especially important as Maven is used by a wider and wider community. While
it stemmed from Java builds, it is now used much more widely than pure Java
libraries.
William
ᐧ
On Tue, Dec 9, 2014 at 2:39 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
> I am not sure I follow. Can you explain what actually happens and how
> forcing <type> element for all projects dependencies is expected to help
> the problem?
>
> --
> Regards,
> Igor
>
>
> On 2014-12-07, 19:25, William Ferguson wrote:
>
>> ## Cross posting to Maven Dev list
>>
>> One solution to this would be to change the POM specification to require
>> the type element for dependencies.
>> That would allow Maven and MavenCentral to immediately fail POMs based
>> upon dependencies that are missing the type element.
>>
>> Yes, it goes against convention over configuration, but Maven is now
>> used by many more build types than just plain Java builds so maybe we
>> need to consider that the convention is no longer to assume jar
>> dependencies.
>>
>> I would rather require a little more configuration to ensure that builds
>> are more deterministic.
>> If we want to shrink the size of the POM then the new POM format is a
>> better solution.
>>
>> William
>>
>>
>> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach wrote:
>>
>> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
>> troubles declaring an aar dependency. Here is the pom.xml declaration:
>>
>> |
>> <dependency>
>> <groupId>com.android.support</groupId>
>> <artifactId>support-v13</artifactId>
>> <version>21.0.2</version>
>> <type>aar</type>
>> </dependency>
>> |
>>
>> Just about any Maven command, even "mvn dependency:tree" yields:
>>
>> [ERROR] Failed to execute goal on project wallet: Could not resolve
>> dependencies for project de.schildbach.wallet:wallet:apk:4.13-test:
>> Failure to find com.android.support:support-v4:jar:21.0.2 in
>> file:///home/aschildbach/dev/android-sdk/extras/android/m2repository
>> was cached in the local repository, resolution will not be
>> reattempted until the update interval of android-support has elapsed
>> or updates are forced -> [Help 1]
>>
>> Where does that .jar type in the error message stem from? I declared
>> aar.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: problem with AAR dependency
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
I am not sure I follow. Can you explain what actually happens and how
forcing <type> element for all projects dependencies is expected to help
the problem?
--
Regards,
Igor
On 2014-12-07, 19:25, William Ferguson wrote:
> ## Cross posting to Maven Dev list
>
> One solution to this would be to change the POM specification to require
> the type element for dependencies.
> That would allow Maven and MavenCentral to immediately fail POMs based
> upon dependencies that are missing the type element.
>
> Yes, it goes against convention over configuration, but Maven is now
> used by many more build types than just plain Java builds so maybe we
> need to consider that the convention is no longer to assume jar
> dependencies.
>
> I would rather require a little more configuration to ensure that builds
> are more deterministic.
> If we want to shrink the size of the POM then the new POM format is a
> better solution.
>
> William
>
>
> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach wrote:
>
> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got
> troubles declaring an aar dependency. Here is the pom.xml declaration:
>
> |
> <dependency>
> <groupId>com.android.support</groupId>
> <artifactId>support-v13</artifactId>
> <version>21.0.2</version>
> <type>aar</type>
> </dependency>
> |
>
> Just about any Maven command, even "mvn dependency:tree" yields:
>
> [ERROR] Failed to execute goal on project wallet: Could not resolve
> dependencies for project de.schildbach.wallet:wallet:apk:4.13-test:
> Failure to find com.android.support:support-v4:jar:21.0.2 in
> file:///home/aschildbach/dev/android-sdk/extras/android/m2repository
> was cached in the local repository, resolution will not be
> reattempted until the update interval of android-support has elapsed
> or updates are forced -> [Help 1]
>
> Where does that .jar type in the error message stem from? I declared
> aar.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: problem with AAR dependency
Posted by Manfred Moser <ma...@mosabuam.com>.
Wrong .. the Android Maven Plugin is fully capable of creating aar files as well as consuming them as a dependency (or transitive dependency). Problem is that the pom created by Gradle does not specify the dependencies correctly.
Manfred
Robert Patrick wrote on 08.12.2014 08:40:
> The problem is almost certainly because the code below specifies a packaging
> type of “aar” without the requisite work to teach Maven about that
> packaging type (see
> http://books.sonatype.com/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html)?
>
>
>
>
> I see no reason to eliminate the assumption that any dependency without a known
> packaging type specified is a jar.
>
>
>
>
>
> --
>
> Robert Patrick <HYPERLINK
> "mailto:robert.patrick@oracle.com"robert.patrick@oracle.com>
>
> VP, FMW Platform Engineering, Oracle Corporation
>
> 7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872
>
> Frisco, TX 75034, USA Mobile:
> +1.469.556.9450
>
>
>
> HYPERLINK
> "http://www.amazon.com/Professional-Oracle-WebLogic-Server-Patrick/dp/0470484306/"Professional
> Oracle WebLogic Server
>
> by Robert Patrick, Gregory Nyberg, and Philip Aston
>
> with Josh Bregman and Paul Done
>
> Book Home Page: HYPERLINK
> "http://www.wrox.com/WileyCDA/WroxTitle/Professional-Oracle-WebLogic-Server.productCd-0470484306.html"http://www.wrox.com/
>
> Kindle Version: HYPERLINK
> "http://www.amazon.com/Professional-Oracle-WebLogic-Server-ebook/dp/B004HD69J2/"http://www.amazon.com/
>
>
>
>
>
> From: William Ferguson [mailto:william.ferguson@xandar.com.au]
> Sent: Sunday, December 07, 2014 6:25 PM
> To: maven-android-developers@googlegroups.com
> Cc: Maven Developers List
> Subject: Re: problem with AAR dependency
>
>
>
> ## Cross posting to Maven Dev list
>
>
>
> One solution to this would be to change the POM specification to require the
> type element for dependencies.
>
> That would allow Maven and MavenCentral to immediately fail POMs based upon
> dependencies that are missing the type element.
>
>
>
> Yes, it goes against convention over configuration, but Maven is now used by
> many more build types than just plain Java builds so maybe we need to consider
> that the convention is no longer to assume jar dependencies.
>
>
>
> I would rather require a little more configuration to ensure that builds are
> more deterministic.
>
> If we want to shrink the size of the POM then the new POM format is a better
> solution.
>
>
>
> William
>
>
>
> On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach wrote:
>
> I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got troubles
> declaring an aar dependency. Here is the pom.xml declaration:
>
> <dependency>
> <groupId>com.android.support</groupId>
> <artifactId>support-v13</artifactId>
> <version>21.0.2</version>
> <type>aar</type>
> </dependency>
>
>
> Just about any Maven command, even "mvn dependency:tree" yields:
>
> [ERROR] Failed to execute goal on project wallet: Could not resolve
> dependencies for project de.schildbach.wallet:wallet:apk:4.13-test: Failure to
> find com.android.support:support-v4:jar:21.0.2 in HYPERLINK
> "file:///\\home\aschildbach\dev\android-sdk\extras\android\m2repository"file:///home/aschildbach/dev/android-sdk/extras/android/m2repository
> was cached in the local repository, resolution will not be reattempted until
> the update interval of android-support has elapsed or updates are forced ->
> [Help 1]
>
> Where does that .jar type in the error message stem from? I declared aar.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: problem with AAR dependency
Posted by Robert Patrick <ro...@oracle.com>.
The problem is almost certainly because the code below specifies a packaging type of “aar” without the requisite work to teach Maven about that packaging type (see http://books.sonatype.com/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html)?
I see no reason to eliminate the assumption that any dependency without a known packaging type specified is a jar.
--
Robert Patrick <HYPERLINK "mailto:robert.patrick@oracle.com"robert.patrick@oracle.com>
VP, FMW Platform Engineering, Oracle Corporation
7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872
Frisco, TX 75034, USA Mobile: +1.469.556.9450
HYPERLINK "http://www.amazon.com/Professional-Oracle-WebLogic-Server-Patrick/dp/0470484306/"Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: HYPERLINK "http://www.wrox.com/WileyCDA/WroxTitle/Professional-Oracle-WebLogic-Server.productCd-0470484306.html"http://www.wrox.com/
Kindle Version: HYPERLINK "http://www.amazon.com/Professional-Oracle-WebLogic-Server-ebook/dp/B004HD69J2/"http://www.amazon.com/
From: William Ferguson [mailto:william.ferguson@xandar.com.au]
Sent: Sunday, December 07, 2014 6:25 PM
To: maven-android-developers@googlegroups.com
Cc: Maven Developers List
Subject: Re: problem with AAR dependency
## Cross posting to Maven Dev list
One solution to this would be to change the POM specification to require the type element for dependencies.
That would allow Maven and MavenCentral to immediately fail POMs based upon dependencies that are missing the type element.
Yes, it goes against convention over configuration, but Maven is now used by many more build types than just plain Java builds so maybe we need to consider that the convention is no longer to assume jar dependencies.
I would rather require a little more configuration to ensure that builds are more deterministic.
If we want to shrink the size of the POM then the new POM format is a better solution.
William
On Thursday, December 4, 2014 1:47:33 AM UTC+10, Andreas Schildbach wrote:
I'm using maven-android-plugin 4.0.0 with Maven 3.0.5. I've got troubles declaring an aar dependency. Here is the pom.xml declaration:
<dependency>
<groupId>com.android.support</groupId>
<artifactId>support-v13</artifactId>
<version>21.0.2</version>
<type>aar</type>
</dependency>
Just about any Maven command, even "mvn dependency:tree" yields:
[ERROR] Failed to execute goal on project wallet: Could not resolve dependencies for project de.schildbach.wallet:wallet:apk:4.13-test: Failure to find com.android.support:support-v4:jar:21.0.2 in HYPERLINK "file:///\\home\aschildbach\dev\android-sdk\extras\android\m2repository"file:///home/aschildbach/dev/android-sdk/extras/android/m2repository was cached in the local repository, resolution will not be reattempted until the update interval of android-support has elapsed or updates are forced -> [Help 1]
Where does that .jar type in the error message stem from? I declared aar.