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 07:13:25 GMT
Thanks Ron,

I see Maven has phase like install and deploy, but I never used them
before. Are the two phases suppose to do deployment work, which copy
application jar and dependency jars to destination host, and setup other
environment variable like classpath?

BTW, in the context of a Java jar console application.

regards,
Lin

On Mon, Apr 6, 2015 at 11:20 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> 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 <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
>>>
>>>
>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ---------------------------------------------------------------------
> 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