Bugzilla – Full Text Bug Listing
| Summary: | Remove Sirius extension points in favor of declarative services | ||
|---|---|---|---|
| Product: | [Modeling] Sirius | Reporter: | Stephane Begaudeau <stephane.begaudeau> |
| Component: | Core | Assignee: | Project inbox <sirius.core-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cedric.brun, laurent.redor, pierre-charles.david |
| Version: | 1.0.0 | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Stephane Begaudeau
(In reply to Stephane Begaudeau from comment #0) > 4- The dependency to org.eclipse.sirius.common.acceleo.mtl seems useless. If > it's needed by some complex Viewpoint Specification project, they can add > this dependency by themself (and lose the compatibility with non-Eclipse > OSGi runtimes). I believe that this is used for those who want to use > Acceleo 3 modules in their Viewpoint Specification Project in order to have > all the dependencies in order to run their Acceleo modules. I think I will > submit a patch for this (for those who want to have a pure OSGi bundle). This dependency is there because Acceleo 3 is the default query language we recommend. It is not needed just for sophisticated cases with external .mtl file, but even simply to execute basic expressions defined in the VSM. Nodody in the Sirius runtime itself depends on org.eclipse.sirius.common.acceleo.mtl, so without that dependency a modeler's bundle which uses Acceleo could be installable but not work. It seems perfectly fine to me that a VSP which uses Acceleo expressions in its definition declares its dependency to the plug-in which handles Acceleo expressions in Sirius (well, it could be through an Import-Package...) > - Sirius Interpreters (org.eclipse.sirius.query) > Sirius interpreters should be registered thanks to declarative services and > they should implement/extend interfaces/classes that are not located in > bundles requiring Eclipse. The design for these is not very far yet. Yes, one of the goals is to make them as generic and reusable as possible, and that means no dependencies to Eclipse (except for the core of EMF, if you consider that part of Eclipse). They should also not depend on OSGi, i.e. be usable outside of an OSGi container. I don't know enough about DS, but do they bind the code to OSGi-specific types? (In reply to Pierre-Charles David from comment #1) > (In reply to Stephane Begaudeau from comment #0) > > 4- The dependency to org.eclipse.sirius.common.acceleo.mtl seems useless. If > > it's needed by some complex Viewpoint Specification project, they can add > > this dependency by themself (and lose the compatibility with non-Eclipse > > OSGi runtimes). I believe that this is used for those who want to use > > Acceleo 3 modules in their Viewpoint Specification Project in order to have > > all the dependencies in order to run their Acceleo modules. I think I will > > submit a patch for this (for those who want to have a pure OSGi bundle). > > This dependency is there because Acceleo 3 is the default query language we > recommend. It is not needed just for sophisticated cases with external .mtl > file, but even simply to execute basic expressions defined in the VSM. > > Nodody in the Sirius runtime itself depends on > org.eclipse.sirius.common.acceleo.mtl, so without that dependency a > modeler's bundle which uses Acceleo could be installable but not work. It > seems perfectly fine to me that a VSP which uses Acceleo expressions in its > definition declares its dependency to the plug-in which handles Acceleo > expressions in Sirius (well, it could be through an Import-Package...) There must be something that I am missing but if the bundle org.eclipse.sirius.common.acceleo.mtl provides a service for Sirius (thanks to its current extension point "org.eclipse.sirius.common.expressionInterpreter" or thanks to DS), then Sirius has an instance of the Acceleo interpreter (AcceleoMTLInterpreter). Then, when Sirius needs to execute the Acceleo expressions, it just has to delegate to the proper interpreter. > > - Sirius Interpreters (org.eclipse.sirius.query) > > Sirius interpreters should be registered thanks to declarative services and > > they should implement/extend interfaces/classes that are not located in > > bundles requiring Eclipse. > > The design for these is not very far yet. Yes, one of the goals is to make > them as generic and reusable as possible, and that means no dependencies to > Eclipse (except for the core of EMF, if you consider that part of Eclipse). > They should also not depend on OSGi, i.e. be usable outside of an OSGi > container. I don't know enough about DS, but do they bind the code to > OSGi-specific types? With DS, you will have "three" roles: - A bundle which provides (exported package) the interface/class that the services must implement/extends. For example org.eclipse.sirius.query.api. It's just a regular Java class/interface [1]. No OSGi dependencies needed. - A bundle which provides an instance of this service. The package does not need to be exported. No OSGi dependencies needed, only a dependency with the bundle containing the definition of the service. For example org.eclipse.sirius.query.mtl. This bundle provides the service [2] and a XML file to let OSGi discover the service [3] (à la plugin.xml). It also has an entry in its manifest in order to tell OSGi which XML file to look for {4]. - A bundle which uses OSGi code, a service tracker customizer, to discover the services [5]. This bundle only depends on the first one and an OSGi runtime. For example, org.eclipse.sirius.core. The service tracker customizer can be added in the activator [6] (this.serviceTracker.open() in start and this.serviceTracker.close() in stop). Sometime, the first and last roles are played by the same bundle but then the bundle providing the services have a dependency to a bundle (the third one) which tends to have more "business logic" (and thus more dependencies). With the architecture using three bundles, the first two bundles could be used in another OSGi runtime. We would just have to create a new service tracker customizer and that's it. 1: https://github.com/sbegaudeau/Ariadne/blob/master/connectors/core/fr.obeo.ariadne.ide.connector.core/src/fr/obeo/ariadne/ide/connector/core/explorer/AbstractAriadneExplorer.java 2: https://github.com/sbegaudeau/Ariadne/blob/master/connectors/ci/fr.obeo.ariadne.ide.connector.mylyn.build/src/fr/obeo/ariadne/ide/connector/mylyn/build/internal/explorer/MylynBuildExplorer.java 3: https://github.com/sbegaudeau/Ariadne/blob/master/connectors/ci/fr.obeo.ariadne.ide.connector.mylyn.build/OSGI-INF/component.xml 4: https://github.com/sbegaudeau/Ariadne/blob/master/connectors/ci/fr.obeo.ariadne.ide.connector.mylyn.build/META-INF/MANIFEST.MF#L22 5: https://github.com/sbegaudeau/Ariadne/blob/master/connectors/core/fr.obeo.ariadne.ide.connector.core/src/fr/obeo/ariadne/ide/connector/core/internal/explorer/AriadneExplorerServiceTrackerCustomizer.java 6: https://github.com/sbegaudeau/Ariadne/blob/master/connectors/core/fr.obeo.ariadne.ide.connector.core/src/fr/obeo/ariadne/ide/connector/core/internal/AriadneCorePlugin.java (In reply to Stephane Begaudeau from comment #2) > (In reply to Pierre-Charles David from comment #1) > > (In reply to Stephane Begaudeau from comment #0) > > > 4- The dependency to org.eclipse.sirius.common.acceleo.mtl seems useless. If > > > it's needed by some complex Viewpoint Specification project, they can add > > > this dependency by themself (and lose the compatibility with non-Eclipse > > > OSGi runtimes). I believe that this is used for those who want to use > > > Acceleo 3 modules in their Viewpoint Specification Project in order to have > > > all the dependencies in order to run their Acceleo modules. I think I will > > > submit a patch for this (for those who want to have a pure OSGi bundle). > > > > This dependency is there because Acceleo 3 is the default query language we > > recommend. It is not needed just for sophisticated cases with external .mtl > > file, but even simply to execute basic expressions defined in the VSM. > > > > Nodody in the Sirius runtime itself depends on > > org.eclipse.sirius.common.acceleo.mtl, so without that dependency a > > modeler's bundle which uses Acceleo could be installable but not work. It > > seems perfectly fine to me that a VSP which uses Acceleo expressions in its > > definition declares its dependency to the plug-in which handles Acceleo > > expressions in Sirius (well, it could be through an Import-Package...) > > There must be something that I am missing but if the bundle > org.eclipse.sirius.common.acceleo.mtl provides a service for Sirius (thanks > to its current extension point > "org.eclipse.sirius.common.expressionInterpreter" or thanks to DS), then > Sirius has an instance of the Acceleo interpreter (AcceleoMTLInterpreter). > Then, when Sirius needs to execute the Acceleo expressions, it just has to > delegate to the proper interpreter. > Just to give a bit more background on this specific point. That's indeed what the sirius runtime does, though not having this dependency explicit in the project containing the VSM leads to people installing this graphical environnement without the proper interpreter support if they did not install the Sirius features before (most people don't have Sirius when they install UML Designer for instance) as P2 can't infer this dependency. We used to have this problem which led us to add this dependency right away during the project creation. So, a VSM containing Acceleo3 expressions actually depends on the Acceleo3 interpreter, even if technically it can be compiled and distributed without it. In a perfect world, the MANIFEST.MF would reflect the actual usage into the VSM and would not have this dependency if the specifier did not use Acceleo 3 expressions. But right now, besides the feature: and java: interpreter Sirius does not provide any other, having this mechanic of updating the Manifest.MF sounds a bit overkill then... (In reply to Cedric Brun from comment #3) > (In reply to Stephane Begaudeau from comment #2) > > (In reply to Pierre-Charles David from comment #1) > > > (In reply to Stephane Begaudeau from comment #0) > > > > 4- The dependency to org.eclipse.sirius.common.acceleo.mtl seems useless. If > > > > it's needed by some complex Viewpoint Specification project, they can add > > > > this dependency by themself (and lose the compatibility with non-Eclipse > > > > OSGi runtimes). I believe that this is used for those who want to use > > > > Acceleo 3 modules in their Viewpoint Specification Project in order to have > > > > all the dependencies in order to run their Acceleo modules. I think I will > > > > submit a patch for this (for those who want to have a pure OSGi bundle). > > > > > > This dependency is there because Acceleo 3 is the default query language we > > > recommend. It is not needed just for sophisticated cases with external .mtl > > > file, but even simply to execute basic expressions defined in the VSM. > > > > > > Nodody in the Sirius runtime itself depends on > > > org.eclipse.sirius.common.acceleo.mtl, so without that dependency a > > > modeler's bundle which uses Acceleo could be installable but not work. It > > > seems perfectly fine to me that a VSP which uses Acceleo expressions in its > > > definition declares its dependency to the plug-in which handles Acceleo > > > expressions in Sirius (well, it could be through an Import-Package...) > > > > There must be something that I am missing but if the bundle > > org.eclipse.sirius.common.acceleo.mtl provides a service for Sirius (thanks > > to its current extension point > > "org.eclipse.sirius.common.expressionInterpreter" or thanks to DS), then > > Sirius has an instance of the Acceleo interpreter (AcceleoMTLInterpreter). > > Then, when Sirius needs to execute the Acceleo expressions, it just has to > > delegate to the proper interpreter. > > > > Just to give a bit more background on this specific point. That's indeed > what the sirius runtime does, though not having this dependency explicit in > the project containing the VSM leads to people installing this graphical > environnement without the proper interpreter support if they did not install > the Sirius features before (most people don't have Sirius when they install > UML Designer for instance) as P2 can't infer this dependency. > > We used to have this problem which led us to add this dependency right away > during the project creation. > > So, a VSM containing Acceleo3 expressions actually depends on the Acceleo3 > interpreter, even if technically it can be compiled and distributed without > it. In a perfect world, the MANIFEST.MF would reflect the actual usage into > the VSM and would not have this dependency if the specifier did not use > Acceleo 3 expressions. But right now, besides the feature: and java: > interpreter Sirius does not provide any other, having this mechanic of > updating the Manifest.MF sounds a bit overkill then... I was not thinking about telling people to just update the MANIFEST.MF by themself if they want to use Acceleo 3. What I had in mind was something like a checkbox in the Viewpoint Specification Project (checked by default to keep the current behavior) to choose between an "Acceleo 3 Viewpoint Specification Project" or a "Pure OSGi Viewpoint Specification Project" for the newly created project. If unchecked, it would not put the Acceleo nature on the project (!) and it would not create a dependency to anything related to Acceleo in the MANIFEST.MF. A few points of interest I'd like to see cleared: * does this have any impact on the "lazyness" of all the bundles which are extending Sirius ? * will bundles only providing declarative services will be started automatically when without runlevel tweaks ? * does this change the installation and provisioning story ? Does P2 provision required services or fails the installation if a required service is not here ? I don't think so. Should we only rely on features then ? (In reply to Cedric Brun from comment #5) > A few points of interest I'd like to see cleared: > * does this have any impact on the "lazyness" of all the bundles which are > extending Sirius ? > * will bundles only providing declarative services will be started > automatically when without runlevel tweaks ? > * does this change the installation and provisioning story ? Does P2 > provision required services or fails the installation if a required service > is not here ? I don't think so. Should we only rely on features then ? * You can still have lazy bundles with declarative services. When I start my Eclipse, all my bundles are just installed. When I use my menu or when I start my UI bundle, only my UI bundle and its dependencies are loaded and when I look for instances of my required services, I will trigger the loading of the bundles providing those services.[Screenshot 1, 2, 3 and 4]. In Ariadne, I look for my required services in the start method of the activator of my bundle but I could do it somewhere else. * The bundle providing declarative services can be activated when you are instanciating a new instance of the required service. In my Ariadne examples, the code can be used without any runlevel trick. [Screenshot 5] * P2 will not rely on the services but on the dependencies from the MANIFEST.MF. If Sirius requires some interpreters, it will have a dependency to the bundle containing the definition of the interpreters (import package org.eclipse.sirius.query;version="1.0.0" for example) this dependency will not force the installation of a bundle providing the service (like the Acceleo 3 interpreter). To have this behavior, features should be used. Right now, OSGi ship with the definition of Http Service (org.osgi.service.http.HttpService), but if you don't add a bundle providing this service like Jetty, if you try to find any service references for HttpService, you will just retrieve null. And if you add the Jetty bundles, they won't start until you are using them. 1: https://plus.google.com/u/0/photos/105625286543794908607/albums/5552047126204483729/5958758939198306802?pid=5958758939198306802&oid=105625286543794908607 2: https://plus.google.com/u/0/photos/105625286543794908607/albums/5552047126204483729/5958758942620873138?pid=5958758942620873138&oid=105625286543794908607 3: https://plus.google.com/u/0/photos/105625286543794908607/albums/5552047126204483729/5958758941336240882?pid=5958758941336240882&oid=105625286543794908607 4: https://plus.google.com/u/0/photos/105625286543794908607/albums/5552047126204483729/5958758952597655042?pid=5958758952597655042&oid=105625286543794908607 5: https://plus.google.com/u/0/photos/105625286543794908607/albums/5552047126204483729/5958758953269661074?pid=5958758953269661074&oid=105625286543794908607 |