Skip to content
Permalink
Browse files

[Wiki] Update documentation for generator versioning options

  • Loading branch information...
Thomas Reuter authored and donsciarra committed Feb 1, 2019
1 parent 8effdbe commit 3d3168e7e5fc41a9259f2f585c2bf37f82aff3a2
@@ -112,10 +112,13 @@ public static String usageString() {
usageString.append(" -templatesEncoding <encoding of templates>\n");
usageString.append(" -generationId <name of what is being generated>\n");
usageString.append(" " + dumpVersionDefinition() + "\n");
usageString.append(" package: interface major versions (if existing) are added as an additional package \"v<version>\"\n");
usageString.append(" name: interface major versions (if existing) are appended to the interface name\n");
usageString.append(" none: interface versions don't affect the generated interface or package name\n");
usageString.append(" package: interface/typecollection major versions (if existing) are added as an additional package \"v<version>\"\n");
usageString.append(" name: interface/typecollection major versions (if existing) are appended to the interface/type name\n");
usageString.append(" none: interface/typecollection versions do not affect the generated name and package of interfaces and types\n");
usageString.append(" default: none\n");
usageString.append(" Note:\n");
usageString.append(" - Consumer and provider applications of one interface have to use the same versioning scheme to be able to communicate with each other.\n");
usageString.append(" - The feature has been fully tested to work in Java, in C++ and JS only the versioning of interfaces has been tested so far but the versioning of types is expected to work as well.\n");
usageString.append(" Optional, C++ only: \n");
usageString.append(" -outputHeaderPath <path to directory containing header files>\n");
usageString.append(" -includePrefix <prefix to use in include statements>\n");
@@ -20,8 +20,9 @@ the versioning scheme [here](JoynrVersioning.md).
* **[JS]** Fixed an issue where joynr.shutdown would not wait for clearSubscriptions before shutting
down.
* **[Java]** Eliminated declared but unneeded dependcies in some of the sub-projects. Also avoided
defining versions inside the dependencyManagement for transitive dependencies not being directly
used in joynr.
* **[Generator, Java]** The flag `addVersionTo` now also appends version information at file system
level to generated types. See [Generator Documentation](generator.md) for additional information.
The feature has been tested to work in Java, expected to work also in C++ and JS.

## Configuration property changes
None.
@@ -22,16 +22,30 @@ have to be provided in the Maven configuration:
<configuration>
<!-- provide the Franca model file(s) -->
<model><PATH_TO_MODEL_FILE_OR_DIRECTORY></model>
<!-- choose the generation language -->
<!-- choose the generation language
(see section "Choosing the generation language"):
either by specifying <generationLanguage>
or <rootGenerator> -->
<generationLanguage><GENERATION_LANGUAGE></generationLanguage>
<rootGenerator><FULL_NAME_OF_ROOT_GENERATOR></rootGenerator>
<!-- specify the output directory -->
<outputPath><PATH_TO_OUTPUT_DIRECTORY></outputPath>
<!-- optional parameters -->
<!-- specify how the major version shall affect the generated interface name and package:
package: interface major versions (if existing) are added as an additional package
name: interface major versions (if existing) are appended to the interface name
none (default): interface versions don't affect the generated interface or package name-->
<addVersionTo>name/package/none</addVersionTo>
<!-- specify how the major version of Franca interfaces and typecollections shall
affect the generated name and package of interfaces and types:
package: interface/typecollection major versions (if existing) are added as an
additional package segment
name: interface/typecollection major versions (if existing) are appended to the
interface/type name
none (default): interface/typecollection versions do not affect the generated
name and package of interfaces and types
NOTE:
- Consumer and provider applications of one interface have to use the same
versioning scheme to be able to communicate with each other!
- The feature has been fully tested to work in Java, in C++ and JS only the
versioning of interfaces has been tested so far but the versioning of types
is expected to work as well. -->
<addVersionTo>name|package|none</addVersionTo>
<parameter>
<!-- for Jee code generation use generation language "java"
and set the following parameter
@@ -52,8 +66,8 @@ have to be provided in the Maven configuration:
</execution>
</executions>
<dependencies>
<!-- For Javai/Jee code generation:
add the Java/Jee generator dependency -->
<!-- For Java/JEE code generation:
add the Java/JEE generator dependency -->
<dependency>
<groupId>io.joynr.tools.generator</groupId>
<artifactId>java-generator</artifactId>
@@ -76,14 +90,6 @@ have to be provided in the Maven configuration:
<version><JOYNR_VERSION></version>
</dependency>

<!-- For JEE code generation:
add the JEE generator dependency -->
<dependency>
<groupId>io.joynr.tools.generator</groupId>
<artifactId>java-generator</artifactId>
<version><JOYNR_VERSION></version>
</dependency>

<!-- optionally, use model files from a dependency artifact -->
<dependency>
<groupId><MODEL_GROUP_ID></groupId>
@@ -116,7 +122,8 @@ apply plugin: 'io.joynr.tools.generator.joynr-generator-gradle-plugin'
Note: The Joynr Generator Plugin has to be applied after the *Java* or *Kotlin* plugin,
as it attaches itself to the corresponding *clean* task.

The following parameters can be configured:
The following parameters can be configured (see section [Maven configuration](#maven-configuration)
for details):

* **modelPath**
* **outputPath**
@@ -152,12 +159,20 @@ gradle clean
```

## Choosing the generation language
The **&lt;GENERATION_LANGUAGE&gt;** can be either ```java```, ```cpp```, or ```javascript```.
The value **&lt;GENERATION_LANGUAGE&gt;** of the setting `generationLanguage` can be either
`java`, `cpp`, or `javascript`.

In each case, the corresponding dependency has to be added to the plugin's dependencies
section (see above):
* for ```java```: the artifact **io.joynr.tools.generator: java-generator**
* for ```cpp```: the artifact **io.joynr.tools.generator: cpp-generator**
* for ```javascript```: the artifact **io.joynr.tools.generator: js-generator**
* for **java**: the artifact `io.joynr.tools.generator: java-generator`
* for **cpp**: the artifact `io.joynr.tools.generator: cpp-generator`
* for **javascript**: the artifact `io.joynr.tools.generator: js-generator`

Alternatively, the generation language can also be chosen by the setting `rootGenerator`.
Possible values of **&lt;FULL_NAME_OF_ROOT_GENERATOR&gt;** are
* for **java**: `io.joynr.generator.JoynrJavaGenerator`,
* for **cpp**: `io.joynr.generator.cpp.JoynrCppGenerator`,
* for **javascript**: `io.joynr.generator.js.JoynrJSGenerator`


## Providing the Franca model files
@@ -210,10 +225,19 @@ to *gen*.
-templatesEncoding <encoding of templates>
-generationId <name of what is being generated>
-addVersionTo <name, package, none>
package: interface major versions (if existing) are added as an additional package
name: interface major versions (if existing) are appended to the interface name
none: interface versions don't affect the generated interface or package name
package: interface/typecollection major versions (if existing) are added as an additional
package segment
name: interface/typecollection major versions (if existing) are appended to the
interface/type name
none: interface/typecollection versions do not affect the generated name and package of
interfaces and types
default: none
NOTE:
- Consumer and provider applications of one interface have to use the same versioning
scheme to be able to communicate with each other!
- The feature has been fully tested to work in Java, in C++ and JS only the versioning
of interfaces has been tested so far but the versioning of types is expected to work
as well.
Optional, C++ only:
-outputHeaderPath <path to directory containing header files>
-includePrefix <prefix to use in include statements>

0 comments on commit 3d3168e

Please sign in to comment.
You can’t perform that action at this time.