Community
Participate
Working Groups
There are many ideas on what to include in Lyo next. I think we should aim for the quickest 2.2.0 release and plan the 2.3.0 release after it. Possible improvements can be made in a few areas. Tech debt: * Jena 3 migration. Many new libraries rely on Jena 3 and they can't be used with Lyo that relies on Jena 2. * Wink migration. At least from 1.2.1-INCUBATION to its latest 1.4 release. We also need to consider keeping Wink alive (see its dev mailing list) or plan for Jersey/Dropwizard migration. * oauth library migration. Google abandoned their old oAuth library around 2010 and it can no longer be considered secure. New features: * Library for interacting with triplestores within OSLC adaptors. * New and more approachable materials for the beginners (NB: clean up lyo.{docs,server} sample code). Deployment and general updates: * cleanup of all projects (use of aggregator projects, proper use of dependencyManagement, new library versions, fix javadoc errors for build under JDK8 without suppressing them) * better deployment (automatic javadoc/site deployment, signing the artefacts, maven central release) * Common release cycle with Lyo Tools for Eclipse (generator and modelling tools) * Mavenise projects in lyo.tools repository using Eclipse Tycho. Please suggest your ideas for the 2.3.0 roadmap.
Other possibilities: * Improve resource shape decoding (@Nick Crossley would have more to say on this) * SSO and TLS support (IBM JTS code and abstract it for general use) * Support 1 or 2 major use case basic flows, e.g. a higher-level API that can authenticate, find the query service for a project, retrieve the desired work item, and modify it in a single transaction. Purpose is to make it easier for people to do some common task instead of making all the individual API calls. The specific use case(s) to implement are TBD. * Build system technical debt. Improving/understanding naming conventions, reconsider how JAR files should be distributed, remove unused build routines, document build system use/capabilities, etc.
re: "Support 1 or 2 major use case basic flows", would org.eclipse.lyo.client.java satisfy these requirements? It appears to be the a higher level API that does most of the listed items. This is part of OSLC4J, but doesn't get included in org.eclipse.lyo.oslc4j.build. The build/release process must do it separately as it is included in the distributed jar files.
(In reply to Jim Amsden from comment #2) > re: "Support 1 or 2 major use case basic flows", would > org.eclipse.lyo.client.java satisfy these requirements? It appears to be the > a higher level API that does most of the listed items. > > This is part of OSLC4J, but doesn't get included in > org.eclipse.lyo.oslc4j.build. The build/release process must do it > separately as it is included in the distributed jar files. We need to understand the supported use cases and the extent of the support. Ideally we can document these APIs better so they're more accessible. We may also want to review what would be useful in the OSLC world today and see if they should be improved, expanded, replaced, etc.
Packaging of a client-only library would be useful. For shape handling, it would be useful to have helpers to find creation factory shapes, and then from creation shapes or instance shapes for updates: * find the mandatory properties * find allowed property values for a given property name * find allowed values with given enumeration labels, or with given owl:sameAs values using the representations described at https://jazz.net/wiki/bin/view/LinkedData/BestPractices * etc.
Some commonly used classes are missing support in Lyo today. One example is foam:Person, used for many of the dcterms properties (creator, contributor, etc.). It would be fairly low cost to add these.
New Gerrit change created: https://git.eclipse.org/r/112268
Gerrit change https://git.eclipse.org/r/112268 was merged to [master]. Commit: http://git.eclipse.org/c/lyo/org.eclipse.lyo.tools.git/commit/?id=3e264abd893cbd514e4764d5b51b9ef47775d1dd
