Error Extending Themes

316 views
Skip to first unread message

Joerg

unread,
Feb 28, 2012, 2:33:42 PM2/28/12
to adt-dev
Hi,

I have file an issue for gauges-android:
https://github.com/github/gauges-android/issues/14#issuecomment-4223181

"The Android Eclipse tooling does not seem to support extending themes
from referenced libraries so it marks them as missing which causes the
error markers in the theme.xml file".

Is this a know issue?

Regards,
Joerg

Xavier Ducrohet

unread,
Feb 28, 2012, 2:54:49 PM2/28/12
to adt...@googlegroups.com
Is this a maven problem only, or do you see it when building with Ant or Eclipse?
--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

Joerg

unread,
Feb 29, 2012, 12:51:43 AM2/29/12
to adt-dev
Hi Xavier,

thank you for your quick response! Let me go more into detail.

The build process of the *gauges-android* project is based on Maven
(pom.xml). It also comes with Eclipse projects that you can import.

In order to work on Maven-based projects in eclipse, you need the
"Maven Integration for Eclipse" plugin (m2e) and the "Android
Configurator for M2E". I use Maven 3.0.4, the latest android-maven-
plugin 3.1.1. and Eclipse 3.7.2. For more details on the versions
please refer to the issue link mentioned above.

What the m2e-Plugin does is adding the Maven dependencies defined in
the pom.xml to the eclipse build path. It uses the libs of the local
repository ($HOME/.m2/...). In the case of gauges-android, it also
adds the popular AndroidSherlock-Library as JAR to the build path :
http://r.jakewharton.com/maven/release/com/actionbarsherlock/library/4.0.0-RC1/library-4.0.0-RC1.jar.

Unfortunately, Eclipse complains that the parent theme of
ActionbarSherlock (@style/Theme.Sherlock) cannot be found in the
theme.xml. This makes developing Maven-based projects in Eclipse very
hard since you cannot run the project directly from eclipse.

The Maven command line build works well without errors. The error in
eclipse might have something to do with the Eclipse support for
"ApkLibs" http://code.google.com/p/maven-android-plugin/wiki/ApkLib.
Though, I am not a maven-android expert. I suggest that you clone the
gauges-android project and try to reproduce the error.

Another question : will Maven be officially supported as part of the
SDK in the future as it is ant today?

Thanks in advance,
Joerg

On Feb 28, 8:54 pm, Xavier Ducrohet <x...@android.com> wrote:
> Is this a maven problem only, or do you see it when building with Ant or
> Eclipse?
>
> On Tue, Feb 28, 2012 at 11:33 AM, Joerg <voydmach...@gmail.com> wrote:
> > Hi,
>
> > I have file an issue for gauges-android:
> >https://github.com/github/gauges-android/issues/14#issuecomment-4223181
>
> > "The Android Eclipse tooling does not seem to support extending themes
> > from referenced libraries so it marks them as missing which causes the
> > error markers in the theme.xml file".
>
> > Is this a know issue?
>
> > Regards,
> > Joerg
>
> --
> Xavier Ducrohet
> Android SDK Tech Lead
> Google Inc.http://developer.android.com|http://tools.android.com

Tomáš Procházka

unread,
Feb 29, 2012, 5:12:53 AM2/29/12
to adt...@googlegroups.com
I think that it will be not possible until ADT will have support for ApkLibs.
Author of maven plugin waiting for it.
I personally think that maven is only way to handle jar and apklibrary on the bigger project.

Dne středa, 29. února 2012 6:51:43 UTC+1 Joerg napsal(a):
Dne středa, 29. února 2012 6:51:43 UTC+1 Joerg napsal(a):

Dne středa, 29. února 2012 6:51:43 UTC+1 Joerg napsal(a):

Joerg

unread,
Feb 29, 2012, 5:52:40 AM2/29/12
to adt-dev
So what are the best practices for developing Maven-based Android
projects?

I think it is not feasible to develop an Android project with Eclipse
that has errors and does not compile. I noticed also that the R-Files
do not get generated and hence additional errors appear.

Regards
Joerg


On Feb 29, 11:12 am, Tomáš Procházka <tomas.procha...@gmail.com>
wrote:
> I think that it will be not possible until ADT will have support for
> ApkLibs.
> Author of maven plugin waiting for it.
> I personally think that maven is only way to handle jar and apklibrary on
> the bigger project.
>
> Dne středa, 29. února 2012 6:51:43 UTC+1 Joerg napsal(a):
>
>
>
>
>
>
>
>
>
>
>
> > Hi Xavier,
>
> > thank you for your quick response! Let me go more into detail.
>
> > The build process of the *gauges-android* project is based on Maven
> > (pom.xml). It also comes with Eclipse projects that you can import.
>
> > In order to work on Maven-based projects in eclipse, you need the
> > "Maven Integration for Eclipse" plugin (m2e) and the "Android
> > Configurator for M2E". I use Maven 3.0.4, the latest android-maven-
> > plugin 3.1.1. and Eclipse 3.7.2. For more details on the versions
> > please refer to the issue link mentioned above.
>
> > What the m2e-Plugin does is adding the Maven dependencies defined in
> > the pom.xml to the eclipse build path. It uses the libs of the local
> > repository ($HOME/.m2/...). In the case of gauges-android, it also
> > adds the popular AndroidSherlock-Library as JAR to the build path :
>
> >http://r.jakewharton.com/maven/release/com/actionbarsherlock/library/....
> >http://r.jakewharton.com/maven/release/com/actionbarsherlock/library/....
> >http://r.jakewharton.com/maven/release/com/actionbarsherlock/library/....

Tomáš Procházka

unread,
Feb 29, 2012, 10:34:18 AM2/29/12
to adt...@googlegroups.com
Problem is only dependency on another project with resources.
Only way is manually unzip apklib, put it somewhere and use it as
library project in Eclipse.
If ADT team add support for zipped library project, maven team add
support for setup its location from local repository and world will be
great ;-)

2012/2/29 Joerg <voydm...@gmail.com>:

Joerg

unread,
Feb 29, 2012, 10:58:18 AM2/29/12
to adt-dev
The apklibs are actually unpacked during the mvn-command line build.
The unpacked content can be found in target/unpack/apklibs/
<package_name>_<version>.

Just curious: is the concept of apklibs something that was introduced
by the Maven team?

Another thing that comes to my mind: the way the library projects are
built changed with SDK 14. But appearently, there is no support for
using something like apklibs ("At this time, library projects
containing the jar file directly instead of the source code are not
yet supported. We intend to add this support in r15.",
http://tools.android.com/recent/buildchangesinrevision14). As far as I
understand, there's no support, yet. The consequence is that Maven for
Android is not mature enough - because it is not aligned with the
capabilities of the SDK. Or they other way round :-)

Joerg


On Feb 29, 4:34 pm, Tomáš Procházka <tomas.procha...@atomsoft.cz>
wrote:
> Problem is only dependency on another project with resources.
> Only way is manually unzip apklib, put it somewhere and use it as
> library project in Eclipse.
> If ADT team add support for zipped library project, maven team add
> support for setup its location from local repository and world will be
> great ;-)
>
> 2012/2/29 Joerg <voydmach...@gmail.com>:

Manfred Moser

unread,
Feb 29, 2012, 12:37:30 PM2/29/12
to adt...@googlegroups.com
Hi!

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>:

Xavier Ducrohet

unread,
Feb 29, 2012, 12:46:23 PM2/29/12
to adt...@googlegroups.com
What's flawed about the current library system?

I'll freely admit that It's certainly limited, but I'm not sure how flawed it is (the first version was certainly flawed), and I'm not sure what revamp you are expecting?

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) ;)

Xav

2012/2/29 Manfred Moser <mos...@gmail.com>

Xavier Ducrohet

unread,
Feb 29, 2012, 12:49:49 PM2/29/12
to adt...@googlegroups.com
To answer the original question, ADT does not support maven. They use different build structure and project properties definition.
There might be a way to use ADT and yet replace our current project files (.classpath mainly) with something that works with the Maven build system but I don't know as I haven't tried it. you should ask them.

I'm open to to help people who use Maven use ADT too, but we're not going to actively work on it. We are open to add extension points to ADT to make it work, but the actual integration work has to come from outside my team.

thanks
Xav

Manfred Moser

unread,
Feb 29, 2012, 12:54:05 PM2/29/12
to adt...@googlegroups.com
2012/2/29 Xavier Ducrohet <x...@android.com>:

> What's flawed about the current library system?
>
> I'll freely admit that It's certainly limited, but I'm not sure how flawed
> it is (the first version was certainly flawed), and I'm not sure what revamp
> you are expecting?

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 Moser

unread,
Feb 29, 2012, 12:57:06 PM2/29/12
to adt...@googlegroups.com
And if anybody want to sponsors that work I am sure a solution can be
found. I will let Ricardo know about this discussion. Maybe we can
create issues to detail changes that would help him with the eclipse
integration.

manfred

Xavier Ducrohet

unread,
Feb 29, 2012, 1:25:54 PM2/29/12
to adt...@googlegroups.com
Yes the plain jar stuff will be coming soon hopefully.

One thing I've wanted though was to let devs put more than just code + resources in it.
I could see someone doing a big library (like actionBarSherlock for instance) also include custom lint rules and maybe even custom interactivity code for the layout editor in Eclipse (both of these have APIs to provide extensions, although we haven't tested them yet). We have to think about the internal structure of the jar to allow this.

Manfred Moser

unread,
Feb 29, 2012, 1:31:56 PM2/29/12
to adt...@googlegroups.com
If it does all that would it not warrant to call it some other file
format? Yes it would be a zip file but the content would do all sorts
of things beyond a jar so we would need a way to recognize that
easily.

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

Xavier Ducrohet

unread,
Feb 29, 2012, 1:36:17 PM2/29/12
to adt...@googlegroups.com
Yes we've actually been thinking about having a different extension.

I want to think about all of this upfront because I don't want to introduce something and then later on change it again. Our recent changes and revamp have been hard enough on developers.

If people are interested we could start a design discussion here on adt-dev. We'll be ready to start on this in a week or two.

Tomáš Procházka

unread,
Mar 1, 2012, 1:01:23 AM3/1/12
to adt...@googlegroups.com
I personally think that apklib is good extenstion name, but I think that content should be already compiled, no simple packaged sources and XML, but everything in final binary form. I thing .classes and also xml should be compiled and png optimized. This will allow much faster build if project use many dependencies.

And the maven plugin will be able make also the source package, which can be possible to upload to thr maven repository (like normal maven works) and will be possible use this in the Eclipse (if user choose "download sources") to display more detailed javadoc allow go to the source of java or layout files.

This would be ideal world for the Android.

Bigger project has still much more dependencies and is much more elegant add only a groupId, artifactId and version to pom.xml and everything for everyone, who will build project, will be simply work. I have like the ANT, there is possible do many thing, but dependency management is huge problem. And maven can also make quick new project setup.


Dne středa, 29. února 2012 19:36:17 UTC+1 Xavier Ducrohet napsal(a):

Xavier Ducrohet

unread,
Mar 1, 2012, 1:57:33 PM3/1/12
to adt...@googlegroups.com
don't apklib contain compiled code?

As for the resources, we can't compile the xml as all the IDs haven't been generated yet. PNG can certainly be optimized though.

I agree that we need (much) better dependency support. I'm not sure I want to force Maven on every developer out there though...


2012/2/29 Tomáš Procházka <tomas.p...@gmail.com>

Hugo Josefson

unread,
Mar 1, 2012, 2:27:02 PM3/1/12
to adt...@googlegroups.com
An apklib file is all source, and contains no compiled code.

It's simply a standard Android Library project directory (exactly as the user can create within Eclipse or with ant), zipped up into a zip file, then renamed to .apklib. We consume them with android-maven-plugin, and can also create them from Maven/Android library projects. There is nothing Maven specific about .apklib files, except that they are named .apklib instead of .zip, because .zip was already taken in Maven-land :)

The details are here:

As I wrote on that page, the reason to use this file format, is because it is as close to what Eclipse and ant uses for library projects. They use directories. Maven however, needs each dependency to be *one* file. That's why we had to zip the directory up. The whole thing is about enabling collaboration; if we would have gone with a Maven-specific file layout, it would have only benefited the Maven/Android community, and not the entire Android community. As it is now, an Android developer using Maven can give their .apklib file to a non-Maven developer, and they can simply unzip it and use the directory in Eclipse as an Android Library project.

If ant/ADT starts supporting an Android library project type, which can be represented as a single file, then that could be consumed by android-maven-plugin too. If it's different from apklib, we would have to make some minor changes (which is fine), but if it's the same, it would work out of the box.

Hope this helps.

Thanks,
--
Hugo Josefson, founder of android-maven-plugin

Xavier Ducrohet

unread,
Mar 1, 2012, 2:46:00 PM3/1/12
to adt...@googlegroups.com
If it's really just a zip of the project structure used by Ant/ADT then that's great. We're not going to change this anytime soon.

However, I think that our single-file library distribution file will only be for compiled libraries. It'll be very similar though. Just replace the src/ folder with the actual jar file, keep the res/ libs/ and assets/ folders and maybe add a tools/ folder for custom tools plugins (lint, layout editor).

Xav

Manfred Moser

unread,
Mar 1, 2012, 3:02:52 PM3/1/12
to adt...@googlegroups.com
Sounds good.. apart from libs.. I would not want to have libs in
there.. rather some sort of dependency declaration to whatever the
libs are..

Xavier Ducrohet

unread,
Mar 1, 2012, 3:03:41 PM3/1/12
to adt...@googlegroups.com
libs/ can contain NDK stuff though...

Manfred Moser

unread,
Mar 1, 2012, 3:22:07 PM3/1/12
to adt...@googlegroups.com
Okay.. not sure about that... ideally even that would be separate to
allow reuse.. but realistically it might have to stay

Manfred Moser

unread,
Mar 1, 2012, 5:34:09 PM3/1/12
to adt...@googlegroups.com
Btw... one thing to consider in terms of other extension...

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

Xavier Ducrohet

unread,
Mar 1, 2012, 5:39:23 PM3/1/12
to adt...@googlegroups.com
Manfred,
Being able to use the Maven repo but still have an ant based build sounds very interesting. I'll check it out.

thanks!

Manfred Moser

unread,
Mar 1, 2012, 5:52:38 PM3/1/12
to adt...@googlegroups.com
You can use these options for that

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

Ricardo Gladwell

unread,
Mar 4, 2012, 6:45:10 AM3/4/12
to adt...@googlegroups.com
Hi Xavier

I'm Ricardo, one of the developers working on the Maven-ADT integration project, m2e-android[1].

First of all, it would be nice to have be able to add Android Libraries to ADT Android projects in zipped/archive format as Hugo and Manfred suggest. As I understand it, the ADT needs to have Android Library projects checked out into the local Eclipse workspace. If we could add zipped and unzipped Android Libraries to Android projects (either via changes to project.properties or by adding them to the Eclipse classpath) then m2e-android could support automatically downloading and resolving Android Library dependencies.

We would also appreciate some extension points within the ADT. At the moment, we access the API using internal services and it would be nice to have stable, externalised ADT service calls to build reliably against. At the moment, new releases of the ADT break our build a lot and we get loads of "Discouraged access" OSGI warnings.

For example, m2e-android makes use of the following internal classes:

AdtPlugin
AdtConstants
ProjectHelper
ProjectProperties
ProjectPropertiesWorkingCopy
ProjectState
Sdk

Regards...

-- Ricardo Gladwell

[1] http://rgladwell.github.com/m2e-android

Tomáš Procházka

unread,
Mar 4, 2012, 11:29:38 AM3/4/12
to adt...@googlegroups.com
apklib contain .java files, but I don't know why. I think that .class
would be also possible to use with current ADT.

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>:

Manfred Moser

unread,
Mar 7, 2012, 1:43:51 PM3/7/12
to adt...@googlegroups.com
These enhancements would be great. Xavier/Tor .. should we create bug tracker issue for you to track this better?

One of the things I always find useful on the IntelliJ IDEA integration is to be able to configure the paths for

Manifest file
resources directory
assets directory
native libs directory

as well as where the build result apk will be located and what its name will be (e.g. maven allows you to customize that and e.g. in a release build with proguard processing it could have a different name and be a secondary artifact besides the normal apk).

Do you want to have issues created for this as well maybe? 

manfred

Tomáš Procházka

unread,
Mar 22, 2012, 7:45:18 AM3/22/12
to adt...@googlegroups.com
I thought about it.

compiled library:
  • faster compilation of project that will use this library as dependecies
  • more complicated code completion + display javadoc (this can solve maven, which can download automatically also sources and javadoc

apklib with packed source code:
  • easy way to work auto complete (display javadoc from sources)
  • need to be compiled again and again


Dne čtvrtek, 1. března 2012 20:27:02 UTC+1 Hugo Josefson napsal(a):

Manfred Moser

unread,
Mar 22, 2012, 12:06:25 PM3/22/12
to adt...@googlegroups.com
For the Maven Android Plugin we are currently looking to support the
apklib extension files with either compiled or source files includes
and hope to dynamically do the right thing..

Xavier Ducrohet

unread,
Mar 23, 2012, 2:56:20 PM3/23/12
to adt...@googlegroups.com
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).

I'ld like to be as careful as possible when adding stuff to an official public API.

As for supporting archived version of Library Projects, yes this is on our list. Hopefully within the r18/19 timeframe.

Xavier Ducrohet

unread,
Mar 23, 2012, 2:58:01 PM3/23/12
to adt...@googlegroups.com
What's the reasoning behind wanting to move all those files/folders around?

Configuring the output file name should be doable already (at least in Ant) but we should synchronize this with Eclipse.

Tor Norbye

unread,
Mar 23, 2012, 3:27:07 PM3/23/12
to adt...@googlegroups.com
I'd love to know what you're using in AdtPlugin. In addition to the
expected plugin and logging code in AdtPlugin, it contains a bunch of
I/O related utilities which I'd like to move out of that class, maybe
into AdtUtils.

-- Tor

Manfred Moser

unread,
Mar 23, 2012, 3:32:22 PM3/23/12
to adt...@googlegroups.com
Just in case it might help ... it is all on github including
documentation on using it and more.

http://rgladwell.github.com/m2e-android/

manfred

Xavier Ducrohet

unread,
Mar 23, 2012, 3:44:50 PM3/23/12
to adt...@googlegroups.com
it is recommended that we do *not* go look at random open source projects that are close to what we are doing.

It is best if you can give us a list of your dependencies and we'll move them outside of internal.

thanks.

Manfred Moser

unread,
Mar 23, 2012, 3:55:04 PM3/23/12
to adt...@googlegroups.com
How sad! That would make cooperating so much easier. There is no
license conflict or anything like that..

Ricardo will need to let you know..

manfred

Tomáš Procházka

unread,
Mar 25, 2012, 7:30:14 AM3/25/12
to adt...@googlegroups.com
And how complicated is allow set library project as dependency without requirement to import it and open in Eclipse?

It is more easy than full support for archived version of Library Project?


Dne pátek, 23. března 2012 19:56:20 UTC+1 Xavier Ducrohet napsal(a):
Hey Ricardo,

Ricardo Gladwell

unread,
Mar 25, 2012, 12:37:46 PM3/25/12
to adt...@googlegroups.com
Hey Xavier

Thanks for the feedback.


On Friday, March 23, 2012 6:56:20 PM UTC, Xavier Ducrohet wrote:
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)

