On Wed, Jul 28, 2010 at 4:45 PM, Zsolt Vasvari <[email protected]> wrote: > I just tried integrating LVL into my app. Some comments on this > process: > > I have my project set up so that compiler Errors/Warnings are almost > all set to Error level. When I imported the LVL project, I got all > kinds of errors. Mostly missing "this" qualifiers and $NON-NLS tags, > but some of the errors I saw quite interesting. Apparently, whoever > wrote ServerManagedPolicy doesn't have a clear understanding of the > differences between a "long" primitive, a "Long" obejct and its string > representation. There was also a superflous import of > java.lang.String (WTF?, that's first week Java).
$NON-NLS is something specific to Eclipse that we do not use in Android. Our convention for the android source code do not enforce the use of this qualifier. As for importing java.lang.String, those 2 files have been created automatically by aidl (see the files in aidl/) and the tool doesn't care about unneeded imports and automatically put import statements for all the used classes. > Anyhow, I changed the project settings to ignore the errors. That > worked fine until I added the library to my own project. All the > errors came back. It seems that library project uses the settings > from the main project and not the library project. At this point, I > had no choice, but to fix up all the errors in LVL as I was not ready > to lower the warning levels in my app. > > So, going forward, is it possible so that the library's warning > settings take precedence? Since, I am guessing the answer is a no, is > it possible that Google makes sure that any code supposed to be > compiled by every developer does so with the warning levels set to the > strictest possible? It is unreasonable expect that every developer > change their project for the LVL and any upcoming libraries. The issue is that the library code is compiled by the main project so the settings of the library projects are useless. This is not going to change. > By the way, is there a technical reason why LVL cannot be shipped as a > JAR? Do you see the developers modifing the LVL code? Yes and no. Yes because, at this time, the library is only code, with no resources, so you could generate a jar file. However we decided to provide it the way we do because: - we wanted to give the source code (btw, we recommend that you copy it somewhere else before you edit it and link to it) - and we expect you to change it (to have your own implementations for the Policy and Obfuscator), so providing a jar file was pointless since you'd have to regenerate it anyway. - We have the library mechanism. In the future it'll do Manifest merging, so you'll even get more benefit from it. Xav -- Xavier Ducrohet Android SDK Tech Lead Google Inc. Please do not send me questions directly. Thanks! -- 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
