Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Can Orion be less Eclipse

Hi Max / Gorkem,

With regards to your comments.

I have emailed separately instructions on building a WAR file for Orion. My steps create the WAR from Eclipse, because it is easy. We do not have a WAR file created by the Orion build, maybe we should add it.

This is a likely a loaded question but I will bite. We are an Eclipse project and we have a Java based server implementation. It is obvious that we would use the Eclipse IDE for development. This "forced use" of the Eclipse IDE for the Java server development is a barrier to your usage. Can you explain a little more why?


From:        "Max Rydahl Andersen" <manderse@xxxxxxxxxx>
To:        "Orion developer discussions" <orion-dev@xxxxxxxxxxx>
Date:        2015/04/09 03:53 AM
Subject:        Re: [orion-dev] Can Orion be less Eclipse
Sent by:        orion-dev-bounces@xxxxxxxxxxx

On 3 Apr 2015, at 23:46, Gorkem Ercan wrote:

> 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

I think its overstating it to say osgi is *very common* in Java EE world

> 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

Yeah, biggest blocker is that with the current setup only those using
Eclipse IDE
can actually develop and even run this easily.

>> 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?

+1, it would be nice to actually see this in action as opposed to just
keep hearing
about it being possible ;)

>> 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.

+1, the osgi, the forced needed usage of Eclipse IDE for development and
no real docs on how to build/reconfigure this is what keeps getting
to us as reasons they have not dived into Orion.

also orion-dev is awfully quiet :)

orion-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top