-
Notifications
You must be signed in to change notification settings - Fork 15
Lyo 2.3.0 roadmap
WARN 2019-02-04: This roadmap is outdated.
This is a list of tasks that have not yet been incorporated into the rest of the document:
- Mavenizing lyo.tools (to enable P2 site builds as part of the Gerrit build).
- Obsolete OAuth library needs to be replaced (not supported any more, potentially unsafe). In the best case, it would be replaced with google-oauth-java-client or signpost.
- Making OAuth-enabled Lyo client as well as the JazzRootServicesHelper webapp oriented: they should allow for instance destruction and reinstantiation while the user is approving the access token (currently they throw an exception and expect a repeated method invocation of the method on a same class instance after the access token has been approved).
- Deploy to Maven central (some help from the Eclipse webmaster and GPG signing of the artifacts will be required: https://wiki.eclipse.org/Hudson/Maven)
- Migrate to Jena 3.
- Updating Lyo RIO (Reference Implementation for OSLC) for OSLC 3. To become an OASIS Standard, OSLC Core 3.0 needs three "statements of use" or implementations. Lyo could be one or more of these.
- Reorganise Lyo repositories (started with lyo.rio on GH, lyo-store extracted from lyo.tools as well as tools fully moved from lyo.core).
- 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.
- 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
- Replace Wink with Jersey – Andrew has a prototype working without Lyo Client and without the dynamic ShapesService getting registered properly. The prototype shows the migration from Jax-RS 1.1 to 2.0 as well as from Wink to Jersey. Dropwizard may be considered as an enhancement for the Jersey migration to make it closer to “production-ready”.
- We should consider creating a demo toolchain deployment for Kubernetes. Andrew has personal interest for that in his PhD project. Maybe Lyo can get some credits to run its demo on https://www.ibm.com/cloud-computing/bluemix/containers
- Merge the tests in the core into the same project (migrate external JUnit 3 tests to combined JUnit 4/5; JUnit 5 will be GA this autumn):
- org.eclipse.lyo.client.java has very limited automated tests. Additional manual testing can be done using the sample code
- org.eclipse.lyo.core.query has some unit tests, but they don’t appear to be comprehensive
- org.eclipse.lyo.trs has no unit tests
- org.eclipse.lyo.oslc4j.core has some tests, but they appear to be tests for specific issues, not a comprehensive test suite
- org.eclipse.lyo.oslc4j.provider.jena has a lot of tests
- org.eclipse.lyo.oslc4j.provider.json4j has some tests
- org.eclipse.lyo.core.utils has tests fro reading RDF/XML and Turtle
- org.eclipse.lyo.oslc4j.wink has no unit tests
- Generate an interactive Lyo client for each adaptor instead of the pale browsing UI.
- Interest from the Jad and Leonid sides for that
- Improve the docs
Comments from Jim 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. Andrew suggests to try MkDocs to replace both the website and the Wiki https://github.com/berezovskyi/lyo-docs Split the lyo repositories with the examples into multiple separate repositories and move them to Lyo Github (under EPL and with all the IP checks intact). I would love Jim and Jad to do this work mainly, in order to practice with the Eclipse Webmaster communication as well as Git/Github practice. The stress here is that we move the repos in one step and leave all dependency version updates and clean-up for later.
Jim’s points: Review refactoring proposal with eclipse/Lyo community and update as needed
TODO solicit feedback on this roadmap
- Review target environments and resolve any issues
- Continue using eclipse.org for OSLC4J SDK I agree, until you feel comfortable moving between Github and Gerrit, Jim & Jad.
- Use OSLC GitHub organization for samples and reference implementations
- Use OSLC GitHub Wiki and optionally GitHub Pages for documentation, organized by repository I suggest to keep the docs/ folder with markdown in the projects but use MkDocs for the site & docs.
- Use OSLC GitHub issues for change management A bit problematic for now, let’s use this Google Doc as a way to transition away from plain Bugzilla.
- Get approval from the eclipse.org Technology PMC to perform the refactoring and repository migration No need for that as long as we keep the same level of IP check (Type B full legal check).
- Create the GitHub repositories according to the adopted refactoring plan TODO Jim/Jad (Jim or me can +1 for the Eclipse Webmaster).
- Clone the eclipse.org Git repositories that are to be migrated to GitHub - history is retained at eclipse.org We can just ask Eclipse Webmaster to move them, no need to keep them on Eclipse - they remain under the same level of protection on Eclipse org on GH.
- Build and test each repository’s components in order to reach a known, stable state HAHA, good luck with that. This is not that easy to perform cross-repo build & test.
- Migrate eclipse/Lyo documentation to GitHub and GitHub Pages. Actually, I like the idea of moving the repo to Github but not
New contributions (NEW):
- (Andrew/Frederic) New Twitter Bootstrap based templates in the generated adaptors
- (Jad) External class libraries in the generated toolchain
- (Yash) Shape validation library based on SHACL definitions
- (Daniel) Shape validation extension for the Lyo toolchain designer
- (Jad/Frederic/Jim) Link preview in the generated adaptors
- (Andrew/Jad) Maven build config for the Lyo Toolchain Designer
- (Andrew/Omar/Eclipse IP) TRS provider
- (Andrew/Thomas/Eclipse IP) TRS consumer
Reorganisation & refactoring (REF):
- (Andrew & everyone else) A new combined site & wiki on MkDocs.
- (Jim & Jad?) Split the sample code & examples into multiple repositories on Github
- (Jim?) Move the client/server code back into core for simpler process?
Bug fixes (BUG):
New Twitter Bootstrap based templates in the generated adaptors
Responsible: Andrew
Status:
- Patch change requested
- Awaiting CQ
New Twitter bootstrap based template allow to easily structure information in the adaptor and allow using Bootstrap component library, esp. JS controls.
We need to slightly adjust the code in order to use jQuery version as declared in CQ (wrong JS file uploaded) as well as await the CQ decision on the original patch from Frederic.
Responsible: Jad
Status:
- End of patch review
- Await 2.2.0 release to commit directly to the master branch
Allows to generate Java classes for the domain spec resources into a separate folder/package for the whole toolchain. This allows writing libraries for those resources that can be reused across the toolchain.
Responsible: Andrew, Jad/Jim
Status:
- Await CQ for the newly added code
- Jad & Jim to review the refactored interface
Responsible: Jad