Get Vaadin Version in flow - vaadin

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");

Related

What happened to VaadinWebSecurityConfigurerAdapter in Vaadin 19?

We are building a web app with Vaadin 19 Fusion, and I'm following this tutorial:
https://vaadin.com/docs/latest/fusion/security/spring-login
(I have selected the V19+ Docs and then Fusion)
In the tutorial there is a reference to VaadinWebSecurityConfigurerAdapter which is used for setting up the security with Spring, but this class is not available on the classpath. I have tried downloading a plain starter project (v19) from start.vaadin.com, and here I am also not able to use VaadinWebSecurityConfigurerAdapter.
Is there an alternative in v19 or am I missing a dependency? I have the same dependency tree as the starter project, so I was assuming the pom is correct.
It looks like the VaadinWebSecurityConfigurerAdapter will end up in V20, which is scheduled for release in June.
The documentation page you linked has a tag V20 pre-release at the top. This could certainly be made more visible.

com.vaadin.data.Provider not located

Currently, I am working on a Vaadin web application project in Netbeans. Recently, I looked into using the ExpandingTextArea addon, which ended up running into an unfortunate compilation error.
Apparently, the Property class in com.vaadin.data was missing. After searching through my dependencies, I found the com.vaadin.data package in my vaadin-server jar, and as expected, property was missing.
https://vaadin.com/api/7.7.6/com/vaadin/data/Property.html indicated that Property has been present since version 3.0, and as the URL indicates, it's been present up to 7.7.6.
Unfortunately, I am using 8.4.2; looking at https://vaadin.com/framework/releases, no versions between 8.4.2 and 8.5.0 (the most up-to-date version) contain Property (I installed the vaadin-server.jar's and then looked inside each one).
I'm thinking about making a Vaadin 8 version of ExpandingTextArea.
As such, is there some alternative to Property in Vaadin 8 that I could use?

How to execute Maven plugins dynamically?

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!

What is the different between io.swagger.annotations and com.wordnik.swagger.annotations

I am new to swagger and found there are two packages for swagger annotation: io.swagger.annotations and com.wordnik.swagger.annotations. I wonder what the difference is between them and what I should use?
The com.wordnik package is for the older swagger specifications, 1.x. As of swagger specification 2.0, the package is now io.swagger. The annotation signatures should be the same, just the package has changed.
These are different versions of swagger which go with different versions of other supporting software stack that you might be using.
I too came across these two a month ago when trying to integrate my application with swagger ui. I was using cxf 2.7.11, jackson 2.6.0 with spring 3.0.7 . I struggled a lot with com.wordnik (older version where swagger json is generated at url api_docs with usage of ApiListingResource etc) but then thought of implementing io.swagger (newer version) just to see the difference. Turned out that was the version i should have been using in the first place. Everything fell in place after that.
One addition in case others were wondering, too:
We used swagger version 1.3.13 which was called swagger-core_2.10. Initially I thought this may indicate a swagger API 2.X compatibility which it actually isn't: 2.10 is the bundled Scala version (mentioned here) This means means 25 MB of unecessary dependenies! So the current swagger version 1.5.X was rewritten in pure java and is much smaller in size. The scala version was moved to a separate project.

libraries for JSF (Sun/Oracle Mojarra)

I am downloading Sun/Oracle Mojarra implementation of JSF from http://javaserverfaces.java.net/download.html
I downloaded the latest -2.1.9 binary. It comes with only one jar - javax.faces-2.1.9.jar.
I had a sample project which I believe is using the older 2.0 version, which includes 2 jars - jsf-api.jar and jsf-impl.jar.
I replaced those 2 older jars with the single new jar. It seems like the sample project still works well.
My question:
Is there anything else I need to do besides replacing those 2 jars???
Any special reason this is this changed from 2 jars to 1?
Thanks a lot.
MORE:
I noticed versions in my faces-config.xml
<?xml version="1.0"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd" version="2.0">
</faces-config>
I changed 2.0 and 2_0 to 2.1 and 2_1. The sample project still works. SHould I make these changes?
Is there anything else I need to do besides replacing those 2 jars?
No.
Any special reason this is this changed from 2 jars to 1?
Around the time of the release of 2.1.6, they've refactored the build system conform Java EE Maven rules. See also Mojarra issue 2028. This resulted in the two well known jsf-api.jar and jsf-impl.jar files being replaced by a single javax.faces.jar file.
I changed 2.0 and 2_0 to 2.1 and 2_1. The sample project still works. SHould I make these changes?
You can just do so. The only difference is that the faces-config 2.1 XSD definies two new elements as opposed to faces-config 2.0 XSD:
<facelet-cache-factory> to register a custom FaceletCache
<redirect-param> to specify request parameters for in a redirect navigation case.
If you don't need any of them, then it don't matter if you're using the 2.0 or 2.1 XSD. Mojarra 2.1 has internally no 2.0 fallback modus when using JSF 2.1 with a 2.0 XSD.

Resources