-
-
Notifications
You must be signed in to change notification settings - Fork 141
Metadata generator is more tolerable now #842
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
💚 |
run uitests |
run ci |
💔 |
ClassDescriptor clazz = ClassRepo.findClass(className); | ||
generate(clazz, root); | ||
if (clazz == null) { | ||
throw new ClassNotFoundException("Class " + className + " not found in the input jars."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change jars to libraries, since from the user perspective .aar
files are not jars.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After green build + unit tests
and minor changes from the comments are met
// Should we worry about this? If classes would crash, that would happen during the compilation step | ||
// which occurs before the metadata generation | ||
|
||
// throw new IllegalArgumentException(errMsg); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We needed this check when metadata was generated on the basis of .dex
files. It's now obsolete because, as you said, the compilation task will take care of providing an understandable error for the user, so we don't need to.
You can remove the comment and leave the code as it is, without the throw statement.
6792a21
to
7438f48
Compare
💚 |
7438f48
to
d9e81d7
Compare
💔 |
run ci |
💚 |
Addresses issue #832 by making the following small changes:
when collecting classes from input jars, do not crash on clashing classes (classes that are already brought in from another library). The assumption here is that the build will crash at earlier point during the java compilation step, and it should not concern the metadata generator.
(e.g. An android library depends on appache http library, but if imported in gradle as a dependency, the class collection logic in the metadata generation would fail, complaining that 3 classes coincide in name - some of the appache http classes are left inside the android sdk packages for whatever legacy reasons they have)
when traversing a class's methods/fields, do not skip class if the parameter of a single method is not found in the ClassLoader. Instead continue, and try to generate as much metadata as possible for the class being analyzed.