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.)
application.
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.
Ron
Regards
Caoilte
On Mon, Oct 4, 2010 at 1:03 PM, Ron Wheeler
<[email protected]> 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<[email protected]> 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 not
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
