|Enterprise Modules Project (Gemini) FAQ [message #499651]
||Mon, 23 November 2009 10:41
| Mike Keith
Registered: July 2009
· What is Gemini?|
Gemini is an open source project at Eclipse that is composed of a collection of subprojects, each of which is an implementation or integration of an enterprise-level technology running in a module-based environment. Most of the subprojects are the OSGi Reference Implementation of their respective technologies. The subprojects are suitable to be used by application developers or even by container-developers that may want to integrate them into a module-based Java EE container.
· Who is involved in Gemini?
The Gemini project was started by Oracle and SpringSource as a common place to share and continue working on implementations of standard technologies on modular frameworks. Additional partners, committers and community members are still coming forward to join or play supporting roles in the project. Others are welcome.
· Is Gemini a new container?
Gemini is not a container. The Gemini subprojects may run inside a container environment, though. Gemini is a collection of specification implementations that any developer or even a module-based container might use. The subprojects may be used separately or in some collective subset, but when used together there is no glue code or integration layer that would bind them together as a traditional container. They are independent components that may or may not leverage each other. There is no view of the whole.
· Is this an attempt to create a new application development platform that is different from Java EE?
No. The Java EE technologies are still the devloper-facing APIs that are used to create applications. The module system and OSGi are infrastructure, and Gemini is about showing how the Java EE APIs can work on that infrastructure.
· Why is this project at Eclipse?
The project committers wanted a structured, stable, open and developer-friendly venue to house and host a project of this magnitude. The Eclipse ecosystem was a natural choice. It has a reputation for quality, promotes inter-project cooperation, and has a proud and thriving user community. With Equinox, the OSGi R4.2 Reference Implementation, also at Eclipse, it made sense to join forces with the existing community there.
· Why is this project part of the Runtime (RT) project?
Gemini is a collection of runtime components, so making it a subproject of the RT project was the most logical place for it to be.
· Is this project targeted only at Equinox?
We do not intend for the project to be coupled to Equinox, or any specific OSGi framework. Equinox is part of the Eclipse community and a peer in the Runtime project. We expect there to be synergies and advantages to being project-mates and that we would be able to leverage that relationship whenever possible.
· Will there be any tooling for this project?
This is a runtime project composed of runtime components. No Gemini-specific tooling, either in this project or any other project, is currently planned for any of the Gemini subprojects. Existing Java EE support in the Web Tools Platform (WTP) and OSGi support in the Plugin Development Environment (PDE) should be used to develop applications.
· Doesn't EclipseLink already work in OSGi?
EclipseLink has worked in OSGi for a long time, but when the OSGi-enabling code was written there were no standards for running JPA or JAXB in OSGi. Much of what was done in EclipseLink has been proposed and adopted or incorporated into the OSGi enterprise standard. Now the standards are being reintegrated back into EclipseLink.
· Isn't Jetty already a web container in the RT project? Why do we need another one?
The web container integration subproject of Gemini is not a web container. It is the code that is needed for a web container to be able to run in OSGi. This code currently works with Tomcat, and will also be made to work with Jetty. We are eager and willing to partner with the Jetty project to make this happen.
· What can I use Gemini for?
The Gemini subprojects will be suitable for supporting applications written to the supported Java EE APIs, or enterprise-level usage of Java SE APIs. Any application written to run on the OSGi framework should be able to make use of Gemini.
· When can I pick up Gemini and use it?
Some of the subprojects will be ready to use as soon as the legal code contribution work is done and the project is provisioned. Others will be ready later, when some of the rough edges are made smooth.
· How is the project licensed?
Many of the subprojects were also the Reference Implementations in the OSGi Alliance. To meet the requirements of both the Eclipse Foundation and the OSGi Alliance, the source code for each of the subprojects will be dual-licensed under the Eclipse Public License (EPL) and the Apache license.
· What differentiates Gemini from other similar open source projects?
The Aries project was recently started at Apache and is developing implementations of some of the same OSGi specifications. The developers of the Reference Implementations in the Gemini project chose to work at Eclipse because of its natural affinity with and dependence on OSGi, its hosting of the OSGi Core Platform Reference Implementation (Equinox), as well as its strong community. Because the Gemini implementations within Eclipse will be available under both EPL and Apache licenses they can easily be used within the Apache community.
|Re: Enterprise Modules Project (Gemini) FAQ [message #551897 is a reply to message #499651]
||Tue, 10 August 2010 00:45
| Werner Keil
Registered: July 2009
Is there a XML subproject yet? Or would some of those (Apache) projects go |
under "Web" instead?
When getting parts of OHF out into UOMo we come across former OHF parts like
"org.apache.axis",... and most importantly "org.xmlpull.v1" (a rather widely
used XML Toolkit which also seems part of the Android Stack at Google now,
hope this won't disqualify it as "EE" for Oracle ?;-) which beside indirect
dependencies from Apache is used by UOMo XML.
I understand, one of Gemini's aims is to avoid such "artificial" plugin
projects like in Technology and many others, but offer Eclipse and/or Maven
a unified access to those.
See more under /cvsroot/technology/org.eclipse.ohf/plugins for those
interested. I know it's not the only example for that, and I almost bet,
Axis, Xerces or even XMLPULL may exist multiple times in Eclipse.org.
Powered by FUDForum
. Page generated in 0.02871 seconds