maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: <resources> are not aggregated from parent to child pom
Date Mon, 04 Oct 2010 14:56:50 GMT
  On 04/10/2010 8:29 AM, Caoilte O'Connor wrote:
> Hi Ron,
> That's a very noble sentiment. Thanks.
> I think it would help if "Best Practices" were codified.
You are right. This causes almost all of the traffic on this site. 
Everyone starts out with an existing methodology that serves their 
non-Maven ways.
Making the workflow changes without any guides just takes a lot of 
chatter in the forum.
On the good side, you should not feel to bad about this. Everyone goes 
through it but once the workflow is Mavenized, most of the pain vanishes.
It will build any normal application out of the box.
There are some good books and higher level technical materials from 
Sonatype and others that are very good things to read to get an 
understanding of the "Maven Way".

Runing Maven without Nexus (or another repository) is a very frustrating 
way to start out.

My biggest regret about starting with Maven was that we did not have 
Nexus from the beginning.
It would have made Maven much, much easier to use.
We wasted so much time and energy for nothing.
We have had it for 6 months and I wish we had got it going 2 years ago.
> I'm quite prepared to believe that there is a cogent and reasoned
> position for why some parts of the pom are merged and others not but
> like Marshall I am not familiar with it.
You will likely get more useful advice if you describe what you are 
trying to build and try to get workflow advice.

One of the issues in the forum, is that the experts are so good and know 
Maven so well, that they will tell you how to make Maven do the most 
bizarre and intricate things if you ask a question that is too focused 
on a detail and not about workflow.
It is great to have people in the forum, who I think must dream in 
Maven, but sometimes solving a technical problem with a plug-in is not 
better than changing the problem to match what Maven expects to do for 
you if you are building a standard XYZ (Java App, Tomcat, JBoss, etc.) 

Maven does a great job of automating your workflow, IF your workflow 
fits Maven's idea of a good workflow.
If you want to fight Maven, it can be made follow your workflow but it 
will turn and bite you every chance it gets.

You will get it going nicely in the end and the people in the forum are 
really helpful and very smart.


> Regards
> Caoilte
> On Mon, Oct 4, 2010 at 1:03 PM, Ron Wheeler
> <>  wrote:
>>   Maven is almost always right.
>> Figure out why your methodology is not following "Best Practices" and change
>> the way that you work so that maven does it for you automatically.
>> You can fight Maven as much as you want but it will always win.
>> If you can identify why you are building an application that is so unusual
>> that no one else has your workflow, then you may be able to get a solution.
>> In most cases, the application is pretty normal, it is the newbee's workflow
>> that is broken.
>> If you are pioneering some new application platform, you may have a problem
>> but I think that I have seen ejbs with dependent libraries being used in
>> applications before.
>> Mavenize your workflow.
>> I hope that this helps.
>> Ron
>> On 04/10/2010 6:49 AM, Caoilte O'Connor wrote:
>>> It bites in quite a lot of places. I wanted to define one "execution"
>>> of the build-helper-maven-plugin in a parent pom and another in one of
>>> it's children then have the two merged together. However, Maven
>>> overrode the parent configuration in the child.
>>> Given that some sections of the pom (eg dependencies, properties)
>>> merge so seamlessly it is disappointing to discover sections which
>>> don't. Perhaps future versions of Maven will improve things.
>>> c
>>> On Sat, Oct 2, 2010 at 3:41 PM, Marshall Schor<>    wrote:
>>>> On 10/2/2010 7:42 AM, Benjamin Bentmann wrote:
>>>>> Xavier D. wrote:
>>>>>> My pom structure is:  pom.xml has a parent:  parent-pom.xml.
>>>>>> Both have a<resources>      section to include files.
>>>>>> The (child) pom.xml is executed directly and has the effect of only
>>>>>> copying
>>>>>> the child's resources.   Commenting out this resource section, results
>>>>>> in
>>>>>> the parent's resources being copied.
>>>>> This is expected behavior,<resources>    given in a child POM are
>>>>> merged
>>>>> with<resources>    in the parent but completely override those.
>>>> I'm curious as to why this design decision was taken, versus an approach
>>>> which
>>>> allows merging, or perhaps some kind of user (pom - specified) choice.
>>>> I was "bitten" by this also.
>>>> -Marshall Schor
>>>>> Benjamin
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message