Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo

Jim,

 

My guess is that some of these changes will require involvement of the Lyo Project Lead (currently Michael Fiedler, Samuel Padgett, Steve Speicher). You think we can get them involved to make things proceed smoothly? See https://projects.eclipse.org/projects/technology.lyo/who

 

Regarding documentation, note that https://wiki.eclipse.org/Lyo & http://git.eclipse.org/c/www.eclipse.org/lyo.git/ refer to 2 different content:

1. https://wiki.eclipse.org/Lyo is edited directly via the wiki pages.

2. Yet http://git.eclipse.org/c/www.eclipse.org/lyo.git/ reflects the Lyo page(s) under https://www.eclipse.org/lyo/  

 

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: 09 February 2017 15:15
To: Lyo project developer discussions
Subject: Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo

 

Jad,
Thanks for the feedback and the commitment to contribution.  

As you concluded, mirroring the eclipse Git repositories doesn't really help because the eclipse.org process still applies, and the refactoring would have to be done within that process. The mirrors would be read-only.

It is up to the adapter developer where they want to build and govern their adapter. Could be internal private, private or public GitHub, or eclipse.org, either in Lyo or some other eclipse project. I would entertain any adapter development as part of eclipse/Lyo, especially if that development included or required significant changes to OSLC4J, or contributed some reusable adapter framework that would benefit the OSLC community.

Regarding documentation, https://wiki.eclipse.org/Lyo, is the place http://git.eclipse.org/c/www.eclipse.org/lyo.git/is deployed. The problem with the eclipse wiki is the navigation sidebar is taken up by eclipse, Lyo doesn't seem to contribute to the sidebar. So there's no convenient TOC to help navigate the Lyo content.

GitHub wikies do allow creation of a custom sidebar. It might also be helpful to partition the documentation by the refactored repositories so that closely related information is in the same place.


Here's a rough draft action plan to effect this reorganization:

We should plan to do this refactoring after the OSLC4J 2.2.0 release so we are starting with updated dependencies and a solid basis for forking.

1. Review refactoring proposal with eclipse/Lyo community and update as needed
2. Review target environments and resolve any issues
    1. Continue using eclipse.org for OSLC4J SDK
    2. Use OSLC GitHub organization for samples and reference implementations
    3. Use OSLC GitHub Wiki and optionally GitHub Pages for documentation, organized by repository
    4. Use OSLC GitHub issues for change management
3. Get approval from the eclipse.org Technology PMC to perform the refactoring and repository migration
4. Create the GitHub repositories according to the adopted refactoring plan
5. Clone the eclipse.org Git repositories that are to be migrated to GitHub - history is retained at eclipse.org
6. Build and test each repository’s components in order to reach a known, stable state
7. Migrate eclipse/Lyo documentation to GitHub and GitHub Pages

Questions:
1. Where should OSLC4J documentation be deployed? Current documentation:
    1. Tutorial: Integrating products with OSLC - http://open-services.net/resources/tutorials/integrating-products-with-oslc/
    2. OSLC Developer Guide - http://oslc.github.io/developing-oslc-applications/
    3. Lyo Documentation - https://wiki.eclipse.org/Lyo
    4. OSLC4J SDK https://wiki.eclipse.org/Lyo/LyoOSLC4J

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




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





Hi Jim
(Congratulations on your Committer status!)
 
I jump to the last - but more important - question to re-highlight it to the community …
 
>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.

Yes, I plan to contribute to this activity, because I think it’s important to strengthen our OSLC community.
 
And for the details …
 
>Eclipse/Lyo uses Git controlled by eclipse.org, not GitHub. None of the current components of eclipse/Lyo are on GitHub.

I was thinking of the mirroring of the Eclipse repositories. For example, https://github.com/eclipse/lyo.core. Note thought that not all repositories are mirrored, so, we (at Lyo) ought to have somehow control over this.
But still, I assume this is controlled by eclipse.org governance process
 
>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.

So, should we not accept/promote adaptor implementations as part of Lyo?
As a general comment, I am glad to hear your thoughts about adapters requiring enough variability that they are not practically shareable. I share this view. Many people find this however problematic, since they would still expect tools to come with standard adaptor implementations.
 
>4. Restructuring Documentation
>OSLC4J documentation is managed through  
http://git.eclipse.org/c/www.eclipse.org/lyo.git/.
 
We also have the Eclipse wiki https://wiki.eclipse.org/Lyo, which I assumed was the main entry point.
I found it quite cumbersome to use Eclipse Wiki, and if we can move such information to a better platform, it would be great.
 
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:
07 February 2017 15:30
To:
Lyo project developer discussions
Subject:
Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo

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


Back to the top