-
-
Notifications
You must be signed in to change notification settings - Fork 364
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
Proguard contrib module #972
Conversation
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.
Thank you for your contribution. The module looks ok to me. I added some comments I'd like you to address.
Also to accept this new contrib module, we need some documentation under docs/pages/9 - Contrib Modules.md
(modules in alphabetical order). Having some Scaladoc for all public targets would greatly help later users of that module too.
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.
For consistency, if you use an library from an explicit Java version (via JAVA_HOME) you should also call the Java executable from this specific version.
@lefou Thanks for the review! I've addressed most of your feedback. The one thing I'm a little confused about is this:
Does Mill use |
Mill uses |
contrib/proguard/src/Proguard.scala
Outdated
val outJar = PathRef(T.dest / "out.jar") | ||
|
||
val cmd = os.proc( | ||
"java", |
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.
Better use the java
executable found under javaHome
, to make it consistent with the later used classpath.
Thanks for the help. I switched to using the java binary under JAVA_HOME, and also added documentation. |
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.
Looks good to me. Do you plan to also add some ScalaDoc and/or tests anytime soon? If not I can merge now, but those additions would help greatly in comsumption and maintenance of this contrib module.
@lefou I can add some ScalaDoc. I was testing using just the |
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.
Scaladoc looks good. I found two other subtle improvements that are specific to mills caching.
contrib/proguard/src/Proguard.scala
Outdated
def javaHome: T[PathRef] = T { | ||
PathRef(Path(System.getProperty("java.home"))) | ||
} |
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 need to mark this target as input, otherwise mills caching would hide potential changes of the system property.
def javaHome: T[PathRef] = T { | |
PathRef(Path(System.getProperty("java.home"))) | |
} | |
def javaHome: T[PathRef] = T.input { | |
PathRef(Path(System.getProperty("java.home"))) | |
} |
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.
OK, I'll make the change. But I'm wondering now if this should actually be Sources
? What's the difference?
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.
Sources
and also Source
are specializations of Input. Also Source(s) support the watch mode (mill -w
), whereas Input is not able to trigger a re-build on it's own.
@lefou Hi, I finally had some time to work on this again. I added some basic tests. I am ready to merge this now if that's OK with you |
Thank you @sbly ! |
I just notices, that our test setup wasn't running the proguard tests. Running them locally gives me the following error:
|
Hi @lefou. Sorry about being super late getting to this, I don't regularly check Github when I'm not actively working on a PR. So locally, I would always run If this is not the way tests are expected to work, I am happy to work out the error with you. I based my tests off of the existing tests, so there was some copy-pasting that may be the culprit. |
@sbly Thanks for making your assumptions clear. All mill tests should run as-is. I created a PR to fix the setup. |
Create Proguard contrib module
This module will run
proguard
on the normalassembly
output jar to shrink it. By default all steps - shrink, optimize, obfuscate, and preverify - are run though this can be configured. The default entrypoint isfinalMainClass
. Any additional options can be specified freely withadditionalOptions
(proguard has many).