Support for library projects

[GoogleCodeExporter]

I'm unable to get maven-android-plugin to work with library projects: 
http://developer.android.com/guide/developing/eclipse-adt.html#libraryProject

Does maven-android-plugin need specific support do get it working?

Original issue reported on code.google.com by henrik.a...@gmail.com on 21 Oct 2010 at 11:27

[GoogleCodeExporter]

Hi Henrik!

Yes, if I recall correctly, we need to implement something for this.

Albin: we talked about this some time ago. Do you remember what the conclusion 
was?

Original comment by hugo.josefson.old@gmail.com on 21 Oct 2010 at 2:32

• Added labels: Type-Enhancement, Component-EclipseIntegration
• Removed labels: Type-Defect

[GoogleCodeExporter]

I tried using build-helper-maven-plugin, but I couldn't get it to work...

Original comment by henrik.a...@gmail.com on 1 Nov 2010 at 1:00

[GoogleCodeExporter]

Recently discussed:
http://groups.google.com/group/maven-android-developers/browse_thread/thread/ff7
00b5128692836

No, there is not direct support for this at the moment, simply because it 
didn't exist when we implemented the apksources packaging type:
http://code.google.com/p/maven-android-plugin/wiki/ApkSourcesDependency

You might be able to use your library project as an apksources project, but 
YMMV.

We definitively want this though.

Original comment by hugo.josefson.old@gmail.com on 3 Nov 2010 at 8:02

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by mosa...@gmail.com on 4 Nov 2010 at 3:31

• Added labels: Compatibility
• Removed labels: Component-EclipseIntegration

[GoogleCodeExporter]

It would be great if you could add this functionality as it's crucial for using 
Maven. Thank you in advance!

Original comment by cpph...@gmail.com on 16 Nov 2010 at 7:33

[GoogleCodeExporter]

@cpphool It would be great if you could get this started. The codebase is not 
that complex and can easily be cloned on github. Hugo can pull it all in when 
you are done and we can review your code and give feedback.

Original comment by mosa...@gmail.com on 16 Nov 2010 at 8:05

[GoogleCodeExporter]

In an attempt to get LVL working as a library along with avoiding to run ant to 
obfuscate my code, I tried to use Maven (which I love dearly) but I ran into a 
problem during the compile phase:

11/18/10 7:07:20 AM EST: [ERROR] 
\javadevelopment\...\target\generated-sources\extracted-dependencies\src\main\ja
va\com\...\SomeClassFromLibraryProject.java:[90,17] package R does not exist

I installed the library project as instructed and referenced the dependency as 
an apksources type. The generated sources directory looks like it has 
everything from the library projects and the main project. The R.java class 
looks to have everything as well.

Any help on why I'm getting the compile time error would be much appreciated.

Thanks

Original comment by nmaior...@gmail.com on 18 Nov 2010 at 12:15

[GoogleCodeExporter]

I am getting the same Maven compilation failure as "nmaiorana".   It appears 
that the source from the common dependency project (apksources) is not getting 
included correctly into the main project.  

I would also like some clarification on how to properly setup a common library 
project and consume it from another project using Maven.

Thanks in advance...

Original comment by joshpavl...@gmail.com on 19 Nov 2010 at 5:00

[GoogleCodeExporter]

As has been said here before. The plugin DOES NOT support Android library 
projects. If you want that feature... implement it.

Original comment by mosa...@gmail.com on 19 Nov 2010 at 5:35

[GoogleCodeExporter]

Maybe I missed something here. On this link 
http://code.google.com/p/maven-android-plugin/wiki/ApkSourcesDependency it 
talks about making common projects and using Maven dependency management to 
pull them into your end projects. So I thought the functionality was already 
there. But you are saying it does not support them. What did I miss?

Does the plug-in need fixed or does the feature need to be added?

Original comment by nmaior...@gmail.com on 19 Nov 2010 at 11:17

[GoogleCodeExporter]

The plugin supports using Maven Android Projects using apk packaging reuse via 
the apksources depdendency. It does NOT support Android SDK based library 
projects. There are two different things!

Original comment by mosa...@gmail.com on 20 Nov 2010 at 12:26

[GoogleCodeExporter]

