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] > >
