The Java code generator defines certain defaults and naming logic that does not always work as expected. We should simplify it, and maybe even clean up the generator model in the regards.
For a simple statechart there are three files generated:
IStatemachine.java (Lib)
ISimpleStatemachine.java (API)
SimpleStatemachine.java (Impl)
Current behavior: package naming
Default
package name is [projectName] for Lib, and [projectName].[statechartName] for API and Impl
if project name contains invalid characters, e.g "-", there are compilation errors
Using Naming.basePackage
package name is [basePackage] for Lib, and [basePackage].[statechartName] for API and Impl
Using Naming.implementationSuffix
package name is [basePackage] for Lib, and [basePackage].[statechartName][implementationSuffix] for API and Impl
Please note that there is no dot between statechart name and the suffix in the package name which looks weird for me
the class name does not change
Using statechart namespace
does not have any effect on package name
Current behavior: file naming
General Interface: IStatemachine.java
Statechart specific interface: I[statechart.name.toFirstUpper]Statemachine.java
use the default (unnamed) package for API and Impl
This would avoid the problems we have when invalid characters are used in the project name
use yakindu namespace for Lib files, e.g. com.yakindu.scr (SCR for Statechart Runtime)
** Use explicit package naming features:
libraryPackage: package name for Lib files
apiPackage: package name for API files (analog to apiTargetFolder)
basePackage: package name for Impl files, and API files if no apiPackage defined
Using statechart namespace will add the namespace to the package name
package name is [packageName].[namespace] for API and Impl, but stays default for Lib
Using Naming.implementationSuffix
Remove this parameter and add typeName instead (see below)
Proposal: file naming
General Interface: IStatemachine.java
Statechart specific interface: I[statechart.name or typeName].java
Statechart implementation: [statechart.name or typeName].java
=> no implicit suffix, no implicit toFirstUpper
Also relevant when changing this, is to change the default statechart name in the new statechart wizard to Statechart.sct, as the current name default.sct is already a Java keyword and would generate invalid code now.
Together with these changes we can add the following generator model validation rules:
The statechart has no namespace, and no basePackage is defined => warning, generation into unnamed default package is discouraged in Java. With a hint how to change this.
The statechart name is lower cased and no typeName defined => warning, generation of lower cased types is discouraged in Java. With a hint how to change this.
The Java code generator defines certain defaults and naming logic that does not always work as expected. We should simplify it, and maybe even clean up the generator model in the regards.
For a simple statechart there are three files generated:
Current behavior: package naming
Default
Using Naming.basePackage
Using Naming.implementationSuffix
Using statechart namespace
Current behavior: file naming
Proposal: package naming (as discussed with ATE)
Default
** Use explicit package naming features:
Using statechart namespace will add the namespace to the package name
Using Naming.implementationSuffix
Proposal: file naming
Also relevant when changing this, is to change the default statechart name in the new statechart wizard to
Statechart.sct
, as the current namedefault.sct
is already a Java keyword and would generate invalid code now.Together with these changes we can add the following generator model validation rules: