[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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,
because
of 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
that
ship 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
client
side pieces to be organized into OSGi bundles. It is essentially just
being used as a development-time and build-time way to separate out
the
client 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 the
server. I think we would be fine with reorganizing the client side and
use
a 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
is
what problem are we solving by moving to a different Java server side
technology? Is the main concern about barrier to contributors, or is
it
about 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 unnecessary
barrier for adoption for those who are not familiar with the Eclipse
IDE
development.
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev
