We can pass arguments like '--list-config', '--list-classpath', etc. when using Jetty's start.jar as shown at http://www.eclipse.org/jetty/documentation/9.2.8.v20150217/startup-classpath.html and http://www.eclipse.org/jetty/documentation/current/startup.html
I was wondering how could I pass them on while using Jetty Maven plugin. I tried < jvmArgs > and run-forked but that didn't work.
jetty-maven-plugin is just an embedded-jetty for Maven plugins.
It is unrelated to the jetty-distribution's start.jar standalone operation.
For the jetty-maven-plugin there is no Server Classpath, just the maven plugin's own Classpath, determined by maven, gleaned from the effective pom (pom hierarchy) of your maven build. Use maven's --debug to see the plugin classpath during the execution of that plugin's phase (note: the classpath can change between different phases)
The configuration is also part of the phase that the jetty-maven-plugin executes with. Again, use the --debug from maven to see that configuration.
The configuration you see from start.jar --list-config is 100% in the scope of the start.jar determination from the configuration information starting at ${jetty.base}/start.ini, and the selected jetty modules, along with your properties to build up a Jetty instance, a "pre-start" configuration that start.jar will execute to build up a Jetty instance.
Its like you are asking how to understand a bicycle (jetty-maven-plugin) by looking at an technical specifications manual for motorcycle (start.jar). There is only inconsequential overlap between the two: 2 wheels of approximately the same size, with handlebars, and a seat.
Yes, the differences between jetty-maven-plugin and start.jar configuration and startup are that vast.
Related
I am running an open source piece of software (https://github.com/att/XACML) and the documentation says to use maven jetty to run the application. This works fine.
However, I am trying to run it without maven as a dependency, so I am thinking of using the generated war and deploying it with jetty. However, this approach gives me errors specific to the war (can not instantiate null etc.) that do not sure up when running maven jetty.
So my question is: how does maven jetty package the war? Is there anything it does at runtime that would make it different than just trying to deploy the war on its own? What is the difference between using maven jetty and using something like jetty runner with the war generated from maven clean install?
Jetty does not package a war.
Maven does, and you need ...
Your project's pom.xml should be declared as <packaging>war</packaging>
You have a src/main/webapp directory.
You have maven execute the package phase.
When you use something like mvn jetty:run-war the first thing that happens is the package phase executes, THEN the jetty:run-war goal executes.
See: JettyRunWarMojo.java
#Mojo(name = "run-war",
requiresDependencyResolution = ResolutionScope.COMPILE_PLUS_RUNTIME)
#Execute(phase = LifecyclePhase.PACKAGE)
public class JettyRunWarMojo extends AbstractMojo
Jetty is not doing the packaging of war, Maven and it's default package phase is (and the behaviors here are determined by the standard maven lifecycle defined by your <packaging>war</packaging>)
See: https://maven.apache.org/ref/3.2.2/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging
I know it may sound silly question but I am unable to understand the difference between mvn spring-boot:run and java -jar (.jar file generated with mvn install)
I have a spring boot application with jsp pages in /src/main/resources/META-INF/resources/WEB-INF/. If I use mvn spring-boot:run these pages are served. But If I use java -jar these pages are not found by application.
The application that I am working on is at https://github.com/ArslanAnjum/angularSpringApi
UPDATE:
It works with spring boot 1.4.2.RELEASE while I intend to use the latest version i.e., 1.5.8.RELEASE.
UPDATE:
Well I solved the problem by putting jsps in src/main/webapp/WEB-INF/views/ and changing packaging type to war and then running this war using java -jar target/myapp.war and its working fine now.
Short answer: spring-boot:run is a java -jar command on steroïd running as part of your Maven build, ensuring all required parameters are passed to your app (such as resources). spring-boot:run will also ensure that your project is compiled by executing test-compile lifecycle goals prior to running your app.
Long answer:
When you run java -jar, you launch a new JVM instance with all the parameters you passed to this JVM. For example, using the Spring doc example
java -Xdebug -Xrunjdwp:server=y, \
transport=dt_socket, address=8000, suspend=
-jar target/myproject-0.0.1-SNAPSHOT.jar
You will launch a brand new JVM with the given parameters. You need to make sure to include everything needed, such as classpath elements, application parameters, JVM options, etc. on the command line.
When you run mvn spring-boot:run, you launch a Maven build that will:
Run the test-compile lifecycle goals, by default it will be resources:resources, compiler:compile, resources:testResources, compiler:testCompile goals of the Maven Resources and Compiler plugin.
Launch your application with a bunch of parameters that will depend on the
Spring Boot Maven Plugin configuration you defined in your project (your pom.xml, parents and settings, command line, etc.). This includes among other things:
A lot of classpath elements: your target/classes folder which may contain resources and libraries required by your app, your Maven dependencies, etc.
Whether to fork your JVM or not (whether to create a brand new JVM to run your app or re-use the JVM of the Maven build), see fork and agent parameter of the plugin
As per:
I have a spring boot application with jsp pages in
/src/main/resources/META-INF/resources/WEB-INF/. If I use mvn
spring-boot:run these pages are served. But If I use java -jar these
pages are not found by application.
It's because the mvn spring:boot command will make sure your target/classes folder is present in the Classpath when your app is running. After compilation, this folder will contain target/classes/META-INF/resources/WEB-INF among other things. Your app will then be able to find META-INF/resources/WEB-INF and load them when asked. When you ran java -jar command, this folder was probably not on the classpath, your app was then not able to find your resources. (these resources were copied from the src/main/resources folder during the resources:resources goal)
To have a similar result with your java -jar command, you must include your resources on the classpath such as javar -jar myapp.jar -cp $CLASSPATH;/path/to/my/project/target/classes/
Have you tried creating a jar file using mvn package instead of mvn install when you are running jar file using java -jar? package will create a jar/war as per your POM file whereas install will install generated jar file to the local repository for other dependencies if present.
I'm trying to run 'mvn clean install' in a sub-module of a multi-module project. The project is Jacoco but I assume it's more an issue of me not understanding how Maven is being used here than an issue with Jacoco itself.
https://github.com/jacoco/jacoco/blob/master/jacoco-maven-plugin.test/it/it-site/pom.xml
I get the following error:
[ERROR] Plugin #project.groupId#:jacoco-maven-plugin:#project.version#
or one of its dependencies could not be resolved: Failed to read
artifact descriptor for
#project.groupId#:jacoco-maven-plugin:jar:#project.version#
I see the following in the pom:
<groupId>#project.groupId#</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
I'm not familiar with using the # symbol in #project.groupId# although i assume it is somehow supposed to get substituted at runtime.
I can run Maven from the top level pom and I even see [INFO] Building: it-site/pom.xml in the log but a target directory is not created there.
A nudge in the right direction would be appreciated.
This probably has something to do with the pom file here: https://github.com/jacoco/jacoco/blob/master/jacoco-maven-plugin.test/pom.xml
It is using a plugin called the maven invoker.
The Invoker Plugin is used to run a set of Maven projects. The plugin can determine whether each project execution is successful, and optionally can verify the output generated from a given project execution.
And if you read about filtering files with this plugin, it mentions:
POM files selected by the include/exclude patterns. The tokens to be filtered must be enclosed in #...# to avoid interferences with Maven's normal POM interpolation, i.e. use #project.version# instead of ${project.version}.
Regarding why the Invoker Plugin and filtering is being used here...
The Spring Boot documentation provides some relevant background on why that is. Although the docs are for Spring Boot, i think it applies to testing all plugins (which Jacoco is).
Multi-module Maven builds cannot directly include maven plugins that
are part of the reactor unless they have previously been built. ...
The standard build works around this restriction by launching the
samples via the maven-invoker-plugin so that they are not part of the
reactor.
The sample application are used as integration tests during the build
(when you mvn install). Due to the fact that they make use of the
spring-boot-maven-plugin they cannot be called directly, and so
instead are launched via the maven-invoker-plugin.
My library requires me to bootstrap the JVM in order to run it. In case you do not know, if you pass a jar to the JVM with the -bootstrap option, you can override (substitute) any Java library implementation like java.lang.String, etc.
So all I need to do is tell Maven that when it runs my tests it include the -bootclasspath option with my jar/classes.
Is that possible with Maven? Maybe maven will have to bootstrap itself, if the JVM is not able to add new bootstrap classes on-the-fly as it is able to add new classes/jar to the classpath?
Have you tried the argLine and the forkMode parameters of the surefire plugin?
I'm using Maven to manage my build. For developer testing I use Jetty which I launch using the jetty:run goal in the Jetty Maven plugin. I should also note that I have war:exploded running in an earlier phase which builds the directory that Jetty runs against.
The problem I'm having is that the war:exploded task puts the build dependencies into WEB-INF/lib (as it should) and furthermore, Maven appears to be feeding Jetty the build classpath via the system classloader. This leads to every jar getting loaded twice which should be OK except that, sadly, the Datanucleus library throw an exception the second time it gets loaded onto the classpath.
The only solution I can think of at the moment is to create two profiles, a build profile and a developer test profile. The developer test profile would exclude all the dependencies and jetty:run would run in the developer test profile. This seems like a lot of configuration for something I think would be simple.
Does anyone know if there is a way to prevent Maven from loading the build classpath into Jetty?
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<configuration>
<useTestClasspath>true</useTestClasspath>
...
The option "useTestClasspath" should have the effect you are looking for.