[umlgen-dev] API from the generators

[Cédric Notot <cedric.notot@xxxxxxx>]

Hi,

For the creation of the new release 1.0.0, I suggest to specify each 
exported package as internal (x-internal:=true).

Indeed, today, the exposition of APIs from each generator is not clearly 
defined. So, just a simple modification on a Java class method (or 
template) would involve an API break and a rising to the next major 
version of the related plugin and feature (and even of the whole UML 
Generators project).
On my mind, in the most cases, generators will not provide API (by 
nature). If this is not so, the generator has to be designed and 
implemented with caution in order to be extended or/and reused.

Defining these packages as internal, this enables "client" developers to 
extend or reuse some generators BUT warning them this could be broken in 
a next version (even service kind). From the "provider" developer point 
of view, this enables flexibility, waiting that the project gains in 
maturity. This is a good mean to watch needs and use cases in order to 
define real architectures and APIs in the future.
Also, it is really easier to open APIs than to close them.

Let me know your opinion in relation to your generator.

Note about modeling aspects:
The changes on UML Generators profiles (or DSLs) should not involve API 
breaks (unless for DSLs if there is not a migration procedure). Same 
things for the UML meta-model evolutions. All these changes will be come 
with evolutions and adaptations of the generators for a next minor 
version. The use of old profiles will not give any guarantee on the 
result of the generated code (this will have to be managed on a case by 
case basis by the generator leaders, adopting an implementing 
strategy(*) and communicating on it) and the new models will not be back 
compatible.

(*) For example: Automatic model migration or use of Acceleo Java 
services managing different profile versions or just no management of 
old profiles/DSLs...

Best regards,
Cedric