AW: AW: mvn release:prepare does not update parent version

[Markus Karg]

Martin,

thanks for your ideas, but...

>MG the previous email was an attempt to explain prepare-mojo will update 
>current or children artifacts but not parent artifacts

I agree that the docs do not say anything about the parent, but my question is 
not about the docs, it is about this question the plugin is actually asking:

"Resolve Project Dependency Snapshots.: 'my.group:my-parent' set to release? 
(yes/no) yes: yes
What is the next development version?  (1.1-SNAPSHOT) 1.1-SNAPSHOT: "

"my.group:my-parent" *is the parent*. So why does this plugin ask this 
question? *That* is my question! :-)

Also, I do not want to use another third-party plugin to update the parent at 
every *deploy*. I only want the parent to be corrected to that level the Maven 
Release Plugin suggests automatically *when preparing the release* (and only 
then!). So unless prepare-release is a phase (which I am not aware of) your 
suggested trick is not a solution to my actual problem. :-(

Thanks!
-Markus

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

Custom MANIFEST.MF maven-ejb-plugin

[Surendran Duraisamy]

Hi,
How can I generate custom class-path: entries in my maven-ejb-plugin.

I have 3 jar A.jar, B.jar and C.jar in my maven dependency pom.xml. I 
need to put only B.jar and C.jar in my Class-Path: entries of my MANIFEST.


I cannot use dependency scope provided as my project is referred by 
another project which require dependency scope compile.


Is there any filters in maven-ejb-plugin or I exclude only specific 
entries in my maven-ejb-plugin.


Thanks,


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

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Barrie Treloar]

On 8 November 2013 08:32, Alexander Kriegisch
> nexus for myself. But imagine a situation in which all I want to have as a 
> precondition for building a tiny little OSS tool with external (non-Maven 
> dependencies) is a working Maven installation and one command: mvn install. I 
> do not want to put the burden on my users to create their own Nexus or 
> manually download dependencies and install them to the local repo.

Who are your users?

If they are internal to you company then you solve that by using your
company's internal Maven Repository Manager.

If they are users on the internet then you solve that by getting your
dependencies into Central. Which is Solution #1.
What that post is missing is how to get your external jars into
Central, which is documented at
http://maven.apache.org/guides/mini/guide-central-repository-upload.html.

This requires your dependencies by open source. It does not rely on
the developers of that dependency to upload it to central.  If they
are being recalcitrant then you can upload it for the benefit of
everyone else.

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

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Stephen Connolly]

On Thursday, 7 November 2013, Curtis Rueden wrote:

> Hi Alexander,
>
> > do you have any suggestion how to solve this problem in a clean,
> > canonical Maven way, given a single condition: no private Nexus or
> > external Maven repo is available and I want one-stop shopping and
> > clean bootstrapping right from Maven.
>
> The blog post linked earlier answers exactly this question.
>
> The solutions it outlines to this problem are, in order of "best for the
> Maven community to worst for the Maven community":
>
> 1.Get thee to Central
> 2. Get the external jars into a public Maven repository
> 3. Get the external jars into the internal Maven repository
> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> 5. Use an ANT task
> [Everything after this point is "Donny Don't".]
> 6. The file:///${basedir} repository hack
> 7. The system scope hack
>
> Options 1 & 2 require communication with the third party library
> developers, which presumably is untenable for you. You have also rejected
> #3 ("I kinda dislike manually uploading external JARs there"), which leaves
> #4 as your next-best option.
>
> Regards,
> Curtis
>
> P.S. I am intrigued by your current solution, since it doesn't even appear
> on Stephen's list, but I am guessing it would fall under the "Donny Don't"
> section. The non-maven-jar plugin is a more integrated way of doing what
> you are trying to do.


I confined myself to solutions that actually work

;-)

>
>
> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
> alexan...@kriegisch.name > wrote:
>
> > I have never used Ant, so I do nkt have the urge to script my build. I
> > have also read the blog post you mentioned. The JARs I was trying to
> > dynamically download from. "non-Maven" URL are, as I said
> >
> >   - not available on Central (I suggested it to the author, but he
> refused
> > and keeps committing all dependencies to his SCM)
> >
> >   - not available on any other public Maven repo
> >
> >   - not even built with Maven.
> >
> > Our company even has an internal Nexus, but
> >
> >   - I kinda dislike manually uploading external JARs there
> >
> >   - I was in a situation where I did not have access to that Nexus
> instance
> > and wondered if it was not somehow possible to bootstrap external
> > JARs directly with Maven. Thus, I ended up using the combination of
> > download-maven-plugin and maven-install-plugin, both tied to the
> first
> > phase available, named validate. This works nicely if I call validate
> > separately, but I wanted to do it Maven style in one call. I think it
> > is a
> > design flaw in Maven that it behaves differently for validate
> > depending on
> > which phase has been called. I think the principle of least surprise
> > makes
> > users expect a different (consistent) behaviour. I do not see any
> > problems
> > In an approach which executes validate before checking the downloads
> > needed for compile.
> >
> > Having said that and further explained my situation, do you have any
> > suggestion how to solve this problem in a clean, canonical Maven way,
> given
> > a single condition: no private Nexus or external Maven repo is available
> > and I want one-stop shopping and clean bootstrapping right from Maven. I
> > think this is a simple enough and understandable requirement. It is
> > actually what I have started using Maven for.
> >
> >
> > > Am 07.11.2013 um 21:23 schrieb Doug Douglass 
> > > 
> >:
> > >
> > > On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> > > alexan...@kriegisch.name > wrote:
> > >
> > >> Only "mvn compile" yields the exact same result as "mvn validate
> > compile",
> > >> I just did it like this explicitly to make a point and show clearly
> what
> > >> hapens. So again: Why, pray tell, does my two-phase build work if
> first
> > I
> > >> only do "mvn validate" and then "mvn compile", but not with only "mvn
> > >> compile"? The question is still unanswered. Two people told me I made
> a
> > >> mistake but did not explain which one and where the different
> behaviour
> > >> comes from.
> > > You're right, I didn't answer your original question. The different is
> > > because "mvn validate compile" and/or "mvn compile" is a single
> > invocation
> > > of maven and dependencies are resolved once (by default, w/o any other
> > > plugins/configuration). "mvn validate; mvn compile" are 2 separate
> > > invocations of maven; the first one does your "download external,
> > > non-mavenised" business, which makes those dependencies available for
> the
> > > second.
> > >
> > > I still suggest you read Steven's post as you're question/problem
> > indicates
> > > you're heading down the not-uncommon path of trying to script your
> build
> > > (like we all did in the Ant days) vs. giving into The Maven Way.
> There's
> > > lots of similar conversations in the list archives, the blog post is
> the
> > > result of many such "debates". I'll apologize in advance if this is not
> > > yo

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Stephen Connolly]

On Thursday, 7 November 2013, Curtis Rueden wrote:

> Hi Alexander,
>
> > The non-maven-jar plugin was new to me, but unfortunately it also does
> > not do what I want because it expects the JAR to already exist in a
> > certain place and even have a custom Maven module for it.


There are plugins that will download files for you, and a maven rule is one
artifact per module

