maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Date Fri, 02 Mar 2012 13:15:08 GMT
On 02/03/2012 1:32 AM, Markku Saarela wrote:
> Hi,
> Developing with Eclipse IDE and JavaEE server using 
> maven-eclipse-plugin you have to use profiles, because Eclipse does 
> not isolate test code and test resources.
Eclipse does
/src/main/....   code
/src/test   ... test code and resources

You need to set your maven properly but it works fine unless I don't 
understand your issue.

> Only way to do it what i have figured out is to have two profiles one 
> for running application in app server and another for unit testing 
> same code.  Those profiles has only resources and testResources 
> definitions.
> Separating test code for separate code is not an option, because then 
> Sonar reports 0 % coverage.
> rgds,
> Markku
> On 1.3.2012 22:55, Ron Wheeler wrote:
>> On 01/03/2012 2:43 PM, offbyone wrote:
>>> Ok so I should create a base pom with a war configuration and then a 
>>> separate
>>> pom for each site that depends on this with overlays to add the extra
>>> configuration file.
>>> I will try.
>>> If I am interpreting your comments correctly, profiles allow for a 
>>> user to
>>> flaten a maven build deployment, but this is a bad practice and it 
>>> is better
>>> to make your maven structure deep.
>>> So are profiles going to be deprecated?   I would think I am not 
>>> alone in
>>> getting turned down the wrong path because most of the 
>>> documentation/howtos
>>> I have found point to using profiles.
>> There are some uses for profiles that seem harmless so it is a 
>> documentation issue.
>> It is fairly common in Apache documentation for the programmers to 
>> make a big deal about all the wonderful things that the package can do.
>> They are not particularly concerned about "Best Practices".
>> The most common usage is often left out of the documentation since it 
>> is "dull" or not very impressive.
>> This sometimes means that obscure usage of features or seldom used 
>> features are heavily documented while the main use case is  not 
>> described.
>> New Maven users often fall into the trap that you were headed into.
>> A really simple "Best Practice" that most people use, is hard to find 
>> in the documentation while an obscure "Worst Practice" is described 
>> because it shows how clever the software developers are and how 
>> powerful the product is.
>> There should be a "Best Practice" section on the Maven site 
>> describing the best way to implement the common software development 
>> patterns.
>> There are not really a lot of cases to consider but every new Maven 
>> user has to sort out their own case.
>> Ron
>>> -- 
>>> View this message in context: 
>>> Sent from the Maven - Users mailing list archive at
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

View raw message