Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lyo-dev] Open lyo.client resource classes PR
So, do we have a decision on this? I will merge the PR tonight if you don't mind. Your suggestions seem reasonable, but would require more work and this patch will give users the flexibility they need in the short term.

--
/Andrew
On 11 Dec 2018, 14:53 +0100, Jim Amsden <jamsden@xxxxxxxxxx>, wrote:
Jad,
The old code predates OSLC4J and uses pure REST and is useful for users who just want to use REST or need a model for other languages.

Its not clear the same Java classes would be used for the client and server implementations.


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: 12/10/2018 05:30 PM
Subject: Re: [lyo-dev] Open lyo.client resource classes PR
Sent by: lyo-dev-bounces@xxxxxxxxxxx


I’m thinking of the classes that are under the RIO repository (Reference Implementation for OSLC)

https://github.com/eclipse/lyo.rio

If we want least coupling, we should really provide these classes without any connection to client, or server code.

I started the oslc-domains repo for that purpose, but it is not really that consistent with the specs yet.

https://github.com/eclipse/lyo.domains/tree/master/oslc-domains/src/main/java/org/eclipse/lyo/oslc/domains

Jim! There is even the "old" RIOs, which do not seem to leverage on OSLC4J. (See text at start of https://wiki.eclipse.org/Lyo/BuildRIO)

I have not looked at code, but I wonder how they implement it without OSLC4J.

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: 10 December 2018 14:48
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] Open lyo.client resource classes PR

I think these classes are provided for convenience for Lyo Java client users, to provide a simplified way of accessing standard OSLC domain data while not introducing a lot of coupling with other packages.

A better option would be to make these classes fully reflective instead of static. They could contain the parsed RDF triples, and support simple get/set accessor methods that are simple queries on the triples. Fixed methods like getTitle, getIdentifier, etc. could be created for common properties. These methods could be part of an OSLCResource class that could be all most Java client users need. Subclasses could provide more specific convenience methods, but these may not be needed.



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: 12/10/2018 05:17 AM
Subject: Re: [lyo-dev] Open lyo.client resource classes PR
Sent by: lyo-dev-bounces@xxxxxxxxxxx




Sounds very reasonable to me too.

If these classes are being used, I wonder if we should maintain them independent of the client code. I suspect there are similar classes in other repos of Lyo.

Jad

On 5 Dec 2018, at 15:19, Andrii Berezovskyi <andriib@xxxxxx> wrote:

Thanks Ricardo, I think this is completely reasonable. Provided no objections come from other Lyo contributors, I can merge your PR. Thank you for your contribution!

--
/Andrew

On 5 Dec 2018, at 14:29, Ricardo Javier Herrera Ledesma <neormx@xxxxxxxxx> wrote:

Good day lyo devs. I've created a PR for lyo.client project in order to remove final modifier from resource classes like ChangeRequest. Very often in industry, companies have custom properties to add in a ChangeRequest pojo, but this is not possible as these classes are final. We all know this is not a problema as we have the extendedProperties map; however managing such map and properties is tedious, why just don't remove final modifiers and let programmers add their own custom properties for a better handling and code looking?

Regards,
Ricardo.

--
I.S.C. Ricardo J. Herrera
SUN Certified JAVA Programmer (SCJP)
Oracle Certified Professional, Java SE 6 Programmer
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.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://www.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://www.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://www.eclipse.org/mailman/listinfo/lyo-dev


Back to the top