>
> Why not scratch your itch: fork the non-maven-jar-maven-plugin, add support
> for remote JAR locations, and submit a PR?
>
> -Curtis
>
>
> On Thu, Nov 7, 2013 at 4:13 PM, Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
>
> > Sorry, my finger slipped, sent too early...
> >
> >
> > > Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch
> > :
> > >
> > > Thanks for all your answers, I know you want to help me, but you don't.
> > I know what Maven was designed to do, and I can set up an internal repo
> or
> > nexus for myself. But imagine a situation in which all I want to have as
> a
> > precondition for building a tiny little OSS tool with external (non-Maven
> > dependencies) is a working Maven installation and one command: mvn
> install.
> > I do not want to put the burden on my users to create their own Nexus or
> > manually download dependencies and install them to the local repo. I do
> not
> > want to execute ugly Ant tasks and not use system dependencies with fixed
> > paths. I have tried all this and got every variant working without much
> > fuss, but somehow all of this feels so unclean. I would much prefer to
> get
> > it working in a declarative Maven style. The non-maven
> >
> > The non-maven-jar plugin was new to me, but unfortunately it also does
> not
> > do what I want because it expects the JAR to already exist in a certain
> > place and even have a custom Maven module for it. Maybe I can somehow
> > combine it with the download plugin, but it seems awkward.
> >
> > Basically my solution with binding download and dynamic artifact
> > installation to a local repo to the validate phase works nicely as long
> as
> > I call the mvn validate separately for the very first time. Afterwards it
> > is absolutely transparent because the artifacts are first class maven
> > citizens after installation. The little bit of comfort missing is just a
> > trick to delay artifact resolution until after dynamic installation, for
> > which I hoped to get a magic Maven option or switch as a hint here on the
> > user group. Thanks for bearing with me, even thanks for lecturing me
> about
> > Maven basics I already knew by heart. I share your opinion that people
> not
> > maintaining their artifacts on Central & Co. are indeed "bad", but hey,
> it
> > is a real life situation I want to deal with and handle as gracefully as
> > possible with as few dirty tricks as possible.
> >
> > I might look into creating a custom lifecycle with an additional
> > pre-validate phase, if at all possible. I just fear that that hypothetic
> > lifecycle will also check dependencies before starting the hypothetic
> > pre-validate phase...
> >
> >
> > >
> > >
> > >> Am 07.11.2013 um 22:43 schrieb Curtis Rueden :
> > >>
> > >> Hi Alexander,
> > >>
> > >>> do you have any suggestion how to solve this problem in a clean,
> > >>> canonical Maven way, given a single condition: no private Nexus or
> > >>> external Maven repo is available and I want one-stop shopping and
> > >>> clean bootstrapping right from Maven.
> > >>
> > >> The blog post linked earlier answers exactly this question.
> > >>
> > >> The solutions it outlines to this problem are, in order of "best for
> the
> > >> Maven community to worst for the Maven community":
> > >>
> > >> 1.Get thee to Central
> > >> 2. Get the external jars into a public Maven repository
> > >> 3. Get the external jars into the internal Maven repository
> > >> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> > >> 5. Use an ANT task
> > >> [Everything after this point is "Donny Don't".]
> > >> 6. The file:///${basedir} repository hack
> > >> 7. The system scope hack
> > >>
> > >> Options 1 & 2 require communication with the third party library
> > >> developers, which presumably is untenable for you. You have also
> > rejected
> > >> #3 ("I kinda dislike manually uploading external JARs there"), which
> > leaves
> > >> #4 as your next-best option.
> > >>
> > >> Regards,
> > >> Curtis
> > >>
> > >> P.S. I am intrigued by your current solution, since it doesn't even
> > appear
> > >> on Stephen's list, but I am guessing it would fall under the "Donny
> > Don't"
> > >> section. The non-maven-jar plugin is a more integrated way of doing
> what
> >



-- 
Sent from my phone

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Curtis Rueden]

Hi Alexander,

> The non-maven-jar plugin was new to me, but unfortunately it also does
> not do what I want because it expects the JAR to already exist in a
> certain place and even have a custom Maven module for it.

Why not scratch your itch: fork the non-maven-jar-maven-plugin, add support
for remote JAR locations, and submit a PR?

-Curtis


On Thu, Nov 7, 2013 at 4:13 PM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Sorry, my finger slipped, sent too early...
>
>
> > Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch
> :
> >
> > Thanks for all your answers, I know you want to help me, but you don't.
> I know what Maven was designed to do, and I can set up an internal repo or
> nexus for myself. But imagine a situation in which all I want to have as a
> precondition for building a tiny little OSS tool with external (non-Maven
> dependencies) is a working Maven installation and one command: mvn install.
> I do not want to put the burden on my users to create their own Nexus or
> manually download dependencies and install them to the local repo. I do not
> want to execute ugly Ant tasks and not use system dependencies with fixed
> paths. I have tried all this and got every variant working without much
> fuss, but somehow all of this feels so unclean. I would much prefer to get
> it working in a declarative Maven style. The non-maven
>
> The non-maven-jar plugin was new to me, but unfortunately it also does not
> do what I want because it expects the JAR to already exist in a certain
> place and even have a custom Maven module for it. Maybe I can somehow
> combine it with the download plugin, but it seems awkward.
>
> Basically my solution with binding download and dynamic artifact
> installation to a local repo to the validate phase works nicely as long as
> I call the mvn validate separately for the very first time. Afterwards it
> is absolutely transparent because the artifacts are first class maven
> citizens after installation. The little bit of comfort missing is just a
> trick to delay artifact resolution until after dynamic installation, for
> which I hoped to get a magic Maven option or switch as a hint here on the
> user group. Thanks for bearing with me, even thanks for lecturing me about
> Maven basics I already knew by heart. I share your opinion that people not
> maintaining their artifacts on Central & Co. are indeed "bad", but hey, it
> is a real life situation I want to deal with and handle as gracefully as
> possible with as few dirty tricks as possible.
>
> I might look into creating a custom lifecycle with an additional
> pre-validate phase, if at all possible. I just fear that that hypothetic
> lifecycle will also check dependencies before starting the hypothetic
> pre-validate phase...
>
>
> >
> >
> >> Am 07.11.2013 um 22:43 schrieb Curtis Rueden :
> >>
> >> Hi Alexander,
> >>
> >>> do you have any suggestion how to solve this problem in a clean,
> >>> canonical Maven way, given a single condition: no private Nexus or
> >>> external Maven repo is available and I want one-stop shopping and
> >>> clean bootstrapping right from Maven.
> >>
> >> The blog post linked earlier answers exactly this question.
> >>
> >> The solutions it outlines to this problem are, in order of "best for the
> >> Maven community to worst for the Maven community":
> >>
> >> 1.Get thee to Central
> >> 2. Get the external jars into a public Maven repository
> >> 3. Get the external jars into the internal Maven repository
> >> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> >> 5. Use an ANT task
> >> [Everything after this point is "Donny Don't".]
> >> 6. The file:///${basedir} repository hack
> >> 7. The system scope hack
> >>
> >> Options 1 & 2 require communication with the third party library
> >> developers, which presumably is untenable for you. You have also
> rejected
> >> #3 ("I kinda dislike manually uploading external JARs there"), which
> leaves
> >> #4 as your next-best option.
> >>
> >> Regards,
> >> Curtis
> >>
> >> P.S. I am intrigued by your current solution, since it doesn't even
> appear
> >> on Stephen's list, but I am guessing it would fall under the "Donny
> Don't"
> >> section. The non-maven-jar plugin is a more integrated way of doing what
> >> you are trying to do.
> >>
> >>
> >> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
> >> alexan...@kriegisch.name> wrote:
> >>
> >>> I have never used Ant, so I do nkt have the urge to script my build. I
> >>> have also read the blog post you mentioned. The JARs I was trying to
> >>> dynamically download from. "non-Maven" URL are, as I said
> >>>
> >>> - not available on Central (I suggested it to the author, but he
> refused
> >>>   and keeps committing all dependencies to his SCM)
> >>>
> >>> - not available on any other public Maven repo
> >>>
> >>> - not even built with Maven.
> >>>
> >>> Our company even has an internal Nexus, but
> >>>
> >>> - I kinda dislike manually uploading external JARs there
> >>>
> >>> - I 

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Alexander Kriegisch]

Sorry, my finger slipped, sent too early...


> Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch :
> 
> Thanks for all your answers, I know you want to help me, but you don't. I 
> know what Maven was designed to do, and I can set up an internal repo or 
> nexus for myself. But imagine a situation in which all I want to have as a 
> precondition for building a tiny little OSS tool with external (non-Maven 
> dependencies) is a working Maven installation and one command: mvn install. I 
> do not want to put the burden on my users to create their own Nexus or 
> manually download dependencies and install them to the local repo. I do not 
> want to execute ugly Ant tasks and not use system dependencies with fixed 
> paths. I have tried all this and got every variant working without much fuss, 
> but somehow all of this feels so unclean. I would much prefer to get it 
> working in a declarative Maven style. The non-maven

The non-maven-jar plugin was new to me, but unfortunately it also does not do 
what I want because it expects the JAR to already exist in a certain place and 
even have a custom Maven module for it. Maybe I can somehow combine it with the 
download plugin, but it seems awkward.

Basically my solution with binding download and dynamic artifact installation 
to a local repo to the validate phase works nicely as long as I call the mvn 
validate separately for the very first time. Afterwards it is absolutely 
transparent because the artifacts are first class maven citizens after 
installation. The little bit of comfort missing is just a trick to delay 
artifact resolution until after dynamic installation, for which I hoped to get 
a magic Maven option or switch as a hint here on the user group. Thanks for 
bearing with me, even thanks for lecturing me about Maven basics I already knew 
by heart. I share your opinion that people not maintaining their artifacts on 
Central & Co. are indeed "bad", but hey, it is a real life situation I want to 
deal with and handle as gracefully as possible with as few dirty tricks as 
possible.

I might look into creating a custom lifecycle with an additional pre-validate 
phase, if at all possible. I just fear that that hypothetic lifecycle will also 
check dependencies before starting the hypothetic pre-validate phase... 


> 
> 
>> Am 07.11.2013 um 22:43 schrieb Curtis Rueden :
>> 
>> Hi Alexander,
>> 
>>> do you have any suggestion how to solve this problem in a clean,
>>> canonical Maven way, given a single condition: no private Nexus or
>>> external Maven repo is available and I want one-stop shopping and
>>> clean bootstrapping right from Maven.
>> 
>> The blog post linked earlier answers exactly this question.
>> 
>> The solutions it outlines to this problem are, in order of "best for the
>> Maven community to worst for the Maven community":
>> 
>> 1.Get thee to Central
>> 2. Get the external jars into a public Maven repository
>> 3. Get the external jars into the internal Maven repository
>> 4. Use the reactor (and Stephen's non-maven-jar plugin)
>> 5. Use an ANT task
>> [Everything after this point is "Donny Don't".]
>> 6. The file:///${basedir} repository hack
>> 7. The system scope hack
>> 
>> Options 1 & 2 require communication with the third party library
>> developers, which presumably is untenable for you. You have also rejected
>> #3 ("I kinda dislike manually uploading external JARs there"), which leaves
>> #4 as your next-best option.
>> 
>> Regards,
>> Curtis
>> 
>> P.S. I am intrigued by your current solution, since it doesn't even appear
>> on Stephen's list, but I am guessing it would fall under the "Donny Don't"
>> section. The non-maven-jar plugin is a more integrated way of doing what
>> you are trying to do.
>> 
>> 
>> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
>> alexan...@kriegisch.name> wrote:
>> 
>>> I have never used Ant, so I do nkt have the urge to script my build. I
>>> have also read the blog post you mentioned. The JARs I was trying to
>>> dynamically download from. "non-Maven" URL are, as I said
>>> 
>>> - not available on Central (I suggested it to the author, but he refused
>>>   and keeps committing all dependencies to his SCM)
>>> 
>>> - not available on any other public Maven repo
>>> 
>>> - not even built with Maven.
>>> 
>>> Our company even has an internal Nexus, but
>>> 
>>> - I kinda dislike manually uploading external JARs there
>>> 
>>> - I was in a situation where I did not have access to that Nexus instance
>>>   and wondered if it was not somehow possible to bootstrap external
>>>   JARs directly with Maven. Thus, I ended up using the combination of
>>>   download-maven-plugin and maven-install-plugin, both tied to the first
>>>   phase available, named validate. This works nicely if I call validate
>>>   separately, but I wanted to do it Maven style in one call. I think it
>>> is a
>>>   design flaw in Maven that it behaves differently for validate
>>> depending on
>>>   which phase has been called.

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Alexander Kriegisch]

Thanks for all your answers, I know you want to help me, but you don't. I know 
what Maven was designed to do, and I can set up an internal repo or nexus for 
myself. But imagine a situation in which all I want to have as a precondition 
for building a tiny little OSS tool with external (non-Maven dependencies) is a 
working Maven installation and one command: mvn install. I do not want to put 
the burden on my users to create their own Nexus or manually download 
dependencies and install them to the local repo. I do not want to execute ugly 
Ant tasks and not use system dependencies with fixed paths. I have tried all 
this and got every variant working without much fuss, but somehow all of this 
feels so unclean. I would much prefer to get it working in a declarative Maven 
style. The non-maven