Sorry to ask such silly questions, but can you explain the difference between 
reuse and library projects? When you use a library project in another projects 
it just links to the source and resource directories for that library project. 
It sounds like thats what the apksources dependency does. What is the 
difference I am missing?

Again, sorry for being so dense.

Original comment by nmaior...@gmail.com on 20 Nov 2010 at 1:10

[GoogleCodeExporter]

I did a bit of manual testing. It looks like library project will work if a 
couple of things happen: 

1 - Generate a R.java for every dependency package
2 - Generate the resources in a way that allows the depending project to take 
precedence over dependency resources with the same name

R.java solution:
I manually added the R.java packages to the generated-sources/r directory by 
copying the generated R.java into packages corresponding to my dependencies. 
The build completed and everything looked good.

As for the resources, I did find that the project's resources clobbered the 
dependency resources just like described. I may look into using the res-overlay 
concept to see how this works. But the eclipse sdk appears to resolve this by 
allowing the building project to take precedence over it's library projects 
(which is pretty cool when you want to extend an application and just need to 
change a couple of resources.)  I'm using this to create a lite version of my 
application to change things like application_name and some window titles. In 
my lite project I only need to reference the strings I'm changing.

I pulled down the plug-in project from GitHUB and will look into extending it. 
I will admit that I have never done a plug-in, but I'll give it a shot. I will 
most likely try to generate the R.java for each dependency first. Any pointers 
at which classes I should be looking at? Would it make sense to have a new 
dependency type of apklibrary to treat dependencies differently?

Original comment by nmaior...@gmail.com on 20 Nov 2010 at 2:53

[GoogleCodeExporter]

Hi nmaiorana!

Thank you for your detailed input. This was valuable.

I'm glad to hear that you also want to give extending the plugin a try.

For finding where to start, you should probably look at the comopnents.xml, 
where the lifecycle of <packaging>apk</packaging> is defined. I managed to put 
both the lifecycle for normal apk's and for instrumentation test apk's in the 
same lifecycle, and simply made the actual goals for instrumentation testingm, 
such that they skip themselves if they see that the project does not look like 
a test project.

Having identified the different goals in the components.xml lifecycle 
definition, you should be able to find their respective classes in the packages 
named with the numerical order of the goals.

I think it will make sense to make the library project a different project 
type, such as apklibrary or if there is a generally used file extension of 
abbreviation for it, then you could use that. Not very important at this time, 
since we can change it before releasing the plugin with this feature. Look at 
how I made the apksources project type (start in components.xml I think, or 
search all files for the word apksources.) You should be able to pick up some 
hints that way.

The apklibrary lifecycle can then be quite simple, much like the apksources 
lifecycle, because it's the actual sources which are saved from the library 
project and not any compiled stuff(?)

One reason for making it a different project type than apk, is so that project 
dependencies declared in an apk project can be identified as 
<type>apklibrary</type>, just like we identify apksources dependencies, and 
treat them in a special way. I think that's done in some generate-sources 
goal... You should be able to check all dependencies the same way and handle 
the <type>apklibrary</type> ones in the way they need to be handled in order to 
compile with the project in a good way.

Remember! Everything must happen in the target directory ( 
${project.build.directory} ). The plugin must change nothing in the src 
directory. That's one of the contracts of how Maven projects are handled. Rule 
of thumb: A user should only have to tell their source code revision tool 
(git/svn) to ignore "target", and then whatever they build should not make any 
change to anything the source code revision tool sees.

Good luck, and do ask if you get stuck!

/Hugo

Original comment by hugo.josefson.old@gmail.com on 20 Nov 2010 at 6:43

[GoogleCodeExporter]

Thanks for your input. I did get something working by using the artifact 
groupId to generate an R for each library, however I'm not thinking this is a 
good long term solution.

What if instead of unpacking each library into one common directory, if we 
unpacked them into their own directories like they do it in Eclipse.  That way 
we can include the Android Manifest for each artifact.

Thoughts?

-Nick

Original comment by nmaior...@gmail.com on 20 Nov 2010 at 8:00

[GoogleCodeExporter]

Yes, if they need to be handled separately, then they should be unpacked into 
separate directories. Dependencies of type apklibrary should not be mixed with 
those of type apksources.

