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: [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]
