-
-
Notifications
You must be signed in to change notification settings - Fork 420
Android: add android libs to dummyAndroid module for auto update
#5399
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
Android: add android libs to dummyAndroid module for auto update
#5399
Conversation
dummyAndroid module for auto update
…#5400) Works around com-lihaoyi#5375 I still don't know why it happens, but it's happened multiple times, and in any case it should be fine to ignore the error --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Since Mill is on Scala 3, it's time for the examples to be Scala 3 as well. Also bumped library versions in the examples Left a few on Scala 2 where the upgrade was a bit fiddly (e.g. dealing with fatal warnings, compiler plugins, etc.)
…m-lihaoyi#5404) This reverts commit d03fd45. Fixes com-lihaoyi#5398
- `mill.vcs` needs to be stable - `mill.tabcomplete` does not need to be stable - `mill.scalanativelib`, `mill.scalajslib`, `mill.kotlinlib` can probably be stable by now
…om-lihaoyi#5407) - `core/api/` has been moved to `core/api/shared/`, under `mill.api.shared` - `core/define/` has been moved to `core/api/`, under `mill.api` - `mill.api` now has explicit exports for the relevant user-facing classes in `mill.api.shared` The goal of this is to eliminate the user-facing split between `mill.define` and `mill.api`. Previously, the split was purely based on the internal concerns of what classes are necessary to interface with `mill.daemon`, and is totally irrelevant to the user. This causes confusion in where to find things, since it's generally impossible to remember what lives in which one This change unifies the user-facing API under `mill.api`, while keeping the backend split of `core/api` and `core/api/shared` to accommodate the separation necessary internally. Now users can directly import stuff from `mill.api` all the time, and whether the actual implementation lives in `mill.api` or `mill.api.shared` doesn't really matter since everything that lives elsewhere is re-exported For now the number of things exported from `import mill.api._` and `import mill._` is somewhat arbitrary, but we can add more exports later if necessary
|
This PR changes 595 files. Looks like a git merge gone wrong. Can you please rebase on latest |
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, thank you!
|
@souvlakias The |
The settings are a bit different in our org, I gave you access to our fork @lefou , please try again (you should have received an invite) |
Extension PR of #5392, resolves #5392 (review)
Notes:
Thanks @lefou for your draft, and please let me know if there's anything to fix/add.