If the package id from each of their AndroidManifest.xml is needed as parameter 
for something, then you can find code for that somewhere in (I think) the 
AbstractAndroidMojo class.

If it's something other than the package id, then it should be read or deduced 
from whatever file it is specified in.

It sounds to me like what is needed is that after having extracted each 
apklibrary into its own directory, each of those should be processed with the 
same code as in android:generate-sources? (to create the R.java and any aidl 
related java files)

Original comment by hugo.josefson.old@gmail.com on 20 Nov 2010 at 10:33

[GoogleCodeExporter]

Update:  Got it working without adding additional type. Still using the groupId 
to determine the package name for the R file. Interestingly, I only had to mod 
2 methods (slightly) and add one other method.

Side Note: I made a change to a AndroidSdkTest.java and AndroidSdk.java. I 
added something to use the native file delimiter so they did not get mixed.

So, to proceed with the use of apklibrary types I was thinking of this:

- Replicate what they do in the Eclipse plug-in as much as possible
- Extract each source in it's own directory and add it to the resource/compiled 
resource list
- Will probably need to modify the build/install to include the android 
manifest or APK File. This is probably the most definitive way to determine the 
package name for the R
- Try to determine how the Eclipse plug-in handles resource overlays. Somehow 
they managed to provide resources with the same name giving precedence to the 
application being built. Using the res-overlay directory actually broke this 
and none of my overlay resources make it into the apk when I build with Eclipse.

Let me know if you want me to commit what I've done so far. I'm also new to 
GetHub so I'm not even sure if I pulled it down properly.

-Nick

Original comment by nmaior...@gmail.com on 20 Nov 2010 at 10:54

[GoogleCodeExporter]

Good news! I have the apklibrary type working. I also have figured out how to 
use the compiler to automatically overlay based on precedence. This will give 
us the same capability as apksources, only in a "library" style format without 
the need of an res-overlay directory. 

I have actually gone 3 deep in dependencies and it worked!

Overview
Full Application 
  -----> Application Common Library
         -----> LVL Library
         -----> Facebook Library

Lite Application
  -----> Application Common Library
         -----> LVL Library
         -----> Facebook Library

The lite application overlays app_name, arrays, and icons by just specifying 
those resources in the res directory.

I honestly think we don't need to use the combined-sources directory since the 
compiler allowed me to specify all the resource locations in order of 
precedence.
In fact, I did not even populate it with apklibrary artifacts, just the main 
project's. However this is redundant since I also included the main project's 
res directory.

Any way, let me know what you think. It's been a long day.

-Nick

Original comment by nmaior...@gmail.com on 21 Nov 2010 at 4:56

[GoogleCodeExporter]

I'm ready to give you these updates.  What I have done:
I believe I kept your existing logic undisturbed if the package type is apklib 
or it has a dependency to an apklib artifact.

Created apklib component:
 - <package>apklib</package>
 - Creates target/generated-sources/r (is empty unless dependent on another apklib)
 - Artifacts: artifact-version.ap_, artifact-version.apklib, artifact-version.jar
 - Installed: artifact-version.apklib, artifact-version.jar

Referencing an apklib dependency:
 - Dependency <type>apklib</type>
 - Creates target/generated-sources/extracted-dependencies/dependent/{assets, META-INF, res, src}
 - Creates target/generated-sources/r/{package for main projects and every apklib dependency
 - Artifacts: artifact-version.ap_, artifact-version.apk, artifact-version.jar

Using apklib works pretty much the way referencing libs in Eclipse works. You 
order them in the precedence of which resources with like names gets used. The 
project having the highest precedence. 

I have noticed that maven works much better with Eclipse Android applications 
if you don't let it manage the dependencies in Eclipse. The Eclipse Android ADK 
needs the /gen directory which is equivalent to the generates-sources/r 
directory.

-Nick

Original comment by nmaior...@gmail.com on 21 Nov 2010 at 6:22

[GoogleCodeExporter]

Hi Nick,

This sounds very interesting! I look forward to seeing the code :) Please go 
ahead and push the changes you have made, into your fork of the 
maven-android-plugin on github (if you have set that up).

You say you are new to github, so you will probably want to start looking at 
their help website:

http://help.github.com/

Did you make a fork on github from the jayway/maven-android-plugin repo yet? If 
so, and if you cloned your fork on github to your local disk, you are on the 
easiest path. If not, it's possible to set up a separate "remote" in your local 
git repo to your fork, or change the url of "origin". If you don't know what 
that last sentence meant, simply go ahead and fork the project on github, clone 
your fork to a new directory on your local disk, then move the modified files 
over to the new directory.

Now simply commit there and push. That way your changes will end up on your 
fork of the project on github, and I can see them there. (Don't worry about 
messing up the jayway/maven-android-plugin repo; you only have push permissions 
to your fork.)

Thanks,
Hugo

Original comment by hugo.josefson.old@gmail.com on 21 Nov 2010 at 11:37

[GoogleCodeExporter]

It's out there. Let me know if you have questions.

Hopefully you can create apklib artifacts and use them in your apk projects!

Original comment by nmaior...@gmail.com on 22 Nov 2010 at 4:40

[GoogleCodeExporter]

Excuse me guys,
i need to use lib project in my application.
I've read Nick has solved this issue (maybe), is this fix included in 
maven-android-plugin 2.6.0 version?

How i can use it?
thanks.

Original comment by a.grumiro on 26 Nov 2010 at 9:38

[GoogleCodeExporter]

Actually i've follow error

pom.xml) has 1 error
[ERROR]     Unknown packaging: apklib @ line 7, column 13

Original comment by a.grumiro on 26 Nov 2010 at 9:41

[GoogleCodeExporter]

I've download 2.6.1-SNAPSHOT builded and installed.

In my library project i've setted packaging = apklib, but it gives

[ERROR]     Unknown packaging: apklib @ line 7, column 13

Any suggests?
thanks

Original comment by a.grumiro on 26 Nov 2010 at 10:22

[GoogleCodeExporter]

Ok i've downloaded code from nmaiorana git fork. And now issue on project 
library with <packaging>apklib</packaging> is follow

[INFO] --- maven-android-plugin:2.6.1-SNAPSHOT:dex (default-dex) @ testlib ---
[INFO] /Users/mymac/opt/android-sdk-mac_x86/platforms/android-8/tools/dx 
[--dex, --output=/Users/mymac/Progetti/TestLib/target/classes.dex, 
/Users/mymac/Progetti/TestLib/target/android-classes]
[INFO] 
[INFO] trouble processing "javax/xml/namespace/QName.class":
[INFO] 
[INFO] Attempt to include a core class (java.* or javax.*) in something other
[INFO] than a core library. It is likely that you have attempted to include
[INFO] in an application the core library (or a part thereof) from a desktop
[INFO] virtual machine. This will most assuredly not work. At a minimum, it
[INFO] jeopardizes the compatibility of your app with future versions of the
[INFO] platform. It is also often of questionable legality.
[INFO] 
[INFO] If you really intend to build a core library -- which is only
[INFO] appropriate as part of creating a full virtual machine distribution,
[INFO] as opposed to compiling an application -- then use the
[INFO] "--core-library" option to suppress this error message.
[INFO] 
[INFO] If you go ahead and use "--core-library" but are in fact building an
[INFO] application, then be forewarned that your application will still fail
[INFO] to build or run, at some point. Please be prepared for angry customers
[INFO] who find, for example, that your application ceases to function once
[INFO] they upgrade their operating system. You will be to blame for this
[INFO] problem.
[INFO] 
[INFO] If you are legitimately using some code that happens to be in a core
[INFO] package, then the easiest safe alternative you have is to repackage
[INFO] that code. That is, move the classes in question into your own package
[INFO] namespace. This means that they will never be in conflict with core
[INFO] system classes. If you find that you cannot do this, then that is an
[INFO] indication that the path you are on will ultimately lead to pain,
[INFO] suffering, grief, and lamentation.
[INFO] 
[INFO] 1 error; aborting
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE

Original comment by a.grumiro on 26 Nov 2010 at 11:16

[GoogleCodeExporter]

Did you build and install an apklib project?

Can you send me you pom.xml file?

Original comment by nmaior...@gmail.com on 26 Nov 2010 at 12:17

[GoogleCodeExporter]

I found a link that might help: 
http://stackoverflow.com/questions/839435/android-core-library-error

Does this project compile in Eclipse?

Original comment by nmaior...@gmail.com on 26 Nov 2010 at 1:04

[GoogleCodeExporter]

The "apklib" type and packing worked great for me...  Here are the steps I
used:

   1. Download 2.6.1-SNAPSHOT from nmaiorana git fork
   2. Built and installed 2.6.1-SNAPSHOT.
   3. Changed my library project to use the "apklib" packaging.
   (<packaging>apklib</packaging>)
   4. Changed my the project consuming the library project to use the
   dependency type of "apklib". (<type>apklib</type>)
   5. Built my project and deployed it to the emulator.

Thanks for adding the changes nmaiorana.  The "apklib" works as expected.

Original comment by joshpavl...@gmail.com on 26 Nov 2010 at 1:07

[GoogleCodeExporter]

You are very welcome. Let me know if there are any other changes you need.

Original comment by nmaior...@gmail.com on 26 Nov 2010 at 9:30

[GoogleCodeExporter]

Hello

I am very interested in this. I am working in a project where we use android 
libraries like this. I get a lot of "package R does not exist". How do I get my 
hands on the 2.6.1-SNAPSHOT on the maven-android-plugin?

How do I do step 1 above?

Original comment by henrik.g...@gmail.com on 30 Nov 2010 at 1:07

[GoogleCodeExporter]

Go to github.com and pull down the fork. Install it using maven. Change the 
plugin version in your pom.

Original comment by nmaior...@gmail.com on 30 Nov 2010 at 2:21

[GoogleCodeExporter]

Thanks.
I found the fork and downloaded the code. Unfortunatly I am not able to install 
since the AndroidSdkTest fails since I do not have all the obsolete SDKs 
installed.
Any tips on how to proceed?

Original comment by henrik.g...@gmail.com on 30 Nov 2010 at 3:06

[GoogleCodeExporter]

Skip the tests.

Original comment by nmaior...@gmail.com on 30 Nov 2010 at 4:23

[GoogleCodeExporter]

Hello
It seems to be working now. I did however find one strange issue. When I first 
tried using the 2.6.1-SNAPSHOT I got an error about the package R does not 
exist. It turned out I had missed to change the packaging from apk to apklib. 
Shouldn't the maven-android-plugin work with both?

I also have other issues. I am not able to build the main application. All the 
libraries builds and installs fine.

I then tried the copy approach. I copied all the R files into the 
generated-resource/r catalog. The application builds just fine. But I get run 
time null pointer exceptions. It seems like the IDs in the different R.java 
files mismatch. The application can not find a layout in one of the library 
components. The thing is that all works fine when running in Eclipse not using 
Maven.

Any ideas? Need more info to be able to help just let me know.

Original comment by henrik.g...@gmail.com on 1 Dec 2010 at 11:06

[GoogleCodeExporter]

Did you run an install on your apklib 
projects?

You should not have to copy anything. You should get an R package for each 
apklib and the main application.

Your main application should be an apk type package.

Original comment by nmaior...@gmail.com on 1 Dec 2010 at 4:00

[GoogleCodeExporter]

Does anyone know when the "apklib" functionality will be pulled into the master 
"jayway / maven-android-plugin" git repository?  And then, when it might be 
released?

Original comment by joshpavl...@gmail.com on 8 Dec 2010 at 2:05

[GoogleCodeExporter]

Afaik it was release with 2.8.0

Original comment by mosa...@gmail.com on 8 Dec 2010 at 7:38

[GoogleCodeExporter]

joshpavlovich/mosa:  I think you still need to use nmaiorana's branch.

nmaiorana: Great job so far!  It doesn't seem like aidl's are being built in 
the apk project referencing the apklib project.  Do you have a fix for this?

Original comment by henrik.a...@gmail.com on 9 Dec 2010 at 10:58

[GoogleCodeExporter]