Sure, here is a list of the exact calls m2e-android is using with the ADT:

com.android.ide.eclipse.adt.AdtConstants.NATURE_DEFAULT
com.android.ide.eclipse.adt.internal.project.ProjectHelper.fixProject();
com.android.ide.eclipse.adt.internal.sdk.ProjectState
com.android.ide.eclipse.adt.internal.sdk.ProjectState.isLibrary();
com.android.ide.eclipse.adt.internal.sdk.ProjectState.getLibraries()
com.android.ide.eclipse.adt.internal.sdk.ProjectState.LibraryState;
com.android.ide.eclipse.adt.internal.sdk.Sdk.getProjectState();
com.android.io.StreamException;
com.android.sdklib.internal.project.ProjectProperties.getProperties()
com.android.sdklib.internal.project.ProjectProperties.PROPERTY_LIBRARY;
com.android.sdklib.internal.project.ProjectPropertiesWorkingCopy
com.android.sdklib.internal.project.ProjectPropertiesWorkingCopy.PROPERTY_LIB_REF

This is a list of the calls that are used by our integration test suite, so its less important these are made external but they might highlight calls that API consumers might want to call:

com.android.ide.eclipse.adt.internal.sdk.ProjectState.getFullLibraryProjects()

Should I open a ticket for this somewhere?
 
