Vaadin Flow OSGi Starter not working
Closed this issue · 4 comments
@Sandared commented on Tue Mar 05 2019
Hi,
I just tried to download and run the OSGi Vaadin starter but this results in several different errors.
-
When I imported the starter project in to Eclipse I get an error regarding the maven-antrun-plugin:
I'm not sure if this is directly Vaadin related but wanted to point out that this error exists -
After importing the project (with the above error) I tried to run the starter as described on the website via mvn -Pprepare-osgi-container -Prun-osgi-container verify the build process ended with the following error message:
I'm using the latest Eclipse for java developers release.
Things I noticed when browsing the starter POM:
- You are using the bnd-maven plugin in version 3.3.0 where 4.1.0 is the current version and 4.2.0 is currently in version RC1.
- The starter uses OSGi dependencies in version 6.0.0 where 7.0.0 is the current one. Maybe you could use the enRoute BOMs to use the current reference implementations for OSGi which would also resemble more the official setup promoted by the OSGi Alliance, i.e., the enRoute setup.
Or you could switch entirely to the enRoute setup for the starter instead of using profiles and just reference to the repective Vaadin BOM, as I did in the examples I provided for #25
Kind regards,
Thomas
@QNENet commented on Tue Mar 05 2019
Instead of the starter, an archetype for a base Vaadin OSGi project to be used in an enRoute environment is to be preferred.
No need for the prepare and run contents in the pom.
This would make the "heavenly" situation of Vaadin/OSGi a simple reality.
@QNENet commented on Tue Mar 05 2019
I think adding this to the parent pom pluginManagement in an enRoute project solves this problem
<!--This plugin's configuration is used to store Eclipse
m2e settings only. It has no influence on the Maven build itself. -->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>
org.commonjava.maven.plugins
</groupId>
<artifactId>
directory-maven-plugin
</artifactId>
<versionRange>
[0.1,)
</versionRange>
<goals>
<goal>highest-basedir</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>
org.apache.maven.plugins
</groupId>
<artifactId>
maven-plugin-plugin
</artifactId>
<versionRange>
[3.2,)
</versionRange>
<goals>
<goal>descriptor</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
@denis-anisimov commented on Wed Mar 06 2019
Let's go item by item:
1)This is a known eclipse issue. It doesn't affect anyhow the project execution or anything else. Eclipse maven support is just unable to use m2e connector. You may ignore the error or if it's annoying you may add pluginExecutionFilter like here: http://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html
2) Auto-deploy install are warnings about inability to deploy jars in the deploy folder (which is auto deployment folder for Felix) because they have no MANIFEST. This is can be ignored. There are some dependencies which are copied into the deploy folder but they are not OSGi bundles. I believe most of them are WebJars which are known as OSGi incompatible but they are dependencies in platform. This is very minor issue which doesn't affect anyhow the project execution. I will create a ticket about it. java.net.URI exception is a consequence of -s in the command line arguments line. I will fix it as a part of this ticket. It also doesn't affect anyhow the project execution.
3) Let's talk about bind exception separately. This is the only exception which affect the project execution. For some reason the port 8080 is occupied on your box. And Jetty is unable to connect it. This is not a project error. Please check which application uses 8080 port and stop it.
As a result: there is no any error in the project which affects the project execution.
Only one real problem is a consequence of your local environment .
@denis-anisimov commented on Wed Mar 06 2019
Also I will update dependency versions and plugin versions if it's possible.
So:
- technically this is not a bug since nothing prevents from running the project.
- the issue is moved to the correct repository
- I've updated versions of the plugin and dependency
- Also made some additional fixes
- Added
pluginExecutionFilterto avoid m2e error. - Removed
-sfrom the command line arguments which allows to avoid unnecessary URI parsing exception
Another issue is created about Auto-deploy install exceptions:
#29
Hi Denis,
thank you very much for the detailed explanation. I just tried the starter on another pc and it worked. Sorry for the confusion.
Kind regards,
Thomas