Hi, Moving forward on the discussion, I created the associated issues in Jira for the 2.x release:
SHIRO-832 Move the shiro-lang module into shiro-core SHIRO-833 Move the shiro-event module into shiro-core SHIRO-834 Move the shiro-cache module into shiro-core SHIRO-835 Move the shiro-config module into shiro-core Feel free to comment :) regards, François [email protected] Le 28/07/2021 à 14:46, Francois Papon a écrit : > Agree about the crypto module, may be it's better to keep it in its own > module because of the dependencies. > > regards, > > François > [email protected] > > Le 28/07/2021 à 12:49, Benjamin Marwell a écrit : >> General +1 if dependencies allow it. >> >> Not so sure about the crypto modules, though. Because of what Brian >> said, dependencies on BC and other libraries, we have several support >> modules. >> The lang module can probably be reduced by quite a bit. We already >> removed the Base64 implementation, most StringUtil methods can be >> replaced by JDK methods, some are never even used. >> >> If we merge them into core, be aware that we lose the ability to >> compile shiro in parallel (mvnd or mvn -T1C and similar). >> A larger core module will also mean that some may be tempted to write >> less appropriate tests (by using specific implementations instead of >> mocking interfaces which are not the objects under test). >> >> - Ben >> >> Am Mi., 28. Juli 2021 um 00:02 Uhr schrieb Brian Demers >> <[email protected]>: >>> 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] >>>> >>>>
