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: local policy)
Message-ID: <4F511F89.1040903@artifact-software.com>
Date: Fri, 02 Mar 2012 14:29:13 -0500
From: Ron Wheeler <rwheeler@artifact-software.com>
Reply-To: rwheeler@artifact-software.com
Organization: Artifact Software
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Maven Users List <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> <4F5118E4.1070305@iki.fi>
In-Reply-To: <4F5118E4.1070305@iki.fi>
Content-Type: multipart/mixed;
 boundary="------------000804080109070608060800"

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

I am not sure if this directly answers your question but perhaps a bit 
of background helps.

We use Eclipse STS which comes with Maven support built in. We used to 
waste so much time upgrading Eclipse and getting everyone configured in 
the same way.
Now it is a single download (BIG) to get everything that you need except 
Subversion.

We have individual projects since the project is divided up on 
functional lines with core modules for the database access and some 
modules that can best be described as utilities (messaging for example).
This means that for any maintenance activity almost all of the modules 
are not affected.
In addition, modules are worked on by different people.
No one would have all of modules checked out at once. Certainly you 
would not have them open in Eclipse.

We use SNAPSHOTs during development and maintenance.
We do not make all of the 70 modules carry the same release version. It 
is possible to see a version 1.10.3 of the overall application running 
with most of the WAR files as version 1.10 if they were bug free up to 
the 1.10.3 release.

We do some unit testing and do most of our testing on the developer's 
workstation.
We have at least 1 test server where developers can test in an 
environment that is almost identical to production and can be tested by 
the client(s). More than 1 if we have a big maintenance issue while we 
are trying to get a major development tested. We are starting to use the 
cloud for this so the actual number of test servers potentially 
available is close to infinite.

We deploy the WAR files by hand to the appropriate server.

We use JNDI to support our Spring configurations so we do not have any 
variation in the WARs between test and different production servers.

This is certainly not the only way to do things but I have never heard 
of any problems with test classes or test configurations leaking into 
production.

The build is described in the master POM for the project. The master POM 
is the key to every project and contains everything that is common 
between modules so the module poms are pretty small.

Below is the build description from the master POM for a project.
I hope that this helps a bit.

Ron

<build>
<sourceDirectory>src/main</sourceDirectory>
<scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
<testSourceDirectory>src/test</testSourceDirectory>
<outputDirectory>target/classes</outputDirectory>
<testOutputDirectory>target/test-classes</testOutputDirectory>
<resources>
<resource>
<directory>src/main</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
<testResources>
<testResource>
<directory>test</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</testResource>
</testResources>
<directory>target</directory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<encoding>UTF-8</encoding>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.5</version>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<warSourceDirectory>WebContent</warSourceDirectory>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
</plugin>

</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>
                                         jar-with-dependencies
</descriptorRef>
</descriptorRefs>

</configuration>
</execution>
</executions>
</plugin>

</plugins>
</pluginManagement>
</build>

Ron


On 02/03/2012 2:00 PM, Markku Saarela wrote:
> 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
>>>>>

-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


--------------000804080109070608060800
Content-Type: text/plain; charset=us-ascii


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