posal-Ease-the-usage-of-Failsafe-tp5811232p5812480.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I like failsafe as well and in our jenkins instances we do not use
failsafe:verify. Instead the build will go red for a broken surefire
test but only yellow for a broken IT. Adding more plugins into to
default lifecycle slows down execution as well and for some projects
it is just not needed.
Regar
2014-10-28 17:54 GMT+01:00 Benson Margulies :
> Personally, I wonder why we don't merge them.
>
> Failsafe adds some lifestyle phase bindings and then changes some
> defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to
> have the extra executions with shifted defaults for things
Hi,
i'm completely against merging maven-failsafe-plugin into the life cycle...
Running maven-failsafe-plugin within integration-test phase is one
solution...but sometimes you have other things to do for integration
tests
In pre-integration-test phase it's often the case to start an
app
I wrote it before I had my apache commit bit.
there are pluses and minuses to combining them.
For instance it is harder to configure different defaults for goals when
they are the same plugin.
But in any case, for either path changing the bindings to make them easier
to use will still require ad
If my memory serves me right, the failsafe plugin was conceived/developed
by a third party -- perhaps codehaus. Then it was later adapted by Apache.
I think this is maybe why the two haven't been merged (yet).
Cheers,
Paul
On Tue, Oct 28, 2014 at 12:06 PM, Jeff Jensen <
jeffjen...@upstairstechno
>
> Integrating Failsafe in the same way as Surefire would be great for a lot
> of people I think.
I agree!
Personally, I wonder why we don't merge them.
I've wondered the same thing... is there a technical reason why it "won't"
or is difficult to make work?
On Tue, Oct 28, 2014 at 11:54 AM
Personally, I wonder why we don't merge them.
Failsafe adds some lifestyle phase bindings and then changes some
defaults. Otherwise, it's a giant anti-DRY. Why not expand surefire to
have the extra executions with shifted defaults for things like test
class names?
On Tue, Oct 28, 2014 at 11:50 A
@Paul: Yes I think so or we find a way more convenient in this moment.
@all: I think this shows perfectly why Failsafe should be integrated as
Surefire already is.
Oliver
Am 28.10.14 16:02, schrieb Paul Benedict:
Thanks. Now I know when to use this. For my situation, which is integration
tes
Thanks. Now I know when to use this. For my situation, which is integration
testing against an existing database, I don't need to setup an environment;
this explains why I never needed to use the plugin. There are other cases
the plugin will be valuable, but I wonder if this is why most others stic
The answer is on the index page of the failsafe plugin [1].
"If you use the Surefire Plugin for running tests..."
/Anders
[1] http://maven.apache.org/surefire/maven-failsafe-plugin/
On Tue, Oct 28, 2014 at 3:18 PM, Paul Benedict wrote:
> I have always used surefire for integration tests with a
I have always used surefire for integration tests with a Maven profile (to
activate them on demand since they are time consuming). What benefit am I
missing not using failsafe?
Cheers,
Paul
On Tue, Oct 28, 2014 at 5:26 AM, Oliver B. Fischer
wrote:
> Hi,
>
> I see a lot of people using *Surefir
Hi,
I see a lot of people using *Surefire for intergation tests instead of
Failsafe*. I think the reason for this is that *Failsafe* is from my
perspective is *not integrated* in Maven *as is possible*.
While unittest (*Test.java) are executed if we place them in
|src/test/java| for integrat
13 matches
Mail list logo
