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]
