Vaadin recently updated to Vaadin 23.2.5 but I can't find the corresponding flow-server dependency of the same version:
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>flow-server</artifactId>
<version>23.2.5</version>
</dependency>
So my question is - is this a good idea to use new Vaadin 23.2.5 with flow-server 23.2.4 dependency? I need this dependency for one of my backend module for com.vaadin.flow.shared.Registration; and com.vaadin.flow.component.UIDetachedException
Use the Vaadin BOM in your Dependency Management to always get matching and tested combination of artefacts provided by Vaadin - for example flow-server or components.
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<version>VERSION</version>
<type>pom</type>
</dependency>
Related
the Vaadin documentation states that it has support for a compontent called Select using Java.
How do you access it?
I cant find any corresponding class.
Not even its install section mentions it.
You should add the following dependency to your pom.xml:
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-select-flow</artifactId>
<version>1.0.0</version>
</dependency>
In Vaadin 8, I was able to retrieve version information with
com.vaadin.shared.Version.getFullVersion()
In Vaadin Flow I cannot find a way to get the current version, at least not the one that I expected. I have found this one
com.vaadin.flow.server.Version.getFullVersion()
but the return value is 1.2.2 and not the expected 12.0.0. I guess it is the server version or something..
How do I get the used version of vaadin framework correctly in vaadin flow?
One possible approach to get the Vaadin version is to use
VaadinCoreShrinkWrap.class.getAnnotation(NpmPackage.class).version()
Not optimal, but it should work.
This approach works starting from Vaadin 14. It will cause errors with older versions.
Starting from 10, a Vaadin version doesn't have any content of its own, not even a version number marker. It's only a set of dependency versions that have been tested to work well together.
com.vaadin.flow.server.Version.getFullVersion() gives the version of the Vaadin Flow dependency. This is in most cases a more relevant version number to look at for technical purposes.
Vaadin 10 and Vaadin 11 used Flow 1.0.x, whereas Vaadin 12 uses version 1.2.x. Vaadin 13 will most likely use Flow version 1.3.x or 2.0.x, depending on how big changes will be included by then.
If you want to show Vaadin version and not Flow version I see one option to make it happen but it requires more code and some maven configuration.
You should
Create a properties file including the line vaadin.version=${vaadin.version}
Make sure the file is included in resources that maven-resources-plugin filter with something like the following in you build config:
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>**/config.properties</include>
</includes>
</resource>
<resource>
<directory>src/main/resources</directory>
<filtering>false</filtering>
<excludes>
<exclude>**/config.properties</exclude>
</excludes>
</resource>
</resources>
Read properties file and get value for version property
Properties properties = new Properties();
properties.load(MainView.class.getResourceAsStream("config.properties"));
properties.get("vaadin.version");
I'm working on a Java game project that would benefit a lot from the graph traversal algorithms and query languages included in Neo4j. Unfortunately, querying a server takes too much time and I would like to know if it's possible to use Neo4J as a library, with queries happening in-memory?
You can embed Neo4j in Java applications. Take a look in the docs. If you are working in a Maven project, you can add Neo4j as a Maven dependency:
<project>
...
<dependencies>
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j</artifactId>
<version>3.3.2</version>
</dependency>
...
</dependencies>
...
</project>
Also, there is an ImpermanentDataBase developed for unit test purposes.
I am using maven-remote-resources-plugin, which retrieves the remote resources (such as css file) from another project to a specific directory in the current project. Since I am developing the css files, I would really like to see the changes in runtime with a simple reload-page click on the browser, instead of recompiling and rebuilding the maven project.
My first thought is to remove the build tags wrapping around the plugins, which didn't work.
<build>
<plugins>
<plugin>
<artifactId>maven-remote-resources-plugin</artifactId>
How can I achieve this? First post -- thanks very much to all so-ers!
As of today, I'm getting a build break for existing code that used to compile correctly, due to error locating many key classes in the Dataflow SDK for Java. For example:
[ERROR] /tmp/first-dataflow/src/main/java/com/google/cloud/dataflow/examples/common/DataflowExampleUtils.java:[30,37] cannot find symbol
[ERROR] symbol: class Pipeline
[ERROR] location: package com.google.cloud.dataflow.sdk
Have the APIs changed?
Existing Maven projects that use the previously recommended version range [1.0.0, 2.0.0) for the Google Cloud Dataflow SDK for Java may soon pick up the new 2.0.0-beta1 version of that SDK. This new version has APIs that are not compatible with the 1.x releases, so using this it with existing code will cause these kinds of breakages.
If you are impacted, update your Maven pom.xml to use a version range that precludes anything in the 2.x family, for example by using [1.0.0, 1.99), as follows:
<dependency>
<groupId>com.google.cloud.dataflow</groupId>
<artifactId>google-cloud-dataflow-java-sdk-all</artifactId>
<version>[1.0.0,1.99)</version>
</dependency>
This should fix your compile issues and allow you to continue with the most recent release in the 1.x series (currently 1.9.0).
For more information and updates, you can follow this GitHub issue.
Separately, you can learn more about the 2.0.0-beta1 release, including what these incompatible API changes are, in its release notes. But be aware that it is an early preview and has corresponding caveats about API stability, support timelines, and documentation.