Android for Maven Eclipse

After running the other Classpath Configuration classes the source folders are out of sequence, causing all sorts of problems looking up source. This is an attempt to re-order the classpaths. It hasn't yet been tied into the code, but here for code review and comment.

The project.properties file determines which Android target should be the project built against. This information is already defined in the maven-android-plugin configuration, by the android.sdk.platform property. This commit adds the ability to m2e-android to read this property and generate the project.properties file automatically at project import.

This little PR is loosely related to #182. It is not a good practice to create new entries, this change takes previous attributes into account. Also i refactored the code so i think it is a little bit cleaner now. I did not add any tests, since there is nothing to test in this PR.

Added test to verify JUnit launcher itself is correctly compiling and executing unit tests. This is currently failing with an unexpected result.

Someone needs to look at this and find a way to get this to reliably work.

More info about this in the initial issue #106

There is still some unsolved problems like:

• force maven update project after end of import, do you know how to do it?
• solve this http://stackoverflow.com/questions/12032753/eclipse-pde-how-to-add-marker-with-quick-action
• this bug http://code.google.com/p/android/issues/detail?id=36460 (windows only?)

But I think that you can make some core review already.

I still think that is very uncomfortable use it. I mean that user must import main project, open pom.xml, see what's wrong, perform quick action. Better would be if everything will work directly after import. We will se what users will say...

The maven android sdk deployer by default uses 'android' as the group id instead of com.google.android. I believe google with Gradle is starting to move toward the com.google.android groupID but for legacy projects the 'android' groupID still needs to be supported otherwise projects can't be configured.

During classpath configuration the order of source code folders changes causing problems with source code lookup, for example during debugging:

https://github.com/rgladwell/m2e-android/issues/issue/245

The order should always be:

src/main/java src/main/resources src/test/java src/test/resources Android Framework Android Private Libraries Android Dependencies Maven Dependencies Non-runtime Maven Dependencies

This change reorders the classpath as above. Includes tests.

When the configuration entry "ignoreOptionalWarningsInGenFolder" is set to "true" in the configuration of the Android Maven Plugin, the optional warnings in the "gen" folder are ignored by the Eclipse IDE.

This pull request provides an answer to issue #144.

This is proof of concept change to leverage the Andmore plugins instead of ADT. This will need some future work to allow for either module to be injected depending on what plugins are installed.

This will fail to build until there is a public milestone of andmore available. It is mainly here for discussion on how to support andmore and what current modifications are needed to use the renamed plugins.

I finally fixed the JUnit launcher test. The problem was indeed the project was not compiled, so the JUnit classpath referenced nonexistent files/folders. I managed to compile the project, but it is a little bit tricky, since a simple project.build() call was not enough, so i had to use a workaround. Please see the comments of #235 of my really long investigation...

With the modified buildAndroidProject()method, the ignoreTestBuildDirectoryContainsCompiledClasses test would pass, too. I did not re-enable it because i was not 100% sure why did you disable it in the first place.

By default the library path is "../libraryname" but in most cases a maven Android project is multi-module so the library path resolution fails.

I used a code found on stackoverflow to make the library path relative to the target project. It works on MAC OS but i couldn't test it on a windows machine.

…jects as warnings, not cascaded exceptions (Issue #369)

The caught NullPointerException is the specific issue in the case we're running into in issue #369, but the CoreException catch is to allow it to recover from other such problems with unrelated projects.