Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vaadin Flow OSGi Starter not working #28

Closed
denis-anisimov opened this issue Mar 6, 2019 · 4 comments
Closed

Vaadin Flow OSGi Starter not working #28

denis-anisimov opened this issue Mar 6, 2019 · 4 comments
Assignees

Comments

@denis-anisimov
Copy link

@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.

  1. When I imported the starter project in to Eclipse I get an error regarding the maven-antrun-plugin:
    vaadin-error-1
    I'm not sure if this is directly Vaadin related but wanted to point out that this error exists

  2. 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:

vaadin-error-2

vaadin-error-3

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 Add examples of using DS features in Vaadin components #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.

@denis-anisimov
Copy link
Author

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 pluginExecutionFilter to avoid m2e error.
  • Removed -s from the command line arguments which allows to avoid unnecessary URI parsing exception

@denis-anisimov
Copy link
Author

#27

@denis-anisimov
Copy link
Author

Another issue is created about Auto-deploy install exceptions:
#29

@denis-anisimov denis-anisimov self-assigned this Mar 6, 2019
@Sandared
Copy link

Sandared commented Mar 6, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants