deployment in runtime for "provided" scope jars

[Lin Ma <li...@gmail.com>]

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.

thanks in advance,
Lin

Re: deployment in runtime for "provided" scope jars

[Lin Ma <li...@gmail.com>]

Thanks Jörg!

regards,
Lin

On Tue, Apr 7, 2015 at 12:48 AM, Jörg Schaible <joerg.schaible@swisspost.com
> wrote:

> Hi Lin,
>
> Lin Ma wrote:
>
> > 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?
>
> No. Both goals refer the Maven repository. "install" will copy the result
> of
> your project into your local repository while "deploy" will copy this stuff
> to a remote repository instead (depends on your settings in the
> distributionManagement) to make the artifacts available for other people.
> It
> has nothing to do at all with deployment of an application.
>
> > BTW, in the context of a Java jar console application.
>
> That's what IzPack may do for you.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: deployment in runtime for "provided" scope jars

[Jörg Schaible <jo...@swisspost.com>]

Hi Lin,

Lin Ma wrote:

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

No. Both goals refer the Maven repository. "install" will copy the result of 
your project into your local repository while "deploy" will copy this stuff 
to a remote repository instead (depends on your settings in the 
distributionManagement) to make the artifacts available for other people. It 
has nothing to do at all with deployment of an application.

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

That's what IzPack may do for you.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: deployment in runtime for "provided" scope jars

[Lin Ma <li...@gmail.com>]

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 <ct...@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 <li...@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 <jo...@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
>
>

Re: deployment in runtime for "provided" scope jars

[Ron Wheeler <rw...@artifact-software.com>]

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 <ct...@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 <li...@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 <jo...@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

Re: deployment in runtime for "provided" scope jars

[Lin Ma <li...@gmail.com>]

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 <ct...@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 <li...@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 <jo...@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
>
>

Re: deployment in runtime for "provided" scope jars

[Christopher <ct...@apache.org>]

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 <li...@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 <jo...@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

Re: deployment in runtime for "provided" scope jars

[Lin Ma <li...@gmail.com>]

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 <jo...@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
>
>

Re: deployment in runtime for "provided" scope jars

[Jörg Schaible <jo...@gmx.de>]

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