> Am 07.11.2013 um 22:43 schrieb Curtis Rueden :
> 
> Hi Alexander,
> 
>> do you have any suggestion how to solve this problem in a clean,
>> canonical Maven way, given a single condition: no private Nexus or
>> external Maven repo is available and I want one-stop shopping and
>> clean bootstrapping right from Maven.
> 
> The blog post linked earlier answers exactly this question.
> 
> The solutions it outlines to this problem are, in order of "best for the
> Maven community to worst for the Maven community":
> 
> 1.Get thee to Central
> 2. Get the external jars into a public Maven repository
> 3. Get the external jars into the internal Maven repository
> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> 5. Use an ANT task
> [Everything after this point is "Donny Don't".]
> 6. The file:///${basedir} repository hack
> 7. The system scope hack
> 
> Options 1 & 2 require communication with the third party library
> developers, which presumably is untenable for you. You have also rejected
> #3 ("I kinda dislike manually uploading external JARs there"), which leaves
> #4 as your next-best option.
> 
> Regards,
> Curtis
> 
> P.S. I am intrigued by your current solution, since it doesn't even appear
> on Stephen's list, but I am guessing it would fall under the "Donny Don't"
> section. The non-maven-jar plugin is a more integrated way of doing what
> you are trying to do.
> 
> 
> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
> 
>> I have never used Ant, so I do nkt have the urge to script my build. I
>> have also read the blog post you mentioned. The JARs I was trying to
>> dynamically download from. "non-Maven" URL are, as I said
>> 
>>  - not available on Central (I suggested it to the author, but he refused
>>and keeps committing all dependencies to his SCM)
>> 
>>  - not available on any other public Maven repo
>> 
>>  - not even built with Maven.
>> 
>> Our company even has an internal Nexus, but
>> 
>>  - I kinda dislike manually uploading external JARs there
>> 
>>  - I was in a situation where I did not have access to that Nexus instance
>>and wondered if it was not somehow possible to bootstrap external
>>JARs directly with Maven. Thus, I ended up using the combination of
>>download-maven-plugin and maven-install-plugin, both tied to the first
>>phase available, named validate. This works nicely if I call validate
>>separately, but I wanted to do it Maven style in one call. I think it
>> is a
>>design flaw in Maven that it behaves differently for validate
>> depending on
>>which phase has been called. I think the principle of least surprise
>> makes
>>users expect a different (consistent) behaviour. I do not see any
>> problems
>>In an approach which executes validate before checking the downloads
>>needed for compile.
>> 
>> Having said that and further explained my situation, do you have any
>> suggestion how to solve this problem in a clean, canonical Maven way, given
>> a single condition: no private Nexus or external Maven repo is available
>> and I want one-stop shopping and clean bootstrapping right from Maven. I
>> think this is a simple enough and understandable requirement. It is
>> actually what I have started using Maven for.
>> 
>> 
>>> Am 07.11.2013 um 21:23 schrieb Doug Douglass :
>>> 
>>> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
>>> alexan...@kriegisch.name> wrote:
>>> 
 Only "mvn compile" yields the exact same result as "mvn validate
>> compile",
 I just did it like this explicitly to make a point and show clearly what
 hapens. So again: Why, pray tell, does my two-phase build work if first
>> I
 only do "mvn validate" and then "mvn compile", but not with only "mvn
 compile"? The question is still unanswered. Two people told me I made a
 mistake but did not explain which one and where the different behaviour
 comes from.
