>> Since there are people using wicketstuff shiro integration already, I >> think it'd be nice to have a new major version of the shiro parts if >> the changes will be large. This way the existing community has an >> obvious upgrade path without causing confusion. If it is perceived >> that there is more than one wicket-shiro project, it would probably >> frustrate and/or fragment the community rather than help it. > > Les -- I agree with you, however the problem as we see it is that > wicketstuff is not authoritative in any way. There are already multiple > shiro/ki/jsecurity projects on there, most of which are not maintained in > any way. It contains so many abandoned projects which scare off many > developers. And the versioning and build process is mostly out of our > control.
Shouldn't the existing ki and jsecurity projects be deprecated and removed? One idea I would have is to move all the existing stuff into an 'attic' in the existing wicketstuff SVN repo and add your newest Shiro integration code to the wicket-shiro directory that already exists. Then you update the documentation to reflect this, and all pointers should go to your newest code base. I could help with this since I think I still have committer rights to that repo. We'd naturally have to run it by the community first of course, but if it has backing from the Shiro dev team, it would probably make sense to the Wicket dev team (I'm guessing). I think the Wicket and Wicket-stuff community would be fine with this approach - it doesn't make sense to maintain the old jsecurity/ki ones because they're not being maintained. It also removes the old garbage laying around, cleaning things up for the Wicket community, so there is no longer any feeling of fragmentation. > What Matt, Ryan and I have discussed is potentially contributing the new and > much cleaner integration to the shiro project itself, perhaps as a > shiro-wicket submodule. I see there is a shiro-quartz integration, so we're > hopeful this may be something the shiro devs would be open to. I'm convinced > that shiro-wicket would be seen as authoritative and most devs wouldn't > consider using the wicketstuff implementations. Is this a realistic goal, or > would the shiro team object to something like this? I think it is awesome that you guys are working to clean this up. This is great news! One of the struggles I have with this is one of maintenance - while I believe Wicket is a minor exception due to how many people use Shiro with Wicket, as the number of support modules increase, the higher the maintenance costs there are to the Shiro dev team. This is a real cost too - documentation, Jira issues, bugs, etc. It does take time. My other issue is one of scope. Shiro is a security framework, and as such, it usually sits at a lower level in the framework stack than UI frameworks. In other words, it makes sense for UI frameworks to know about and integrate with security, but the opposite doesn't make as much sense. Do you have any sense of whether or not the Wicket dev team is willing to support a wicket-shiro module in their own SVN repository instead of using wicket-stuff? Given that we're both ASF projects, and it can be modularized away from wicket core quite well, it seems like it would be ideal to be part of Wicket proper (instead of just WicketStuff). Since I wrote the initial (very rough) wicket-jsecurity mini project, I'd be very happy to help you guys in any way I can. Let me know if you think I should join the wicket dev list if you think this would be a good idea. As a final note, I struggle with this quite a bit - my first and foremost desire is to see people happy using Shiro in any application, and naturally integration with other frameworks only helps. It's just hard to juggle the time associated with that. What do you guys think about contacting the Wicket team? Best, Les
