JorgeCastilloPrz
MockServerSuite is in internal package
What 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?
I'd be interested in knowing more about why a package named "internal" is not valid for you folks. I don't think there's much problem about doing breaking changes now, since the user base is almost inexistent though. If it's required for some reason, I would do it.
Well, it's a good practice for library developers to separate packages internal vs not. Internal usually signals that it is the internal implementation details and might change often.
In this case it is fine. But at the same time it is slightly better if the entry point of the library would be at top level package.
Yes I can't argue to that. There's not a reason anymore, it's probably just leftovers from previous iterations. I'll gather this and your other request and prepare a new version soon.
I'm working on the other request. Will open a PR soon. 😊
On Sat, Jan 19, 2019, 09:28 Jorge Castillo [email protected] wrote:
Yes I can't argue to that. There's not a reason anymore, it's probably just leftovers from previous iterations. I'll gather this and your other request and prepare a new version soon.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/JorgeCastilloPrz/hiroaki/issues/63#issuecomment-455760479, or mute the thread https://github.com/notifications/unsubscribe-auth/AAulyyCRk6OgPTlBaYIWFayU0DnKIImPks5vEtc9gaJpZM4aIM9a .
@JorgeCastilloPrz I was gonna take a look at this but I came up with another idea.
What do you think about introducing junit4 module just like done in #71 and move these classes there: MockServerSuite and MockServerRule
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.
From a user point of view, would you need to include both core and junit4 dependencies separately (or core + junit5) or what do you have in mind?
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.