What I do is to create a libs/ directory in Eclipse, and add them to the Eclipse build path. Android Tools/Export Signed Application Properties works fine.
But I *highly* recommend not using Eclipse for your production builds, but rather have a build script that handles checkout, version numbering, naming the resulting builds, etc. A disciplined build process greatly reduces the possibility of confusion and mistakes making it into customer's hands. Unforutnately, the way Eclipse does things, that means two different build methodologies; one for debugging, one for production. Fortunately, the Eclipse side of that is generally pretty painless, and the 'android' command gives you a leg up on an ant script for the production builds. But as to your problem. If you have a 3rd party jar file which is working fine, and it's set up the same way, then the way it's set up isn't really the problem. You need to find out what the problem is. NoClassDefFoundError does not mean what you think it means. Reading the name, you'd think it means what ClassNotFoundException means. No, what it means is that while LOADING a class, and probably while actually running the static initializers of a class, an exception was encountered. If that happens, you don't get a reference to the class, and NoClassDefFoundError is thrown. Unfortunately, you don't get told what the problem was. So you have to use the debugger to figure it out. Set an exception breakpoint on NoClassDefFoundError, and ones for Exception and Error, and run your code. This should expose what the original problem was. I can never understand why NoClassDefFoundError doesn't include the original cause -- it really makes such problems a lot more obscure than they need to be. On Mar 13, 4:00 pm, Tom <orei...@mbari.org> wrote: > I created the libs directory where you specified and copied the > gdata .jar files in there, then from Eclipse ran "Export" project, > then installed on the phone - but with the same result - > NoClassDefFoundError for CalendarService. > > It seems that Eclipse is "silently" failing to handle the gdata jar > files somehow - my project contains another 3rd party jar file which > appears to work just fine. > > Something tells me that I have to stop relying on Eclipse and actually > learn how to use the Android SDK command-line tools... I knew it > wouldn't be this easy. ;-) > > Thanks for all of your help. > > On Mar 13, 3:24 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > > > > Tom wrote: > > >>> This code compiles with no errors, using Eclipse on MacOS, using > > >>> external jar files from the Google gdata project: > > >>> gdata/java/lib/gdata-calendar-2.0.jar > > >>> gdata/java/lib/gdata-calendar-meta-2.0.jar > > >> Did you copy these into your project's libs/ directory? > > > > No, I merely specified the path to the external jar in the Eclipse > > > "Java build path" libraries dialog. This seemed to work for other > > > projects I've developed. I look in my Eclipse project workspace and > > > see assets, bin, gen, res, and src directories but no libs. Where > > > should that directory appear? > > > As a peer to assets/, bin/, gen/, res/, and src/. > > > Now, it is conceivable that Eclipse handles things differently. I don't > > use Eclipse, and from the command line, just dropping the dependent JARs > > in libs/ is all you need. My recommendation to my students is that they > > put their dependent JARs in libs/ plus add them to the Eclipse build path. > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://twitter.com/commonsguy > > > Warescription: Three Android Books, Plus Updates, One Low Price! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
