maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Ma <lin...@gmail.com>
Subject Re: deployment in runtime for "provided" scope jars
Date Tue, 07 Apr 2015 03:28:30 GMT
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 <ctubbsii@apache.org> 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 <linlma@gmail.com> 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 <joerg.schaible@gmx.de>
> 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message