[oslc] What's next for Eclipse/Lyo?

[Jim Amsden]

Happy New Year to the Eclipse/Lyo and open-services.net communities. As we 
start 2017, perhaps we should reflect on what's next for Eclipse/Lyo, 
especially given changes in the dev team, the OASIS OSLC Core 3.0 
specification, and integration in the marketplace. Certainly lifecycle 
collaboration tools have reached a level of maturity over the last few 
years, and OSLC 2.0 has played a central and largely successful role in 
enabling loosely coupled integration between lifecycle tools. Jad has made 
some great progress in the Lyo code generators to provide a simple means 
of designing and implementing tool chains supporting integrated OSLC 
domains.

Where we go next depends a lot on what you, the Lyo community needs. There 
is always a gap and tension between the demand and supply side views of 
any offering. But open-source is essentially demand driven.

So to better understand your needs, let's start an email discussion to 
better determine who's using Eclipse/Lyo, and what changes they'd like to 
see. I'll try to collate the results of the email into a Doodle poll to 
help us determine priorities. Then we can use this to guide planning this 
year.

To get things started, here's a few things we might consider doing.

1. Update Eclipse/Lyo dependencies - some of the dependencies are pretty 
old and might present a barrier to adopting Lyo in more up-to-date 
environments. I have made these changes on a local branch, but have not 
yet done the CQs in order to commit them and create an updated release

2. Update Eclipse/Lyo distribution packages - Lyo consists of a lot of Git 
repositories and eclipse projects. This makes it hard for someone to know 
what they should actually use to meet their needs. We might organize the 
eclipse projects into discrete packages that can be built and released 
independently and would be easier for users to understand and use.

3. Use Maven Central for Eclipse/Lyo distribution packages - Currently 
different releases of Eclipse/Lyo are distributed as Jar files accessed 
from eclipse.org. There is also a Maven repository at 
https://wiki.eclipse.org/Hudson/Maven. Lyo might benefit from being able 
to access the Lyo packages and versions through Maven Central.

4. Create a Lyo 3.0 version compatible with OASIS OSLC Core 3.0 - Its 
taken a lot longer to get the Core 3.0 specification completed and 
standardized. The OASIS OSLC Core TC is about to vote for Committee 
Specification which is the last step before OASIS Standard. This means 
that Core 3.0 has been through public review and is stable enough to 
implement. To become an OASIS Standard, OSLC Core 3.0 needs three 
"statements of use" or implementations. Lyo could be one or more of these. 
Since Core 3.0 is backward compatible with Core 2.0, this could be done by 
extending Lyo without breaking existing OSLC 2.0 clients (consumers) and 
servers (providers). 

5. Extend Lyo to support OSLC Configuration Management 1.0 specification - 
this would allow Lyo to support development of clients and servers that 
support configuration management.

6. Infrastructure Simplification - look at the use of Apache Wink and 
other technologies, and the extensive use of Java annotations and see if 
there are some runtime platform simplifications we could do to expand the 
applicability of OSLC and Lyo

7. Development of OSLC clients and servers in other environments such as 
JavaScript/Node, .Net, MacOS/Swift, etc. See OSLC4JS for example at 
http://oslc.github.io/developing-oslc-applications/oslc-open-source-node-projects.html





Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20170103/4c62d28c/attachment-0003.html>