General +1
I don't think these modules are used without shiro-core. shiro-core depends on all of these modules, and that is what ends up getting used. The only downside i would see is the case of 3rd party implementations of things like cache or crypto. These current modules are pretty small (mostly interfaces), and very few dependencies, this makes it really easy to consume and test. We can minimize the potential downside by keeping the dependency tree of shiro-core limited Ideally keeping the (java) package the same/similar would give us the opportunity to pull the logic back out into a separate module in the future if needed. The crypto implementation bits get a little tricky with BouncyCastle. Which ideally _shouldn't_ be required (or some users may need the FIPS version). A big +1 for moving to JDK8 based classes. Classes like Base64, as well as java.time (Duration, Instant, etc) I have someone conflicting view in my head for the "ideal" project structure, but I favor François suggestion as I think it will help keep things simple (less complex build, easier to document, etc) But I'd love to hear opposing views! On Tue, Jul 27, 2021 at 5:11 PM <[email protected]> wrote: > Hi, > > I would like to start a thread about the Shiro modules for the next 2.x > version. > > I think it would be nice to merge some module in the core module like : > > - shiro-lang > > - shiro-config > > - shiro-event > > - shiro-cache > > - shiro-crypto > > We can also make some code cleanup on some util/tool classes in favor of > JDK8 included classes. > > Thoughts? > > -- > François > [email protected] > >
