[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [pde-dev] Web Application Bundle - running
|
On Mon, Jun 15, 2009 at 12:38 PM, Don Laidlaw
<Don.Laidlaw@xxxxxxxxx> wrote:
OSGi will soon release a spec (now OSGi EEG RFC 66) for web application container that can deploy web application bundles. These are bundles that contain web applications, with an appropriate META-INF/MANIFEST.MF, that can be deployed in an OSGi container. Without going into the spec, this basically means we can have a nice modular web application. Yeah!
The RFC will make definitely make it easier. For years, people have been doing it in various ways, but having a standard will definitely help.
The good folks over an SpringSource are making the reference implementation of the spec. See the blog post at http://blog.springsource.com/2009/05/27/introduction-to-the-osgi-web-container/ for details. The reference implementation works quite well.
Of course I want to be able to run by bundle by using an OSGi Framework launch configuration. That works now, which is the good new. The bad news is that my project must have all of the resources in the root folder of the project. So WEB-INF and META-INF folders plus all html, jsp, etc resources must be in the project root. If you do this, you can run the web application bundle with the OSGi Framework launch configuration now.
The problem is that this is very painful for build tools. In most build tools you want to have a folder to contain your resource to make it easy to select what gets put into the deployment archive (jar, war, etc) If everything is in the root of the project, you need a custom setup for every project that selects, the correct files and folders.
In a J2EE dynamic war project, you typically use a folder like WebContent and this runs fine in a tomcat container. Something similar is required for an OSGi Web Application Bundle.
Again, this is not required to actually use PDE today to run these bundles, but it is really, really painful to require all the resources to be in the project root. Using ant or maven to build these projects is still doable, but it requires a custom script or pom for each project to uniquely select the appropriate resources to add to the build output.
Any ideas?
So, this issue of MANIFEST.MF location has been open for awhile.
153023: Resolve path to MANIFEST.MF and plugin.xml relatively vs. to project root
This issue is being considered for Eclipse 3.6, it would be great if we can have some contributions in this space. Historically, the reason the MANIFEST.MF is in the project root is to enable self-hosting to be easy. Equinox has something called "dev-mode" which enables PDE to self-host without actually exporting and packaging the bundle. You simply can reference bundles in your workspace. This is pretty valuable for developers. Other OSGi frameworks generally don't have this feature so you see tools like PAX Runner being forced to export the bundles before you can self-host.
One option you can do to make the build and launching experience easier, is use the concept of product definitions in PDE. Product definitions enable you to define a "product" which is really just a collection of bundles (or feature) with some configuration information. Personally, I have use product definitions to do RCP applications and web applications and it's worked great. The reason it works great is that product definitions are easily shareable amongst teammates and PDE Build can be fed a product definition to make the build process easier (which may not help you since you may use Maven).
We are in the process of closing out Galileo so a lot of people are disappearing for vacation now :)
We are also starting the planning process for the next release and this is on the list of things to consider. However, things would move quicker if people are willing to contribute to enable this particular workflow while still enabling easy self-hosting.
I hope this explanation helps a bit Don.
Cheers,
--
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource |
http://twitter.com/caniszczyk
