I have a web application deployed as exploded war using wildfly. What I want to get is
Changes in jsp files are automatically reflected, without redeploying the app
Changes in .class files enforce an app redeployment.
At the moment I am in a situation in which either I can get one option or the other, but not both at the same time (meaning that either every jsp change forces a new deployment or that .class files do not force a new deployment).
Current configuration of wildfly (using version 8.1.0) is
<deployment-scanner
path="deployments"
relative-to="jboss.server.base.dir"
scan-enabled="true"
scan-interval="1000"
auto-deploy-exploded="true"
runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"
/>
...
<servlet-container name="default">
<jsp-config development="true"/>
</servlet-container>
Also, something I have found is that no matter what I set in the deployment-scanner config, once the server is up and running, if I go to the wildfly web console, the parameter auto-deploy-war is marked as true and auto-deploy-exploded is marked as false, even the scan-interval is always set to 5000 ms, which makes me think that the deployment scanner config is somehow being ignored.
I am kind of lost here quite frankly, it has to be possible for wildfly to reload the app if the change is a .class file and not do it if it is a jsp.
Have you tried JRebel? following my blog entries would help also.
http://www.nailedtothex.org/roller/kyle/entry/evaluating-jrebel-for-wildfly-and
http://www.nailedtothex.org/roller/kyle/entry/exploded-deployment-for-wildfly-on
Manik Hot deploy is an open source Maven Plugin that simplifies your web development. The plugin provides both deployment modes - the auto-deployment and also the hot-deployment. It can be easily configured in a maven project by adding the plugin to the pom.xml
....
<build>
<plugins>
.....
<!-- Manik Hotdploy -->
<plugin>
<groupId>org.imixs.maven</groupId>
<artifactId>manik-hotdeploy-maven-plugin</artifactId>
<version>2.0.0</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- List Source and Target folders for Autodeploy and Hotdeploy -->
<autodeployments>
<deployment>
<!-- wildcard deployment -->
<source>target/*.{war,ear,jar}</source>
<target>/opt/wildfly/standalone/deployments/</target>
<unpack>true</unpack>
</deployment>
</autodeployments>
<hotdeployments>
<deployment>
<source>src/main/webapp</source>
<target>/opt/wildfly/standalone//deployments/my-app.war</target>
</deployment>
</hotdeployments>
</configuration>
</plugin>
.....
</plugins>
</build>
....
Related
First of all, i don't know if i wrote the question correctly or not.
I have a dynamic web server that I developed on eclipse, and when I run it on eclipse, using Tomcat 8.0.33 i get this
however, if i compiled and build the project and extracted the war file, then put that war file into the work web apps folder into Tomcat installation directory, and then run Tomcat from terminal using startup.sh, it works perfectly, see please
i tried another version of Tomcat, 8.0.24, and the same problem happened.
i am using eclipse Luna Service Release 2 (4.4.2) on mac os El Captine
Update 1
Maybe because I deleted the web content folder and i am putting my files in src/main/webapp
and that is what I do in pom
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<warSourceDirectory>WebContent</warSourceDirectory>
<failOnMissingWebXml>true</failOnMissingWebXml>
<webResources>
<resource>
<directory>src/main/webapp</directory>
</resource>
</webResources>
</configuration>
</plugin>
Do you think so? if yes how to solve it please ?
If the project is webtools dynamic project, you can edit the file $PROJECT_HOME/.settings/org.eclipse.wst.common.component. Modify the attribute value of source-path of wb-resource element.
<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
<wb-module deploy-name="SemanticRecommenderWebservices">
<wb-resource deploy-path="/" source-path="/src/main/webapp"/>
<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/java"/>
<property name="context-root" value="SemanticRecommenderWebservices"/>
<property name="java-output-path" value="src/main/webapp/WEB-INF/classes"/>
</wb-module>
</project-modules>
The most recent version of the maven plugin has enabled updating of code every 5s, which is a great improvement. But unless I am configuring this wrong, it doesn't seem to pick up static file changes such as work in progress Javascript connecting to the appengine code.
Is there any way to alter this behavior or do I just need to wait for a new release?
Automatic updates cannot be done using appending devserver alone right now. Strictly speaking, we need to wait.
But you can achieve the effect of seamless html/js/css/etc update, hot java code replacement, etc. with the configuration below.
Configure Apache httpd or Nginx to serve static code directly from your war-source and route to app engine for servlets. In my case, all the html are directly accessible from webapp directory and servlets are called via /sim/. Using nginx and 7070 port, my working nginx config looks like:
server {
listen 7070;
root /home/pchauhan/Projects/my-company/my-mvn-gae-project/my-mvn-gae-project-war/src/main/webapp;
location /sim/ {
proxy_pass http://localhost:8080/sim/;
}
}
Use this documentation of nginx, for more configurations.
Configure Eclipse and GAE separately.
Now, you can directly make changes to source and get them on refresh, both for html (via nginx) and servlets (via devserver).
Add this webapp folder to your Chrome Dev Tools, Sources Workspace and life will be easier. Small changes can directly be saved from chrome to src via ctrl
Please note, that while this is great, you should test your app once solely on 8080 (devserver port) before uploading, just in case there is a bug in maven config and target is not being created/served correctly.
Alternate Idea for syncing: If you do not want to use nginx/httpd for some reason, you can add target...webapp to chrome workspace, work directly there for seamless updt and then use lsyncd to sync target back to src. I haven't tried it yet, but looks feasible, albeit a bit risky.
So far, best way i found was configuring below entries in pom.xml. This will build automatically your static files and reflects on the page.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<property name="target.webapp.dir"
value="${project.build.directory}/${project.build.finalName}" />
<property name="src.webapp.dir" value="${basedir}/src/main/webapp" />
<sync verbose="true" todir="${target.webapp.dir}"
includeEmptyDirs="true">
<fileset dir="${src.webapp.dir}" />
<preserveintarget>
<include name="WEB-INF/lib/**" />
<include name="WEB-INF/classes/**" />
<include name="WEB-INF/appengine-generated/**" />
</preserveintarget>
</sync>
<!-- <sync verbose="true" todir="${target.webapp.dir}/WEB-INF/classes">
<fileset dir="${basedir}/target/classes" /> </sync> -->
</target>
</configuration>
</execution>
</executions>
</plugin>
And another entry after
<pluginManagement>
<plugins>
<!-- This plugin's configuration is used to store Eclipse m2e settings
only. It has no influence on the Maven build itself. -->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<versionRange>[1.6,)</versionRange>
<goals>
<goal>run</goal>
</goals>
</pluginExecutionFilter>
<action>
<execute>
<runOnIncremental>true</runOnIncremental>
</execute>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
This is working fine. As soon as any static files changed and saved, it got reflected on the page.
Like PoojaC20, I have also not been able to get this working with devserver alone but I ended up with a different workaround which I thought I'd share in case others found it helpful.
I now host my development static files outside of the GAE devserver by using grunt-serve. This allows a large number of advantages including:
Automatic page refresh when static files have changed - don't even need to press the refresh button.
Automatic conversion of advanced CSS such as LESS
Automatic conversion of javascript-compileable languages such as CoffeeScript
Mechanism for minification and CDN-ification when development is done.
The most profound implication of the above is that I have needed to move away from session based authentication to OAuth or OpenID Connect based authentication systems and to make all of my web service calls CORS compatible. This is some work, but it too has one very profound advantage:
Once your web sever has moved to OpenID Connect based authentication, it can now connect identically to native (e.g. mobile) client or web based clients!
I have Java EE project in which I use Arquillian tests with JUnit on JBoss 7 (Windows). Tests are working fine however I cannot debug them.
From what I've googled (https://community.jboss.org/wiki/WhyDontBreakPointsWorkWhenDebugging) I understand that Arquillian tests are being run in separate VM therefore IntelliJ cannot debug them. I need IntelliJ to connect to that machine remotely over socket but I dont know how to do it.
I found this thread: Debugging with Arquillian in IntelliJ - Managed Container However I dont know how to get it work.
Also I stepped over this thread: http://devnet.jetbrains.com/message/5253623?tstart=0 so I filled hopefully appropriet surefire part in my pom.xml but it didnt help:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<debugForkedProcess>true</debugForkedProcess>
<skip>false</skip>
</configuration>
</plugin>
Could anyone guild me please how to debug tests in such configuration?
First of all depend on the container type you are using - managed, remote or embedded. See also https://docs.jboss.org/author/display/ARQ/Containers. For the latter the tests are running in the same JVM and you can for example debug your test directly in the IDE.
The Surefire configuration is in this case not important, because you want to debug in your IDE (unless you are executing maven goals from within your IDE).
For managed and remote containers you need to debug the actual container. For this to wrok you have to pass the right JVM options to the remote container, so that you can open a remote debugging session. One way of doing this is via arquillian.xml:
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<!-- Need to set the default protocol and use resource filtering, because of https://issues.jboss.org/browse/ARQ-579 -->
<defaultProtocol type="Servlet 3.0"/>
<engine>
<property name="deploymentExportPath">target/artifacts</property>
</engine>
<container qualifier="incontainer">
<configuration>
<property name="jbossHome">${jbossTargetDir}</property>
<property name="javaVmArguments">-Xmx1024m -XX:MaxPermSize=512m -Xnoagent -Djava.compiler=NONE -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005</property>
<property name="allowConnectingToRunningServer">true</property>
</configuration>
</container>
The important part in the example above being the javaVmArguments.
I can run Arqullian tests by either Maven or by IntelliJ. I use embedded container. The most important thing is to configure the JBoss home at arqullian.xml nor just at the Maven configuration to IntelliJ know where the JBoss home is.
<arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/schema/arquillian
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<engine>
<property name="deploymentExportPath">testing/target/artifacts</property>
</engine>
<container qualifier="jbossas-managed" default="true">
<configuration>
<!-- JBoss embedded does not use this property
<property name="javaVmArguments">-java.util.logging.manager=org.jboss.logmanager.LogManager -Xmx512m -XX:MaxPermSize=256m -Djava.util.logging.manager=org.jboss.logmanager.LogManager</property>
-->
<property name="jbossHome">target/wildfly-8.1.0.Final</property>
<property name="modulePath">target/wildfly-8.1.0.Final/modules</property>
<property name="allowConnectingToRunningServer">true</property>
</configuration>
</container>
IMPORTANT for debugging and running test in IntelliJ:
From some reason you must specify the logging manager to be able run embedded JBoss. For Maven it is easy and you can set it to configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- Fork every test because it will launch a separate AS instance -->
<forkMode>always</forkMode>
<systemPropertyVariables>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
</systemPropertyVariables>
<redirectTestOutputToFile>false</redirectTestOutputToFile>
</configuration>
</plugin>
But the IntelliJ does not care about these plugin configuration at Maven and you must set it directly at the test case configuration. I did not find better solution. The embedded container does not care about Java VM configuration in arqullian.xml.
Here is always possibility to debug throught remote debugging. I like to do it at IDE. For me it is more confortable way. When you want to enable remote debugging you must set configuration to JAVA_OPT for embedded container nor at arqullian.xml.
Till now, our web application supports only English. Now we have to provide support for Italian as well. There is GWT module for some functionality. To support the Italian language I have added below line in the file "APP_Module.gwt.xml"
<extend-property name="locale" values="it"/>
I have also placed "XXX_it.properties" file under the source code where the properties file for en is kept.
Setting the locale in the jsp by following line:
<meta name="gwt:property" content="locale=${locale}">
Now, the issue is how to compile the code. I am debugging the application but it is not hitting the client code of GWT presented under WEB-INF/src.
I am very new to GWT. Please suggest how can I compile the code or there is no need of compilation. It will automatically take the changes done in "APP_Module.gwt.xml" and there is some other issue. How can I see logs of GWT?
To add support for locales to GWT application, you need to do the following in your xxx.gwt.xml:
under <module> add this to include the support:
<inherits name="com.google.gwt.i18n.I18N" />
and this to configure it:
<extend-property name="locale" values="en,it"/>
<set-property-fallback name="locale" value="en"/>
Add all your property files under some package like this:
src/main/resources/foo/bar/client/i18n/MyMessages.properties
src/main/resources/foo/bar/client/i18n/MyMessages_it.properties
Then you need to tell GWT to compile them into classes. This is example from a pom.xml file (if you don't use maven, you will have to use a different way, but you still need to configure it).
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3.1.google</version>
<executions>
<execution>
<goals>
<goal>i18n</goal>
<goal>generateAsync</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
<configuration>
<i18nMessagesBundles>
<resourceBundle>foo.bar.client.i18n.MyMessages</resourceBundle>
</i18nMessagesBundles>
</configuration>
</plugin>
Then you need to recompile the code. In maven mvn compile. And that's all, you will have your messages in generated sources folder ready to use.
For seeing the logs of gwt you can use gradlew gwt also you can use it to compile the code too.
I'm trying to make an "executable" war file (java -jar myWarFile.war) that will start up a Jetty webserver that hosts the webapp contained in the WAR file I executed.
I found a page that described how to make what I'm looking for:
However, following that advice along with how I think I'm supposed to make an executable jar (war) isn't working.
I have an Ant task creating a WAR file with a manifest that looks like:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 1.5.0_18-b02 (Sun Microsystems Inc.)
Main-Class: Start
The contents of the WAR file look like:
> Start.class
> jsp
> build.jsp
> META-INF
> MANIFEST.MF
> WEB-INF
> lib
> jetty-6.1.22.jar
> jetty-util.6.1.22.jar
When I try to execute the WAR file, the error is:
Exception in thread "main" java.lang.NoClassDefFoundError: org/mortbay/jetty/Handler
Caused by: java.lang.ClassNotFoundException: org.mortbay.jetty.Handler
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: Start. Program will exit.
There appears to be two errors here: one where it seems the JAR files can't be found, and one where the Start class can't be found.
To fix the first one, I put the Jetty JAR files in the base of the WAR file and tried again -- same error. I also tried adding the WEB-INF/lib/<specific-JAR-files> to the Class-Path attribute of the manifest. That did not work either.
Does anyone have any insight as to what I'm doing right/wrong and how I can get this executable WAR file up and running?
The link you have in your question provides most of what you need. However, there are a few things that need to be done in addition to that.
Any class files that Jetty needs to start up will need to be located at the root of the war file when it's packaged. We can leverage Ant to do that for us before we <war> the file. The war's manifest file will also need a Main-Class attribute to execute the server.
Here's a step-by-step:
Create your Jetty server class:
This is adapted from the link you provided.
package com.mycompany.myapp;
import java.io.File;
import java.net.URL;
import java.security.ProtectionDomain;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.webapp.WebAppContext;
public final class EmbeddedJettyServer
{
public static void main(String[] args) throws Exception
{
int port = Integer.parseInt(System.getProperty("port", "8080"));
Server server = new Server(port);
ProtectionDomain domain = EmbeddedJettyServer.class.getProtectionDomain();
URL location = domain.getCodeSource().getLocation();
WebAppContext webapp = new WebAppContext();
webapp.setContextPath("/");
webapp.setDescriptor(location.toExternalForm() + "/WEB-INF/web.xml");
webapp.setServer(server);
webapp.setWar(location.toExternalForm());
// (Optional) Set the directory the war will extract to.
// If not set, java.io.tmpdir will be used, which can cause problems
// if the temp directory gets cleaned periodically.
// Your build scripts should remove this directory between deployments
webapp.setTempDirectory(new File("/path/to/webapp-directory"));
server.setHandler(webapp);
server.start();
server.join();
}
}
To see what all you can configure here, have a look at the Jetty API documentation.
Build the war with Ant:
This uses a staging directory to unpack the necessary class files into the root of the war so they're accessible when the war is executed.
<target name="war" description="--> Creates self-executing war">
<property name="staging.dir" location="${basedir}/staging"/>
<property name="webapp.dir" location="${basedir}/src/webapp"/>
<mkdir dir="${staging.dir}"/>
<!-- assumes you have all of your war content (excluding classes and libraries) already structured in a directory called src/webapp -->
<!-- e.g. -->
<!-- src/webapp/index.html -->
<!-- src/webapp/WEB-INF/web.xml -->
<!-- src/webapp/WEB-INF/classes/my.properties -->
<!-- etc ... -->
<copy todir="${staging.dir}">
<fileset dir="${webapp.dir}" includes="**/*"/>
</copy>
<unjar dest="${staging.dir}">
<!-- you'll have to locate these jars or appropriate versions; note that these include JSP support -->
<!-- you might find some of them in the downloaded Jetty .tgz -->
<fileset dir="path/to/jetty/jars">
<include name="ant-1.6.5.jar"/>
<include name="core-3.1.1.jar"/>
<include name="jetty-6.1.24.jar"/>
<include name="jsp-2.1-glassfish-2.1.v20091210.jar"/><!-- your JSP implementation may vary -->
<include name="jsp-api-2.1-glassfish-2.1.v20091210.jar"/><!-- your JSP implementation may vary -->
<include name="servlet-api-2.5-20081211.jar"/><!-- your Servlet API implementation may vary -->
</fileset>
<patternset><!-- to exclude some of the stuff we don't really need -->
<exclude name="META-INF/**/*"/>
<exclude name="images/**/*"/>
<exclude name=".options"/>
<exclude name="about.html"/>
<exclude name="jdtCompilerAdapter.jar"/>
<exclude name="plugin*"/>
</patternset>
</unjar>
<!-- copy in the class file built from the above EmbeddedJettyServer.java -->
<copy todir="${staging.dir}">
<fileset dir="path/to/classes/dir" includes="com/mycompany/myapp/EmbeddedJettyServer.class"/>
</copy>
<war destfile="myapp.war" webxml="${webapp.dir}/WEB-INF/web.xml">
<fileset dir="${staging.dir}" includes="**/*"/>
<classes dir="path/to/classes/dir"/><!-- your application classes -->
<lib dir="path/to/lib/dir"/><!-- application dependency jars -->
<manifest>
<!-- add the Main-Class attribute that will execute our server class -->
<attribute name="Main-Class" value="com.mycompany.myapp.EmbeddedJettyServer"/>
</manifest>
</war>
<delete dir="${staging.dir}"/>
</target>
Execute the war:
If everything's set up properly above, you should be able to:
java -jar myapp.war
// or if you want to configure the port (since we are using the System property in the code)
java -Dport=8443 -jar myapp.war
This is an adaptation for Maven of #RobHruska's answer. It just copies the files of the main class and merges the Jetty JAR files into the WAR file, nothing new, just to simplify your life if you are new -like me- to Maven:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>move-main-class</id>
<phase>compile</phase>
<configuration>
<tasks>
<copy todir="${project.build.directory}/${project.build.finalName}">
<fileset dir="${project.build.directory}/${project.build.finalName}/WEB-INF/classes/">
<include name="main/*.class" />
</fileset>
</copy>
<unjar dest="${project.build.directory}/${project.build.finalName}">
<!-- you'll have to locate these jars or appropriate versions; note that these include JSP support -->
<!-- you might find some of them in the downloaded Jetty .tgz -->
<fileset dir="${project.build.directory}/${project.build.finalName}/WEB-INF/lib/">
<include name="ant-1.6.5.jar"/>
<!--<include name="core-3.1.1.jar"/>-->
<include name="jetty*"/>
<include name="servlet-api*"/>
</fileset>
<patternset><!-- to exclude some of the stuff we don't really need -->
<exclude name="META-INF/**/*"/>
<exclude name="images/**/*"/>
<exclude name=".options"/>
<exclude name="about.html"/>
<exclude name="jdtCompilerAdapter.jar"/>
<exclude name="plugin*"/>
</patternset>
</unjar>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<archiveClasses>true</archiveClasses>
<archive>
<manifest>
<mainClass>main.Main</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
We have figured this out by using jetty-console-maven-plugin.
Whenever you run mvn package it creates another war that can be used with java -jar whateverpackage-runnable.war
<plugin>
<groupId>org.simplericity.jettyconsole</groupId>
<artifactId>jetty-console-maven-plugin</artifactId>
<version>1.45</version>
<executions>
<execution>
<goals>
<goal>createconsole</goal>
</goals>
</execution>
</executions>
<configuration>
<additionalDependencies>
<additionalDependency>
<artifactId>jetty-console-requestlog-plugin</artifactId>
</additionalDependency>
<additionalDependency>
<artifactId>jetty-console-gzip-plugin</artifactId>
</additionalDependency>
<additionalDependency>
<artifactId>jetty-console-ajp-plugin</artifactId>
</additionalDependency>
<additionalDependency>
<artifactId>jetty-console-startstop-plugin</artifactId>
</additionalDependency>
</additionalDependencies>
</configuration>
</plugin>
It also generates the init.d scripts and everything for you!
Hudson solves this exact problem using the Winstone servlet container, which supports this use case directly. http://winstone.sourceforge.net/#embedding
Perhaps this would work for you?
Even though this is kind of old another alternative with Jetty 8 is to simply include the Jetty jars as dependencies in your pom and add the following in your pom (versus an ant script that unpackages the war and repackages it):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createDependencyReducedPom>true</createDependencyReducedPom>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>JettyStandaloneMain</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
<!-- The main class needs to be in the root of the war in order to be
runnable -->
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>move-main-class</id>
<phase>compile</phase>
<configuration>
<tasks>
<move todir="${project.build.directory}/${project.build.finalName}">
<fileset dir="${project.build.directory}/classes/">
<include name="JettyStandaloneMain.class" />
</fileset>
</move>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
I take it that by "without maven" you want a jar that you can run by itself and not with "mvn jetty:run"--not that you don't want to use maven at all.
It took me way to long to figure this out because I found many options--none of them dirt simple. Eventually I found this maven plugin from simplericity. It works wonderfully.
This is my example ANT extract. The idea is to unpackage the Jetty dependencies and then include them locally just like a normal JAR file:
<!-- Hack: Java doesn't support jars within jars/wars -->
<unjar src="${lib.dir}/container/jetty.jar" dest="${build.dir}/unjar"/>
<unjar src="${lib.dir}/container/jetty-util.jar" dest="${build.dir}/unjar"/>
<unjar src="${lib.dir}/container/servlet-api.jar" dest="${build.dir}/unjar"/>
<unjar src="${lib.dir}/container/jsp-api.jar" dest="${build.dir}/unjar"/>
<!-- Build war file as normal, just including the compiled and unjar'ed files -->
<war destfile="${war.file}" webxml="${config.dir}/web.xml">
<fileset dir="${build.dir}/classes"/>
<fileset dir="${build.dir}/unjar"/>
<fileset dir="${resources.dir}" excludes="*.swp"/>
<lib dir="${lib.dir}/runtime"/>
<manifest>
<attribute name="Main-Class" value="Start"/>
</manifest>
</war>
Note:
The WEB-INF/lib direcory is for the web applications dependencies. In this case we're packaging the WAR file so that it works like the normal Jetty JAR file on startup
Putting .jars inside a .war file root does nothing
Putting .jars inside WEB-INF/lib doesn't help the JVM find the Jetty files to even begin launching your .war. It's "too late" to put them there.
Putting .jars in the manifest Class-Path only works for external .jar files, not those contained in the .jar
So what to do?
Use a build script to simply merge all the .jar files you need into the .war file. This takes a little extra work. It's also a bit ugly in that the compiled code is part of the servable files in the .war
Add dependent .jars to the JVM's classpath with "java -cp jetty.jar:... ..." Works though this kind of defeats the purpose of one stand-alone .war
I have done a similar thing before but are you launchign the app as "java -jar xxx.war" ?. You have only 2 jars and it is not going to be enough I think. Also try using Jetty 7.0.0M1 (which is the latest version). When I added jetty-server and jetty-webapp as two dependencies (they are from org.eclipse.jetty) I get the following jar's in the lib directory. FYI the org.mortbay.jetty.Handler was in the jetty-server*.jar.
jetty-continuation-7.0.0.M1.jar
jetty-http-7.0.0.M1.jar
jetty-io-7.0.0.M1.jar
jetty-security-7.0.0.M1.jar
jetty-server-7.0.0.M1.jar
jetty-servlet-7.0.0.M1.jar
jetty-util-7.0.0.M1.jar
jetty-webapp-7.0.0.M1.jar
jetty-xml-7.0.0.M1.jar