I've gotten some really great help from this forum and hoping that I can get yet more advice. Some time ago I created a number of plugins. I was always in need of a front end and the only real choice was a web app. I was never able to successfully get a web app and container configured and running in OSGi and eventually moved on to other functionality. Since that time Virgo has become available and has solved certain problems. I have one major issue before I can begin the conversion and it's my hope that I can get some resolution here (either way).
Basically I have to keep my bundles separate from each other. They should be able to come and go and not affect the overall solution's running status. It is impossible to know what bundles will be running on the server at any given time because there will be multiple installations, each with their own requirements. Likewise there will be new bundles created and added to the existing solution in the future. This addition of bundles needs to work without modifying any of the existing bundles. The development of the plugins/bundles has already been completed to allow these requirements to be met so it's really about server configuration/capabilities at this point.
From what I've gleaned from documentation, help in the forum, and from searching google here are the options that I've found:
- Separate bundles can be added and removed as described above. These bundles exist in the global scope. This would be ideal however it doesn't appear that it's possible to have a bundle project reference other bundle projects within the Virgo Tooling.
- PAR. File containing all bundles within the application. The bundles are scoped to prevent access from bundles not within the scope. The application is well defined and new bundles cannot be added nor can bundles be removed at runtime. If any bundle changes running status in the application, all bundles experience a change in running status. This seems like a good fit for a project that has rigid requirements and can be deployed with one configuration. This would not work for my requirements.
- Plan. Project containing XML file specifying all artifacts for the application. Scope can be either local or global. All referenced bundle files must exist in the repository. If any bundle is not found in the repository the application fails to start. This probably could have been made to work for development however the tools do not allow bundle projects to reference each other nor place the bundles into the server repository at runtime.
So there it is. If I'm missing something (and I really hope I am) please let me know. The web interface is really the last hurdle I face.
I've just read the overview and I'm starting to wonder if Snaps would be a good fit for the above. From the documentation I read, it doesn't appear that the bundles need to be predefined in the host. I'm going to test later today but might this be a viable solution?
I took some time and found that snaps was going to work out rather well for one of my main problems. I was able to satisfy the other requirements so things are looking pretty good. The only bad news is that I was using Sitemesh which doesn't look like an option so it's on to something else.
It looks like Sitemesh, along with the other opensymphony projects, has been discontinued. Sitemesh 3 is being worked on by another entity but it is a long way from being complete. I attempted to get Sitemesh 2.4 working with my project however it appears that it is referencing libraries that are older and incompatible with the libraries in Virgo. For example it uses javax.servlet 2.5 rather than the 3.0.