>>> You're right, I didn't answer your original question. The different is
>>> because "mvn validate compile" and/or "mvn compile" is a single
>> invocation
>>> of maven and dependencies are resolved once (by default, w/o any other
>>> plugins

RE: AW: mvn release:prepare does not update parent version

[Martin Gainty]

  


> From: k...@quipsy.de
> To: users@maven.apache.org
> Date: Thu, 7 Nov 2013 17:11:32 +0100
> Subject: AW: mvn release:prepare does not update parent version
> 
> Sorry for the really long delay, but there had been several urgent projects 
> meanwhile.
> 
> I built a really microscopic project which showcases the problem. It consists 
> of a rather empty parent POM which has been released as "1.0" plus a 
> super-simple POM using that one as a "company parent POM". So this is NOT a 
> module! Please check the marked lines to understand my problem!
> 
> POM before release:
> 
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> my-artifact
> my-artifact
> 
> my.group
> my-parent
>  1.0-SNAPSHOT
> 
> 
> scm:svn:svn://svn/Research/my-artifact/trunk
> 
> 
> 
> releases
> http://nexus.quipsy.local/nexus/content/repositories/releases
> 
> 
> snapshots
> http://nexus.quipsy.local/nexus/content/repositories/snapshots
> 
> 
> 
> 
> Preparing and performing the release:
> 
> C:\Users\Markus Karg\workspace\artifact\my-artifact>mvn release:prepare 
> release:perform
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building my-artifact 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-release-plugin:2.0:prepare (default-cli) @ my-artifact ---
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
> [INFO] Working directory: C:\Users\Markus Karg\workspace\artifact\my-artifact
> [INFO] Checking dependencies and plugins for snapshots ...
> There are still some remaining snapshot dependencies.: Do you want to resolve 
> them now? (yes/no) no: : yes
> Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
> Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
> Resolve Project Dependency Snapshots.: 'my.group:my-parent' set to 
> release? (yes/no) yes: :
> What is the next development version? (1.1-SNAPSHOT) 1.1-SNAPSHOT: :
> What is the release version for "my-artifact"? (my.group:my-artifact) 1.0: :
> What is SCM release tag or label for "my-artifact"? (my.group:my-artifact) 
> my-artifact-1.0: :
> What is the new development version for "my-artifact"? (my.group:my-artifact) 
> 1.1-SNAPSHOT: :
> [INFO] Transforming 'my-artifact'...
> [INFO] Not generating release POMs
> [INFO] Executing goals 'clean verify'...
> [WARNING] Maven will be executed in interactive mode, but no input stream has 
> been configured for this MavenInvoker instance.
> [INFO] [INFO] Scanning for projects...
> [INFO] [INFO]
> [INFO] [INFO] 
> 
> [INFO] [INFO] Building my-artifact 1.0
> [INFO] [INFO] 
> 
> [INFO] [INFO]
> [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ 
> my-artifact ---
> [INFO] [INFO]
> [INFO] [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
> my-artifact ---
> [INFO] [debug] execute contextualize
> [INFO] [WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
> resources, i.e. build is platform dependent!
> [INFO] [INFO] skip non existing resourceDirectory C:\Users\Markus 
> Karg\workspace\artifact\my-artifact\src\main\resources
> [INFO] [INFO]
> [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ 
> my-artifact ---
> [INFO] [INFO] No sources to compile
> [INFO] [INFO]
> [INFO] [INFO] --- maven-resources-plugin:2.5:testResources 
> (default-testResources) @ my-artifact ---
> [INFO] [debug] execute contextualize
> [INFO] [WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
> resources, i.e. build is platform dependent!
> [INFO] [INFO] skip non existing resourceDirectory C:\Users\Markus 
> Karg\workspace\artifact\my-artifact\src\test\resources
> [INFO] [INFO]
> [INFO] [INFO] --- maven-compiler-plugin:2.3.2:testCompile 
> (default-testCompile) @ my-artifact ---
> [INFO] [INFO] No sources to compile
> [INFO] [INFO]
> [INFO] [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ 
> my-artifact ---
> [INFO] [INFO] No tests to run.
> [INFO] [INFO] Surefire report directory: C:\Users\Markus 
> Karg\workspace\artifact\my-artifact\target\surefire-reports
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO]
> [INFO] Results :
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO] [INFO]
> [INFO] [INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ my-artifact ---
> [INFO] [WARNING] JAR will be empty - no 

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Curtis Rueden]

Hi Alexander,

> do you have any suggestion how to solve this problem in a clean,
> canonical Maven way, given a single condition: no private Nexus or
> external Maven repo is available and I want one-stop shopping and
> clean bootstrapping right from Maven.

The blog post linked earlier answers exactly this question.

The solutions it outlines to this problem are, in order of "best for the
Maven community to worst for the Maven community":

1.Get thee to Central
2. Get the external jars into a public Maven repository
3. Get the external jars into the internal Maven repository
4. Use the reactor (and Stephen's non-maven-jar plugin)
5. Use an ANT task
[Everything after this point is "Donny Don't".]
6. The file:///${basedir} repository hack
7. The system scope hack

Options 1 & 2 require communication with the third party library
developers, which presumably is untenable for you. You have also rejected
#3 ("I kinda dislike manually uploading external JARs there"), which leaves
#4 as your next-best option.

Regards,
Curtis

P.S. I am intrigued by your current solution, since it doesn't even appear
on Stephen's list, but I am guessing it would fall under the "Donny Don't"
section. The non-maven-jar plugin is a more integrated way of doing what
you are trying to do.


On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> I have never used Ant, so I do nkt have the urge to script my build. I
> have also read the blog post you mentioned. The JARs I was trying to
> dynamically download from. "non-Maven" URL are, as I said
>
>   - not available on Central (I suggested it to the author, but he refused
> and keeps committing all dependencies to his SCM)
>
>   - not available on any other public Maven repo
>
>   - not even built with Maven.
>
> Our company even has an internal Nexus, but
>
>   - I kinda dislike manually uploading external JARs there
>
>   - I was in a situation where I did not have access to that Nexus instance
> and wondered if it was not somehow possible to bootstrap external
> JARs directly with Maven. Thus, I ended up using the combination of
> download-maven-plugin and maven-install-plugin, both tied to the first
> phase available, named validate. This works nicely if I call validate
> separately, but I wanted to do it Maven style in one call. I think it
> is a
> design flaw in Maven that it behaves differently for validate
> depending on
> which phase has been called. I think the principle of least surprise
> makes
> users expect a different (consistent) behaviour. I do not see any
> problems
> In an approach which executes validate before checking the downloads
> needed for compile.
>
> Having said that and further explained my situation, do you have any
> suggestion how to solve this problem in a clean, canonical Maven way, given
> a single condition: no private Nexus or external Maven repo is available
> and I want one-stop shopping and clean bootstrapping right from Maven. I
> think this is a simple enough and understandable requirement. It is
> actually what I have started using Maven for.
>
>
> > Am 07.11.2013 um 21:23 schrieb Doug Douglass :
> >
> > On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> > alexan...@kriegisch.name> wrote:
> >
> >> Only "mvn compile" yields the exact same result as "mvn validate
> compile",
> >> I just did it like this explicitly to make a point and show clearly what
> >> hapens. So again: Why, pray tell, does my two-phase build work if first
> I
> >> only do "mvn validate" and then "mvn compile", but not with only "mvn
> >> compile"? The question is still unanswered. Two people told me I made a
> >> mistake but did not explain which one and where the different behaviour
> >> comes from.
> > You're right, I didn't answer your original question. The different is
> > because "mvn validate compile" and/or "mvn compile" is a single
> invocation
> > of maven and dependencies are resolved once (by default, w/o any other
> > plugins/configuration). "mvn validate; mvn compile" are 2 separate
> > invocations of maven; the first one does your "download external,
> > non-mavenised" business, which makes those dependencies available for the
> > second.
> >
> > I still suggest you read Steven's post as you're question/problem
> indicates
> > you're heading down the not-uncommon path of trying to script your build
> > (like we all did in the Ant days) vs. giving into The Maven Way. There's
> > lots of similar conversations in the list archives, the blog post is the
> > result of many such "debates". I'll apologize in advance if this is not
> > your case.
> >
> > Cheers,
> > Doug
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Robert Kuropkat]

On 11/07/2013 04:29 PM, Alexander Kriegisch wrote:





Our company even has an internal Nexus, but

   - I kinda dislike manually uploading external JARs there


That's what an internal Maven repository (Nexus or Artifactory) is 
actually for.  You limit the surprises caused by relying on transient or 
unreliable sources.  It's no different than storing custom rpms in a 
local yum repository so you don't lose those.




   - I was in a situation where I did not have access to that Nexus instance


I've seen, and done so myself, the idea of setting up yet another Nexus 
repository on your development laptop.  While it seems a little 
outlandish, what it does do is cache everything you need locally so you 
can work offline.  Of course, if you have no network connection and 
spring a new dependency onto the scene, you are stuck, but I would think 
that a reasonable assumption under any circumstance.  If needed, it also 
gives you a way to vet any library upgrades locally before submitting 
them to the corporate repository (Nexus).  Depends on what your internal 
processes are.


P.S.  You can do this without a repository manager like Nexus by 
injecting it directly into your .m2 cache, but at that point, I like the 
management utility of Nexus to keep them and leave me the option of 
blowing away my .m2 cache if something gets chunked up there...







Having said that and further explained my situation, do you have any suggestion 
how to solve this problem in a clean, canonical Maven way, given a single 
condition: no private Nexus or external Maven repo is available and I want 
one-stop shopping and clean bootstrapping right from Maven. I think this is a 
simple enough and understandable requirement. It is actually what I have 
started using Maven for.





Being new to Maven myself, I'll defer to better suggestions, but I would 
say the most Maven-like solution is to submit the jars to your corporate 
Nexus and then everything else just works like magic. You'll probably 
want to create a custom "hosted" repo to store such things, one that is 
separate from any repos you push snapshots and releases into and then 
use a "Group" to make it all visible or some such...






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

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Doug Douglass]

On Thu, Nov 7, 2013 at 2:29 PM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> I have never used Ant, so I do nkt have the urge to script my build. I
> have also read the blog post you mentioned. The JARs I was trying to
> dynamically download from. "non-Maven" URL are, as I said
>
>   - not available on Central (I suggested it to the author, but he refused
> and keeps committing all dependencies to his SCM)
>
>   - not available on any other public Maven repo
>
>   - not even built with Maven.
>
> Our company even has an internal Nexus, but
>
>   - I kinda dislike manually uploading external JARs there
>
>   - I was in a situation where I did not have access to that Nexus instance
> and wondered if it was not somehow possible to bootstrap external
> JARs directly with Maven. Thus, I ended up using the combination of
> download-maven-plugin and maven-install-plugin, both tied to the first
> phase available, named validate. This works nicely if I call validate
> separately, but I wanted to do it Maven style in one call. I think it
> is a
> design flaw in Maven that it behaves differently for validate
> depending on
> which phase has been called. I think the principle of least surprise
> makes
> users expect a different (consistent) behaviour. I do not see any
> problems
> In an approach which executes validate before checking the downloads
> needed for compile.
>
> Having said that and further explained my situation, do you have any
> suggestion how to solve this problem in a clean, canonical Maven way, given
> a single condition: no private Nexus or external Maven repo is available
> and I want one-stop shopping and clean bootstrapping right from Maven. I
> think this is a simple enough and understandable requirement. It is
> actually what I have started using Maven for.
>
>
I don't mean to sound rude, but all these excuses have been heard here
before and Steven's blog post is a direct and detailed response that
provides many solutions to your problem. Maven has a robust dependency
resolution and download mechanism, if you choose not to use it, you will be
continually fighting an uphill battle that will (already has) lead to
frustration.

That said, my pragmatic advice to your situation is Steven's solution #4.

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Manfred Moser]

Ultimately Maven is designed to get components from a repo manager and
publish them back to the repo manager. Using it without a repository
managers is like saying you want to drive a car but it cant have an engine
or wheels.

manfred


> I have never used Ant, so I do nkt have the urge to script my build. I
> have also read the blog post you mentioned. The JARs I was trying to
> dynamically download from. "non-Maven" URL are, as I said
>
>   - not available on Central (I suggested it to the author, but he refused
> and keeps committing all dependencies to his SCM)
>
>   - not available on any other public Maven repo
>
>   - not even built with Maven.
>
> Our company even has an internal Nexus, but
>
>   - I kinda dislike manually uploading external JARs there
>
>   - I was in a situation where I did not have access to that Nexus
> instance
> and wondered if it was not somehow possible to bootstrap external
> JARs directly with Maven. Thus, I ended up using the combination of
> download-maven-plugin and maven-install-plugin, both tied to the first
> phase available, named validate. This works nicely if I call validate
> separately, but I wanted to do it Maven style in one call. I think it
> is a
> design flaw in Maven that it behaves differently for validate
> depending on
> which phase has been called. I think the principle of least surprise
> makes
> users expect a different (consistent) behaviour. I do not see any
> problems
> In an approach which executes validate before checking the downloads
> needed for compile.
>
> Having said that and further explained my situation, do you have any
> suggestion how to solve this problem in a clean, canonical Maven way,
> given a single condition: no private Nexus or external Maven repo is
> available and I want one-stop shopping and clean bootstrapping right from
> Maven. I think this is a simple enough and understandable requirement. It
> is actually what I have started using Maven for.
>
>
>> Am 07.11.2013 um 21:23 schrieb Doug Douglass :
>>
>> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
>> alexan...@kriegisch.name> wrote:
>>
>>> Only "mvn compile" yields the exact same result as "mvn validate
>>> compile",
>>> I just did it like this explicitly to make a point and show clearly
>>> what
>>> hapens. So again: Why, pray tell, does my two-phase build work if first
>>> I
>>> only do "mvn validate" and then "mvn compile", but not with only "mvn
>>> compile"? The question is still unanswered. Two people told me I made a
>>> mistake but did not explain which one and where the different behaviour
>>> comes from.
>> You're right, I didn't answer your original question. The different is
>> because "mvn validate compile" and/or "mvn compile" is a single
>> invocation
>> of maven and dependencies are resolved once (by default, w/o any other
>> plugins/configuration). "mvn validate; mvn compile" are 2 separate
>> invocations of maven; the first one does your "download external,
>> non-mavenised" business, which makes those dependencies available for
>> the
>> second.
>>
>> I still suggest you read Steven's post as you're question/problem
>> indicates
>> you're heading down the not-uncommon path of trying to script your build
>> (like we all did in the Ant days) vs. giving into The Maven Way. There's
>> lots of similar conversations in the list archives, the blog post is the
>> result of many such "debates". I'll apologize in advance if this is not
>> your case.
>>
>> Cheers,
>> Doug
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>


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

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Alexander Kriegisch]

I have never used Ant, so I do nkt have the urge to script my build. I have 
also read the blog post you mentioned. The JARs I was trying to dynamically 
download from. "non-Maven" URL are, as I said

  - not available on Central (I suggested it to the author, but he refused
and keeps committing all dependencies to his SCM)

  - not available on any other public Maven repo

  - not even built with Maven.

Our company even has an internal Nexus, but

  - I kinda dislike manually uploading external JARs there

  - I was in a situation where I did not have access to that Nexus instance
and wondered if it was not somehow possible to bootstrap external
JARs directly with Maven. Thus, I ended up using the combination of
download-maven-plugin and maven-install-plugin, both tied to the first
phase available, named validate. This works nicely if I call validate
separately, but I wanted to do it Maven style in one call. I think it is a
design flaw in Maven that it behaves differently for validate depending on
which phase has been called. I think the principle of least surprise makes
users expect a different (consistent) behaviour. I do not see any problems
In an approach which executes validate before checking the downloads
needed for compile.

Having said that and further explained my situation, do you have any suggestion 
how to solve this problem in a clean, canonical Maven way, given a single 
condition: no private Nexus or external Maven repo is available and I want 
one-stop shopping and clean bootstrapping right from Maven. I think this is a 
simple enough and understandable requirement. It is actually what I have 
started using Maven for.


> Am 07.11.2013 um 21:23 schrieb Doug Douglass :
> 
> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
> 
>> Only "mvn compile" yields the exact same result as "mvn validate compile",
>> I just did it like this explicitly to make a point and show clearly what
>> hapens. So again: Why, pray tell, does my two-phase build work if first I
>> only do "mvn validate" and then "mvn compile", but not with only "mvn
>> compile"? The question is still unanswered. Two people told me I made a
>> mistake but did not explain which one and where the different behaviour
>> comes from.
> You're right, I didn't answer your original question. The different is
> because "mvn validate compile" and/or "mvn compile" is a single invocation
> of maven and dependencies are resolved once (by default, w/o any other
> plugins/configuration). "mvn validate; mvn compile" are 2 separate
> invocations of maven; the first one does your "download external,
> non-mavenised" business, which makes those dependencies available for the
> second.
> 
> I still suggest you read Steven's post as you're question/problem indicates
> you're heading down the not-uncommon path of trying to script your build
> (like we all did in the Ant days) vs. giving into The Maven Way. There's
> lots of similar conversations in the list archives, the blog post is the
> result of many such "debates". I'll apologize in advance if this is not
> your case.
> 
> Cheers,
> Doug

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

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Doug Douglass]

On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Only "mvn compile" yields the exact same result as "mvn validate compile",
> I just did it like this explicitly to make a point and show clearly what
> hapens. So again: Why, pray tell, does my two-phase build work if first I
> only do "mvn validate" and then "mvn compile", but not with only "mvn
> compile"? The question is still unanswered. Two people told me I made a
> mistake but did not explain which one and where the different behaviour
> comes from.
>
>
You're right, I didn't answer your original question. The different is
because "mvn validate compile" and/or "mvn compile" is a single invocation
of maven and dependencies are resolved once (by default, w/o any other
plugins/configuration). "mvn validate; mvn compile" are 2 separate
invocations of maven; the first one does your "download external,
non-mavenised" business, which makes those dependencies available for the
second.

I still suggest you read Steven's post as you're question/problem indicates
you're heading down the not-uncommon path of trying to script your build
(like we all did in the Ant days) vs. giving into The Maven Way. There's
lots of similar conversations in the list archives, the blog post is the
result of many such "debates". I'll apologize in advance if this is not
your case.

Cheers,
Doug

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Vincent Latombe]

