I am in doubt. What I think would be best are creating a parent framework like wicket ioc. And then the different security providers could use that.. Does it seem reasonable?
That would mean keeping Wicket security at stuff, but probably extracting interfaces? And maybe adopting a few committers from wicket shiro / wicket security and if there are other integrations to a sub project at Apache Wicket, to make it less of a burden as Igor writes. [ ] adopt Wicket security into Apache Wicket [X ] keep Wicket security at Wicket Stuff 2010/1/22 Martijn Dashorst <martijn.dasho...@gmail.com> > Guys, > > I'd like to discuss the future of the Wicket Security project. > Currently the project lives on/in the wicketstuff repository, but uses > group id and package names "org.apache.wicket". IMO We should either: > > - adopt Wicket Security into the Wicket project and move everything > over from Wicket Stuff into a subproject within Apache Wicket (and > adopt the committers), or > - keep Wicket Security at wicketstuff and move it into the fold of > wicket stuff, including groupid/package rename. > > Since development on wicket security 1.4 is currently happening with a > 1.4-beta1 just released, it is prudent to decide its future now (with > a pending package rename). > > Considering that both the wicket security contributors and the Wicket > PMC members are needed to make this happen, all their opinions are > considered binding. > > [ ] adopt Wicket security into Apache Wicket > [ ] keep Wicket security at Wicket Stuff > > Martijn > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
