Skip to content

Loading…

ADT 14 incompatability #45

Closed
rgladwell opened this Issue · 108 comments
@rgladwell
Owner

STS 2.8.0.RELEASE (Windows 7 64bit, eclipse 32bit)
ADT 14.0.0

With m2e-android 0.4.0.201110162334 I get:

error buildiing android project (com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-12:generate-sources:default-generate-sources:generate-sources) pom.xml /gemini-client-android line 58 Maven Build Problem

This is working for other platforms, not just wiondeows (see issue #36)

@lgawron

I tried com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-13 today, as the new plugin release is bringing some ADT 14 compatibility - unfortunately no difference - the error is still there.

@tmonney

Same for me:

  • STS 2.8.0
  • ADT 14.0.0
  • m2e-android 0.4.0.201110162334 but on a Mac.

By the way, there is a typo in the error message: "buildiing" with 2 i's

@kefik

Hi, the same for me:

Using: com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-13
Tried: Eclipse 3.6.SR2 / 3.7.SR1
ADT: 14.0.0
m2e-andriod: 0.4.0.201110162334
Maven: 3.0.3
Android SDK: r14
OS: Windows7 64bit (but running 32bit Java as well as Eclipse)

@kefik

The instructions on compiling the plugin from sources including "install m2e v1.0.0" I'm currently running 1.0.1, going to try anyway.

@thoutbeckers

I have the same problem with OSX / recent Indigo J2EE developer install.

Using

Android Configurator for M2E 0.4.0.201110162334 me.gladwell.eclipse.m2e.android.feature.feature.group

<artifactId>android-maven-plugin</artifactId>
<version>3.0.0-alpha-13</version>

I get:
error buildiing android project (com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-13:generate-sources:default-generate-sources:generate-sources)
in the problem view.

Nothing in .log, nothing in the Error Log.

@thoutbeckers

Running a manual Maven build inside Eclipse, it appears to be because my version is Maven is not new enough for android-maven-plugin:3.0.0-alpha-13, so my problem is probalbly not related to m2e-android!

Failed to execute goal com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-13:generate-sources (default-generate-sources) on project android2: The plugin com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-13 requires Maven version [3.0.3
@kefik

Try to install Maven 3.0.3, my problems persisted even after I had installed it.

@7Bit

error buildiing android project (com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-13:generate-sources:default-generate-sources:generate-sources)

Win 7 x64
Eclipse 3.7.1
Maven 3.0.3
android-maven-plugin 3.0.0-alpha-13
m2e - Maven Integration for Eclipse 1.0.100.20110804-1717
Android Configurator for M2E 0.4.0.201110162334

@julakali

Same here, Eclipse Helios on Linux, tried maven 3.0.3 (via "external".. does it work that way?).

error buildiing android project (com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.0.0-alpha-12:generate-sources:default-generate-sources:generate-sources)

@thoutbeckers

You can install a newer internal maven through the m2e marketplace (preferences -> maven -> discovery -> open catalog). However installing maven 3.0.3 from there does not resolve the problem with m2e-android.

It does however let me "launch" a maven build.

@thoutbeckers

I decided to look in the source a bit, I noticed that output is sent to the console:

https://github.com/rgladwell/m2e-android/blob/master/me.gladwell.eclipse.m2e.android/src/main/java/me/gladwell/eclipse/m2e/android/AndroidMavenBuildParticipant.java#L90

The output there is

ANDROID-040-003: Error Log not set: Will not output error logs
ANDROID-040-000: Executed command: Commandline = /bin/sh -c /android/android-sdk-mac/platform-tools/dx --dex --output=/workspace/android2/bin/classes/android2.apk /workspace/android2/target/android-classes /workspace/android2/bin/classes/android2.apk, Result = 1
me.gladwell.android.tools.AndroidToolsException: error executing dx command=[me.gladwell.android.tools.drivers.DexCommand@3a2cf85b]
    at me.gladwell.android.tools.CommandLineAndroidTools.convertClassFiles(CommandLineAndroidTools.java:45)
    at me.gladwell.eclipse.m2e.android.AndroidMavenBuildParticipant.build(AndroidMavenBuildParticipant.java:81)
    at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:180)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: me.gladwell.android.tools.ExecutionException: ANDROID-040-001: Could not execute: Command = /bin/sh -c /android/android-sdk-mac/platform-tools/dx --dex --output=/workspace/android2/bin/classes/android2.apk /workspace/android2/target/android-classes /workspace/android2/bin/classes/android2.apk, Result = 1, Error = UNEXPECTED TOP-LEVEL EXCEPTION:java.util.zip.ZipException: error in opening zip file  at java.util.zip.ZipFile.open(Native Method)    at java.util.zip.ZipFile.<init>(ZipFile.java:127)   at java.util.zip.ZipFile.<init>(ZipFile.java:144)   at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:206)    at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)   at com.android.dx.command.dexer.Main.processOne(Main.java:418)  at com.android.dx.command.dexer.Main.processAllFiles(Main.java:329) at com.android.dx.command.dexer.Main.run(Main.java:206) at com.android.dx.command.dexer.Main.main(Main.java:174)    at com.android.dx.command.Main.main(Main.java:95)1 error; aborting
    at me.gladwell.android.tools.drivers.MavenCommandExecutor.executeCommand(MavenCommandExecutor.java:97)
    at me.gladwell.android.tools.drivers.MavenCommandExecutor.executeCommand(MavenCommandExecutor.java:69)
    at me.gladwell.android.tools.drivers.DexCommand.execute(DexCommand.java:41)
    at me.gladwell.android.tools.CommandLineAndroidTools.convertClassFiles(CommandLineAndroidTools.java:43)
    ... 14 more