Hi,

It doesn't work because in Maven, dependencies are resolved prior to any
plugin execution (for each module contained in the reactor). Which
dependencies (compile, runtime, test) are resolved depend on what is
required by the various plugins that are be called in the lifecycle
(depending on the phase you called)

That's why mvn validate works : it only execute the execution you defined,
and this desn't require any dependency resolution
Whilest mvn compile doesn't : compile phase has a maven-compiler-plugin
execution which requires dependency resolution for scope compile, and this
happens before any plugin execution.


Vincent


2013/11/7 Alexander Kriegisch 

> Only "mvn compile" yields the exact same result as "mvn validate compile",
> I just did it like this explicitly to make a point and show clearly what
> hapens. So again: Why, pray tell, does my two-phase build work if first I
> only do "mvn validate" and then "mvn compile", but not with only "mvn
> compile"? The question is still unanswered. Two people told me I made a
> mistake but did not explain which one and where the different behaviour
> comes from.
>
> If it helps I can send logs of "mvn -X ..." when I am back in office so
> you can see the difference if my explanation is not good enough. I thought
> it was. :-(
>
>
>
> > Am 07.11.2013 um 18:04 schrieb "Manfred Moser" :
> >
> > You should not use either call. The validate phase is automatically run
> > before the compile phase as part of the default lifecycle
> >
> > Just use
> >
> > mvn compile
> >
> > In general it does not make sense to call multiple phases of the same
> > lifecycle since each phase invocation will run all phases up to and
> > including the phase mentioned.
> >
> > manfred
> >
> >> Hi.
> >>
> >> I have used mvn for a while, but am by no means an expert, so if I am
> >> asking an obvious question please pardon me and answer it anyway if you
> >> can. Thanks.
> >>
> >> I have bound some plugin executions to the validate phase because I need
> >> them to happen before compile. If I execute
> >>
> >>mvn validate
> >>mvn compile
> >>
> >> everything is fine. But if I call
> >>
> >>mvn validate compile
> >>
> >> Maven behaves differently. What I do during validate is download
> external,
> >> non-mavenised (as in unavailable on Central) dependencies and install
> them
> >> locally if they are not registered in my local repo yet. Those
> >> dependencies are used in the compile phase. Now if I seperate the two
> >> calls it works, but if I do it in one mvn call and rely on the order of
> >> phases, Maven breaks my build by checking for remote and local artifact
> >> availability *before* actually starting the validate stuff from my POM.
> If
> >> I run "mvn -X ..." I can clearly see the difference.
> >>
> >> Am I doing anything wrong? Can I force Maven to actually do what is
> >> described in the documentation, i.e. perform the whole validate phase
> with
> >> all executions bound to it in my POM *before* doing anything else
> related
> >> to the compile phase such as trying to download dependencies?
> >>
> >> Thank you
> >> --
> >> Alexander Kriegisch
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Alexander Kriegisch]

