maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@takari.io>
Subject Re: problem with AAR dependency
Date Thu, 22 Jan 2015 02:13:08 GMT

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 <igor@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


Mime
View raw message