Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of markku.saarela@iki.fi
 designates 195.156.147.13 as permitted sender)
Message-ID: <4F5118E4.1070305@iki.fi>
Date: Fri, 02 Mar 2012 21:00:52 +0200
From: Markku Saarela <markku.saarela@iki.fi>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: users@maven.apache.org
Subject: Re: using build profiles for WAR plugin [maven-eclipse-plugin]
References: 
 <CAKjsY4nYpk8G07sfi6htj3YdTsm8Nf9Sy8zXwsYhVUSvZLizqw@mail.gmail.com>
 <CALy+7UkOiyGZefAk-+6RcpwaEoj-5i58g_HpkfKnzx27nadFmg@mail.gmail.com>
 <1330551151690-5526140.post@n5.nabble.com>
 <CA+U2j0oYdFK6ufRjUD5wvXkAik-NukhXKvq21ivCxyX1E8FXWw@mail.gmail.com>
 <1330556657341-5526330.post@n5.nabble.com>
 <4F4EF6C6.1040803@artifact-software.com>
 <1330626648021-5528742.post@n5.nabble.com>
 <CALy+7UmEN5zLyTME_N-uty1gqM_H2JP0TZ1HSFouqj5r0yw3Vg@mail.gmail.com>
 <1330629394151-5528917.post@n5.nabble.com>
 <4F4FCE9C.6090704@artifact-software.com>
 <1330630997645-5528994.post@n5.nabble.com>
 <4F4FE258.1000804@artifact-software.com> <4F506970.8000902@pp6.inet.fi>
 <4F50C7DC.8080702@artifact-software.com> <4F50E507.5020606@pp6.inet.fi>
 <4F50EC5E.40707@artifact-software.com>
In-Reply-To: <4F50EC5E.40707@artifact-software.com>
Content-Type: multipart/alternative;
 boundary="------------070609090100040105030009"

--------------070609090100040105030009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

In multi-module project i hit the same problem with m2e and 
maven-eclipse-plugin. Are you saying not to import multi-module projects 
into Eclipse, instead every module separately? Or you don't use server 
plugins to deploy application instead you deploy outside Eclipse and use 
remote application debugging? But still this does not prevent unit tests 
failing with multi-module configuration because of this dependent 
project classpath has those artifacts in it's classpath before it's own 
ones.

So if you have solution to this i am more than happy to hear it.

Markku

On 2.3.2012 17:50, Ron Wheeler wrote:
> We have been developing and maintaining a large  portal application 
> with over 70 WAR files in Eclipse with Maven since 2007 and several 
> smaller portals and standalone applications. We have not had this 
> problem.
>
> That is not to say that I am an expert in Eclipse but we know enough 
> to make it work.
>
> We do not use maven-eclipse-plug-in. We use the assembly plug-in to 
> build our war files.
> Perhaps that is the difference.
>
> We also deploy to Tomcat which might be a better servlet engine than 
> Glassfish.
>
> I am not sure how relevant our experience is to your problem but if I 
> can provide any additional information that you think might help, let 
> me know.
>
> Ron
>
>
> On 02/03/2012 10:19 AM, Markku Saarela wrote:
>> Hi,
>>
>> You don't understand how Eclipse IDE works. Eclipse does not have 
>> different classpaths for testing and actual runtime. So Eclipse basic 
>> design is faulty. There is bug open since 2008 to provide means to 
>> tell Eclipse that which are test sources and not include them to 
>> runtime classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708
>>
>> So everything under src/test goes also into GlassFish server if you 
>> deploy application in Eclipse. That causes that those unit test 
>> properties and configuration and classes are picked first and they 
>> are effective and application does not work.
>>
>> Even worst if you have multi-module project and B module is dependent 
>> from A and A project defines SPI interface and has in src/test/java 
>> test implementation for that and of course in 
>> src/test/resources/META-INF/services SPI file for exposing that test 
>> SPI implementation then if B implements also that SPI interface and 
>> put SPI file in src/main/resources/META-INF/services, you cannot test 
>> you implementation via ServiceLoader because it pick's that module A 
>> test implementation. Same goes for properties and everything else.
>>
>> Of course NetBeans and IntelliJ has correct way to do things but they 
>> are not an option.
>>
>> Markku
>>
>>
>> On 2.3.2012 15:15, Ron Wheeler wrote:
>>> 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: 
>>>>>> http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html
>>>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>> --------------------------------------------------------------------- 
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


--------------070609090100040105030009--