As for supporting archived version of Library Projects, yes this is on our list. Hopefully within the r18/19 timeframe.

Cool, is there a ticket for this I could watch?

Regards...

-- Ricardo Gladwell

Xavier Ducrohet

unread,
Mar 26, 2012, 2:53:23 PM3/26/12
to adt...@googlegroups.com
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ázka <tomas.p...@gmail.com>

Xavier Ducrohet

unread,
Mar 26, 2012, 2:55:20 PM3/26/12
to adt...@googlegroups.com
Could you file a ticket with all of this? thanks.

Tomáš Procházka

unread,
Mar 26, 2012, 2:58:50 PM3/26/12
to adt...@googlegroups.com
Not only jar files, but also XML and other resources, which eclipse need for auto-complete, error checking, etc.

Dne pondělí, 26. března 2012 20:53:23 UTC+2 Xavier Ducrohet napsal(a):
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ázka
And how complicated is allow set library project as dependency without requirement to import it and open in Eclipse?

Xavier Ducrohet

unread,
Mar 26, 2012, 3:00:53 PM3/26/12
to adt...@googlegroups.com
of course. Right now libraries need to be a project so that they get compiled.
Once a library has no Java source code, then nothing needs to be compiled in the library so they don't need to be a project in eclipse.
Its content (jar file, resources) will be pulled into the projects depending on them anyway.

2012/3/26 Tomáš Procházka <tomas.p...@gmail.com>

Ricardo Gladwell

unread,
Mar 27, 2012, 5:57:40 AM3/27/12
to adt...@googlegroups.com
Sure , created here:

http://code.google.com/p/android/issues/detail?id=27811

Please let me know if it is ok.

Tomáš Procházka

unread,
Mar 30, 2012, 11:10:54 AM3/30/12
to adt...@googlegroups.com
And some issue (task) for support packed library project already?


Dne pondělí, 26. března 2012 20:55:20 UTC+2 Xavier Ducrohet napsal(a):
Reply all
Reply to author
Forward
0 new messages