Tim Holloway wrote:
Myself, I'd probably just write a native Android app that opportunistically contacts a web server via REST or Web Services when it can. Less work, smaller footprint.
Tim Holloway wrote:I think there's some confusion here in that the desired goal isn't actually a product that can be executed either as a JAR or a WAR, but just a plain old WAR to execute in a server. So we don't need to worry about a dual-purpose WAR file. Which is good, since the classpaths for JARs and WARs are just different enough to be annoying.
Tim Holloway wrote:These are all Jetty internal classes. Jetty is a J2EE container, which means that unless you're actually customizing Jetty, you shouldn't be using a Main class nor importing any of the org.mortbay.jetty packages, since J2EE requires a WAR and use the javax. enterprise APIs not the Jetty-specific implementations.
Peter Johnson wrote:If you examine an existing executable war file, such as the Jenkins war file, you will notice that it has the attributes of both an executable JAR file and a standard WAR file. Thus if you run it via "java -jar jenkins.war" it runs the enbedded Jetty(?) servlet engine with Jenkins pre-defined. Otherwise, if you deploy it to your favorite app server, it deploys like a standard WAR file.
Wim Vanni wrote:In my understanding a war-file is exclusively for Java Web Application Servers (e.g. Tomcat). In a way they are already 'executable' because when you deploy a war-file on such a server it will auto-unzip/install/configure/whatever the packaged web application.
It is not possible - not to my knowledge at least - to make it executable like you have an executable jar or like certain file extensions (exe, ...) make a file executable on the operating system.
Greg Charles wrote: You have to be careful about buffers and such though.