I think Wicket is listed as semi-compatible because it requires some customization (override some methods, change some configuration) to make it work, not because its internals are inherently incompatible to GAE, or because it has some incompatible visual components.
Such customization are simply disabling resource polling, enabling sessions and persisting the session store in the HttpSession, and those shouldn't change, since the defaults shoud target to the plain-old Java web application, not GAE. Some things could be done to improve GAE support, such as eliminating javax.swing dependencies (from the Tree component), but I think nothing one could do would change the classification from semi-compatible to compatible in that listing. Unless, of course, GAE turns to be the main target for Wicket (which I don't think is the case). my 2c, Tetsuo On Mon, Sep 20, 2010 at 9:52 AM, Peter Ertl <pe...@gmx.org> wrote: > Why not prefix all issue titles with something like > > [GAE] problem description > > ? > > This should be easy to filter or lookup > > Am 20.09.2010 um 14:43 schrieb Clint Checketts: > > > There is a 'Will it play in app engine' page that tracks libraries that > are > > compatible with Google App Engine (aka GAE): > > > http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 > > > > Correctly, Wicket is listed as Semi-Compatible. > > > > As a project I've been looking through the Wicket codebase locating the > > pieces that need to change to make it fully compatible. Does it make > sense > > to have a master Jira that tracks the overall 'compatible with GAE' state > > while making individual issues for the specific changes that reference > back > > to the master issue? > > > > Thanks, > > > > -Clint Checketts > >
