Community
Participate
Working Groups
Do you think it's a good idea to keep the Lyo Modelling Tools and Lyo Core in version sync? Or it will be a pain for the releng?
There's two parts to that question - the generators and what they generate. If the generated results stand alone in most deployments then the generators and generated results can be versioned separately from OSLC4J. But if end users combine generated coded with hand crafted code, then it might be better to have at least the generated output release aligned with OSLC4J.
End users (as in developers) do need to add hand-crafted code to the generated code. But the generated code is so far not so dependent on the version of OSLC4J being used, so I am not sure why we need to tie the versions together. Also note that: * OSLC4J is a set of maven libraries, while the generators are Eclipse Plugins. * Currently the generator projects are distrivuted across Core & Tools repositories. but ultimately, we said we should put all generator code under Tools. This somehow tells me that we don't need to tie the versions of these 2 different things together. I believe this can also simplify our release process. "major releases" of the generator are not necessarily in synch with major releases of OSLC4J.
Refactoring the code generator into its own repository (not necessarily generic tools) is a good idea no matter what its relationship is to OSLC4J. What is the code generator's dependence on OSLC4J? Does it use the client and server SDK in the generated code? If so, then there would seem to be some at least potential version dependency. If not, why not and what are the implications for eclipse/Lyo and the OSLC4J SDK?
A summary from an email thread on lyo-dev@eclipse.org: Jad El-Khoury said: If we take the BugzillaAdaptor as an example (from the org.eclipse.lyo.docs repository), the generator produces all java classes and jsp pages for that projects. All, except for the actual code that communicates with Bugzilla (Calls using com.j2bugzilla.base. BugzillaConnector). That is, (a) the OSLC-Resource classes, extending AbstractResource, (b) the JAX-RS classes that handle the REST services, (b) the main OslcWinkApplication, etc. The generated code is completely reliant on OSLC4J libraries, and hence depends Wink as well. Jim Amsden said: Jad, that's exactly what I thought, thanks for the great summary. So although the code generator itself is an eclipse plugin and does not directly use OSLC4J or Wink in its implementation, the code it produces isn't an eclipse plugin, and does use OSLC4J and therefore Wink. So this at least produces an indirect version dependency between the code generator and OSLC4J/Wink through the code it generates. So it seems reasonable to consider version alignment between the code generator and OSLC4J. Jad Said: True. And, that’s because the generated project (BugzillaAdaptor again as an example) is directly dependent on Wink. We create a WinkApplication. But, if you consider other (big) changes to OSLC4J such as migrating from Jena2 to Jena3, which will require a change to the OSLC4J version. Such a change is not necessarily visible to the generator, and hence may not necessitate a change in the generator version.
I would suggest a Gedankenexperiment: say we update Lyo to use Jena 3 in Lyo 2.2.0. The generator will break, right? On the other hand, I would suggest asking if we can keep the versioning separate as it is not convenient to combine those releases. We can say Lyo Generator 1.5 supports Lyo Core 2.1.x. Not sure if this is the best idea.
The question then becomes how do we know if the code created by the generator is consistent with what version of OSLC4J? Keeping them versioned aligned would at least ensure a version of the generator is known to work with the same version of OSLC4J.
