On Sun, Jan 29, 2012 at 9:37 PM, Doug <[email protected]> wrote: > On Jan 26, 2:33 pm, Mark Murphy <[email protected]> wrote: >> True, though I'm a bit hesitant to rely upon that behavior until they >> release the full library-project-as-distributable-JAR support. > > Why is this? You're basically just depending on the R symbols being > defined in a class that's not in the library jar file but instead is > elsewhere in the classpath of the VM.
And, until the library JAR file supports redistribution, I have no way of being assured whether the JAR contains an R.class or not. Clearly an R.java was needed at compile time of the library JAR, otherwise the code would not compile and there would be no class files to put in the JAR. In principle, that R.class could be in the JAR, thereby causing problems when there is a conflicting R.class in the host project. This is one of those things that may well work with the tools as they stand, but with a fuller solution hopefully coming out soon, I'm not exactly rushing to fuss with it. Now, if there are rumblings that redistributable library project JARs are being postponed for whatever reason, then my interest in your approach rises. Hence, my use of the term "hesitant". I'm not saying your approach is wrong. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 4.1 Available! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
