You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by fp...@apache.org on 2021/07/27 21:11:20 UTC
[PROPOSAL] - Shiro 2 maven modules
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
fpapon@apache.org
Re: [PROPOSAL] - Shiro 2 maven modules
Posted by Francois Papon <fr...@openobject.fr>.
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
fpapon@apache.org
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
> fpapon@apache.org
>
> 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
>> <br...@gmail.com>:
>>> 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 <fp...@apache.org> 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
>>>> fpapon@apache.org
>>>>
>>>>
Re: [PROPOSAL] - Shiro 2 maven modules
Posted by Francois Papon <fr...@openobject.fr>.
Agree about the crypto module, may be it's better to keep it in its own
module because of the dependencies.
regards,
François
fpapon@apache.org
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
> <br...@gmail.com>:
>> 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 <fp...@apache.org> 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
>>> fpapon@apache.org
>>>
>>>
Re: [PROPOSAL] - Shiro 2 maven modules
Posted by Benjamin Marwell <bm...@apache.org>.
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
<br...@gmail.com>:
>
> 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 <fp...@apache.org> 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
> > fpapon@apache.org
> >
> >
Re: [PROPOSAL] - Shiro 2 maven modules
Posted by Brian Demers <br...@gmail.com>.
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 <fp...@apache.org> 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
> fpapon@apache.org
>
>