The generic type parameters of 'Map' are missing in Flink-CEP - maven

Code for detecting pattern in Flink-CEP is shown below
// Generate temperature warnings for each matched warning pattern
DataStream<TemperatureEvent> warnings = tempPatternStream.select(
(Map<String, MonitoringEvent> pattern) -> {
TemperatureEvent first = (TemperatureEvent) pattern.get("first");
return new TemperatureEvent(first.getRackID(), first.getTemperature()) ;
}
);
if build using command + F9 in Mac, following error is shown
Exception in thread "main" org.apache.flink.api.common.functions.InvalidTypesException: The generic type parameters of 'Map' are missing.
It seems that your compiler has not stored them into the .class file.
Currently, only the Eclipse JDT compiler preserves the type information necessary to use the lambdas feature type-safely.
See the documentation for more information about how to compile jobs containing lambda expressions.
at org.apache.flink.api.java.typeutils.TypeExtractor.validateLambdaGenericParameter(TypeExtractor.java:1316)
at org.apache.flink.api.java.typeutils.TypeExtractor.validateLambdaGenericParameters(TypeExtractor.java:1302)
at org.apache.flink.api.java.typeutils.TypeExtractor.getUnaryOperatorReturnType(TypeExtractor.java:346)
at org.apache.flink.cep.PatternStream.select(PatternStream.java:64)
at org.stsffap.cep.monitoring.CEPMonitoring.main(CEPMonitoring.java:85
However building usign mvn clean install and then running via Control + R shows output,
I am wondering why this is happening all the time ?
Is there any way around to do it?
PS : however I am using eclipse JDT Plugin , even then it is showing error in log . Contents of POM.XML are
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerId>jdt</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-compiler-jdt</artifactId>
<version>0.21.0</version>
</dependency>
</dependencies>
</plugin>
Suggestions are most welcome.Thanks in advance

I know that Java 8 Lambdas are very convenient. However, they provide almost no type information via reflection, which is why Flink has problems with generating the underlying serializers. In order to also run your Flink programs in the IDE, I would recommend to use Java anonymous classes instead of lambdas, whenever generic types are involved.

first, check your jdk version, is 1.8? and also upgrade the version of tycho-compiler-jdt to 1.0.0 your san refer below plugin :
<plugin>
<!-- Use compiler plugin with tycho as the adapter to the JDT compiler. -->
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
<compilerId>jdt</compilerId>
</configuration>
<dependencies>
<!-- This dependency provides the implementation of compiler "jdt": -->
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-compiler-jdt</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</plugin>
you can refer source : https://ci.apache.org/projects/flink/flink-docs-release-1.4/dev/java8.html
after this you have to do is to build the project on the cli using maven. Once the program has been built via maven, you can also run it from within IntelliJ.

Related

How to compile Spring Boot applications with Java 8 --parameter flag

Spring documentation tells that, if we compile our project using Java 8 --parameters flag, we can skip giving parameter names in annotations like #PathVariable. That means, we can just use #PathVariable id instead of #PathVariable("id") id.
In a Spring Boot Maven application, I was curious to know how to tell the compiler to use the parameters flag. Is it on by default? Do we need to provide something in the pom.xml?
In Spring Boot 2.0, the --parameters flag should be enabled by default. See yuranos87's answer.
For older versions, in the pom.xml file, you can specify Java compiler options as arguments of the Maven compiler plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
</plugin>
I don't remember needing to do it explicitly in any of my projects. Maybe you just need to add spring-boot-starter-parent(I know, sometimes might not be an option). Otherwise, Spring has already taken care of everything for you.
It is mentioned multiple times in Spring Boot documentation. For example, here:
To allow the input to be mapped to the operation method’s parameters, code implementing an endpoint should be compiled with -parameters. This will happen automatically if you are using Spring Boot’s Gradle plugin or if you are using Maven and spring-boot-starter-parent.
UPDATE
The way Spring Boot does it is quite straight forward(in spring-boot-parent and spring-boot-starter-parent poms):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<parameters>true</parameters>
</configuration>
</plugin>

documenting one or more classes out of a package with maven-javadoc-plugin

I only want to document two classes from a package. In standard javadoc tool, it would be something like:
C:> javadoc -d C:\home\html C:\home\src\java\awt\classA.java C:\home\src\java\awt\classB.java
How can I do it in maven-javadoc-plugin?
sourceFileIncludes should do what you're looking for.
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#sourceFileIncludes
Here's an example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<sourceFileIncludes>
<include>com/mycompany/myproject/MyClass.java</include>
</sourceFileIncludes>
</configuration>
</plugin>
UPDATE:
I tried this out on one of my maven projects and it worked at the package level, but not on individual classes. It looks like these open Maven issues are the cause:
http://jira.codehaus.org/browse/MJAVADOC-388
http://jira.codehaus.org/browse/MJAVADOC-365
Note that issue #365 is actually related to sourceFileExcludes; the fix for that is scheduled for maven-javadoc-plugin 2.11.

Varying plugin configuration for each child module

I have a multi-module build which contains modules which can target either Java 5 or Java 6. I want to allow modules to opt-in to Java 6, and leaving the default to 5.
To set Java 5 as a target I need to configure the following:
maven-compiler-plugin: source and target set to 1.5
maven-bundle-plugin: configure the Bundle-RuntimeExecutionEnvironment to J2SE-1.5
To set Java 6 as a target I need to configure the following:
maven-compiler-plugin: source and target set to 1.6
maven-bundle-plugin: configure the Bundle-RuntimeExecutionEnvironment to JavaSE-1.6
I considered having two properties: java.compiler.source and osgi.bree which can be defined by each module, but this leaves place for error.
How can I override the configuration of these two plugins per module with a single switch?
I would personally structure your project so that Java 5 modules descend from one parent POM and Java 6 modules from another parent POM.
Global Parent (majority of global settings)
Java5 parent (just define source/bundle)
module A
module B
Java 6 parent (just define source/bundle)
module C
How about allowing child modules to set a my.java.version property (or whatever you want it named) and embedding a Groovy script that sets version properties for the compiler and bundle plugins? Something like this in the parent pom:
<project ...>
...
<properties>
<my.java.version>1.5</my.java.version> <!-- default Java version -->
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<!-- set up properties in an early lifecycle phase -->
<phase>initialize</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<!-- this can be as simple or complex as you need it to be -->
<source>
if (project.properties['my.java.version'] == '1.6') {
project.properties['my.compiler.version'] = '1.6'
project.properties['my.execution.environment.version'] = 'JavaSE-1.6'
}
else {
project.properties['my.compiler.version'] = '1.5'
project.properties['my.execution.environment.version'] = 'J2SE-1.5'
}
</source>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<!-- now use the properties from above in the plugin configurations -->
<!-- assume that both of these plugins will execute in a phase later than 'initialize' -->
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${my.compiler.version}</source>
<target>${my.compiler.version}</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<!-- sorry if this part isn't correct; never used this plugin before -->
<instructions>
<Bundle-RuntimeExecutionEnvironment>${my.execution.environment.version}</Bundle-RuntimeExecutionEnvironment>
</instructions>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
I don't think there is an elegant Maven way to solve this complex scenario, neither yours or Duncan's proposed solution are easy maintainable IMO, when number of sub module becomes tremendous.
For maximum maintainability, I would write shell script (and/or batch file on Windows) in case Maven can't do the job very well, for example, a set-version.sh (and set-version.bat) that loop all sub module and reset the default java.compiler.source and osgi.bree properties based on a version-feed.txt, the version-feed.txt gives you a single central place for manipulating your version varying. As you can see, the cons is this is really not a Maven solution, it requires running set-version.sh before mvn ... every time version customization is required.
In addition, For build/release standardization, I would use maven-enforcer-plugin to play/pause the build process based on a property version.set(which is flagged by set-version.sh) and prompt some warning/error message if developer is not follow the correct procedure when doing build. The version.set also gives the flexibility if you prefer to use the default values defined in every sub module, instead of running set-version.sh, just directly set it to true in the parent pom.xml or from command-line parameter.
Sample directory structure:
parent/
module-a/
module-b/
module-c/
... ...
pom.xml
set-version.sh
set-version.bat
version-feed.txt
Hope this make sense.

Android compilation failure in maven

I am making an Android app, and have created a custom view to do some animation.
I have created a custom view, extending ImageView and implementing ValueAnimator.AnimatorUpdateListener.
When I try to compile this with maven it fails with "package android.animation does not exist"
However, when building within Intellij Idea it builds fine. After building in Idea it is even possible to run mvn install successfully.
The successful build running fine in the emulator, but not on my physical device.
When trying to start it up on the device I get:
Failed resolving Lno/derp/myapp/view/MyAnimatedView; interface 7 'Landroid/animation/ValueAnimator$AnimatorUpdateListener;'
Link of class 'Lno/derp/myapp//view/MyAnimatedView;' failed
Could not find class 'no/derp/myapp/view/MyAnimatedView', referenced from method no/derp/myapp.MainActivity.onCreate
and then
java.lang.ClassNotFoundException: no/derp/myapp.MyAnimatedView in loader dalvik.system.PathClassLoader[/data/app/no/derp/myapp-2.apk]
pom.xml:
<packaging>apk</packaging>
<name>My App</name>
<dependencies>
<dependency>
<groupId>com.google.android</groupId>
<artifactId>android</artifactId>
<version>2.3.3</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>com.jayway.maven.plugins.android.generation2</groupId>
<artifactId>android-maven-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<androidManifestFile>${project.basedir}/AndroidManifest.xml</androidManifestFile>
<assetsDirectory>${project.basedir}/assets</assetsDirectory>
<resourceDirectory>${project.basedir}/resources</resourceDirectory>
<undeployBeforeDeploy>true</undeployBeforeDeploy>
</configuration>
<extensions>true</extensions>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<target>1.6</target>
<source>1.6</source>
</configuration>
</plugin>
</plugins>
I am using the latest version of the SDK. A class importing the mentioned package does not compile, it is not just the view. The same happens with version 2.8.3 of android-maven-plugin (or maven-android-plugin as it was called)
Any ideas?
android.animation is available since API Level 11, you need set your dependency in your pom.xml to use 3.0+ to compile your code in command-line.
The reason why it works in Intellij is IDE usually use default.properties to resolve the SDK used to compile source code, I suppose you use the correct API level in your default.properties.
Hope this help.
It seems you are missing the configuration of the plugin for the platform/api level. Check out e.g. helloflashlight example of the official samples.
In your case you would have to add
<sdk>
<!-- platform or api level (api level 4 = platform 1.6)-->
<platform>4</platform>
</sdk>
with api level 9 or 10 or whatever you need. See the API level doc.
And for the compile plugin to have the right API you have to have the correct android dependency. You potentially have to use my Maven Android SDK Deployer to push the dependency into your local repository
Maven Android SDK Deployer helped since I got
<dependency>
<groupId>android</groupId>
<artifactId>android</artifactId>
<version>4.0_r2</version>
<scope>provided</scope>
</dependency>
But the application still crashes on my phone, same as before, "Link of .. failed". Which is natural, since I probably have Android 2.X on my phone.
The reason Idea compiles is because it has the Android SDK set manually, it does not use the maven plugin, I think.

Maven : error: generics are not supported in -source 1.3 , I am using 1.6

I have imported an existing Maven project into Eclipse IDE .
I have modified some code in it , it compiled successfully ,
I am using Java 1.6 as compiler
and when i am trying to run maven clean install -X
Its giving the following error
could not parse error message: (use -source 5 or higher to enable generics)
D:\bayer\util\src\main\java\com\tata\bayer\util\BrokerageCalendar.java:179: error: generics are not supported in -source 1.3
private static Hashtable<String, Boolean> nyseHolidays = new Hashtable<String, Boolean>();
^
could not parse error message: (use -source 5 or higher to enable generics)
D:\bayer\util\src\main\java\com\tata\bayer\util\APIHttpXmlClient.java:27: error: generics are not supported in -source 1.3
Class<? extends APIResponse> responseClass) {
^
Please suggest any ideas as how to resolve this ??
Did you declare that you want to use java 1.6 in your project pom.xml?:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<compilerArgument></compilerArgument>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Configuring the Maven Compiler Plugin will fix the problem. It turns out the problem was caused by the Maven3 package in the Ubuntu repository. An alternate fix is to download Maven 3 from the Apache website which uses a more up to date Compiler plugin.
I wanted to know why this was happening when the documentation states the default Java source is 1.5. To see what mvn is using for your compiler plugin use:
mvn help:effective-pom
My Maven Compiler Plugin was 2.0.2 even though I was using Maven 3.0.4 from the Ubuntu packages.
When I run the same command using Maven 3.0.4 from Apache I have a plugin version 2.3.2, which defaults to Java 1.5 as expected.
You have to configure the Maven Compiler Plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
Another way that doesn't involve modifying the pom is to specify the source and target in the command line:
mvn clean install -Dmaven.compiler.source=1.6 -Dmaven.compiler.target=1.6
Note that this should be avoided generally as the build cannot be guaranteed to be repeatable this way.
I'd prefer this:
<properties>
<maven.compiler.source>1.5</maven.compiler.source>
<maven.compiler.target>1.5</maven.compiler.target>
...

Resources