You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Markku Saarela <ma...@pp6.inet.fi> on 2012/03/02 07:32:16 UTC
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
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.
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
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ivalo <iv...@iki.fi>.
My day job company is assosiate member of Eclipse so of course Eclipse
is tool to use.
Markku
On 2.3.2012 18:14, Wayne Fay wrote:
>> 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
> ...
>> Of course NetBeans and IntelliJ has correct way to do things but they are
>> not an option.
> Help me understand this line of thinking...
>
> Product A is demonstrably broken for what we need and has been since 2008.
> Products B and C support our needs perfectly well. One is free, one is not.
> And yet B and C are "not an option."
>
> This doesn't sound rational to me. Why are they not an option for you?
> I would challenge that assertion with whoever is making the decision.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ivalo <iv...@iki.fi>.
My day job company is associate member of Eclipse so of course Eclipse
is tool to use.
Markku
On 2.3.2012 18:14, Wayne Fay wrote:
>> 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
> ...
>> Of course NetBeans and IntelliJ has correct way to do things but they are
>> not an option.
> Help me understand this line of thinking...
>
> Product A is demonstrably broken for what we need and has been since 2008.
> Products B and C support our needs perfectly well. One is free, one is not.
> And yet B and C are "not an option."
>
> This doesn't sound rational to me. Why are they not an option for you?
> I would challenge that assertion with whoever is making the decision.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Wayne Fay <wa...@gmail.com>.
> 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
...
> Of course NetBeans and IntelliJ has correct way to do things but they are
> not an option.
Help me understand this line of thinking...
Product A is demonstrably broken for what we need and has been since 2008.
Products B and C support our needs perfectly well. One is free, one is not.
And yet B and C are "not an option."
This doesn't sound rational to me. Why are they not an option for you?
I would challenge that assertion with whoever is making the decision.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Barrie Treloar <ba...@gmail.com>.
On Sat, Mar 3, 2012 at 6:28 AM, Markku Saarela <ma...@iki.fi> wrote:
> Our releases do not have any configuration files in artifact's, instead
> manifest classpaths has directory name to point directory that has those
> files. We use separate build to assembly different configurations into
> different environments putting configurations in place.
>
> I like to use Eclipse ability to hot deploy modifications of code into
> server while debugging development trunk code.
>
> So what you say and my experience it is impossible to use multi-module
> project imported with project references for developing software with hot
> deployment and also unit testing without having profiles to set resource
> directories for Eclipse unit testing and deploying into server.
There is nothing stopping you creating an extra level of abstraction,
i.e. "<mymodule>-unittests"
You move all your unit tests out of the original module "<mymodule>"
and into "<mymodule>-unittests".
Obviously "<mymodule>-unittests" would depend on "<mymodule>"
That way you can run unit tests, but you would only ever deploy
"<mymodule>", with no way to pollute with unit tests.
p.s. Given Eclipse is open source, if this was a defect that you
*really* cared about, you should provide a patch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Markku Saarela <ma...@iki.fi>.
Our releases do not have any configuration files in artifact's, instead
manifest classpaths has directory name to point directory that has those
files. We use separate build to assembly different configurations into
different environments putting configurations in place.
I like to use Eclipse ability to hot deploy modifications of code into
server while debugging development trunk code.
So what you say and my experience it is impossible to use multi-module
project imported with project references for developing software with
hot deployment and also unit testing without having profiles to set
resource directories for Eclipse unit testing and deploying into server.
It's not so convenient to go outside IDE to deploy artifact into server
in order to debug / test modifications made.
Markku
On 2.3.2012 21:29, Ron Wheeler wrote:
> 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
>>>>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Markku Saarela <ma...@iki.fi>.
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
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Markku Saarela <ma...@pp6.inet.fi>.
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
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102