ADT 17 Build issues

Google, Google, Google... What should I do with you??? Don't you ever think a bit outside the scope, or is this some sort of a grand master plan to muscle us all to work your way?

I can tell you right now that your main issue regarding the build process of the Android projects in Eclipse is due to the fact that there are two class paths for the same project, one is the Android libs, the other is the IDE classpath. I think that as programmers you should know this is BAD PRACTICE!!!

I came across two major issues, the NoClassDefFoundException, and the terribly annoying jarlist.cache file.

1. In the previous versions of the ADT the dependent jars where automatically exported, which caused the dalvik issues in the build, with the "duplicate files" error. So their solution was to cancel the export completely and leave the export management to Eclipse, which is a step in the right direction... Personally, I would simply resolve the dependencies and not import a duplicate dependency.
   
   SO, if you experience the NoClassDefFoundException, it is because your .class files from the project dependencies were not imported to the output folder of the final Android application project.
   
   Maven, Eclipse, Ant could all have a different dependencies resolution, and different hierarchy structure, plus your own projects hierarchy, brings one to the conclusion that to understand the export  dependencies  feature, you must know what the hell you are doing, and understand projects hierarchy, your build tool, and how it resolves its project's dependencies.
   
   In general it is always best to enable the export on project D, but there are some cases exporting on project A would be preferred. For example:
   
   I.  Projects A, B, C, uses an XML library, where would you export the library? See Answer 1.
   II. Project A is a framework module project that projects B, C uses? See Answer 2.
   
   Nuts ha? but there is no other way to be 100% sure you would not export the same .class file twice!
   It may be that Eclipse resolves this issues, but I've started to trust no one! I have an intermittent Android lib project with most of the dependencies, which are also marked as export, and the final project depend on it.
   
   To enable export for dependencies you go to:  Project -> Right Click -> Properties -> Java Build Path -> Export tab -> check the project you want to export.
   
   And as for this solution, I think it is a bad idea... very bad idea, why? just because, I don't feel like writing another 100 rows about how you should work, this is my advice, you can take it or leave it :)
2. The second most annoying issue with ADT 17, is the jarlist.cache file. Brilliantly the ADT team decided they need some file for god knows whatever reason, (it is really beside the point)  and they have decided to place that file hard coded at ${ ProjectFolder}/bin/jarlist.cache, and because some of us Eclipse users, are used to the fact that the default output folder is ${ ProjectFolder}/bin/, we experience this issue. Problem is that this build action does not effect only Android projects builds, but also pure Java projects, which eventually causes the mess. Android default output folder is at ${ProjectFolder}/bin/classes, you can verify it, go to your android project .classpath file and change the output to "/blah/blah" and see what happens once you clean build... like magic the adt nature returns it to "/bin/classes".
   
   The solution for this mess: point the output of all your projects in the workspace to "/bin/classes", this solves it!

If you encounter more issues with the ADT 17 let me know, I'll add reference to it.

In general, it is a step in the right direction, but this is annoying as hell, they change the freaking project management every version... can't they formulate something stable? I really hope the next version would be better, I mean they turn 18 soon... ;)

Answer 1: Project D

Answer 2: The dependencies whom are unique to Project A, would be exported. common used dependencies would not, they would be exported in Project D!!    << == (This is the conclusion!!)