Thanks Jim for your input.
The generated domain classes ought to have enough placeholders to allow you to insert custom code, that will not disappear upon subsequent generations. Does that
cover your current needs for custom code?
So, if I understand your case correctly, the custom code for a specific domain class is very specific for each adaptor, and hence should not belong to a common
library of resource classes.
Hence, there is no benefit for such an approach?
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: 30 June 2017 15:25
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] How do you structure your Lyo projects?
Jad,
One issue with creating reusable domain libraries is the custom user code that may be added to the domain classes. For example, in my implementation of an OSLC server for the the IBM Watson IoT Platform,
I have custom code in each of my domain classes that handles conversion to/from the IoT Platform JSON representation. Converting from JSON is done in a constructor (calling superclass converters) and toJson is an instance method. If these classes were adapted
to some other data sources, then this variability would need to be factored out.
The reason I took this approach is because the adaptor manager class tends to result in a lot of coupling across the domain classes. That's ok for simple domains, but doesn't seem to scale well.
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: 06/29/2017 06:47 PM
Subject: [lyo-dev] How do you structure your Lyo projects?
Sent by: lyo-dev-bounces@xxxxxxxxxxx
Hi,
I am interested in your (the community’s) opinion on the need to have java libraries that reflect the OSLC domain resources as Java classes.
In the current Lyo Modeller, one can model OSLC resources in the Domain Specification View (https://wiki.eclipse.org/Lyo/ToolchainModellingAndCodeGenerationWorkshop#Domain_Specification_View).
Using this model, the generator then produces the corresponding java classes for
each of the adaptors in the model. This means that the resources classes are duplicated in each of the adaptor projects.
Another alternative is to generate the resources’ java classes into a common library that each adaptor can then add as a dependency.
Would this feature be of interest? Any advantage/disadvantage of either approach?
It would be interesting to hear how people structure their projects, since I would like the generator to reflect such best practices.
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
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev
