Client shall allow Jena models to be POSTed to the OSLC Server endpoints.

javax.servlet-api should generally be provided by a container service but in this case the app runs stand-alone.

if the scope is set to runtime, the java.lang.NoClassDefFoundError: Ljavax/servlet/http/HttpServletRequest exception is thown.

https://stackoverflow.com/a/25924310/464590 says that this behaviour is a MAY for a JAX-RS implementation and this bit seems to differ for Wink and Jersey.

This will test if OslcClient apps can use OpenIDConnect.

I have a need to return an object of a certain class (the one that corresponds to the resource attached to a given capability). However, I need to inline a bunch of other resources in a response. This is a legit use case for OSLC requests, as shapes explicitly allow non-local resources to be inlined.

The solution I am currently using is a pair of custom classes that are then transformed into a simple Object[] (see eclipse/lyo.core#21; blocked by eclipse/lyo.core#22). I believe Lyo Core can do the transformation behind the scenes. Also, I cannot solve eclipse/lyo.core#30 myself but if the transformation happens in the JMH, it can keep a mapping between the System.identityHashCode(Object) and the org.apache.jena.graph.BlankNodeId (I had to stop using RDF BNodes / OSLC LocalResources completely as a workaround).

The classes I use right now (warning, Kotlin ahead):

data class InstanceWithResources<T : IResource>(val instance: T,
                                                val resources: Collection<IResource>)

data class InstanceMultiWithResources<T : IResource>(val instance: Collection<T>,
                                                val resources: Collection<IResource>)

Please comment on the proposal and I will switch the Status to PR Welcome or Abandoned (and remove you from assignees).

This is the new dependency name after Java EE was transferred to Eclipse.

Partly caused by Jena < 3.9 (see JENA-1537).

Blocked by eclipse/lyo.core#58

See eclipse/lyo.core#64 (comment) for the proposal & relevant background.

Covered by org.eclipse.lyo.oslc4j.provider.jena.JenaModelHelper#unmarshal and org.eclipse.lyo.oslc4j.provider.jena.JenaModelHelper#unmarshalSingle

The new version passes the SHACL test suite (the core part w/o the SPARQL extensions).

Plus, Ricardo has encountered some issue with may have manifested in the older versions of shaclex: weso/shaclex#118

Most vendors have a custom full-text search (FTS) implementation and SPARQL filters. Eg:

• http://docs.openlinksw.com/virtuoso/rdfsparqlrulefulltext/ (bif:contains)
• https://jena.apache.org/documentation/query/text-query.html (text:query)
• https://docs.marklogic.com/guide/semantics/semantic-searches#id_46386 (cts:contains)

We need to allow these features to be used independent of the rest of the Store features.

Lyo allows resources to the serialised as blank nodes if null URI is passed the ctor. There might be a need to link to the still. Turtle and other formats allow to reference blank nodes by their IDs:

However, there is no way to create a Link to a resource instance w/o an about URI that would later be resolved to a blank node reference at the marshalling stage by the JMH. Here is the expected behaviour:

_:f10d8ddad853 a :clear;
      :prop "value" .

:res1 a :resource;
  :clear _:f10d8ddad853 .

Here is the actual behaviour:

[ a :clear;
    :prop "value" ] .

:res1 a :resource .

If the overloaded version of ServiceProviderFactory.createServiceProvider w/o path params is called, it will cause java.lang.IllegalArgumentException: The values variable is missing. Verify that null is not being passed in in org.apache.wink.common.internal.UriBuilderImpl.buildFromMap(UriBuilderImpl.java:407).

Passing new HashMap<>() at the end solves the problem.

It simply proceeds to attempt to consume the text/html entity response body for the authentication failure as RDF/XML which produces an inappropriate and unfriendly error message that doesn't mention authentication failure.

[INFO] +- org.eclipse.lyo.oslc4j.core:oslc4j-wink:jar:4.0.0-SNAPSHOT:compile
[INFO] |  +- org.apache.wink:wink:pom:1.2.1-incubating:compile
[INFO] |  +- org.apache.wink:wink-json4j:jar:1.2.1-incubating:compile
[INFO] |  +- org.apache.wink:wink-json4j-provider:jar:1.2.1-incubating:compile
[INFO] |  |  \- org.apache.wink:wink-common:jar:1.2.1-incubating:compile
[INFO] |  |     \- org.apache.geronimo.specs:geronimo-annotation_1.1_spec:jar:1.0:compile
[INFO] |  +- org.apache.wink:wink-client:jar:1.2.1-incubating:compile
[INFO] |  |  +- javax.xml.bind:jaxb-api:jar:2.2:compile
[INFO] |  |  |  \- javax.xml.stream:stax-api:jar:1.0-2:compile
[INFO] |  |  \- javax.activation:activation:jar:1.1:compile
[INFO] |  +- org.apache.wink:wink-server:jar:1.2.1-incubating:compile
[INFO] |  +- stax:stax-api:jar:1.0.1:compile
[INFO] |  \- com.sun.xml.bind:jaxb-impl:jar:2.2:compile

Workaround: use an exclusion as shown below.

    <dependency>
      <groupId>org.eclipse.lyo.oslc4j.core</groupId>
      <artifactId>oslc4j-wink</artifactId>
      <version>${version.lyo}</version>
      <exclusions>
        <exclusion>
          <groupId>stax</groupId>
          <artifactId>stax-api</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

Lyo is responsible for filing CQs for all transitive dependencies. We can do that though Maven dependency lists but it is not feasible to cross-check all 200+ dependencies with the IPZilla page. The approach I suggest is to put the dependency lists (see this wiki page for info how to make one) for each Lyo version in this repo and then we can always generate a new list and diff against it to see what dependencies were added and checked if they require a CQ.

NB! We need to keep Type A and Type B lists separate.

If you use something similar to eclipse/lyo.core#83 on the server, the client gets a Jena model (at least until @neormx's patch eclipse/lyo.core#29 is merged and we allow unmarshalling a collection of any IResource's). Once a resource is unmarshalled through JMH, user is faced with a Link to another resource which has to be located in the Model and unmarshalled again.

Here are two helper methods I wrote to help with this:

    // TODO Andrew@2018-02-23: create a stateful JMH that would keep resources hashed by URI
    private static <R extends IResource> R nav(final Model m, final Link l,
            final Class<R> rClass) {
        final R[] rs = JMH.unmarshal(m, rClass);
        for (R r : rs) {
            if(l.getValue().equals(r.getAbout())) {
                return r;
            }
        }
        throw new IllegalArgumentException("Link cannot be followed in this model");
    }

    @SafeVarargs
    public static IResource navTry(final Model m, final Link l,
            final Class<? extends IResource>... rClass) {
        for (Class<? extends IResource> aClass : rClass) {
            try {
                return nav(m, l, aClass);
            } catch (IllegalArgumentException e) {
                log.warn("Fix RDFS reasoning in JMH!!!"); // see https://github.com/eclipse/lyo.core/pull/29
            }
        }
        // give up
        throw new IllegalArgumentException("Link cannot be followed in this model");
    }

As you can see, a version without workarounds needs eclipse/lyo.core#29. Further, it might be possible to speed up repeated calls to JMH if it were to keep a hash table of all previously unmarshalled resources.

cc @neormx

https://stackoverflow.com/questions/7446599/how-to-deploy-only-the-sub-modules-using-maven-deploy

Nobody needs them in the TRS Client.

I was originally thinking to turn the cli into a webapp but later realised we can build and OSS OSLC platform around this. Question is what part of the Jazz arch would need to be reimplemented to make this interesting in a way similar to Hadoop (see sl. 6).

This issue breaks out a chat discussion for the preferred Lyo communication channels. Here is a summary:

• We have the lyo-dev mailing list, we are moving to make it a dev-friendly list, not the place for users.
• I have added a bit of insult to the injury by asking the webmaster to create a lyo-users mailing list.
• We have announced OSLC community forum around the OSLCfest, which has a Lyo forum under it.
• Finally, we still have the Lyo forum under Eclipse Forums.

Proposal is to:

1. Ask the webmaster to close down the lyo-users list due to a lack of activity.
2. Post a big announcement on the Lyo forum under Eclipse about the move to open-services.net

Support for OAuth 1.0a can be obtained using the old oslc-java-client, OslcOAuthClient, and demonstrated using DoorsOauthSample (which accesses the DOORS Web Access OSLC server).

oslc4j-client will provide OpenIDConnect support as recommended by OSLC Core 3.0.

This class overlaps in functionality with the providers and throws a web exception.

If we don't want to break compat, we should move it into 'legacy' module that users can add w/o breaking code.

Useful links:

• Lyo 2.4 epic
• Lyo 4.0 roadmap

@jadelkhoury Frederic wanted to rename it and was not sure it fits well into Lyo Store. Your take?

eclipse/lyo.core#37 was IDE-generated and resolving merge conflicts it's not worth my time.

This is a placeholder issue to redo it in the future.

This will bring parity with the remote SPARQL backend (good for testing w/o a running server) and will allow us to deprecate & remove the TDB backend.

See:

• https://github.com/eclipse/lyo.store/pull/51/files#r256316939
• https://github.com/eclipse/lyo.store/issues/16
• https://github.com/eclipse/lyo.store/issues/7

https://jena.apache.org/documentation/rdfconnection/

They cause something like EricssonResearch/scott-eu#91

Setting registryURI while starting up registry seems a bit recursive

Let's use this issue to discuss what should be included in the release and track its completion.

The primary elements for consideration in Release 2.4.0 may include:

Migrate build and release process to use the new GitHub repositories

Upgrade to Sirius 5

This includes various improvements of Lyo Designer that Yash has been waiting on Sirius 5 to introduce. e.g., delete a resource in a specification diagram, popups a dialog requesting if you want to delete from diagram or delete from model.

This is complete and included in 2.4.0-SNAPSHOT

Enable embedding Lyo Core as an eclipse plugin

This involves creating a ‘lyo-core-bundle’, which will be an OSGi bundle built with Apache Felix Maven Bundle Plugin (BND) plus will have all of its dependencies vendored via the Embed-Transitive instruction of the BND plugin.

This is complete and included in 2.4.0-SNAPSHOT

Export Domain Vocabularies to RDF

Allows exporting Lyo Designer Domain specifications as RDF vocabularies and/or OSLC ResourceShapes or SHACL. Import is not completed yet. This does not include the the ability to model SHACL shapes.

Ready for review and merge (was blocked waiting for lyo-core-bundle).

Lyo Validation

Validates RDF resources against constraints defined either as SHACL or OSLC Resource Shapes.

This is currently waiting for approval of two CQs:

• CQ 16618
• CQ 13908

CQ 13908 is for the shaclex library with includes over 80+ dependencies. Either this will take a long time, or we could consider distributing Lyo Validation with Type A due diligence in order to avoid holding up the release.

eclipse/Lyo, like any eclipse (sub) project can only deliver one thing under one due diligence type. So we can't deliver OSLC4J and Validation in the same project under two different due diligence types.

There are a few options for resolving this:

1. Remove Validation from release 2.4.0 (note that it was already, perhaps erroneously included in 2.3.0, which exposes OSLC4J 2.3.0 with Type A content - this could be a problem). This artefact is considered released and will be kept.
2. Hold up release 2.4.0 until CQ 13908 is approved for Type B Eclipse IP team does not give us a clear timeline. Also, we need to explicitly trigger this review!
3. ✅ Decouple Validation from eclipse/Lyo, refactor the packages and artifact ids to remove references to Lyo, and distribute outside of eclipse. @yashkhatri is assigned to eclipse/lyo.validation#24

My recommendation would be #1 unless there is some compelling business reason for including Validation in 2.4.0.

TRS Consumer and Provider Library

This provides a framework for building TRS Providers on an adapted data source. The TRS consumer is a sample consumer that provides a SPARQL endpoint on data provided by one or more TRS providers.

This is work in progress, some additional refactoring might need to be done. It was not released in 2.3.0, and has a dependency on Validation.

Recommend this not be included in 2.4.0, but is a candidate for 2.5.0. There is no reason to hold up the 2.4.0 release to complete this work.

Open issues to be resolved

There are issues currently open in eclipse/Bugzilla against 2.4.0.

New list of items to be included in 2.4.0:

• 🚧 Code generate (optional) swagger documentation by jadelkhoury · Pull Request #40 · eclipse/lyo.designer
• 🚧 Adding support for abstract types by neormx · Pull Request #29 · eclipse/lyo.core
• Downgrade the version · Issue #24 · eclipse/lyo.validation

Old list of items to be include in 2.4.0:

• 🚧 393073 – NPE in the hasNext method in class OslcQueryResult
• 🚧 528403 – Architecture Management Resource not compliant to OSLC AM 2.0
• 🚧 518808 – AllowedValues.getValues fails if there is only a single allowed value
• 🚧 Bundling the client as osgi bundle · Issue #6 · eclipse/lyo.client
• 534210 – Consumer Secret OAuth passwords saved in base64
• 531428 – RmUtil return Resource Shape where XSD:int(http://www.w3.org/2001/XMLSchema#int) is null.
• 518809 – Lyo fails with NPE in the presence of badly-formed OSLC property definitions
• 526202 – Allow Lyo libraries to be reused with Lyo OSGI
• 531949 – Support JSON-LD
• 529618 – Override all OslcClient#getResource(...) in OslcOAuthClient
• Revert Jena Libs Dependency Change in Pom · Issue #34 · eclipse/lyo.store

Legend

🚧 means a Pull Request has been submitted and the review/rework is pending.

Release notes

Draft on hackmd

We need to migrate any active Wiki pages from Eclipse wiki (https://wiki.eclipse.org/Lyo) to Github.

I see 2 alternatives: (@jamsden @berezovskyi I would like your opinion on this)

1. https://github.com/eclipse/lyo is only a launch point for related wikies. Wiki pages are managed udner the respective github repo of the Lyo project. (for example, Lyodesigner pages are under https://github.com/eclipse/lyo.designer/wiki)
2. We consolidate ALL wiki pages under https://github.com/eclipse/lyo. Under the respective github repo, we can have ONLY developer-related wiki pages. But end-user documentation for ALL our repositories are consolidated to https://github.com/eclipse/lyo

Irrespective, This are the initial action points:

1. Move this current front page (https://github.com/eclipse/lyo) to “repositories” or “working from source”.
2. Move the the content from https://wiki.eclipse.org/Lyo to this front page https://github.com/eclipse/lyo.
3. Move following pages from Eclipse-wiki to https://github.com/eclipse/lyo.core
   • https://wiki.eclipse.org/Lyo/General_Setup_for_OSLC4J_Development
   • https://wiki.eclipse.org/Lyo/creating_OSLC4J_project
4. Create a simple Client page under (here, or under https://github.com/eclipse/lyo.client?)

Discussed with @jadelkhoury sometime ago

Downsteam deps need to exclude 'commons-logging' in order to rely on SLF4j logging I/F.

When invoking OSLC4J Client with an array of resources, e.g.

client.createResource(twinInfo.cfUri, new Object[] {resA, resB}, 
     OslcMediaType.TEXT_TURTLE);

we get the following exception:

MessageBodyProviderNotFoundException: MessageBodyWriter not found for media type=text/turtle

Turtle support has been added a while ago to the Core (Bug 399761), so this should be a problem in the Client.

They create 300MB TDB and take 60s (per each run).

https://github.com/eclipse/lyo.testsuite/blob/master/org.eclipse.lyo.testsuite.trs/src/main/java/org/eclipse/lyo/testsuite/oslcv2/trs/TRSTest.java

Made the same mistake again. The first pushed branch becomes the default in Github