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
