Re: Maven concurrent builds

[Michael Haefele]

Jenkins also has a setting "Use private Maven repository" in the build
section of the job configuration which takes care of this for you.

Mike

On Wed, Mar 7, 2012 at 5:41 AM, Srinath C  wrote:
> Always use a different local repositories for different projects in Jenkins.
> You can do this by setting the system property
> -Dmaven.local.repo={project_workspace_dir}
>
> Regards,
> Srinath.
>
>
> On Wed, Mar 7, 2012 at 1:59 PM, Jörg Schaible
> wrote:
>
>> Hi Guillaume,
>>
>> Guillaume Polet wrote:
>>
>> > Dear all,
>> >
>> > I was having some doubts regarding Maven's ability to handle properly
>> > concurrent builds. Lately, I had several builds of our project that
>> > failed and it seemed that it was due to interferences between concurrent
>> > builds of the same version of the same project.
>> >
>> > I have a jenkins server which have 6 different builds:
>> > * 1 for continuous build (which runs tests but does not deploy the
>> > artifacts)
>> > * 1 for nightly build
>> > * 1 for releases (or almost release, ie, the pom is still in SNAPSHOT
>> > version but could become a release)
>> > All this is multiplied by two, because I have two versions (on 2
>> > different branches).
>> >
>> > So I had 2 questions:
>> > 1. Can/Does Maven support concurrent builds of the same version of the
>> > same project?
>>
>> Not out of the box. Since by default both builds will use the same local
>> repository creating the same artifacts at same time, the artifacts in the
>> repository are likely to be corrupted.
>>
>> > If yes, do I need to do something to achieve this?
>>
>> Use separate local repositories, it can be defined using separate
>> settings.xml files or by call with a system property. Actually I don't know
>> if Jenkins already supports something like this, because it's a general
>> problem, see below.
>>
>> > If not,
>> > is it something that Maven developers are considering?
>>
>> It's not the first time this problem has been risen.
>>
>> > 2. Can/Does Maven support concurrent builds of different versions of the
>> > same project?
>>
>> They may still corrupt the metadata.xml files, but it is less likely and
>> has
>> AFAICS less consequences.
>>
>> However, every concurrent build may corrupt a shared local repository,
>> because both builds may download the same artifacts at same time. A
>> scenario
>> where this might happen is when you upgrade versions (e.g. of plugins) in a
>> common master-pom and start two parallel builds then. Actually I am not
>> sure
>> if you're safe when running one Maven build in parallel mode. A repository
>> manager like Nexus might prevent this scenario by detecting the same
>> request, but again I am not sure if it does.
>>
>> BTW: This is also the reason why you should never share a local repository
>> with a network mount by multiple users.
>>
>>
>> >
>> > Cheers,
>> > Guillaume
>>
>>
>>
>> -
>> 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: Site plugin in maven 3.

[Michael Haefele]

One more followup.

It does look like the source of at least some of my problems was the
 tag.

We had a few poms that had been cut/pasted and had identical url's.
Once I commented all of those out, everything looks like it is in the right
place and it looks like all the links work so far.

Thanks for your help.

Mike

On Thu, Sep 8, 2011 at 12:52 PM, Michael Haefele <
michael.haef...@parityenergy.com> wrote:

