How do I change the default frontend folder location in a maven Vaadin 14 project from ${project.basedir}/frontend to ${project.basedir}/src/main/frontend?
Also, Vaadin plugin outputs frontend folder in maven build output directory instead of the war exploded directory, where I would expect it to be.
How do it make it to work since I did not map this folder into my web.xml file?
How do I make it put frontend folder into the war archive and see which configuration it is using to make the compiled front end visible to my application?
Vaadin uses the frontend folder differently in both dev and production modes. In production it builds the frontend using the build-frontend goal. Vaadin Maven Plugin don't have a proper documentation, the best place I found explaining what each goals do is here: https://vaadin.com/docs/v14/flow/production/tutorial-production-mode-advanced.html. This page explains that build-frontend is responsible for building and putting the frontend processed into WEB-INF\classes\META-INF\VAADIN\build when in production mode.
Dev mode is very different, development instructions explains that if you don't use an embedded server you should configure your IDE to run prepare-frontend goal before deployment: https://vaadin.com/docs/v14/flow/workflow/run-on-server-intellij.html. But prepare-frontend just creates the empty frontend folder into target, how does it find frontend files if the folder is empty and nothing is copied to the war exploded folder? Answer: when you run the application, Vaadin has a DevModeInitializer that creates the file generated-flow-imports.js into target/frontend, which refer directly to the project source files, so that any modifications made at them may be reflected immediately, and that's why there is no need of any configuration in web.xml or context listener.
Dev mode make kind of a hack with frontend folder to make development smoother, and prod mode compile everything from frontend into a minified file served by the Vaadin servlet, so only in prod mode frontend goes into the war file. In the first case, prepare-frontend must be used, in the second, build-frontend must be used also. So, in order to modify the frontend folder location, one must change the plugin configuration in those two goals:
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<version>${vaadin.version}</version>
<executions>
<execution>
<goals>
<goal>prepare-frontend</goal>
</goals>
</execution>
</executions>
<configuration>
<frontendDirectory>${project.basedir}/src/main/frontend</frontendDirectory>
</configuration>
</plugin>
<profiles>
<profile>
<!-- Production mode is activated using -Pproduction -->
<id>production</id>
<properties>
<vaadin.productionMode>true</vaadin.productionMode>
</properties>
<dependencies>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>flow-server-production-mode</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>build-frontend</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
<configuration>
<frontendDirectory>${project.basedir}/src/main/frontend</frontendDirectory>
</configuration>
</plugin>
</plugins>
</build>
</profile>
That way, the modification will work in both dev and production mode.
Related
When running mvn versions:display-dependency-updates for the Version Maven Plugin I see lots of things like this:
[INFO] org.slf4j:slf4j-api ........................... 1.7.36 -> 2.0.0-alpha7
But just because I'm not using the alpha version of a later version doesn't mean I'm not using the latest available release version. Another Stack Overflow answer indicated that I can set up a rules.xml file to ignore versions like *.-alpha*, putting something like this in my POM:
<configuration>
<rulesUri>file:///${project.basedir}/rules.xml</rulesUri>
</configuration>
My question: is this rules.xml file inheritable? If I put it in a separate project in a parent POM of <packaging>pom</packaging>, published to Maven Central, will the child POMs pick it up? Or will the child projects look for a rules.xml file in the child project directory?
I want to configure the versions-maven-plugin in the parent POM (as I do already) and run mvn versions:display-dependency-updates on any child POM or descendant POM. How can I set up the ignore rules in the parent POM so that these version ignore rules will be picked up when I check for dependency updates in a child POM? (Is there no way to include the rule within the POM itself?)
Or will the child projects look for a rules.xml file in the child project directory?
Yes, if you define the rules.xml file via ${project.basedir} it will resolve to the current local base directory of the child project. I've verified this with a simple parent-child pom setup. So that will not work, unless you duplicate the rules file in every project.
If you wish to include the plugin configuration and ruleset in the parent pom without duplicating the rules file, you have two options:
If you have your ruleset xml file hosted at, for example, http://www.mycompany.com/maven-version-rules.xml then the following configuration in your corporate pom would ensure that all projects use this rule set.
<configuration>
<rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
</configuration>
or
You can provide your ruleset xml file also within a jar, if you want to distribute your ruleset xml as Maven artifact. Therefore you have to declare the containing jar as direct dependency of the versions-maven-plugin and to use classpath as protocol.
<configuration>
<rulesUri>classpath:///package/foo/bar/rules.xml</rulesUri>
</configuration>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>version-rules</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
Source:
https://www.mojohaus.org/versions-maven-plugin/version-rules.html
The configuration in the pom only has rudimentary includes and excludes filters. Those will allow you to exclude any dependency as a whole, but not specific update versions. As far as i can tell from the available documentation there is no way to define version rules in any other way.
See
https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
Update 09-2022
In the github ticket we found in the comments we can see the following update:
It looks like a feature like this has recently been implemented by #369. Please see #318 where it's possible to provide inclusion and exclusion filters for determining which dependency patterns will be considered. Thanks to that, you can rule out patterns such as .*-beta. or .*_ALPHA, albeit not using regexp, but simple asterisk wildcards.
This will land in today's release (2.12.0).
This will add the following features:
Version 2.12.0 will introduce new arguments: dependencyIncluded, dependencyExcludes, dependencyManagementIncludes, dependencyManagementExcludes.
With the following example configuration in pom.xml given:
<profile>
<id>display-dependency-updates</id>
<build>
<plugins>
<plugin>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<dependencyIncludes>org.apache.maven.*:doxia*</dependencyIncludes>
<dependencyManagementIncludes>com.puppy*:*</dependencyManagementIncludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This will also be implemented for filtering plugin and pluginManagement, but that will probably be added in a later release:
So, I've just added the missing plugin- and plugin management filtering which works likewise. I really doubt it will land into today's release though.
Pasting my answer here from Github, because I think it might benefit others.
Provided you have a directory called rules-test in your project containing the rules template file:
<ruleset comparisonMethod="maven"
xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0
https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<ignoreVersion type="regex">${ignoredVersions}</ignoreVersion>
</ignoreVersions>
</ruleset>
Then, in your main project, create the following profile:
<profile>
<id>rules-test</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>rules-test</directory>
<filtering>true</filtering>
</resource>
</resources>
<outputDirectory>${project.basedir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.12.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<rulesUri>file://${project.basedir}/compiled-rules.xml</rulesUri>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
If you then execute the following Maven target:
mvn -P rules-test "-DignoredVersions=.*-(M\d*|.*-SNAPSHOT)" clean validate
then you will get a dependencies report using the filter in the -DignoredVersions argument (filtering out both *-M* and *-SNAPSHOT).
And if you put your ignoredVerions property in your project instead of passing it as a -D argument, then it will be inheritable!
I have a spring boot application based on maven and has several modules. I do use a spring-boot-maven-plugin, however, this plugin is only used on one of the modules. Even though the individual jar files for each modules are pretty small, the executable produced by the main module where I use this plugin with "repackage" goal is pretty large (About 750 MB).
I expanded the jar file that is created and was a little surprised to see that that it has bundled the jar files for several operating systems such as windows, linux, android etc.
If you see the opncsv jar file in the screenshot below, it appears it has bundled those jars for 13 different Operation systems !!
I understand that the executable created this way will be runnable in cross platforms, but just wondering if there is a way to configure this executable creation so that it only packages for certain OS only such as linux where I am running this app on.
The large executable just seems like an overkill in my situation.
Here is the plugin
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>exec</classifier>
<mainClass>org.blabla.products.webapp.Application</mainClass>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Here are the dependency versions of different jars that i am using.
<properties>
<java.version>1.8</java.version>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<mysql-connector-java.version>5.1.40</mysql-connector-java.version>
<!--CHECKED FOR CURRENCY AND UPGRADED AS NEEDED ON 1/27/2019-->
<findbugs-maven-plugin.version>3.0.5</findbugs-maven-plugin.version>
<jacoco-maven-plugin.version>0.8.2</jacoco-maven-plugin.version>
<springfox-swagger2.version>2.9.2</springfox-swagger2.version>
<org.jsoup.version>1.11.3</org.jsoup.version>
<opencsv.version>4.4</opencsv.version>
<httpclient.version>4.5.6</httpclient.version>
<dl4j.version>1.0.0-beta3</dl4j.version>
<spring-web.version>5.1.4.RELEASE</spring-web.version>
<gson.version>2.8.5</gson.version>
<ehcache.version>3.6.3</ehcache.version>
<guava.version>27.0.1-jre</guava.version>
<thymeleaf-extras-springsecurity4.version>3.0.4.RELEASE</thymeleaf-extras-springsecurity4.version>
</properties>
I guess you can try to exclude it with maven. This was already answered here.
I have two projects one is Angular Project(Front End Application ) and another one is Spring boot (Rest Api's).
When I run both the projects individually everything works fine. But now I want to generate a single runnable jar file for both these projects in such a way that when i run the jar in the localhost:8081 it should up both the Angular module as well as spring boot module.
I've added the following plugin to my pom.xml file
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${build.directory}/classes/static/</outputDirectory >
<resources>
<resource>
<directory>../angular6-MyProject/dist</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
Quick answer
You need to copy static files to ${build.directory}/classes/META-INF/resources folder for the servlet container serve them as static files from inside a war/jar file (that's how https://www.webjars.org work).
Handling HTML directly from jar
In the Static Content section of Spring Boot documentation you can find
By default, Spring Boot serves static content from a directory called /static (or /public or /resources or /META-INF/resources) in the classpath or from the root of the ServletContext
The /META-INF/resources is the "standard" way (though not most intuitive) and it comes directly from the Java Servlet Specification 3.0 (from JavaEE version 6)
A Web application exists as a structured hierarchy of directories. The root of this hierarchy serves as the document root for files that are part of the application. For example, for a Web application with the context path
/catalog in a Web container, the index.html file at the base of the Web application hierarchy or in a JAR file inside WEB-INF/lib that includes the
index.html under META-INF/resources directory can be served to satisfy a request from /catalog/index.html.
Therefore, setting an appropriate path should do the job.
Treating Angular application as a dependency
The quoted JavaEE spec is also what webjars utilize. Webjars are client-side dependencies packaged into JAR archive files. The primary reason for webjars to exist is to avoid adding and managing client-side dependencies (like Angular, jQuery), which often results in hard to maintain codebases.
But if the Angular can be a webjar, your frontend can be as well. What I tend to do is to pack the Angular application as a jar file and treat it as a dependency.
Frontend application
Driven npm from Maven + create Jar file
<project>
<groupId>com.examplegroupId>
<artifactId>myapp-ui</artifactId>
<packaging>jar</packaging>
<build>
<plugins>
<!-- run the frontend (npm / bower stack) and update dependencies -->
<plugin>
<groupId>com.github.eirslett</groupId>
<artifactId>frontend-maven-plugin</artifactId>
<configuration>
<installDirectory>target</installDirectory>
</configuration>
<executions>
<execution>
<id>install node and npm</id>
<goals>
<goal>install-node-and-npm</goal>
</goals>
<phase>generate-resources</phase>
<configuration>
<nodeVersion>v8.9.1</nodeVersion>
<npmVersion>5.5.1</npmVersion>
</configuration>
</execution>
<execution>
<id>npm install</id>
<goals>
<goal>npm</goal>
</goals>
<phase>generate-resources</phase>
<configuration>
<arguments>install</arguments>
</configuration>
</execution>
<execution>
<id>npm build</id>
<goals>
<goal>npm</goal>
</goals>
<phase>generate-resources</phase>
<configuration>
<arguments>run build</arguments>
</configuration>
</execution>
</executions>
</plugin>
<!-- copy everything as a webjar -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-resources</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/classes/META-INF/resources</outputDirectory>
<resources>
<resource>
<directory>dist/</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Backend application
Use the dependency directly
<dependencies>
<dependency>
<groupId>com.example<groupId>
<artifactId>myapp-ui</artifactId>
</dependency>
</dependencies>
Notices
Some issues and observations I've seen with webjars:
I've seen some problems with webjars and web fonts (fonts not being load by the browser when served from inside the jar file)
There are ways to build webjars using npm tools and all packages I've seen require and use java underneath anyway. I haven't seen any native JS solution
Webjars themselves don't impact the performance of an application, however serving static content from Servlet container is always significantly less performant (regarding possible throughput) than serving it from say nginx
I followed this tutorial
and it's somehow similar to what Jakub mentioned in his answer. I usually run the mvn spring-boot:run command to launch it in one go. The key to setting up the project is in the pom.xml. Make sure that you are telling the build to copy the Angular dist/ files into the right place. In this case, it needs to copy the compiled JS from Angular's dist/ folder to the server/target/classes/resources so it can host the static content.
The entire build (mvn clean install) can take forever. So during development I just go to the src/main/web directory and run ng-serve from there so I can see my UI changes quickly.
Hope this helps.
The back-end server uses Spring Boot with Spring Web MVC for REST Controller and Spring Data JPA for interacting with MySQL database. Front-end side is made with Angular 11, HTTP Client & Router.
– Spring Boot exports REST APIs using Spring Web MVC & interacts with MySQL Database using Spring Data JPA.
– Angular Client sends HTTP Requests and retrieve HTTP Responses using axioms, shows data on the components. We also use Angular Router for navigating to pages.
Steps to follow to set up Angular 11 with Spring Boot Application.
Create Angular 11 Application to run and build successfully.
Create build according to environment like QA, PROD, LOCAL.
from dist. folder collect compiled files through node-js.
Angular runs on node server by using typescript. once you compile code and build angular project in dist. folder you will get .js files. java script files.
We can you as it is js files from dist folder to run any UI application.
Create Spring boot application and write REST apis and compile and build successfully.
create static folder in resource folder.
put static folder path inside application.properties like classpath:"resource/static/".
put all compiled js file in to static folder from dist folder.
create webConfig.java file in spring boot project to routing URL for index.html.
Create build nd compile successfully spring boot project.
if you run the project you will get UI from spring boot project.
Create jar from spring boot project.
Deploy on Azure and run the project successfully.
thank you you can visit my blog for in details.
https://draft.blogger.com/blog/post/edit/preview/8320325077779788397/7601438449518293236
I am trying out a Simple Java Web Start project based on the Oracle Tutorial. I am using maven to package it as a webapp and deploy it to application server. The full source code is available here
https://github.com/KiranMohan/dynamic-tree-javaws-sample-project
The maven project structure is like
parent
|--lib
|--webapp
The webapp module is a maven war module. It is required to package lib.jar at the root of webapp.war. NOT under WEB-INF/lib.
How to achieve this in maven?
I found that the right way to do this is to use the maven-dependency-plugin.
Since "lib.jar" is not used in the compile phase of "webapp" module, it is only a package time dependency. Using maven-dependency-plugin, I can copy lib.jar to any required directory during the prepare-package phase. The maven-war package would then include the lib.jar in the .war package.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy</id>
<phase>prepare-package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>[ group id ]</groupId>
<artifactId>[artifact id]</artifactId>
<version>[ version ]</version>
<outputDirectory>${project.build.directory}/${project.artifactId}</outputDirectory>
</artifactItem>
</artifactItems>
<!-- other configurations here -->
</configuration>
</execution>
</executions>
</plugin>
Update:
There is a webstart-maven-plugin that does a better job of packaging javaws applications. See my sample project
https://github.com/KiranMohan/dynamic-tree-javaws-sample-project
for details
Well how i said in the comments for sake of readability here is a part of the answer:
Since Maven will always store the dependencies of a web project under its WEB-INF/lib folder by default i (i am no Maven expert ...) would try to place my lib.jar inside the /target folder of the project before the phase package is executed.
NOTE: I havent tried it out so you will have to adjust the paths - expecially the output path so your lib.jar is placed properly to be packed into the root of the war (e.g. if you open your war there will be a lib.jar next to folders such as WEB-INF).
<!--
lets assume the root of my project would be under C:/devjba/projectX this equals the maven
variable ${project.basedir}.
from there the output-directory would be located under C:/devjba/projectX/target which equals the
maven variable ${project.build.directory}. This is the location a .war would be placed in after
the build
lets assume the required jar lib.jar is located under C:/devjba/projectX/misc which would equal to
the expression: ${project.basedir}/misc
-->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>foo</id>
<!-- may adjust to another phase before package but make sure your plugin is bound to a phase
because otherwise it wont be invoked during build! Now its bound to the first phase of the
default lifecycle for packaging type war -->
<phase>process-resources</phase>
<goals>
<!-- use the copy-resources goal of this plugin - it will copy resources :) -->
<goal>copy-resources</goal>
</goals>
<configuration>
<!-- this points to /target of the current project, you may adjust it to wherever it must be placed to be packed into the root of the war (just try&error) -->
<outputDirectory>${project.build.directory}</outputDirectory>
<resources>
<resource>
<!-- this points to a folder /misc under the project root where we expect the lib.jar -->
<directory>${project.basedir}/misc</directory>
<!-- unless you specify what to include anything of the above directory will be included -->
<includes>
<include>lib.jar</include>
</includes>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
As i said i have no experience in signing JARs at all but there is a plugin called maven-jarsigner-plugin which i guess will do the job (i would sign it, then move it, then package the war) with a manual - i recomend you try to configure it according to my "example configuration of the maven-resource-plugin and post a new question directly containing your two plugin configurations. Dont forget to link to this question in that case. And also leave this question open so someone with a better approach may correct my way).
Something bother me a lot...
On a big project with many dependencies, some of them are set as SNAPSHOT in Maven2.
The matter is that it seems i can't get the sources through Eclipse without loading the project or fixing the dependency to the last release.
For debugging, it's really annoying me...
EDIT
This is what i get in eclipse maven console:
26/08/10 11:31:46 CEST: Downloading http://repo-maven/archiva/repository/snapshots/com/blabla/1.1-SNAPSHOT/blabla-1.1-20100824.213711-80-javadoc.jar
26/08/10 11:31:47 CEST: Could not download sources for com.blabla:blabla:1.1-20100824.213711-80
On archiva i can see the deployed stuff i want to retrieve in eclipse...
Repository snapshots
Group ID com.blabla
Artifact ID blabla
Version 1.1-20100824.213711-80
Packaging jar
Parent com.blabla bla 1.1-SNAPSHOT (View)
Other Versions 1.1-20100824.213535-79
I can download sources of this artifact with my browser but not within Eclipse... Any idea?
The matter is that it seems I can't get the sources through Eclipse without loading the project or fixing the dependency to the last release. For debugging, it's really annoying me...
Well, these modules are probably not publishing source JARs as part of the "regular" build process (i.e. outside the release). If these modules are under your control (which is my understanding), configuring the Maven Source Plugin to produce source JARs for them and deploying them in your corporate repo should solve the problem. From the Usage page:
Installing the sources along with your artifact
There are two ways to do this. You can
either bind this plugin to a phase or
you can add it to a profile. The goals
source:jar-no-fork and
source:test-jar-no-fork are preferred
for binding the goal to the build
lifecycle.
Installing the sources using a phase binding
Here is how you would configure the
plugin in your pom.xml to run
automatically during the verify phase:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
We are using the verify phase here
because it is the phase that comes
before the install phase, thus making
sure that the sources jar has been
created before the install takes
place.
Installing the sources using a profile
If you want to install a jar of your
sources along with your artifact
during the release process, you can
add this to your pom.xml file:
<project>
...
<profiles>
<profile>
<id>release</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
...
</project>
Using a profile would probably be a good idea so that building source JARs will only be done by the build running at the CI server level but not on developer machines.