It appears the apk file is added to paths dx should look in for classes to process, but the file doesn't exist. If I create an empty zip the build actually works the first time, but the second time dex complains about duplicate files (it appears to try and merge my classes and dex files already in the apk from the last build).

@rgladwell
Owner

@thoutbeckers thanks for the stack trace, that printStackTrace() shouldn't actually be there but it is being helpful. Are you seeing any messages in the Eclipse Error Log view?

@thoutbeckers

No, as mentioned before for some reason this is not propagated there. It's only a "problem" and the pom.xml gets decorated at the plugin tag with the same error message everyone is posting.

Is there any reason the path to the .apk is passed along as argument to dx? (other than of course to --output). Perhaps dx from android sdk r13 dealt with it differently?

@rgladwell
Owner

Looks like this might be related to this change in maven-android-plugin:

simpligility/android-maven-plugin@ee4210e

@rgladwell rgladwell was assigned
@rgladwell
Owner

Looks as though the APK is not being pre-build by the ADT APKBuilder so that the m2e-android code and inject the dependency classes. Call to dx fails because default APK does not exist.

Disregard the last comment.

@rgladwell
Owner

OK, after some research it appears the ADT has modified its build lifecycle: previously the ADT would build the APK whenever the code changed. Now the APK is only built when it is required, for example if you run an Run As... -> Android Application.

Need to see if we can catch the Run event instead of the build event.

@rgladwell
Owner

After further research I think I understand what the problem is: before the ADT only compiles dependencies in the project lib directory into Dalvik dex format for inclusion in the APK.

But now it compiles ANY library in the project classpath.. This includes the the dependencies for the Maven Android dependencies which cause the error message reported in duplicate issue #46.

The solution is as follows:

  1. Remove m2e-android APK Builder from project, it is redundant.
  2. Modify configurer so that it removes all provided scope dependencies from the Eclipse classpath.
  3. Possibly stop playing around with project output paths

This should result in a simpler and more efficient m2e-android plugin.

@thoutbeckers

I set up your project into PDE and have noticed some of the same things, just about an hour later, heh. Also m2e's MavenBuilder catches your CoreException and logs it as DEBUG, which I guess is why it nevers showed in my error log.

APKBuilder seems to insist on using bin and bin/classes with me (even if I change the general output folder), I guess that's what you refer to with point 3. Sadly the android-tools git repository seems to have fallen of the internet.. is the source for r14 ADT even available somewhere at the moment?

@rgladwell
Owner

@thoutbeckers yes, although I've deleted the whole build participant class and the android-tools library so that error message is now redundnat.

Thanks for the tip regarding the bin and bin/classes folder, I thought there was something weird going on there. It looks as though the ADT still uses the configured output directory (e.g. target/) to output class files, but reads from a hard-coded bin directory so a smaller build particpant might be required just to copy the files across and ensure they are in the right place.

The ADT source code should be available at http://android.googlesource.com/ although it looks like you need a password.

