Les, Thanks for your feedback. I'll respond inline below.
> 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). > Yes, deprecating and moving the existing packages to an attic would be a good idea. I've not done that before and would be worried it would cause someone's build to stop working. I suppose it would be fine if it was run by the community first. > 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. > I completely understand and respect your concerns. Personally, I'd like to not have it part of wicketstuff any longer, as I've found wicketstuff's versioning difficult to work with. I'd rather have more control over the release schedule so that it can coincide with not only wicket, but also shiro releases. However, there are certainly some advantages to just keeping it at wicketstuff. And I'm not going to be the one doing the development, so I'm fine leaving this choice to others. Basically, I see the following four options: 1. Have it become part of Wicket This would be the best solution, but I don't know if the wicket community would accept another security module into wicket core. There is already wicket-auth-roles, and I've gotten the sense that the devs feel it is sufficient. Of course, it is certainly worth approaching them with the idea, but the new version should be implemented with some demo apps for the devs to review first. 2. Have it become part of Shiro This route would give it exposure and credibility as well. However, you are right -- a UI integration probably doesn't belong with a lower level security framework. And maintenance would be a concern, however from what I've seen of Matt's code, it would be very minor. By reusing all of the Shiro annotations, there really isn't a lot to it. 3. Have it become a separate project (google code, github, etc.) Personally, I like this approach, especially github because of how easy it is to fork github projects and pull code from others. It also would give full control over versioning, but would make it more difficult to provide other features, such as availability from central maven repositories and such. Exposure of the project could be enhanced if it was on github, but it also wouldn't seem authoritative. 4. Keep it at wicketstuff This would be the simplest and easiest approach. But we'd definitely want to retire all of the old jsecurity/ki/shiro projects first and do everything we can to make it known this is THE integration to use. Perhaps there is something that can be done to have more control over versioning in a wicketstuff project. 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). > I have no definitive reason for this belief, but I expect the wicket devs feel that wicket-auth-roles is sufficient to include with core and that additional security framework integrations should be external. It is worth discussing with them to make sure. It was for this reason that I asked you and the Shiro community first. > 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. > That would be great! I'm not going to be able to contribute much myself as I'm swamped in real work. But I'm happy to chime in as time allows. Matt is taking the lead on development and I'm sure he'd love input from you. > 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. > I understand. I do think making it easy for a framework to integrate shiro would increase shiro adoption. But there is a point where you can't be responsible to maintain all of these integrations. Thanks again for your feedback, Tauren
