|Re: [orion-dev] Can Orion be less Eclipse|
On 2 Apr 2015, at 16:36, John Arthorne wrote:
Hi Gorkem,The layout of the Orion client is mainly an accident of history, becauseof how it was developed. The main Orion download we produce today is a Java EE application, and OSGi is very common in Java EE world. We use
Java backend has more than OSGi, it has eclipse extension points etc. For instance servlet and filter definitions as eclipse extensions on plugin.xml contributes to barriers for entry to OSGi/JavaEE developers
Jetty for the open source download, but within IBM there are products thatship Orion as a WAR file running on other servers such as Websphere.
I heard rumours about this one :) Is there any documentation on how to build Orion as .war? Would it make sense to make .war one of the build artifacts for the project?
You are right that there is absolutely no runtime benefit for the clientside pieces to be organized into OSGi bundles. It is essentially justbeing used as a development-time and build-time way to separate out theclient side pieces that are separately consumable. For example if you don't want Git you can carve out that piece and use the rest of theserver. I think we would be fine with reorganizing the client side and usea different source layout as long as we maintained separation of those concerns. I.e., if you were interested in working on reorganizing the client code that would be welcome!
I may give a shot at that, something in lines of npm modules perhaps? I would not like to disturb the current momentum either so I guess it is best to come out with a solid proposal to discuss before anything.
As for the Java server technology, I guess "standard" is a loaded term. Java Servlets and OSGi are standards as much as JAX-RS. The question iswhat problem are we solving by moving to a different Java server sidetechnology? Is the main concern about barrier to contributors, or is itabout consumability of the Java server on other Java EE application servers? Or maybe both?
Not much concern was expressed on deployment. Other than the missing pieces on node.js backend, which is an interesting option. I can say that this is mostly about barriers to entry.
John From: "Gorkem Ercan" <gorkem.ercan@xxxxxxxxx> To: "Orion developer discussions" <orion-dev@xxxxxxxxxxx> Date: 04/01/2015 01:27 PM Subject: [orion-dev] Can Orion be less Eclipse Sent by: orion-dev-bounces@xxxxxxxxxxx Hi, I have been interacting with a group of developers who are considering to adopt and contribute to Orion. While talking with them I started to realize the current structure of Orion is presenting an unnecessarybarrier for adoption for those who are not familiar with the Eclipse IDEdevelopment. For instance, the client part of Orion is organized as OSGi bundles. And these JS projects are built with maven/tycho which is not very familiar to JS developers. I am not aware of any benefit for using bundles for the client bits or organizing them as bundles. Is there a good reason for continuing to do so? IMHO the client parts of Orion should not have any Eclipseness in it and adopt more of node.js and grunt practices. The Java backend is also puzzling to even seasoned server side java developers. There are servlets but it is all mixed up into OSGi and moreover Eclipse plugin extensions. It can practically be only run/developed on Eclipse IDE. And I suspect that Jetty is a hard to replace part Orion Java backend. For me the lack of use of standards such as JAX-RS on the Java backend, is puzzling. I think the future development of the Java backend should be driven more towards Java server standards so that it is familiar to a larger audience. As an Eclipse developer, I do not recognize much of these (or similar ones I have omitted) but they do provide a barrier to newcomers. Thanks, -- Gorkem _______________________________________________ orion-dev mailing list orion-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribefrom this list, visit https://dev.eclipse.org/mailman/listinfo/orion-dev _______________________________________________ orion-dev mailing list orion-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top