@rgladwell
Owner

@thoutbeckers thinking about it that bin issue sounds like an ADT bug.

@thoutbeckers

One of those "feature" bugs perhaps. Google is pretty sweet on using hardcoded paths (like a "sources" directory for linking sources to android.jar).

I also found the link to googlesource, but it appears to be something not for the general public. (maybe they moved away from kernel.org in a hurry after it was hacked).

If you could hook into whatever they do before launch this could still be a nice thing I guess. I'm sure hardcoded paths and such are something they are willing to change if there's a good reason (I'd say "maven" is a pretty good one).

@thoutbeckers

Looks like ADT sources are available from here for now:
http://groups.google.com/group/adt-dev/browse_thread/thread/2c7c7a9ac685bf24# (android-gpl-tools)

@thoutbeckers

Taking a brief look at it, what is does it just a normal build, except is passes a flag which tells the builder it's a launch, so an .apk gets created (PostCompilerBuilder:436)

@thoutbeckers

As an aside, the behaviour of not always making an apk can be toggled in preferences (Android -> Build). And we didn't "get" the pre-launch build because AndroidMavenBuildParticipant did not return true for callOnEmptyDelta.

@joakime

I just cloned https://android.googlesource.com/platform/sdk just fine.
Unfortunately you can't compile without the rest of the android repo

@rgladwell
Owner

Thinking about number 2. above, do we want to remove provided dependencies from the MAVEN classpath container? This would seem confusing to users: they would expect the dependencies they see in the POM editor to appear in the classpath, so it might be confusing if the m2e-android silently removed them

Thoughts?

@nemanjanedic

To me as a user this wouldn't be a problem if there will be no redness in the Project Explorer. It could be confusing, indeed, but with an appropriate message/disclaimer in the documentation (project site) it would be easier.

@kefik

It might be confusing ... is it possible for the m2e-android plugin to report that somewhere in Eclipse (e.g. Maven console)?

@rgladwell
Owner

@kefik i could add a warning marker to the POM to indicate that non-compile dependencies have been excluded.

@kefik

@rgladwell sounds good to me

@rgladwell
Owner

@kefik just might be annoying having a warning marker that you can never get rid of on your project, but maybe better than simply removing dependencies silently.

@kefik

@rgladwell yes, true... what about just issuing "warning" into the Eclipse Error Log?

@rgladwell
Owner

@kefik thanks for the tip but could be more obscure there, also not sure its appropriate: Eclipse Error log is for errors with the Eclipse workspace, error markers are for project-specific warnings.

@kefik

@rgladwell well Maven is issuing various info messages to Maven console, m2e-android may have something similar? Anyway, it might not need to be mentioned in Eclipse at all, it's may be very subtle and if the fix will work, nobody will notice as nemanjanedic is suggesting ... I won't question it as a user :-)

@rgladwell
Owner

@kefit i could just implement it and if people complain, add warnings later. it's the agile way!

@anthonydahanne
Collaborator

hello guys
what about just removing the last argument (apk) in AndroidMavenBuildParticipant line 81 ?
dexService.convertClassFiles(sdk, apk, outputDirectory);
it dexifies ok.

@rgladwell
Owner

@anthonydahanne interesting, does that still add the Maven dependencies to the target APK?

@anthonydahanne
Collaborator
@rgladwell
Owner

@anthonydahanne does that mean you don't have to remove the provided Android Maven dependencies from the Eclipse classpath as well?

Maybe you could prepare a pull request in a new branch for this, please, and I'll try and test it when I get in front of my home dev machine? if it works we could publish a fix ASAP.

Although given the new changes to the way the ADT builds APKs I think we should still get rid of the m2e-android APK building code in the long-term.

@anthonydahanne
Collaborator

oups, I just noticed something : the apk prodced, after applying the patch described above, does not contain the android ness of an apk : xml files & co are not there.. that's why I guess you used the ADT produced apk in the classpath when launching the dex step...

@rgladwell
Owner

@anthonydahanne current m2e-android APK building code could be extended to do so, but that would definitely require work.

@anthonydahanne
Collaborator

what about following the same workflow as in android-maven-plugin, ie do it all in m2e-android instead of using adt produced artifacts ? what would be the impacts ?

@akloeber

