Jump to: navigation, search

Gemini/GeminiFAQ

< Gemini
Revision as of 09:19, 13 June 2011 by Michael.keith.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Gemini FAQ

  1. 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.

  2. 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 have since come forward to lead, join or play supporting roles in the project. For example, SAP now leads two of the subprojects and contributes on the others.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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. However, other OSGi frameworks, such as Felix, are used regularly by some Gemini consumers.

  8. 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.

  9. 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 in the form of the Gemini JPA project.

  10. 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.

  11. What is the relationship between Spring DM and Blueprint?

    The Spring DM project was migrated to become the Gemini Blueprint project. It was the initial Reference Implementation of the OSGi Blueprint specification and will continue to be developed as the next generation of Spring DM.

  12. 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.

  13. How can I use Gemini?

    Each of the subprojects can be downloaded separately from their respective download sites. Any one or more of the subprojects can be used in the same runtime.

  14. 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.

  15. What differentiates Gemini from other similar open source projects?

    The Aries project was 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 OSGi community. Because the Gemini implementations within Eclipse will be available under both EPL and Apache licenses they can easily be used within and by the Apache community.