Why not use a proper installer so that the user can run something
user-friendly that knows how to deploy your jars and do any deploy-time
configurations so the user does not need to know how your application works.
For example: In Windows, you would like to have your code in Program
Files and your configuration and data in a folder of the user's choosing.
In Linux, you might want code in /usr/local/myapp with the data under
/home or /var.
Maven is not going to be able to build you something that will do this.
IzPack is free and supports Maven. It also allows you to build an
installer that works on different platforms.
Other packages are available to build installers as well.
Maven is a great build system but not the best tool for packaging up
artifacts for deployment.
This leads to a lot of unhappy people.
Ron
On 06/04/2015 11:28 PM, Lin Ma wrote:
Thanks Christopher,
I am packaging a standalone console application so your suggestion below is
more suitable. Is there an example to refer to how to
configure maven-assembly-plugin to create a tar ball and a launch script?
"If you're trying to package a standalone application, maybe use the
maven-assembly-plugin to create a tarball which includes a README, all the
jars in a lib/ directory, and a launch script in bin/ which sets up the
CLASSPATH and executes java."
regards,
Lin
On Mon, Apr 6, 2015 at 7:11 PM, Christopher <[email protected]> wrote:
To add to what Jörg said, it is my understanding that a dependency of
your project marked as "provided" implies something about how you
intend to package it in the artifacts you create. "provided"
essentially means you don't intend to package (assemble) it (and you
expect it to be provided by the target runtime environment).
I would generally avoid "provided" entirely (because it's typically
misused), and rely on more explicit means of determining what will be
packaged/bundled/assembled into your final artifacts (the notable
exception being the servlet-api, which Jörg already mentioned).
"compile" scope for a dependency simply means that you use that
artifacts' API in your project (for example, perhaps slf4j-api).
"runtime" means that you don't need that dependency's API for your
code to compile, but it will be needed at runtime for your code to
work properly (for example, slf4j-log4j12, or perhaps a codec which is
loaded dynamically by your code, based on an annotation or class
name). "runtime" scoped artifacts can often be made "optional"
(<optional>true</optional>), because your code may work without them,
and other projects depending on your artifacts do not necessarily need
them.
Regarding "deploy them into runtime", I think you're talking about
packaging. There are several ways you can package your artifacts. You
can package it as a JAR, or a WAR. You could also use the
maven-assembly-plugin to package it into a ZIP or tarball (.tar.gz).
The maven-shade-plugin could be useful for creating a "fat jar", and
there are probably many other options also. To decide, consider what
your target environment needs. If you're trying to package a
standalone application, maybe use the maven-assembly-plugin to create
a tarball which includes a README, all the jars in a lib/ directory,
and a launch script in bin/ which sets up the CLASSPATH and executes
java.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Apr 6, 2015 at 9:21 PM, Lin Ma <[email protected]> wrote:
Thanks Jörg,
It makes sense. How about for "compile" scope? What is the best practices
to deploy them into runtime along with application code? Thanks.
regards,
Lin
On Mon, Apr 6, 2015 at 6:09 PM, Jörg Schaible <[email protected]>
wrote:
Lin Ma wrote:
Hi Maven expert,
I think Maven is good for build, and not sure if cover runtime
deployment
well. Wondering what is the best practices for deploy "provided" scope
jars?
Currently, I either build a fat jar, or manual copy external
dependencies
jars into class path.
And better solutions is appreciated.
Don't declare them as "provided".
See, "provided" means, such a dependency is already present in the
target
environment of the application. E.g. a web application can assume that
the
application server provides servlet-api if it is compliant with the
specification.
Otherwise, "provided" is simply wrong.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
