On Jan 20, 2015, at 6:03 PM, William Ferguson <william.fergu...@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.fergu...@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.fergu...@xandar.com.au | w:https://wylas-timing.com >> http://lexathon.com >> ᐧ >> >> On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko <i...@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.fergu...@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 <i...@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 <i...@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-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>>>> --------- >>>>>>>> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
