MockServerSuite is in internal package
See original GitHub issueWhat is the reason that the public class mentioned in the Readme is inside a package named internal
?
I realized that since we have a lint check that warns imports with internal
in them.
Moving them would be an backward incompatible change but would you considering doing that?
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (5 by maintainers)
Top Results From Across the Web
Use of internal package not allowed - Stack Overflow
Internal packages (packages that are inside a folder that has an internal folder in their path) can only be imported from packages rooted...
Read more >Use internal packages to reduce your public API surface
internal / is a special directory name recognised by the go tool which will prevent one package from being imported by another unless...
Read more >Illegal internal package import in adf 12.1.3 — oracle-tech
Hi, We have migrated our application from 11.1.2.4 to 12.1.3, which is causing an warning/error for internal imports used in the code.
Read more >Go 1.4 Release Notes - The Go Programming Language
Internal packages. Go's package system makes it easy to structure programs into components with clean boundaries, but there are only two forms of...
Read more >5.1. Internal Package - Keypirinha
5.1. Internal Package¶ · Keypirinha: Configure Application to edit application's configuration file(s) · Keypirinha: Refresh Catalog to ask all packages to ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Even with the current form, existing ones can be used with jUnit5 with the vintage engine. But that’s for migration purposes and people would not want to keep it forever. https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4
The stuff that I did with jUnit5 support is not compatible.
Core would be a transitive dependency for both so that the users do not have to add it manually. They would add either junit4 or jUnit5 or Android one.
Then it also opens up the possibility to have core without even using any of the junit dependency.