Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 47. Configuring the API Component Maven Plug-In
Abstract
This chapter provides a reference for all of the configuration options available on the API component Maven plug-in.
47.1. Overview of the Plug-In Configuration
Overview
The main purpose of the API component Maven plug-in, camel-api-component-maven-plugin, is to generate the API mapping classes, which implement the mapping between endpoint URIs and API method invocations. By editing the configuration of the API component Maven plug-in, you can customize various aspects of the API mapping.
Location of the generated code
The API mapping classes generated by the API component Maven plug-in are placed in the following location, by default:
ProjectName-component/target/generated-sources/camel-component
ProjectName-component/target/generated-sources/camel-componentPrerequisites
The main inputs to the API component Maven plug-in are the Java API classes and the Javadoc metadata. These are made available to the plug-in by declaring them as regular Maven dependencies (where the Javadoc Maven dependencies should be declared with provided scope).
Setting up the plug-in
The recommended way to set up the API component Maven plug-in is to generate starting point code using the API component archetype. This generates the default plug-in configuration in the ProjectName-component/pom.xml file, which you can then customize for your project. The main aspects of the plug-in set-up are, as follows:
- Maven dependencies must be declared for the requisite Java API and for the Javadoc metadata.
-
The plug-in’s base configuration is declared in the
pluginManagementscope (which also defines the version of the plug-in to use). - The plug-in instance itself is declared and configured.
-
The
build-helper-mavenplug-in is configured to pick up the generated sources from thetarget/generated-sources/camel-componentdirectory and include them in the Maven build.
Example base configuration
The following POM file extract shows the base configuration of the API component Maven plug-in, as defined in the Maven pluginManagement scope when the code has been generated using the API component archetype:
The configuration specified in the pluginManagement scope provides default settings for the plug-in. It does not actually create an instance of a plug-in, but its default settings will be used by any API component plug-in instance.
Base configuration
In addition to specifying the plug-in version (in the version element), the preceding base configuration specifies the following configuration properties:
scheme- The URI scheme for this API component.
componentName- The name of this API component (which is also used as a prefix for generated class names).
componentPackage-
Specifies the Java package containing the classes generated by the API component Maven archetype. This package is also exported by the default
maven-bundle-pluginconfiguration. Hence, if you want a class to be publicly visible, you should place it in this Java package. outPackage-
Specifies the Java package where the generated API mapping classes are placed (when they are generated by the API component Maven plug-in). By default, this has the value of the
componentNameproperty, with the addition of the.internalsuffix. This package is declared as private by the defaultmaven-bundle-pluginconfiguration. Hence, if you want a class to be private, you should place it in this Java package.
Example instance configuration
The following POM file extract shows a sample instance of the API component Maven plug-in, which is configured to generate an API mapping during the Maven build:
Basic mapping configuration
The plug-in is configured by the configuration element, which contains a single apis child element to configure the classes of the Java API. Each API class is configured by an api element, as follows:
apiNameThe API name is a short name for the API class and is used as the
endpoint-prefixpart of an endpoint URI.NoteIf the API consists of just a single Java class, you can leave the
apiNameelement empty, so that theendpoint-prefixbecomes redundant, and you can then specify the endpoint URI using the format shown in the section called “URI format for a single API class”.proxyClass- This element specifies the fully-qualified name of the API class.
fromJavadoc-
If the API class is accompanied by Javadoc metadata, you must indicate this by including the
fromJavadocelement and the Javadoc itself must also be specified in the Maven file, as aprovideddependency. fromSignatureFileIf the API class is accompanied by signature file metadata, you must indicate this by including the
fromSignatureFileelement, where the content of this element specifies the location of the signature file.NoteThe signature files do not get included in the final package built by Maven, because these files are needed only at build time, not at run time.
Customizing the API mapping
The following aspects of the API mapping can be customized by configuring the plug-in:
-
Method aliases — you can define additional names (aliases) for an API method using the
aliasesconfiguration element. For details, see Section 47.3, “Method Aliases”. -
Nullable options — you can use the
nullableOptionsconfiguration element to declare method arguments that default tonull. For details, see Section 47.4, “Nullable Options”. -
Argument name substitution — due to the way the API mapping is implemented, the arguments from all of the methods in a particular API class belong to the same namespace. If two arguments with the same name are declared to be of different type, this leads to a clash. To avoid such name clashes, you can use the
substitutionsconfiguration element to rename method arguments (as they would appear in a URI). For details, see Section 47.5, “Argument Name Substitution”. -
Excluding arguments — when it comes to mapping Java arguments to URI options, you might sometimes want to exclude certain arguments from the mapping. You can filter out unwanted arguments by specifying either the
excludeConfigNameselement or theexcludeConfigTypeselement. For details, see Section 47.6, “Excluded Arguments”. -
Extra options — sometimes you might want to define extra options, which are not part of the Java API. You can do this using the
extraOptionsconfiguration element.
Configuring Javadoc metadata
It is possible to filter the Javadoc metadata to ignore or explicitly include certain content. For details of how to do this, see Section 47.2, “Javadoc Options”.
Configuring signature file metadata
In cases where no Javadoc is available, you can resort to signature files to supply the needed mapping metadata. The fromSignatureFile is used to specify the location of the corresponding signature file. It has no special options.
47.2. Javadoc Options
Overview
If the metadata for your Java API is provided by Javadoc, it is generally sufficient to specify the fromJavadoc element with no options. But in cases where you do not want to include the entire Java API in your API mapping, you can filter the Javadoc metadata to customize the content. In other words, because the API component Maven plug-in generates the API mapping by iterating over the Javadoc metadata, it is possible to customize the scope of the generated API mapping by filtering out unwanted parts of the Javadoc metadata.
Syntax
The fromJavadoc element can be configured with optional child elements, as follows:
Scope
As shown in the following extract, the fromJavadoc element can optionally appear as a child of the apis element and/or as a child of api elements:
You can define the fromJavadoc element at the following scopes:
-
As a child of an
apielement — thefromJavadocoptions apply only to the API class specified by theapielement. -
As a child of the
apiselement — thefromJavadocoptions apply to all API classes by default, but can be overridden at theapilevel.
Options
The following options can be defined as child elements of fromJavadoc:
excludePackages-
Specifies a regular expression (
java.util.regexsyntax) for excluding Java packages from the API mapping model. All package names that match the regular expression are excluded; and all classes derived from the excluded classes are also ignored. Default value isjavax?\.lang.\*. excludeClasses-
Specifies a regular expression (
java.util.regexsyntax) for excluding API base classes from the API mapping. All class names that match the regular expression are excluded; and all classes derived from the excluded classes are also ignored. excludeMethods-
Specifies a regular expression (
java.util.regexsyntax) for excluding methods from the API mapping model. includeMethods-
Specifies a regular expression (
java.util.regexsyntax) for including methods from the API mapping model. includeStaticMethods-
If
true, static methods will also be included in the API mapping model. Default isfalse.
47.3. Method Aliases
Overview
Often it can be useful to define additional names (aliases) for a given method, in addition to the standard method name that appears in the Java API. A particularly common case is where you allow a property name (such as widget) to be used as an alias for an accessor method (such as getWidget or setWidget).
Syntax
The aliases element can be defined with one or more alias child elements, as follows:
Where MethodPattern is a regular expression (java.util.regex syntax) for matching method names from the Java API, and the pattern typically includes capturing groups. The Alias is the replacement expression (for use in a URI), which can use the text from the preceding capturing groups (for example, specified as $1, $2, or $3 for the text from the first, second, or third capturing group).
Scope
As shown in the following extract, the aliases element can optionally appear as a child of the apis element and/or as a child of api elements:
You can define the aliases element at the following scopes:
-
As a child of an
apielement — thealiasesmappings apply only to the API class specified by theapielement. -
As a child of the
apiselement — thealiasesmappings apply to all API classes by default, but can be overridden at theapilevel.
Example
The following example shows how to generate aliases for the common get/set bean method pattern:
With the preceding alias definition, you could use widget as an alias for either of the methods getWidget or setWidget. Note the use of a capturing group, (.+), to capture the latter part of the method name (for example, Widget).
47.4. Nullable Options
Overview
In some cases, it can make sense to let method arguments default to null. But this is not allowed by default. If you want to allow some of your method arguments from the Java API to take null values, you must declare this explicitly using the nullableOptions element.
Syntax
The nullableOptions element can be defined with one or more nullableOption child elements, as follows:
<nullableOptions> <nullableOption>ArgumentName</nullableOption> ... </nullableOptions>
<nullableOptions>
<nullableOption>ArgumentName</nullableOption>
...
</nullableOptions>
Where ArgumentName is the name of a method argument from the Java API.
Scope
As shown in the following extract, the nullableOptions element can optionally appear as a child of the apis element and/or as a child of api elements:
You can define the nullableOptions element at the following scopes:
-
As a child of an
apielement — thenullableOptionsmappings apply only to the API class specified by theapielement. -
As a child of the
apiselement — thenullableOptionsmappings apply to all API classes by default, but can be overridden at theapilevel.
Example
The following example shows the nullable options declared for the CompaniesResource proxy class from the Apache Camel LinkedIn component:
47.5. Argument Name Substitution
Overview
The API component framework requires that URI option names are unique within each proxy class (Java API class). This is not always the case for method argument names, however. For example, consider the following Java methods in an API class:
public void doSomething(int id, String name); public void doSomethingElse(int id, String name);
public void doSomething(int id, String name);
public void doSomethingElse(int id, String name);
When you build your Maven project, the camel-api-component-maven-plugin generates the configuration class, ProxyClassEndpointConfiguration, which contains getter and setter methods for all of the arguments in the ProxyClass class. For example, given the preceding methods, the plug-in would generate the following getter and setter methods in the configuration class:
public int getId(); public void setId(int id); public String getName(); public void setName(String name);
public int getId();
public void setId(int id);
public String getName();
public void setName(String name);
But what happens, if the id argument appears multiple times as different types, as in the following example:
public void doSomething(int id, String name); public void doSomethingElse(int id, String name); public String lookupByID(String id);
public void doSomething(int id, String name);
public void doSomethingElse(int id, String name);
public String lookupByID(String id);
In this case, the code generation would fail, because you cannot define a getId method that returns int and a getId method that returns String in the same scope. The solution to this problem is to use argument name substitution to customize the mapping of argument names to URI option names.
Syntax
The substitutions element can be defined with one or more substitution child elements, as follows:
Where the argType element and the replaceWithType element are optional and can be omitted.
Scope
As shown in the following extract, the substitutions element can optionally appear as a child of the apis element and/or as a child of api elements:
You can define the substitutions element at the following scopes:
-
As a child of an
apielement — thesubstitutionsapply only to the API class specified by theapielement. -
As a child of the
apiselement — thesubstitutionsapply to all API classes by default, but can be overridden at theapilevel.
Child elements
Each substitution element can be defined with the following child elements:
method-
Specifies a regular expression (
java.util.regexsyntax) to match a method name from the Java API. argName-
Specifies a regular expression (
java.util.regexsyntax) to match an argument name from the matched method, where the pattern typically includes capturing groups. argType-
(Optional) Specifies a regular expression (
java.util.regexsyntax) to match the type of the argument. If you set thereplaceWithTypeoption totrue, you would typically use capturing groups in this regular expression. replacement-
Given a particular match of the
methodpattern,argNamepattern, and (optionally)argTypepattern, thereplacementelement defines the substitute argument name (for use in a URI). The replacement text can be constructed using strings captured from theargNameregular expression pattern (using the syntax,$1,$2,$3to insert the first, second, or third capturing group, respectively). Alternatively, the replacement text can be constructed using strings captured from theargTyperegular expression pattern, if you set thereplaceWithTypeoption totrue. replaceWithType-
When
true, specifies that the replacement text is constructed using strings captured from theargTyperegular expression. Defaults tofalse.
Example
The following substitution example modifies every argument of java.lang.String type, by adding the suffix, Param to the argument name:
For example, given the following method signature:
public String greetUs(String name1, String name2);
public String greetUs(String name1, String name2);
The arguments of this method would be specified through the options, name1Param and name2Param, in the endpoint URI.
47.6. Excluded Arguments
Overview
Sometimes, you might need to exclude certain arguments, when it comes to mapping Java arguments to URI options. You can filter out unwanted arguments by specifying either the excludeConfigNames element or the excludeConfigTypes element in the camel-api-component-maven-plugin plug-in configuration.
Syntax
The excludeConfigNames element and the excludeConfigTypes element are specified as follows:
<excludeConfigNames>ArgumentNamePattern</excludeConfigNames> <excludeConfigTypes>TypeNamePattern</excludeConfigTypes>
<excludeConfigNames>ArgumentNamePattern</excludeConfigNames>
<excludeConfigTypes>TypeNamePattern</excludeConfigTypes>
Where ArgumentNamePattern and TypeNamePattern are regular expressions that match the argument name and the argument type, respectively.
Scope
As shown in the following extract, the excludeConfigNames element and the excludeConfigTypes element can optionally appear as children of the apis element and/or as children of api elements:
You can define the excludeConfigNames element and the excludeConfigTypes element at the following scopes:
-
As a child of an
apielement — the exclusions apply only to the API class specified by theapielement. -
As a child of the
apiselement — the exclusions apply to all API classes by default, but can be overridden at theapilevel.
Elements
The following elements can be used to exclude arguments from the API mapping (so that they are unavailable as URI options):
excludeConfigNames-
Specifies a regular expression (
java.util.regexsyntax) for excluding arguments, based on matching the argument name. excludeConfigTypes-
Specifies a regular expression (
java.util.regexsyntax) for excluding arguments, based on matching the argument type.
47.7. Extra Options
Overview
The extraOptions options are usually used to either compute or hide complex API parameters by providing simpler options instead. For example, the API method might take a POJO option, that could be provided more easily as parts of the POJO in the URI. The component could do this by adding the parts as extra options, and creating the POJO parameter internally. To complete the implementation of these extra options, you also need to override the interceptProperties method in the EndpointConsumer and/or EndpointProducer classes (see Section 46.4, “Programming Model”).
Syntax
The extraOptions element can be defined with one or more extraOption child elements, as follows:
Where TypeName is the fully-qualified type name of the extra option and OptionName is the name of the extra URI option.
Scope
As shown in the following extract, the extraOptions element can optionally appear as a child of the apis element and/or as a child of api elements:
You can define the extraOptions element at the following scopes:
-
As a child of an
apielement — theextraOptionsapply only to the API class specified by theapielement. -
As a child of the
apiselement — theextraOptionsapply to all API classes by default, but can be overridden at theapilevel.
Child elements
Each extraOptions element can be defined with the following child elements:
type- Specifies the fully-qualified type name of the extra option.
name- Specifies the option name, as it would appear in an endpoint URI.
Example
The following example defines an extra URI option, customOption, which is of java.util.list<String> type:
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}