Here's a dirty workaround to make aidl's work.  I just extract the jar from the 
library project into the classes folder.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-antrun-plugin</artifactId>
  <executions>
    <execution>
      <phase>process-resources</phase>
      <goals>
        <goal>run</goal>
      </goals>
      <configuration>
        <tasks>
          <unzip src="${basedir}/../library/target/library.jar" dest="target/classes/" overwrite="true" />
          <copy todir="${basedir}/target/classes/" overwrite="true" >
            <fileset dir="${basedir}/../library/src/">
              <include name="**/*.properties" />
            </fileset>
            <fileset dir="${basedir}/src/">
              <include name="**/*.properties" />
            </fileset>
          </copy>
        </tasks>
      </configuration>
    </execution>
  </executions>
</plugin>

There's another workaround here: I discovered that maven-android-plugin doesn't 
copy properties files from the src folder.  The Eclipse plugin does this.

Original comment by henrik.a...@gmail.com on 9 Dec 2010 at 11:42

[GoogleCodeExporter]

Im a bit confused about the status of this issue. I tried to build and use 
nmaiorana's code (https://github.com/nmaiorana/maven-android-plugin), but it 
seems to miss fix for issue 49. Is there any up-to-date guide on how to set up 
a common-stuff project and a project depending on it 
(http://code.google.com/p/maven-android-plugin/wiki/ApkSourcesDependency is not 
valid anymore I guess...). When it comes to packaging type and dependency type, 
I see different types mentioned; apk, apksources and apklib... Hope to get this 
clarified.

Original comment by croon...@googlemail.com on 9 Dec 2010 at 11:54

[GoogleCodeExporter]

I forked a version from master on Monday. There is a branch 
"issue-96-library-projects", this should have the latest.

I'll have to look into the property and aidl files.

-nick

Original comment by nmaior...@gmail.com on 9 Dec 2010 at 1:06

[GoogleCodeExporter]

nmaiorana: What happened to the apklib type? When changing from version 2.6.1 
to 2.8.3 of your code, I get "Cannot find lifecycle mapping for packaging: 
'apklib'" when running mvn clean install

Original comment by croon...@googlemail.com on 9 Dec 2010 at 2:11

[GoogleCodeExporter]

Croonerg, did you pull from the fork master or branch?

Original comment by nmaior...@gmail.com on 10 Dec 2010 at 12:49

[GoogleCodeExporter]

henrik, I'm looking into the AIDL files. I have not worked with them yet, so if 
you can pass along any conventions that would be great. Like Do you store yours 
in the src folder?

When you say they didn't copy over, are you speaking of the generated java 
files or the actual .aidl files?

Original comment by nmaior...@gmail.com on 10 Dec 2010 at 1:02

[GoogleCodeExporter]

You can find the apklib version of the plug-in here:  
https://github.com/nmaiorana/maven-android-plugin/tree/issue-96-library-projects

Original comment by nmaior...@gmail.com on 10 Dec 2010 at 1:10

[GoogleCodeExporter]

Just a hint about R files, getting the R files from the APKLib project won't 
work because the address contained in the file will change. You should have a 
look into https://github.com/akquinet/android-rindirect/wiki which fix the 
issue by generating the missing R file/files. It has a maven frontend.

Original comment by clement....@gmail.com on 10 Dec 2010 at 8:17

[GoogleCodeExporter]

I tried both the branch and fork with same results.

Original comment by croon...@googlemail.com on 10 Dec 2010 at 8:45

[GoogleCodeExporter]

nmaiorana: I store the aidl files in the src folder.  They are being copied 
over, but they are not compiled into class files.

Original comment by henrik.a...@gmail.com on 10 Dec 2010 at 9:03

[GoogleCodeExporter]

I just checked the branch, and it appears to be in order. 

Some things to look at:

- Check  src/main/resources/META-INF/plexus/components.xml to see of the apklib 
component is there
- Check the version for the plugin in your pom file
- Make sure you installed the branch version

Original comment by nmaior...@gmail.com on 10 Dec 2010 at 11:58

[GoogleCodeExporter]

Ah, problems were caused due to my lack of git skills, but I finally got the 
right code now. But the generated apk does still only contain assets files from 
the lib project, the 'local' ones are discarded...

Original comment by croon...@googlemail.com on 10 Dec 2010 at 12:37