I would definitely suggest to choose some sort of option 2. It doesn't really matter if you migrate your services to Spring, EJB or whatever, but the separation of services (or business logic or whatever you want to call it) and the view (or presentation or layout or...) would come in very handy in this case.
I firmly believe in the saying "premature optimization is the root of all evil", meaning that you should really skip any additional layer or indirection you simply don't need. However, if there actually is a use case which justifies a separation into different layers (or abstraction levels or...) you should tackle it as soon as you can. You will benefit a lot from it later on.
Just think of the Wicket application and the Android application as two different presentations of your grocery store. If you clearly separate the business logic from the presentation and make it accessible via HTTP (be it RESTful, SOAP or whatever way you prefer), you can easily imagine building an iOS, Windows Phone, you-name-it presentation of your grocery store without touching the core itself.