maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: deployment in runtime for "provided" scope jars
Date Tue, 07 Apr 2015 02:11:44 GMT
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
View raw message