Only "mvn compile" yields the exact same result as "mvn validate compile", I 
just did it like this explicitly to make a point and show clearly what hapens. 
So again: Why, pray tell, does my two-phase build work if first I only do "mvn 
validate" and then "mvn compile", but not with only "mvn compile"? The question 
is still unanswered. Two people told me I made a mistake but did not explain 
which one and where the different behaviour comes from.

If it helps I can send logs of "mvn -X ..." when I am back in office so you can 
see the difference if my explanation is not good enough. I thought it was. :-(



> Am 07.11.2013 um 18:04 schrieb "Manfred Moser" :
> 
> You should not use either call. The validate phase is automatically run
> before the compile phase as part of the default lifecycle
> 
> Just use
> 
> mvn compile
> 
> In general it does not make sense to call multiple phases of the same
> lifecycle since each phase invocation will run all phases up to and
> including the phase mentioned.
> 
> manfred
> 
>> Hi.
>> 
>> I have used mvn for a while, but am by no means an expert, so if I am
>> asking an obvious question please pardon me and answer it anyway if you
>> can. Thanks.
>> 
>> I have bound some plugin executions to the validate phase because I need
>> them to happen before compile. If I execute
>> 
>>mvn validate
>>mvn compile
>> 
>> everything is fine. But if I call
>> 
>>mvn validate compile
>> 
>> Maven behaves differently. What I do during validate is download external,
>> non-mavenised (as in unavailable on Central) dependencies and install them
>> locally if they are not registered in my local repo yet. Those
>> dependencies are used in the compile phase. Now if I seperate the two
>> calls it works, but if I do it in one mvn call and rely on the order of
>> phases, Maven breaks my build by checking for remote and local artifact
>> availability *before* actually starting the validate stuff from my POM. If
>> I run "mvn -X ..." I can clearly see the difference.
>> 
>> Am I doing anything wrong? Can I force Maven to actually do what is
>> described in the documentation, i.e. perform the whole validate phase with
>> all executions bound to it in my POM *before* doing anything else related
>> to the compile phase such as trying to download dependencies?
>> 
>> Thank you
>> --
>> Alexander Kriegisch
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

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

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Doug Douglass]

On Thu, Nov 7, 2013 at 8:46 AM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

>
> Am I doing anything wrong?


Simple answer, yes.

Read Stephen Connolly's excellent blog posting,
http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
.

Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Manfred Moser]

You should not use either call. The validate phase is automatically run
before the compile phase as part of the default lifecycle

Just use

mvn compile

In general it does not make sense to call multiple phases of the same
lifecycle since each phase invocation will run all phases up to and
including the phase mentioned.

manfred

 > Hi.
>
> I have used mvn for a while, but am by no means an expert, so if I am
> asking an obvious question please pardon me and answer it anyway if you
> can. Thanks.
>
> I have bound some plugin executions to the validate phase because I need
> them to happen before compile. If I execute
>
> mvn validate
> mvn compile
>
> everything is fine. But if I call
>
> mvn validate compile
>
> Maven behaves differently. What I do during validate is download external,
> non-mavenised (as in unavailable on Central) dependencies and install them
> locally if they are not registered in my local repo yet. Those
> dependencies are used in the compile phase. Now if I seperate the two
> calls it works, but if I do it in one mvn call and rely on the order of
> phases, Maven breaks my build by checking for remote and local artifact
> availability *before* actually starting the validate stuff from my POM. If
> I run "mvn -X ..." I can clearly see the difference.
>
> Am I doing anything wrong? Can I force Maven to actually do what is
> described in the documentation, i.e. perform the whole validate phase with
> all executions bound to it in my POM *before* doing anything else related
> to the compile phase such as trying to download dependencies?
>
> Thank you
> --
> Alexander Kriegisch
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>


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

AW: mvn release:prepare does not update parent version

[Markus Karg]

Sorry for the really long delay, but there had been several urgent projects 
meanwhile.

I built a really microscopic project which showcases the problem. It consists 
of a rather empty parent POM which has been released as "1.0" plus a 
super-simple POM using that one as a "company parent POM". So this is NOT a 
module! Please check the marked lines to understand my problem!

POM before release:

http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
  4.0.0
  my-artifact
  my-artifact
  
my.group
my-parent
1.0-SNAPSHOT
  
  

scm:svn:svn://svn/Research/my-artifact/trunk
  
  

  releases
  http://nexus.quipsy.local/nexus/content/repositories/releases


  snapshots
  http://nexus.quipsy.local/nexus/content/repositories/snapshots

  


Preparing and performing the release:

C:\Users\Markus Karg\workspace\artifact\my-artifact>mvn release:prepare 
release:perform
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building my-artifact 1.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-release-plugin:2.0:prepare (default-cli) @ my-artifact ---
[INFO] Verifying that there are no local modifications...
[INFO] Executing: cmd.exe /X /C "svn --non-interactive status"
[INFO] Working directory: C:\Users\Markus Karg\workspace\artifact\my-artifact
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve 
them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :
Resolve Project Dependency Snapshots.: 'my.group:my-parent' set to release? 
(yes/no) yes: :
What is the next development version? (1.1-SNAPSHOT) 1.1-SNAPSHOT: :
What is the release version for "my-artifact"? (my.group:my-artifact) 1.0: :
What is SCM release tag or label for "my-artifact"? (my.group:my-artifact) 
my-artifact-1.0: :
What is the new development version for "my-artifact"? (my.group:my-artifact) 
1.1-SNAPSHOT: :
[INFO] Transforming 'my-artifact'...
[INFO] Not generating release POMs
[INFO] Executing goals 'clean verify'...
[WARNING] Maven will be executed in interactive mode, but no input stream has 
been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [INFO]
[INFO] [INFO] 

[INFO] [INFO] Building my-artifact 1.0
[INFO] [INFO] 

