Hi Jad,
We talked with Jim over Skype and I suggested him to construct Lyo-generated domain classes using Factory Method or Builder Class patterns, which are
Lyo-independent and allow the construction to span multiple domain classes etc.
I have two technical considerations regarding the “class library” vs “toolchain designer library” approach:
- If you are planning to alter the shapes of the domain resources, we are supposed to provide
the toolchain designer library or reconsider annotating the resources with the shape annotations, because the developers won’t be able to change domain resource class annotations easily once we ship them in a library.
- On the other hand, I was trying to develop a library for a particular domain resource to be
shared across the adaptors and was suffering a lot in the process. In that case, it was a real torture to pass the com.example.foo.Requirement or com.example.bar.Requirement to the library. In the end, we ended up generating a resource class and copying it
to the library (and passing that around, which is a lot of manual work). Note that the current generator uses different package names for the interfaces also, which makes them really useless for cross-application reuse.
To summarise:
- Library with the common full class name is needed for assisting library development.
- Toolchain designer library may allow full resource shape flexibility.
You can try to pick one but if you think a bit bigger, any large enterprise would like to have custom domain resources with a lot of library
code which would have to be shared across the toolchain. The only good way I can think of is to allow 1-1 mapping of the namespace to the Java package and generate each domain into a different project. That might seem like an overkill (an adaptor with 3 domains
will become 5 projects – modelling, webapp, and 3 domain resource libraries that will be included as POM dependencies in the webapp), but I think this is the best way for the whole toolchain.
-Andrew.
From: <lyo-dev-bounces@xxxxxxxxxxx> on behalf of Jad El-Khoury <jad@xxxxxx>
Reply-To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: Friday, 30 June 2017 at 17:21
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] How do you structure your Lyo projects?
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