> Ah!
>
> http://jira.codehaus.org/**browse/MSITE-600<http://jira.codehaus.org/browse/MSITE-600>
> http://maven.apache.org/**plugins/maven-site-plugin/faq.**html#Use_of_url<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Use_of_url>
> http://maven.apache.org/**plugins/maven-site-plugin/faq.**
> html#Why_do_my_absolute_links_**get_translated_into_relative_**links<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_do_my_absolute_links_get_translated_into_relative_links>
>
> All sound like potential causes of what I am seeing.  That will be the
> first thing I check when I get back.
>
> One more question possibly in relation to http://jira.codehaus.org/**
> browse/MSITE-600 <http://jira.codehaus.org/browse/MSITE-600>.
>
> In a few of the cases I tried, I'd end up with site:stage attempting to
> place files in target/staging/../../mysite/morestuff (ie. in the base
> directory of my aggregator) or even farther up the directory tree..
>
> How would you feel about having site:stage verify all the staging files
> actually went into the staging directory and erroring out otherwise?
>
> Having maven place files in non-target directories makes me really nervous
> (even if my configuration might be to blame).
>
> Thanks for all the help!
> Mike
>
> On Thu, Sep 8, 2011 at 12:29 PM, Lukas Theussl wrote:
>
>>
>>
>> Michael Haefele wrote:
>>
>>> Third time trying to send this... I keep getting spam blocked.
>>>
>>> "Technical details of permanent failure:
>>> Google tried to deliver your message, but it was rejected by the
>>> recipient
>>> domain. We recommend contacting the other email provider for further
>>> information about the cause of this error. The error that the other
>>> server
>>> returned was: 552 552 spam score (5.3) exceeded threshold
>>> (HTML_MESSAGE,RCVD_IN_DNSWL_**LOW,SPF_NEUTRAL,URI_OBFU_WWW (state 18)."
>>>
>>>
>>> The long and the short of it is I need to come up with a set of test
>>> projects to verify what I am seeing.
>>>
>>> If I'm reading this right, there are a few expected behaviors..
>>> 1.  mvn site:site site:stage should work.
>>>
>>
>> It should work up to http://maven.apache.org/**
>> plugins/maven-site-plugin/faq.**html#What_is_the_difference_**
>> between_mvn_site_and_mvn_site:**site<http://maven.apache.org/plugins/maven-site-plugin/faq.html#What_is_the_difference_between_mvn_site_and_mvn_site:site>
>>
>>
>>  2.  The<**site>  is important.
>>>
>>
>> Only in a multi-module build and/or if you want to stage/deploy your site.
>>
>>
>>  *  It can be in the form of file://mysite/ or scp://mysite/
>>>
>>
>> it should be a valid URL (and to make sense it should be an absolute URL,
>> even though in practice a relative one will probably work too, as in the
>> example you have shown in your previous email).
>>
>>
>>  *  It will be inherited by child modules (as in hierarchy, not
>>> aggregator/directory children) and appended with that child artifactId.
>>>
>>
>> yes, unless you explicitly override it in the inheriting child. However,
>> note 
>> http://jira.codehaus.org/**browse/MSITE-600<http://jira.codehaus.org/browse/MSITE-600>which
>>  I still haven't managed to fix in a satisfactory manner.
>>
>>
>>  ** This will not work if the module directory does not match the
>>> artifactId.
>>> 3.  Does the  tag matter?
>>>
>>
>> See
>> http://maven.apache.org/**plugins/maven-site-plugin/faq.**html#Use_of_url<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Use_of_url>
>> http://maven.apache.org/**plugins/maven-site-plugin/faq.**
>> html#Why_do_my_absolute_links_**get_translated_into_relative_**links<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_do_my_absolute_links_get_translated_into_relative_links>
>>
>>
>>
>>
>>> What I would like to do is add
>>> 
>>> anId
>>> scp://mysite/
>>> 
>>> to my corporate pom and have that be inherited down to the ch

Re: Site plugin in maven 3.

[Michael Haefele]

Ah!

http://jira.codehaus.org/**browse/MSITE-600<http://jira.codehaus.org/browse/MSITE-600>
http://maven.apache.org/**plugins/maven-site-plugin/faq.**html#Use_of_url<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Use_of_url>
http://maven.apache.org/**plugins/maven-site-plugin/faq.**
html#Why_do_my_absolute_links_**get_translated_into_relative_**links<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_do_my_absolute_links_get_translated_into_relative_links>

All sound like potential causes of what I am seeing.  That will be the first
thing I check when I get back.

One more question possibly in relation to http://jira.codehaus.org/**
browse/MSITE-600 <http://jira.codehaus.org/browse/MSITE-600>.

In a few of the cases I tried, I'd end up with site:stage attempting to
place files in target/staging/../../mysite/morestuff (ie. in the base
directory of my aggregator) or even farther up the directory tree..

How would you feel about having site:stage verify all the staging files
actually went into the staging directory and erroring out otherwise?

Having maven place files in non-target directories makes me really nervous
(even if my configuration might be to blame).

Thanks for all the help!
Mike

On Thu, Sep 8, 2011 at 12:29 PM, Lukas Theussl  wrote:

>
>
> Michael Haefele wrote:
>
>> Third time trying to send this... I keep getting spam blocked.
>>
>> "Technical details of permanent failure:
>> Google tried to deliver your message, but it was rejected by the recipient
>> domain. We recommend contacting the other email provider for further
>> information about the cause of this error. The error that the other server
>> returned was: 552 552 spam score (5.3) exceeded threshold
>> (HTML_MESSAGE,RCVD_IN_DNSWL_**LOW,SPF_NEUTRAL,URI_OBFU_WWW (state 18)."
>>
>>
>> The long and the short of it is I need to come up with a set of test
>> projects to verify what I am seeing.
>>
>> If I'm reading this right, there are a few expected behaviors..
>> 1.  mvn site:site site:stage should work.
>>
>
> It should work up to http://maven.apache.org/**
> plugins/maven-site-plugin/faq.**html#What_is_the_difference_**
> between_mvn_site_and_mvn_site:**site<http://maven.apache.org/plugins/maven-site-plugin/faq.html#What_is_the_difference_between_mvn_site_and_mvn_site:site>
>
>
>  2.  The<**site>  is important.
>>
>
> Only in a multi-module build and/or if you want to stage/deploy your site.
>
>
>  *  It can be in the form of file://mysite/ or scp://mysite/
>>
>
> it should be a valid URL (and to make sense it should be an absolute URL,
> even though in practice a relative one will probably work too, as in the
> example you have shown in your previous email).
>
>
>  *  It will be inherited by child modules (as in hierarchy, not
>> aggregator/directory children) and appended with that child artifactId.
>>
>
> yes, unless you explicitly override it in the inheriting child. However,
> note 
> http://jira.codehaus.org/**browse/MSITE-600<http://jira.codehaus.org/browse/MSITE-600>which
>  I still haven't managed to fix in a satisfactory manner.
>
>
>  ** This will not work if the module directory does not match the
>> artifactId.
>> 3.  Does the  tag matter?
>>
>
> See
> http://maven.apache.org/**plugins/maven-site-plugin/faq.**html#Use_of_url<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Use_of_url>
> http://maven.apache.org/**plugins/maven-site-plugin/faq.**
> html#Why_do_my_absolute_links_**get_translated_into_relative_**links<http://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_do_my_absolute_links_get_translated_into_relative_links>
>
>
>
>
>> What I would like to do is add
>> 
>> anId
>> scp://mysite/
>> 
>> to my corporate pom and have that be inherited down to the children,
>> grandchildren, etc nodes..
>>
>> So, for example, if I have a hierarchy
>> corp->my-grandparent->my-**parent->my-module
>> and an aggregator root module
>> corp->my-aggregator which aggregates my-grandparent, my-parent and
>> my-module
>>
>> my-aggregator/
>> my-aggregator/my-grandparent
>> my-aggregator/my-parent
>> my-aggregator/my-module
>>
>> If only corp has a url defined,
>> I would expect the my-module url to be
>> scp://mysite/my-grandparent/**my-parent/my-module/ ?
>>
>
> yes
>
>
>  And the following structure for my-aggregator/staging ?
>> target/staging/corp/my-**aggregator
>> target/staging/corp/my-**grandparent
>> target/staging/corp/my-**grandparent/my-parent
>> target/

Re: Site plugin in maven 3.

[Michael Haefele]

Third time trying to send this... I keep getting spam blocked.

"Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient
domain. We recommend contacting the other email provider for further
information about the cause of this error. The error that the other server
returned was: 552 552 spam score (5.3) exceeded threshold
(HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,URI_OBFU_WWW (state 18)."


The long and the short of it is I need to come up with a set of test
projects to verify what I am seeing.

If I'm reading this right, there are a few expected behaviors..
1.  mvn site:site site:stage should work.
2.  The  is important.
*  It can be in the form of file://mysite/ or scp://mysite/
*  It will be inherited by child modules (as in hierarchy, not
aggregator/directory children) and appended with that child artifactId.
** This will not work if the module directory does not match the artifactId.
3.  Does the  tag matter?

What I would like to do is add

anId
scp://mysite/

to my corporate pom and have that be inherited down to the children,
grandchildren, etc nodes..

So, for example, if I have a hierarchy
corp->my-grandparent->my-parent->my-module
and an aggregator root module
corp->my-aggregator which aggregates my-grandparent, my-parent and my-module

my-aggregator/
my-aggregator/my-grandparent
my-aggregator/my-parent
my-aggregator/my-module

If only corp has a url defined,
I would expect the my-module url to be
scp://mysite/my-grandparent/my-parent/my-module/ ?
And the following structure for my-aggregator/staging ?
target/staging/corp/my-aggregator
target/staging/corp/my-grandparent
target/staging/corp/my-grandparent/my-parent
target/staging/corp/my-grandparent/my-parent/my-grandparent

And all the links properly navigate this structure.

I've got a bit of vacation coming up, but after that I will try to come up
with some simple test projects to confirm what I am seeing on our main
project (or perhaps expose that I'm doing something non-maveny that i can
fix).

Thanks!
Mike

Site plugin in maven 3.

[Michael Haefele]

The question on using site with aggregated projects got me to trying out the
maven 3 version of the site plugin..

Thought I'd post a little list of the steps required and a report card.

My use case is I want to generate a site in some directory in a nightly CI
build for an aggregated project.

I don't really care what the site looks like beyond maybe adding any
reporting plugins that sound interesting.
I certainly don't want to deploy it anywhere as it's already
web accessible as an artifact of the nightly build (this has the added
benefit of being able to compare Tuesday's site with Wednesday's site).
Basically i want to run the plugin and use whatever the default output
is

In Maven 2, this use case didn't fare very well (specifically this use case.
 If this is an outlandish use case, that's fine).
Basically I jumped through 4 or 5 flaming hoops and gave up (again, it's a
nice to have, but not part of core business in any way, so the last 3 hoops
were more out of stubbornness than a good use of my time).

So hopefully Maven 3 would be a little more forgiving.

To get started, I followed the link sent in the other post.  (
http://maven.apache.org/**plugins/maven-site-plugin/faq.**
html#Why_dont_the_links_**between_parent_and_child_**
modules_work_when_I_run_mvn_**site
)

I need to use site:stage, but this requires the site to be generated...

So...
mvn clean site:site && mvn site:stage  (mvn clean site:site site:stage does
not work well I discovered)
Yields:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:stage (default-cli) on
project pep-parent-dep-mgmt: Missing site information in the distribution
management of the project pep-parent-dep-mgmt
(com.pep:pep-parent-dep-mgmt:3.10-SNAPSHOT) -> [Help 1]

So I'll count this as Hoop #1.  Why does maven need this information (as in,
why can't maven leave this blank or put in a "fix-me" value)?

I tried adding



  www.yourcompany.com
  scp://www.yourcompany.com/www/docs/project/

  

, straight out of
http://maven.apache.org/plugins/maven-site-plugin/usage.html#Deploying_a_Site
(even
though i'm not actually deploying).
But this eventually causes some weird directory names in the site links
(they include the "scp://"), so I took that out and just used


This one actually deployed everything except the grandparent module  (we
have a grandparent, a parent which has grandparent as parent, and an
aggregating project, which does not have the parent or grandparent as a
parent) to target/staging/../../../../ (which turned out to be just above my
~ directory).  I don't know where all the ../../../ came from (maybe the
 in the  tag?).

I finally goldilocked on
mysite

Which doesn't really make any sense, but seems to do the least crazy to the
staging directory structure..
I added this to the aggregating project and the grandparent project

mvn clean site:site && mvn site:stage

This now works except the grandparent project doesn't seem to have it's own
directory (clicking on the module link takes you to the staging directory)..
 But certainly good enough for my purposes..

In summary, I'd probably give the 3.0 site plugin a B- for this use case,
which is a HUGE improvement over maven 2.

My main issue is with configuring the  tag, which seems like
an unnecessary step if site:stage doesn't need it (especially since getting
it wrong can do odd things to where the files are staged).
It would be great if this defaulted to some safe value.

or if someone could suggest some safe value, that would be awesome.
It looks like if I use file:// or scp:// as suggested by
http://maven.apache.org/plugins/maven-site-plugin/usage.html#Deploying_a_Site
it
starts doing really strange things with the directories.

Again, it just feels like one should be able to run mvn site:stage and get a
meaningful result where all the links make sense...
No?

Thanks,
Mike

Re: Maven folder structure

[Michael Haefele]

"Let the Wookie win."

On Thu, May 19, 2011 at 12:33 PM, Ron Wheeler
 wrote:
> +1
> If you don't do things the Maven way, you will be in a battle until Maven
> defeats you.
> You might as well give in early, you have no chance of wining.
> Maven is relentless and determined to bend you to its will.
>
> Ron
>
> On 19/05/2011 10:28 AM, Thiessen, Todd (Todd) wrote:
>>
>> Your scenario is not uncommon. I have seems many teams go through it.
>>
>> The advice I always give is to NOT give in to the temptation to try and
>> keep your existing structure when you move to maven.  Your build will be a
>> large mess.
>>
>> Converting to maven means more than simply adopting a folder convention.
>>  It is also about a build philosophy. For example, Maven strongly encourages
>> one artifact per project.  You will run into this when converting your build
>> to use maven. If you deviate from using the default folder conventions, in
>> my experience, only leads to greater confusion and more time to get the
>> conversion done.
>>
>>> -Original Message-
>>> From: uday shankar [mailto:adonis.u...@gmail.com]
>>> Sent: Thursday, May 19, 2011 10:15 AM
>>> To: users@maven.apache.org
>>> Subject: Re: Maven folder structure
>>>
>>> Hi Karl,
>>> I understand that you are asking me to stick to the default folder
>>> structure
>>> created by maven.
>>> This(sticking to the default folder structure) works fine when we are
>>> using
>>> maven right from the beginning of the project.But what if say,
>>> Scenario 1: we have started the project in eclipse, and in the middle
>>> of the
>>> development process I want to use maven. And maven commands seem to be
>>> using
>>> the default folder structure. How can we use maven with a different
>>> folder
>>> structure(because a simple web application created using maven commands
>>> have
>>> different structure when compared to a web application created in
>>> eclipse)??
>>>
>>> Scenario 2: If say initially we were using Ant as the building tool for
>>> a
>>> project. Now we want to use Maven as the tool , how do we implement
>>> that?
>>> What is the process of migration from ant to maven?
>>>
>>> If there is ambiguity anywhere, I will try explaining again.
>>> Thanks,
>>> Uday
>>>
>>>
>>>
>>> --
>>> View this message in context: http://maven.40175.n5.nabble.com/Maven-
>>> folder-structure-tp4409276p4409835.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>> -
>>> 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
>
>

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

Re: order of the unpacking from "unpack-dependencys"

[Michael Haefele]

Or use maybe use both.
Put an  in for the unpack-dependencies mojo to exclude all
scripts and then use an  in the unpack mojo for just the
scripts you actually want from the proper artifact.

Over-writing in the right order seems like the sort of thing that will
eventually come back to cause headaches down the road.
Better to just get the right file and none of the wrong ones.

Mike

On Thu, May 12, 2011 at 10:02 AM, Asmann, Roland
 wrote:
> Hi,
>
> You could perhaps try the "unpack" goal... You do have to add all the
> dependencies again, but that one should take the order in which the
> artifacts are listed.
>
> Roland
>
>
> On 12-05-11 15:52, David Bräutigam wrote:
>> Hello,,
>>
>> i have the following strange problem with the "unpack-dependencys" in my
>> pom. What i want is to unpack the scripts i need in the deploy directory.
>> The problem is that i have multiple modules with the same scripts. Therefor
>> to have a correct result they must be overwritten in the right order.
>> Sadly "unpack-dependencys" does not care about the order in which i declare
>> the dependency's. But strangely the order remains always the same so there
>> must be a determining order.
>>
>> Could me help somebody to understand and hopefully manipulate the unpack
>> order so that my project will be deployed correctly.
>>
>> Regards
>>
>> David
>
> --
> Roland Asmann
> Senior Software Engineer
>
> adesso Austria GmbH
> Floridotower 26. Stock              T +43 1 2198790-27
> Floridsdorfer Hauptstr. 1           F +43 1 2198790-927
> A-1210 Wien                         M +43 664 88657566
>                                    E roland.asm...@adesso.at
>                                    W www.adesso.at
>
> -
>             >>> business. people. technology. <<<
> -

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