Conversation
Codecov Report
@@ Coverage Diff @@
## master #16 +/- ##
=============================================
- Coverage 100.00% 7.51% -92.49%
+ Complexity 20 6 -14
=============================================
Files 9 12 +3
Lines 89 266 +177
Branches 4 25 +21
=============================================
- Hits 89 20 -69
- Misses 0 246 +246 |
|
Tnx for asking. Happy to comment. Quite busy at the beginning of this week but will try to squeeze it in. |
DanielGronau
left a comment
There was a problem hiding this comment.
The only problem I see is the unclosed InputStream in ManifestHelper, everything else is cosmetics.
| } | ||
| } | ||
| } catch (Exception e) { | ||
| } |
There was a problem hiding this comment.
I would add an comment that ignoring the catch block is intentional.
| } | ||
| } | ||
| } catch (IOException e1) { | ||
| } |
| int lastDot = className.lastIndexOf('.'); | ||
| if (lastDot > 0) { | ||
| packageName = className.substring(0, lastDot); | ||
| } |
There was a problem hiding this comment.
Theoretically, packageName could be obtained via (PackageElement)(type.getEnclosingElement()), but I'm not sure this is better here.
| while (resEnum.hasMoreElements()) { | ||
| try { | ||
| URL url = resEnum.nextElement(); | ||
| InputStream is = url.openStream(); |
|
@DanielGronau thx for reviewing and pointing out some of the little defects. As i said it is POC level code. However i am interested in your opinion, if this is something to pursue. |
I agree this it is a difficult decision. The reflection / mirror stuff makes the code hard to read, but I think this could be improved by introducing an abstraction layer. In order to support debugging, having good logging in place could help a lot. The big plus I see - beside the client experience and nativity - is getting more control and freedom. So I would suggest to go forward. |
|
Ok, in the last 1/2 h I've learned quite something about apt. This was indeed interesting ;-) But instead of having us reverse engineer: could you please provide an example (or running test) how a user of the library is supposed to use it? Or do I miss something? |
|
@samba2 Unit Tests are especially hard here, as they would probably rely on mocks entirely due to TypeMirrors and stuff. If we decide to keep it, it might be sensible to create an extra module for roundtrip tests. As we're not there yet, i did not want to put the extra effort in and break the projects structure. |
|
for the record: @otbe voted +1 |
Co-authored-by: Daniel Gronau <Daniel.Gronau@gmx.de>
Co-authored-by: Daniel Gronau <Daniel.Gronau@gmx.de>
Not sure if that makes it better. Certainly the processor is hard to understand and test, but as a client, you only see easy generated code and you can navigate to handle methods easily (which were the initial drivers).
Please comment.
To use this in IIP for instance, just do a local install and update the dependency in the project's pom - nothing more to do.