I would definitely prefer using the ADT produced artifacts. I switched back from the m2e-android builder to the ADT package builder because of the suggestion and the problems described above (bin folder expected by ADT versus target folder produced by maven build). Furthermore it is much faster and even the "automatic build" feature could be used again (I had turned it of when using m2e-android builder).

The only anoying thing anymore is that I have to remove the android dependency with scope "provided" when developing in Eclipse.

@thoutbeckers

m2e-android could use the same "trick" as ADT.

While editing just compile enough things (with help from ADT or otherwise) to make sure you can work, when launching make a build "as maven would" so that whatever you run on your device/simulator is the same as when you do an external build.

@rgladwell
Owner

@akloeber which version of m2e-android are you referring to? The feedback I got from 0.3.0 is that it was fairly performant.

@rgladwell
Owner

@anthonydahanne I think in the short-term we should simply remove the build stuff and rely on the internal APK Builder. In the long-term, we may need to replicate the build code from the android-maven-plugin to support some of its advanced features.

@rgladwell
Owner

@thoutbeckers the problem is that the way APK builds flies completely in the face of standardised Eclipse build (thanks Google). I'm not confident that we could catch the "Run As" build event all the way down the stack in the m2e extension.

@thoutbeckers

It's just a regular build afaik, I remember seeing the code in ADT that triggers the build. Let me copy paste from my earlier comments:

And we didn't "get" the pre-launch build because AndroidMavenBuildParticipant did not return true for callOnEmptyDelta.

In other words, the delta is empty because nothing changed, and we currently say we're not interested in building then.

And you can see wheter it's a "launch" build or a regular build by looking at a flag:

Taking a brief look at it, what is does it just a normal build, except is passes a flag which tells the builder it's a launch, so an .apk gets created (PostCompilerBuilder:436)

@rgladwell
Owner

@thoutbeckers thanks for the info, can we access that flag in an m2e BuildParticpant though?

@thoutbeckers

It's a normal argument to Eclipse IncrementalProjectBuilder own build method:

http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fresources%2FIncrementalProjectBuilder.html

It's passed in the arguments Map under the key (somewhat confusingly) "RunPostCompiler". I don't know if M2E exposes the arguments passed to build to it's participants, but it probably should.

@rgladwell
Owner

@thoutbeckers This is the interface for a build participant:

https://github.com/eclipse/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/project/configurator/AbstractBuildParticipant.java

Can't see anything to retrieve build arguments, maybe we should raise this as a bug/enhancement request against the m2e project?

@thoutbeckers

Ugh, you're right:

https://github.com/eclipse/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/builder/MavenBuilder.java#L59

Just completely ignores args.

I wonder who thought turning

build(int kind, Map<String,String> args, IProgressMonitor monitor)

into:

build(int kind, IProgressMonitor monitor)

was a good idea.. but it seems like a bug to me.

@rgladwell
Owner

Perhaps the m2e guys build the build participant API before Eclipse added the args argument, and never had a requirement to support it.

I raised a bug for it:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=362295

But given that ADT now compiles all classpath dependencies I'm not sure we need the build participant.

@rgladwell
Owner

Hit a small hitch: it seems as though we might not be able to delete classpath entries in the Maven Classpath Container:

http://dev.eclipse.org/mhonarc/lists/m2e-dev/msg00783.html

@rgladwell rgladwell added a commit that referenced this issue
@rgladwell [issue #45] Remove: Due to changes in the ADT, now all project classpath
libraries are included in target APK (previously only JAR files in project lib/
directory were respected). This makes m2e-android build functionality, tests
and android-tools library redundant so these have been removed.
3b3a701
@thoutbeckers
@rgladwell
Owner

@thoutbeckers I'm sure I could but would rather not have to add a lifecycle mapping unless I have to. Do you have a link to the default implementation.

Also please see branch adt-14-support for current work progress so far.

@rgladwell
Owner

@thoutbeckers thanks :)

@rgladwell rgladwell added a commit that referenced this issue
@rgladwell [task #45] Change: completed work to remove non-runtime dependencies,
such as android Maven jars, that cause build problems with ADT 14+.
f07cbf6
@rgladwell
Owner

OK, I think I've got this working. If someone could please build from the adt-14-support branch and verify, I'll merge to trunk.

@thoutbeckers

It's working for me, after I managed to install the r15 release of ADT.

The only thing that does not work at the moment is my main project showing up as a dependency (through maven) for my integration project. This does work as an external maven build, and within Eclipse it's easily fixed by adding the project through the build path.

But I realize this may be intentional, since this way it's easier to pick up changes from the upstream project?

@rgladwell
Owner

@thoutbeckers no, that should work if it was working before. we're probably being too liberal about what we remove from the Maven classpath container. Probably needs another unit test + fix to resolve.

@rgladwell
Owner

I doubt I'll get a chance to work on this today, will try and work on a fix next week.

@thoutbeckers

It appears that it is not returned as a runtime dependency by MavenProject.getRuntimeClasspathElements() , and thus filtered.

https://github.com/apache/maven-3/blob/trunk/maven-core/src/main/java/org/apache/maven/project/MavenProject.java#L642

Maybe if I have some time later this week I'll look into it myself (and if I'm possibly doing something strange in my POM files). Meanwhile, I'll see how far this workaround will get me.

@rgladwell
Owner

Yes, we should probably delete items from a list of provided scope dependencies, rather than delete anything not on a list of provided scope dependencies.

@rgladwell
Owner

OK, could someone please test this latest commit, it should fix the problem of not including workspace project dependencies in the classpath.

@curtiss-howard

I can test. Can you push a new build out to the update site? I'm starting from scratch trying to build the plugins in a Maven commandline but it doesn't seem to work (can't find the ADT bundle).

@rgladwell
Owner

@curtiss-howard i'd prefer to get confirmation that the source code is working before pushing to the master update site. it could generate a lot of extra issues.

@iandees
@jeffjensen

"Me too" :-)

@anthonydahanne
Collaborator

if you cannot build because of missing adt15, please have a look at issue #47
in particular, replace , in indigo.target those lines :

-<unit id="com.android.ide.eclipse.adt.feature.group" version="12.0.0.v201106281929-138431"/>
-<repository location="http://rgladwell.github.com/publish_adt_to_p2repo/"/>
+<unit id="com.android.ide.eclipse.adt.feature.group" version="15.0.0.v201110251216-213216"/>
+<repository location="http://ci.dahanne.net/view/m2e-android_jobs/job/publish_adt_to_p2repo/ws/p2/"/>

worked for me

@thoutbeckers

@rgladwell, works for me!

m2e recognizes the dependency's artifact as another workspace project and adds the project to the Maven dependecies classpath.

@curtiss-howard

This sort of works for me. I have one library project that just won't output any classes to bin/classes despite being configured the same as three other projects that do behave correctly. I'll just chalk it up to my hacked-up build of your plugin.

@curtiss-howard

Also, forgot to mention that I had to remove me.gladwell.android.tools from feature.xml to get things to compile.

@anthonydahanne
Collaborator

I just got 1 problem, though, on a project using slf4j (and slf4j android), I got this error that prevented the apk to build :
[2011-10-31 21:25:21 - regalandroid] Dx
UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.IllegalArgumentException: already added: Lorg/slf4j/helpers/BasicMarker;
[2011-10-31 21:25:21 - regalandroid] Dx at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
[2011-10-31 21:25:21 - regalandroid] Dx at com.android.dx.dex.file.DexFile.add(DexFile.java:163)

guess this library did not get filtered out from being added twice on the classpath.
you can try to add slf4j and sl4j-android on your maven dependencies to reproduce, see https://github.com/anthonydahanne/ReGalAndroid/blob/master/regalandroid/pom.xml as an example

@rgladwell
Owner

@anthonydahanne looks as though you have an slf4j dependency that is compile scope: if it comes with the Android platform it should be "provided" scope and will therefore be filtered out of the Eclipse maven classpath container as per a1c8002 . Do you not use the Android Maven jar files in your Android POMs?

@stephanmehlhase

I'd like to test it, but right now I'm unable to compile with the following error after I did what anthonydahanne proposed.

[INFO] {org.osgi.framework.executionenvironment=OSGi/Minimum-1.0,OSGi/Minimum-1.1, osgi.ws=gtk, osgi.arch=x86, osgi.os=linux, org.eclipse.update.install.features=true, org.osgi.framework.system.packages=}
[INFO] [Software being installed: me.gladwell.eclipse.m2e.android.feature.feature.group 0.4.0.qualifier, Missing requirement: me.gladwell.eclipse.m2e.android.feature.feature.group 0.4.0.qualifier requires 'me.gladwell.android.tools 0.0.0' but it could not be found]

@curtiss-howard

@stephanmelhase, that's what I was referring to. You have to remove the entry for me.gladwell.android.tools from the me.gladwell.eclipse.m2e.android.feature project.

@stephanmehlhase

Okay thanks, I was able to compile the plugin and test it. I have problems with a library project however. Declaring a dependency of type "apklib" to the library project will generate the correct APK when using maven on the console. However, the library project is not included into the classpath. Changing the type of the dependency to "jar" will fix it in Eclipse but will break the build on the console. I use alpha-13 of the android-maven-plugin and Eclipse Indigo.

@curtiss-howard

Actually, I think it is including the library under the "Libraries" (or perhaps it's "Android Libraries") classpath container. The problem seems to be what I noticed in issue 43. ADT expects classes in bin/classes in order to build its own JAR to include on your non-library project but classes are going to target/classes as normal. I've noticed with this patch that most of my library projects allow the JAR to be built correctly, but in one it doesn't. Check your library project's bin/.jar. You should see no classes in it.

@stephanmehlhase

Okay, after removing and adding the library project again it is now working. Also the library project's jar is not empty. I will test a bit more in the next few days to check how stable it is working.

@rgladwell
Owner

@stephanmelhase that doesn't look like a regression caused by changes as part of this issue so, if its ok, i'm going to leave fixing issue #43 for the time being an prioritise a release with this fix.

@rgladwell
Owner

Merged to master, should hit CI master/update site within the hour:

https://rgladwell.github.com/m2e-android/updates/master/

Can people please verify if this works.

@anthonydahanne
Collaborator

ci went ok, can use http://ci.dahanne.net/job/m2e-android_master/ws/me.gladwell.eclipse.m2e.android.update/target/repository/ as the update site for now(until new mvn deploy)

@rgladwell
Owner

The new version is now up here:

https://rgladwell.github.com/m2e-android/updates/master/

Can people please verify if this works.

@akloeber

I installed the latest master version and the build works perfectly.

Many thanks!

@rgladwell
Owner

@akloeber thanks for the feedback, will try and release this week or at the weekend at the latest.

@rgladwell rgladwell closed this
@7Bit

It's working now! Thanks a lot!

@jeffjensen

w00t! Works great again... Thank you very much!

@rgladwell
Owner

Thanks for the feedback and help on this ticket, guys, much appreciated everybody!

@iandees

I may be a bit behind in my reading on this issue, but we should be switching all "apklib" packging specifiers to "jar" now, right? In the past, "apklib" ran aapt to generate the R.java and compile it, but it looks like the resulting jar file is not being included in the parent project's Maven Dependencies build path.

@rgladwell
Owner

@iandees Android library projects are out-of-scope for this ticket, focussing on getting basic ADT 15+ support out the door. Please update issue #43 with relevant information, any sample projects you have so I can write some intergration tests, and any patches that help fix this issue.

@rgladwell
Owner

Anyone tested this update on Windows 7? Could you please verify its working?

@curtiss-howard

I'm on Windows 7 and it works fine, aside from my library problem in issue #43.

@rgladwell
Owner

Interesting, I'm getting reports of problems with basic Android projects on Windows 7:

https://twitter.com/ajaegle/statuses/132032998072786944

Only thing that seems different is that its Windows 7. Or that is a 64 bit OS.

@curtiss-howard

You know what, one of my apps had that problem as well, but I wrote it off as being related to the library issue. Looks very familiar though, classes from the app's src/main/java weren't included. I'm on Win 7/64 bit as well. I'll investigate that.

@rgladwell
Owner

@curtiss-howard LOL oh no, just as I thought I had nearly got this one out the door. Please do let me know if you can reproduce.

@curtiss-howard

Yeah, I think so. With a dead simple app, I get this:

[2011-11-03 07:38:47 - issue-43-application] Dx no classfiles specified
[2011-11-03 07:38:47 - issue-43-application] Conversion to Dalvik format failed with error 1

Implying that nothing in src/main/java was added.

@rgladwell
Owner

OK, I'm think I'm going to open a separate issue and go live with the existing release, unless anyone has any major objections. I think we need to get some basic andriod-maven-plugin and ADT 15 support out there at least for non-Windows users, and then I can fix this Windows 7 issue with a further release.

Also I suspect this Windows issue might actually be an ADT bug, m2e-android doesn't do any building any more.

@jeffjensen

I'm running Windows 7 64bit as well using m2e-android 0.4.0.201111020121 and android-maven-plugin 3.0.0-alpha-13 with a small app having a parent pom and separate IT module as originally created with the archetype.

After upgrade to latest Android release, I was encountering this error as well: Conversion to Dalvik format failed with error 1

I just reviewed my POMs to try and remember what fixed that error for me. IIRC, the latest Android Maven Plugin fixed it. The only other change I remember at that time is possibly upgrading to latest ProGuard (I saw tons of posts that an older version of it was the cause for many, but was not my cause).

I also remember needing to run (project context menu) -> Android -> Fix Project Properties
And then (project context menu) Maven -> Update Project Configuration
to further fix.

While the latest m2e-android fixed the POM error (this issue 45), I still cannot build, deploy, run the app to device from Eclipse as this exception occurs:
11-03 13:56:01.054: E/AndroidRuntime(397): java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{xxx.yyy.zzz/xxx.yyy.zzz.activity.login.LoginActivity}: java.lang.ClassNotFoundException: xxx.yyy.zzz.activity.login.LoginActivity in loader dalvik.system.PathClassLoader[/data/app/xxx.yyy.zzzz.apk]

It builds, deploys, and runs successfully from the command line with Maven though, e.g. mvn install.
So, it also seems to align with others' reports that the classes are not correctly included in apk.

@RicardoGladwell, I very much agree with your idea to release the current m2e-android, as it allows a clean compile/no errors for Eclipse editing (this issue), and resolve this next problem(s) as a separate issue(s).

@rgladwell rgladwell reopened this
@rgladwell
Owner

OK, I think as per comment 2496293 there is still an issue where source files are not being copied to the correct destination due to the fact ADT ignores the Eclipse project classpath output folder and always looks in the bin/classes directory.

Merging from #51

@rgladwell
Owner

When people verify did they test with a clean build, empty binary directories and by executing Run As... Android Application?

@rgladwell
Owner

Issues #43 #50 and #51 merged into this ticket,

@thoutbeckers

When including another project in the workspace as a dependency m2e has the option to resolve this to another project instead of a jar (this is on the Maven option pane as "resolve dependencies from Workspace projects"). This however leads to sources not being included in the dependent project, or at least not most of the time.

But this appears broken in "normal" ADT too, code from referenced projects does not appear to be included, nor their exported libraries. I looks like ADT includes only classed from jars/class-folders on the classpath of the project, not other projects (see BuilderHelper -> handleClasspathEntry(IClasspathEntry e, IWorkspaceRoot wsRoot,
ArrayList<String> oslibraryList, ResourceMarker resMarker)
in ADT). So post r14's "dex everything that's on the classpath" is sadly limited to "dex everything on the classpath that I can wrangle a jar file of class folder from".

Though I'm not using them atm it seems to me any Library projects exposed through the Maven classpath container will get the same treatment by ADT.

Not resolving the workspace projects leads to including jars that are in your local maven repo, which at the moment are only updated when you do an external maven build (neither m2e-android nor m2e update the jar there afaik).

@rgladwell
Owner

@thoutbeckers thanks for highlighting this issue. I think it would be better to raise this as a separate ticket, I'd prefer to get basic working ADT 14+ support out the door first. We can decide then whether or not to address the workspace project dependencies issue.

working on a fix for the output directory issue.

@rgladwell rgladwell added a commit that referenced this issue
@rgladwell [task #45] Fix: properly configure source output folders. ADT 14+ now
requires class files be built into new default binary location (bin/classes).
ae34e56
@rgladwell
Owner

This should now be complete, wait about an hour after this message and please update, then:

  1. Run Maven -> Update Project Configuration
  2. Project -> Clean
  3. Run As... -> Android Application

And verify this fixes your issues.

@jeffjensen

WFM so far!! :-) Thank you!

@iamdanielkim iamdanielkim added a commit that referenced this issue
@rgladwell [task #45] Fix: properly configure source output folders. ADT 14+ now
requires class files be built into new default binary location (bin/classes).
0c87e1d
@rgladwell
Owner

@jeffjensen thanks for the feedback

closing this ticket and going for a release.

@rgladwell rgladwell closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.