[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [lyo-dev] Open lyo.client resource classes PR
|
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 MemberOSLC and Linked Lifecycle
Data919-525-6575From:
Jad
El-Khoury <jad@xxxxxx>To:
Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>Date:
12/10/2018
05:30 PMSubject:
Re:
[lyo-dev] Open lyo.client resource classes PRSent
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