| Re: [che-dev] Modular Che: OSGi + DS |
Hello, all!
We are playing with prototype, trying to simplify workspace agent and make it as friendly as possible with the rest of Eclipse plug-ins ecosystem. This is one of the most significant pain points with which we are faced today trying to launch Eclipse-based model-driven IDE into the clouds.
This simplification could be done by making workspace agent’s services almost like POJOs without any infrastructure dependencies like JAX-RS annotations, special interface implementations, platform class imports, etc.
As a result, workspace code has no dependencies from particular deployment environment and could work on desktop environment, as well as server and cloud one. So, new Eclipse bundles could be done as reusable and capable of working in different environments: desktop IDE and cloud IDE.
Moreover it could be a motivation to refractor Eclipse IDE core using OSGi DS and e4 in collaboration with RCP and e(fx)clipse guys.
We are playing for some time with prototype based on OSGi DS and Equinox. But for the sake of simplicity, I’m afraid, we have done some ugly things, some spooky things in the process:
- converted Guice to OSGi DS while preserved REST and WebSockets protocols compatibility with frontend;
- dropped Everrest in favor of Eclipse ECF + Jersey+Jackson + Jetty and removed all JaxRS annotations;
- in the process of converting DTOs to EMF codegeneration.
Is it too bad? Does anyone like it and feels the same except us and Sun Tan?
---
WBW,
Alexey Ivanov
Hi guys,Thanks for your input.Not sure we are ready to talk about moving somewhere from lightweight DI / Guice on platform level butif you are interested in supporting OSGI and want contributing here I'd suggest you trying something able to expose OSGI as a Guice extension for Che (useful for Workspace Agent obviously). Have not tried it but supposedly it should not be very difficult, something likeRegards,On Mon, May 30, 2016 at 12:48 PM, Sun Tan <sun.tan@xxxxxxxxx> wrote:Hi all, Hi AlexI really believe that all agents running inside the docker workspace should be serving by a headless Eclipse IDE exposing dynamic micro services (jetty on OSGi equinox)So yes i'm interested to evolve Che to that direction,WDYT ?Sun.Le lun. 23 mai 2016 à 18:57, Tyler Jewell <tyler@xxxxxxxxxxx> a écrit :Hi Alex:Thanks for your thoughts.Over the past many months, we have been working on strategies for better modularization. As a first step, we needed to remove a lot of libraries that were being deployed into each agent that were unnecessary. We have recently completed most of that work, and this subsequently makes the packages for what goes onto the agent and master much smaller. Additionally, the next step we are working towards is enabling each workspace to host a separate configuration of plugins / extensions. So it will be possible for each workspace in a single Che server to have a different set of extensions / plugins, whether they are server-side or client-side. This poses a variety of challenges around browser caching, especially when you have a single user bouncing between two workspaces with different configurations. We also have a good vision of decoupling a lot of our agent capabilities into micro services that can be deployed and run independently within a workspace runtime, further reducing the elements that need to be packaged into a single workspace agent.What company do you work for and what projects are you thinking about? The next Eclipse Che planning meeting is next Tuesday, May 31st at 7am pacific time. There is a public google hangout that anyone can join. Perhaps your team can join the call, learn a bit more about the current roadmap, and hear about various directions that can be taken?Tyler
Tyler Jewell | CEO | tyler@codenvy.com | 978.884.5355
_______________________________________________On Mon, May 23, 2016 at 8:30 AM, Alex Ivanov <amivanoff@xxxxxxxxx> wrote:Hello, folks!
First of all, big thank you, Che Team, for such a great work! At our company we are playing with deep Che customizations. It’s very interesting!
But it’s quickly become clear for us that WAR monolithic deployment troubles Che modules reusability in case of deep customizations.
Different modularity technologies in Eclipse RCP and Eclipse Che (OSGi vs WAR) limit Eclipse RCP/IDE/MDD bundles reusability inside Che environment.
On the other side, we’ve seen recent Liferay success in adopting OSGi and DS for huge monolithic WAR portal modularization.
So, my questions to the core developers and adopters:
- Do you have some long-term plans of adopting OSGi and DS to modularize monolithic WAR portal, to make Che even more flexible and reusable?
- Is someone here interested to evolve Che in this direction?
We have some initial prototypes of server-side Che modules as OSGi Declarative Services without any server-side dependencies on top of Equinox+Jetty+Jersey+ECF container. And we wonder if it’s interesting for someone?
---
WBW,
Alexey Ivanov
-----
С уважением,
Алексей Иванов
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
--
--Sun Seng David TAN
Senior Java Developer
Eclipse Che commiter
Mobile : +33 21 02 41 73
Email : sun.tan@xxxxxxxxx
Site Web : www.serli.com
Suivez-nous sur Twitter : @SerliFr @sunsengdavidtan et Facebook : SerliFr
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev