Hi Paul, Since I’ve never used Vaadin, I don’t know really know how it works. If all you need to serve is static files, and you do not need to do any template processing server side (for instance how Wicket would), then yes, I think an enRoute web application could work for you.
Currently, enRoute can serve static files as a kind of mixin. All you need to do is ship a static directory with your resources (and require the enRoute web provider), and the files will be served on the corresponding path in the http world. For instance, if you have a bundle that ships Vaadin resources in /static/app1, and a second bundle that ships in /static/apps, then you can access the files from http://hostname/app1 and http://hostname/app2 respectively. You could even ship with overlapping directories and “mix in” the content if you need to. Personally, I have found that this provides a neat mechanism to organise and deploy web projects. No need at all for a WAR just to ship resources. Else, you can use webresources, but (although I haven’t really used it much and I haven’t completely grasped its utility yet) I get the impression it is better for single resources, like for example an angular release. The current doc writes mostly about the webresrouce approach, but it sounds to me like the mixin approach may be more useful in your case. Let me know how it works out for you, I’m interested to hear. If you can provide more details, perhaps I can help more. I’m starting to understand the enRoute web server pretty well, and I’m actually in the process of reworking it to make it a bit more flexible. Cheers, =David > On Jun 5, 2016, at 8:30 AM, Paul F Fraser <pa...@a2zliving.com> wrote: > > Hi, > > Past OSGi examples for Vaadin used a staticResources bundle which looked > through all bundles to find Vaadin resources. > > Using EnRoute should I investigate (ask for help!) developing an extension > annotation to perform this task or should I stick with the staticResources > approach? > > It seems to me that the EnRoute handling of statics and resources fits nicely > with the requirements for Vaadin. > > To use Vaadin with OSGi in the past I have found a usable workflow to be > > 1. Create normal Vaadin project. > > 2. Create war in Vaadin project. > > 3. Extract VAADIN resources etc. from war into OSGi project as necessary. > > Vaadin now provides ability to create Spring Boot projects but have not > worked on OSGi. > > Paul Fraser > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev