Despite what vendors would have you think, the lines between kinds of "containers" and even system services have become rather blurred. Most of the commercial "app" servers provide servlet containers and EJB containers but may have other sorts of containers and services. Services (all kinds of middleware) such a JMS providers can live outside of containers entirely (or be implemented in micro-containers. JMS may be implemented in non-Java messaging systems. And most commercial products provide some means control the classpath outside the EAR/WAR distributions.
Part of this may be the view that Fedora is a "product" to be deployed rather than a set of libraries to be built into a "product" by a third party. And the derived product is deployed into an execution environment. Supported by whoever built the derived product. If so, future refactorings of Fedora could keep this in mind --- to optimize to support build processes and largely drop the notion of a deployment (installer) altogether. The modularity has kind of been going in that direction for a while anyway. -- Dan Davis On 8/12/2011 10:37 AM, Aaron Birkland wrote: >> I'd like to suggest a different route, one already formally endorsed by >> Fedora. Moving the application to the OSGi framework will enable it to be >> deployed in almost any container (including many totally off the JEE specs), >> helped by the clean, stringent OSGi classloading architecture. It's an >> enormous amount of work to be done, certainly, but I'd suggest that it will >> be work of more lasting benefit than constructing in-project machinery to >> support multiple containers. > +1, for sure. > >> There might be some simple ways to help the community support itself without >> investing a lot of committer time in the effort. If one site has good >> schemes for this kind of deployment that aren't too onerous, that might be >> very helpful to start. > Right. In the link I posted yesterday, the jboss community seems to > have acknowledged that dependencies in wars that conflict with container > provided artifacts is a common problem, and there are some > configuration-based workarounds. I'm sure we could collect stories of > what works and what doesn't. > > -Aaron > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. > http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Fedora-commons-developers mailing list > Fedora-commons-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
