Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo

["Jim Amsden" <jamsden@xxxxxxxxxx>]

Jad,
Thanks for the feedback. 

1. Maintaining common community 

Yes, we should do that. We already have
multiple mailing lists and bug tracking systems for OSLC if you include
OASIS OSLC Member Section and TCs, open-services.net and eclipse/Lyo. Most
of these all come together through community member subscriptions. So as
long as its easy to subscribe, and there is a central launching point like
open-services.net for people to get involved, different systems and processes
for maintaining different things shouldn't have a significant negative
impact on community collaboration.

Anyone can choose to host an OSLC project
of any sort on eclipse, and petition to have that project be part of eclipse/Lyo.
This would be appropriate for projects that desired to exploit the eclipse.org
governance process to manage their development work. But the process of
doing that, and managing the project in the context of eclipse.org is much
higher than creating a project on GitHub, and may not be necessary for
many OSLC projects.

Eclipse/Lyo uses Git controlled by eclipse.org,
not GitHub. None of the current components of eclipse/Lyo are on GitHub.

There are a number of OSLC projects
on GitHub already that are not part of eclipse/Lyo including:
1.1 OSLC GitHub organization - https://github.com/OSLC
1.2 OSLC4JS - http://oslc.github.io/developing-oslc-applications/oslc-open-source-node-projects.html
1.3 Id4mbse - https://github.com/ld4mbse
1.4 koneksys - https://github.com/koneksys


3. Adapter implementations

These are often done privately, i.e.,
not as open source. Those that are are consumers and implementers of the
OSLC4J SDK. Adapter development may exhibit enough variability that we
need to keep this open and flexible. 

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

4. Restructuring Documentation

Yes, this needs to be included too.
Again, we need to reduce the overhead of developing and maintaining documentation.
OSLC4J documentation is managed through  http://git.eclipse.org/c/www.eclipse.org/lyo.git/.
Other eclipse/Lyo documentation has already migrated to GitHub pages at
http://oslc.github.io/developing-oslc-applications/.
Individual projects might find the GitHub wiki an adequate place to put
documentation linked from the GitHub project readme file.

One issue with the eclipse/Lyo documentation
is that too many things are coupled together in the same documentation
set. Refactoring the documentation could help separate these concerns making
it easier to address key documentation update needs without getting bogged
down into lots of other things.

I think the action we need from the
eclipse/Lyo dev community is whether or not we want to do this refactoring
activity. And then we can look at the mechanics of how to do it, and the
details of what should be refactored where.




From:      
 Jad El-Khoury <jad@xxxxxx>
To:      
 Lyo project developer
discussions <lyo-dev@xxxxxxxxxxx>
Date:      
 02/07/2017 03:35 AM
Subject:    
   Re: [lyo-dev]
Strawman Proposal for Refactoring eclipse/Lyo
Sent by:    
   lyo-dev-bounces@xxxxxxxxxxx

---

Hi
Jim,
 
I like the proposal in
the large. Some of these components will certainly benefit from a lightweight
process if placed on GitHub. 
But it would be nice to
maintain a common community across both. (Common mailing lists, bug tracking(?),
etc.)
Do we even know who has
access to GitHub’s Lyo accounts today?
 
And, I just draw your
attention to another set of contributions we need to consider. Namely,
adaptor implementations that I don’t believe fall in the Samples nor Reference
Implementations categories. For example, we have the repositories org.eclipse.lyo.adapter.magicdraw.git
& org.eclipse.lyo.adapter.simulink
 
Besides structuring our
repositories, I would also be nice if we can also put some effort in improving
and structuring our documentation. I believe we currently have a number
of variants of the Bugzilla tutorial at the moment.
 
I have otherwise some
detailed comments, but I guess we can take that once we start executing.
 
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of
Technology
School of Industrial Engineering
and Management, Mechatronics Division
Brinellvägen 83, SE-100
44 Stockholm, Sweden
Phone: +46(0)8 790 6877
Mobile: +46(0)70 773 93 45
jad@xxxxxx,
www.kth.se
 
From: lyo-dev-bounces@xxxxxxxxxxx
[mailto:lyo-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Amsden
Sent: 03 February 2017 18:31
To: Lyo project developer discussions
Subject: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo
 
In order to improve the usability of eclipse/Lyo
contributions, and in particular OSLC4J as a means of developing OSLC client
and server applications, eclips/Lyo might benefit from some refactoring
to better separate concerns, different RIO implementation architectures,
client and server development, etc. It may also be useful to consider moving
some of the RIO and sample code to GitHub as these projects perhaps don't
need, or are not sufficiently benefiting from the eclipse.org governance
processes.

Attached is a draft proposal for this refactoring for consideration by
the eclipse/Lyo community.



Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev