| In 2016, Eclipse Scout will become a Java framework. [message #1633407] |
Tue, 24 February 2015 16:22  |
Eclipse User |
|
|
|
Currently, Eclipse Scout applications are based on OSGi and the Eclipse runtime platform. In the past, we have addressed the challenge to integrate a plugin based application with Java EE technologies again and again. And according to some Scout customers, integrating the plugin based Scout server with Spring technology did cost them significantly more time than anticipated.
Observing the market and the need of our customers over the past years, we have come to the conclusion that Scout's dependencies to the OSGi/Eclipse platform did bring more harm than good to Scout projects. This is why we decided to remove these dependencies with the Scout 2016 release.
With this change, Eclipse Scout applications will become standard Java applications that will seamlessly integrate with Java EE technologies and other Java frameworks, such as Spring. We also hope that this change will increase the adoption of Eclipse Scout in the Java domain.
As this is a major change we are starting to talk about this topic early and did also announce it a corresponding blog post.
The purpose of this forum post is to collect public feedback on this change. Please feel free to ask questions or talk about your concerns.
[Updated on: Thu, 03 September 2015 06:10] by Moderator |
|
|
|
|
|
| Re: In 2016, Eclipse Scout will become a Java framework. [message #1641115 is a reply to message #1637681] |
Sat, 28 February 2015 07:04  |
| Eclipse User |
|
|
|
Thanks a lot for your input on that. In my answer below, I would like to focus on jobs and services as these cover the core topics of the changes.
For jobs, we will be based on the lightweight Java Executor framework, meaning that Runnables or Callables are scheduled on behalf of an Executor. Thereby, we extend the Executor in a way to fit our needs, like running in the proper client or server context, registering executing server jobs as transaction members, offer functionality to put model jobs, which by definition are executed in sequence, into wait state without preventing other model jobs from running and so on.
OSGi services we will replace with beans registered in a BeanManager in the terms of CDI. Out of the box, we will profit from dependency injection and interception, and most important, we comply with the J2EE specification to run in a container and interact with other application's beans.
|
|
|
|
|
|
| Re: In 2016, Eclipse Scout will become a Java framework. [message #1665652 is a reply to message #1665532] |
Wed, 11 March 2015 06:26 |
| Eclipse User |
|
|
|
Karaf could work. I wonder if someone ever tried to deploy a scout server app to Karaf. I know that some experiments were made with Eclipse Virgo (I am not sure if they were successful or if the project was aborted before they even deploy anything).
From our observations, it is rarely the case that the developer team can choose where and how the application should be deployed. In lot of cases this is defined by the operation team and you should deploy to an application server type they already managed.
If I understand you well, you are describing a scenario where an exe containing a Jetty is deployed to a server and executed. I do not think that a lot of operation team will accept this setup.
As Matthias wrote it to Boy D'Poy, the new Scout JARs should be able to start in an OSGi environment; it will be up to you to decide if you want to continue to use OSGi or not.
|
|
|
Powered by
FUDForum. Page generated in 0.04239 seconds
Home
as since my den where I build my Scout apps up, I perfectly feel perfect with the OSGi (Tycho/Maven ....) environment you plan to transfer to a the JEE one.
)