CODEWITHSUNDEEP
mavenintellij-ideavaadinwarvaadin8
Basil Bourque
Basil Bourque

Reputation: 340350

Where is Vaadin 8 built app (WAR file or other artifacts) being stored in IntelliJ 2017?

When creating a Vaadin app via the simple Maven archetype:

mvn -B archetype:generate -DarchetypeGroupId=com.vaadin -DarchetypeArtifactId=vaadin-archetype-application -DarchetypeVersion=8.0.6 -DgroupId=org.test -DartifactId=vaadin-app -Dversion=1.0-SNAPSHOT

…and running via the bundled Jetty servlet container, where is my built web app being stored? Is there a WAR file being generated? If so, where?

I am using Java 8 Update 131 on macOS Sierra 10.12.5 with IntelliJ 2017.1.3.

Upvotes: 1

Views: 266

Answers (3)

petey
petey

Reputation: 17170

In target folder after mvn install

After you execute mvn install in Maven, a .war file can be found in the "target" folder.

For example… See this screenshot of a project named TryAgain where the folder target contains the WAR file named tryagain-1.0-SNAPSHOT.war.

Screenshot of a .war file found inside the folder named "target".

Upvotes: 1

Naman
Naman

Reputation: 32046

The details on the documentation of the Maven War Plugin usage states that:

Invoking

mvn package

or

mvn compile war:war

shall generate the WAR file target/vaadin-app-1.0-SNAPSHOT.war

Additionally linking the vaadin-docs which also state that after executing mvn package

The location of the resulting WAR package should be displayed in the command output.

Upvotes: 1

Morfic
Morfic

Reputation: 15528

As far as I know and as the docs suggest, when running mvn jetty:run, no artifact is being built. Instead, using its own internal mechanisms, the maven jetty plugin will (re)load your compiled classes from target\classes

The run goal runs on a webapp that does not have to be built into a WAR. Instead, Jetty deploys the webapp from its sources. It looks for the constituent parts of a webapp in the Maven default project locations, although you can override these in the plugin configuration. For example, by default it looks for:

  • resources in ${project.basedir}/src/main/webapp
  • classes in ${project.build.outputDirectory}
  • web.xml in ${project.basedir}/src/main/webapp/WEB-INF/

The plugin automatically ensures the classes are rebuilt and up-to-date before deployment. If you change the source of a class and your IDE automatically compiles it in the background, the plugin picks up the changed class.

You do not need to assemble the webapp into a WAR, saving time during the development cycle. Once invoked, you can configure the plugin to run continuously, scanning for changes in the project and automatically performing a hot redeploy when necessary. Any changes you make are immediately reflected in the running instance of Jetty, letting you quickly jump from coding to testing, rather than going through the cycle of: code, compile, reassemble, redeploy, test.

... and (may) use the dependencies from the maven repo:

*Note The classpath of the running Jetty instance and its deployed webapp are managed by Maven, and may not be exactly what you expect. For example: a webapp’s dependent jars might be referenced via the local repository, not the WEB-INF/lib directory.

Some of the above mentioned info can also be observed in the log, when running the plugin (running maven with -X aka debug output on, provides more info):

[INFO] Configuring Jetty for project: vaadin-app
[INFO] webAppSourceDirectory not set. Trying src\main\webapp
[INFO] Reload Mechanic: automatic
[INFO] Classes = D:\tmp\test\vaadin-app\target\classes
[DEBUG] Starting Jetty Server ...
[INFO] Context path = /
[INFO] Tmp directory = D:\tmp\test\vaadin-app\target\tmp
[INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
[INFO] Web overrides =  none
[DEBUG] Adding artifact vaadin-server-8.0.6.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact vaadin-sass-compiler-0.9.13.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact sac-1.3.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact flute-1.3.0.gg2.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact vaadin-shared-8.0.6.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact jsoup-1.8.3.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact gentyref-1.2.0.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact vaadin-push-8.0.6.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact atmosphere-runtime-2.4.5.vaadin2.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact vaadin-slf4j-jdk14-1.6.1.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact vaadin-client-compiled-8.0.6.jar with scope compile for WEB-INF/lib 
[DEBUG] Adding artifact vaadin-themes-8.0.6.jar with scope compile for WEB-INF/lib 
[INFO] web.xml file = null
[INFO] Webapp directory = D:\tmp\test\vaadin-app\src\main\webapp
[INFO] Started Jetty Server

However, if you want to build and deploy a packaged war or an exploded one, you can use the jetty:run-war:

This goal first packages your webapp as a WAR file and then deploys it to Jetty. If you set a non-zero scanInterval, Jetty watches your pom.xml and the WAR file; if either changes, it redeploys the war.

... and/or jetty:run-exploded:

The run-exploded goal first assembles your webapp into an exploded WAR file and then deploys it to Jetty. If you set a non-zero scanInterval, Jetty watches your pom.xml,`WEB-INF/lib, WEB-INF/ and WEB-INF/web.xml for changes and redeploys when necessary.

Upvotes: 2

Related Questions