[INFO] [INFO]
[INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ my-artifact 
---
[INFO] [INFO]
[INFO] [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
my-artifact ---
[INFO] [debug] execute contextualize
[INFO] [WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
resources, i.e. build is platform dependent!
[INFO] [INFO] skip non existing resourceDirectory C:\Users\Markus 
Karg\workspace\artifact\my-artifact\src\main\resources
[INFO] [INFO]
[INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ 
my-artifact ---
[INFO] [INFO] No sources to compile
[INFO] [INFO]
[INFO] [INFO] --- maven-resources-plugin:2.5:testResources 
(default-testResources) @ my-artifact ---
[INFO] [debug] execute contextualize
[INFO] [WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
resources, i.e. build is platform dependent!
[INFO] [INFO] skip non existing resourceDirectory C:\Users\Markus 
Karg\workspace\artifact\my-artifact\src\test\resources
[INFO] [INFO]
[INFO] [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) 
@ my-artifact ---
[INFO] [INFO] No sources to compile
[INFO] [INFO]
[INFO] [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ my-artifact 
---
[INFO] [INFO] No tests to run.
[INFO] [INFO] Surefire report directory: C:\Users\Markus 
Karg\workspace\artifact\my-artifact\target\surefire-reports
[INFO]
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO]
[INFO] Results :
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] [INFO]
[INFO] [INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ my-artifact ---
[INFO] [WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] [INFO] Building jar: C:\Users\Markus 
Karg\workspace\artifact\my-artifact\target\my-artifact-1.0.jar
[INFO] [INFO] 

[INFO] [INFO] BUILD SUCCESS
[INFO] [INFO] 

[ANN] Application Assembler Maven Plugin 1.6 Released

[Dan Tran]

Hi,

The Mojo team is pleased to announce the release of the Application
Assembler Maven Plugin version 1.6.

The Application Assembler Plugin is a Maven plugin for generating
scripts for starting java applications. All dependencies and the
artifact of the project itself are placed in a generated Maven
repository in a defined assemble directory. All artifacts
(dependencies + the artifact from the project) are added to the
classpath in the generated bin scripts.

http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/

To get this update, simply specify the version in your project's
plugin configuration:

  
org.codehaus.mojo
appassembler-maven-plugin
1.6
  

Release Notes

Bug

   - [MAPPASM-188 ] - Empty
   CLASSPATH_PREFIX adds current directory to classpath
   - [MAPPASM-204 ] - Support
   Solaris x86_64 - Commercial JSW only
   - [MAPPASM-208 ] -
   binFolder configuration is not used to generate path to environment setup
   file.
   - [MAPPASM-211 ] - Null
   pointer exception when providing empty 

Improvement

   - [MAPPASM-59 ] -
   appassembler chmod and bat file creation
   - [MAPPASM-202 ] -
   Deprecate program.name in favor of program.id
   - [MAPPASM-207 ] - Add
   CONFIGDIR environment variable for configurationDirectory property in
   scripts
   - [MAPPASM-209 ] - Allow
   false for JSW daemons

New Feature

   - [MAPPASM-206 ] - Support
   endorsed lib folder



Enjoy,

The Mojo team.

Why is "mvn validate compile" different from "mvn validate; mvn compile"?

[Alexander Kriegisch]

Hi.

I have used mvn for a while, but am by no means an expert, so if I am asking an 
obvious question please pardon me and answer it anyway if you can. Thanks.

I have bound some plugin executions to the validate phase because I need them 
to happen before compile. If I execute

mvn validate
mvn compile

everything is fine. But if I call

mvn validate compile

Maven behaves differently. What I do during validate is download external, 
non-mavenised (as in unavailable on Central) dependencies and install them 
locally if they are not registered in my local repo yet. Those dependencies are 
used in the compile phase. Now if I seperate the two calls it works, but if I 
do it in one mvn call and rely on the order of phases, Maven breaks my build by 
checking for remote and local artifact availability *before* actually starting 
the validate stuff from my POM. If I run "mvn -X ..." I can clearly see the 
difference.

Am I doing anything wrong? Can I force Maven to actually do what is described 
in the documentation, i.e. perform the whole validate phase with all executions 
bound to it in my POM *before* doing anything else related to the compile phase 
such as trying to download dependencies?

Thank you
-- 
Alexander Kriegisch


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

Re: Help for Maven Migration

[Jason Tesser]

I had trouble here.  Can you provide an example of your CURL for
artifactory?

Is it generating the pom for you automatically?


On Thu, Nov 7, 2013 at 3:43 AM, Andy  wrote:

> Also +1, I had 198 deps and did exactly this earlier this year in just a
> morning using Artifactory API : http://www.jfrog.com/
> confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-
> DeployArtifact
>
> Andy.
>
>
> On 06.11.2013 23:35, Ron Wheeler wrote:
>
>> +1.
>>
>> On 06/11/2013 3:57 PM, Wayne Fay wrote:
>>
>>> I want to know Should I just deploy my entire WEB-INF/lib to Artifactory?

>>> Most likely, no, you should not do this.
>>>
>>> Instead spend the time to match each Jar file up to an equivalent Jar
>>> file deployed in Central. For Jars which do not exist in Central or
>>> those with modified contents, you can consider uploading them to your
>>> private Artifactory instead - but I would deploy under a GAV that
>>> somehow specifies "this is our internal version of the artifact" so
>>> you can keep track of them easily and hopefully get rid of them in
>>> most instances in the future.
>>>
>>>  Deploying my entire WEB-INF/lib seems easiest to me BUT then what is the
 EASIEST way to generate the POM for the dependencies? Is there a single
 command that can do this? Is there a MVN command that will do this for
 me?

>>> You only have 130 dependencies. This seems like a lot, but it honestly
>>> is not. This is a 1-time job you need to perform and then you never
>>> need to do it again. Find 1-2 days in your schedule and just start the
>>> work - you will be done sooner than you realize.
>>>
>>> All other "solutions" to this problem have their own set of related
>>> problems. You are simply kicking the can down the road a bit if you do
>>> not complete this work today, and do it the right way.
>>>
>>> Wayne
>>>
>> **
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Help for Maven Migration

[Andy]

Also +1, I had 198 deps and did exactly this earlier this year in just a morning using Artifactory API : 
http://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-DeployArtifact


Andy.

On 06.11.2013 23:35, Ron Wheeler wrote:

+1.

On 06/11/2013 3:57 PM, Wayne Fay wrote:

I want to know Should I just deploy my entire WEB-INF/lib to Artifactory?

Most likely, no, you should not do this.

Instead spend the time to match each Jar file up to an equivalent Jar
file deployed in Central. For Jars which do not exist in Central or
those with modified contents, you can consider uploading them to your
private Artifactory instead - but I would deploy under a GAV that
somehow specifies "this is our internal version of the artifact" so
you can keep track of them easily and hopefully get rid of them in
most instances in the future.


Deploying my entire WEB-INF/lib seems easiest to me BUT then what is the
EASIEST way to generate the POM for the dependencies? Is there a single
command that can do this? Is there a MVN command that will do this for me?

You only have 130 dependencies. This seems like a lot, but it honestly
is not. This is a 1-time job you need to perform and then you never
need to do it again. Find 1-2 days in your schedule and just start the
work - you will be done sooner than you realize.

All other "solutions" to this problem have their own set of related
problems. You are simply kicking the can down the road a bit if you do
not complete this work today, and do it the right way.

Wayne

**


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