2012/2/29 Joerg <voydm...@gmail.com>:
Just a quick explanation. My name is Manfred Moser and I am one of the
core committers of the Android Maven Plugin.
Yes.. we did introduce the apklib format to enable reuse long before
the Android SDK and ADT came up with library projects. It is a
natural extension of the good support for using projects that have
external dependencies in Maven while trying to work around the
limitations of the Android build toolchain.
The current version of library projects is flawed and will be revamped
as part of .. well originally r16 of the SDK, then r17 and now that is
also not happening to work with plain jar artifacts.
apklib files are pretty much plain jars but the extension is used by
the build to recognize that the build has to work differently with
them (exploding them into target..).
Ideally the SDK would support apklib but we do not have the resources
to patch to provide patches for that. Hopefully the upcoming jar
library format will be compatible...
To get this all to work in Eclipse you might have to help Ricardo with
the m2e-android tool and potentially supply patches to ADT since it is
not very configurable (e.g. it can not work with different paths for
e.g. the AndroidManifest file and other limitations).
I am not very versed in the Eclipse integration myself since I don't
use it.. myself and many other developers using the Android Maven
plugin use in IntelliJ IDEA since Jetbrains has been very responsive
to change requests exposing configuration options for their Android
integration.
In all cases... the open source motto applies. You want it fixed...
supply a patch!!!
manfred
2012/2/29 Joerg <voydm...@gmail.com>:
I was talking about the first version being flawed.. the current
version is just too limited for many users from what I know. The
revamp I thought is coming is to support plain jar files with the
resources in it. But I might of course be wrong since I dont work on
the SDK ;-)
> As for making our binary based distribution files compatible with apklib,
> well that remain to be seen since I haven't designed the former, nor looked
> at the latter (yet) ;)
That would be great though ;-)
In either case .. imho the SDK team is doing a GREAT job and we should
all be thankful for the work they do... and the openness provided so
people can help if they want to.
manfred
manfred
Also what about just doing the simple things first and releasing it
and then going more complex with things like manifest merges and stuff
like you suggest. A lot of this could probably driven by the user
community.. at least in terms of needs. And e.g. the compatibility
library and others distributed by google would be good candidates for
introduction..
manfred
I think it would be good to have a unique extension since artifacts
could be identified easily and e.g. could be deployed to the Central
Repository (like is already the case with lots of Android stuff) but
they could be easily identified as Android artifacts..
I could work with Sonatype to get it to work nicely with the new
extension e.g. for searches and so on.
Any artifact that is in central can then be easily used from other
tools. E.g. like the lint tool I deployed to central and Christopher
picked up for the Jenkins integration. That sort of sharing could
become really easy.
And also keep in mind that once artifacts are in central any build
tool can pick them up since they all understand the format and can
work it be they Apache Ivy with Ant, Gradle, Gant, SBT, and so on and
so on..
It work be great for all of them. And if you wanted to you could just
use e.g. the aether-ant-tasks to integrated Maven dependency
resolution within the Ant build you are already using.
I realize that Maven is not for everyone... but open source
cooperation and sharing is... at least for anyone that wants to be
part of the Android ecosystem imho ;-)
manfred
Apache Ivy http://ant.apache.org/ivy/
is a separate dependency manager with a bunch of issues..
Maven Ant Task http://maven.apache.org/ant-tasks/index.html
basically allows you to use the maven dependency mgt resolution
mechanism and more in ant tasks
Aether Ant Tasks https://docs.sonatype.org/display/AETHER/Aether+Ant+Tasks
is the newer version of the Maven Ant Task that uses the new
dependency resolution framework used in Maven but available for other
tools to integrate with - Eclipse Aether...
http://www.eclipse.org/aether/
I would suggest to use Aether Ant tasks or Eclipse Aether directly...
and if you need anything there changed I can help push for it.. even
other build systems like Gradle and SBT that are using Ivy internally
are pushing towards Aether due to problems with ivy.
manfred
And I thought that now, when R. class use final field is possible to
generate all IDs and compile XML separately for every project library
or no?
Maven should by only alternative. We still can support ANT as main
build tool but when will be exist some basic coordination with maven
team, Android world will be much better.
--
Ing. Tomáš Procházka
2012/3/1 Xavier Ducrohet <x...@android.com>:
-- Tor
http://rgladwell.github.com/m2e-android/
manfred
Ricardo will need to let you know..
manfred
Hey Ricardo,
Hey Ricardo,can you give us more granularity in what you need in those classes? Some of them are a bit big (AdtPlugin and Sdk for instance)
As for supporting archived version of Library Projects, yes this is on our list. Hopefully within the r18/19 timeframe.
Once libraries can declare themselves as not having code (only jar files), then adding them to Eclipse is really not needed.
This will probably be the first step. Then we'll move to supporting archived versions.
2012/3/25 Tomáš ProcházkaAnd how complicated is allow set library project as dependency without requirement to import it and open in Eclipse?