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