Am 2014-10-28 um 03:17 schrieb yanshuai:
hi, all,
I found a mistake in slf4j-configuration.properties of maven-embedder project,
org.slf4j.helpers.Log4JLoggerFactory should be
org.slf4j.helpers.Log4jLoggerFactory. Otherwise, when I use log4j2 instead of
slf4j-simple, it will not find the
Nexus operation has been resumed. Please vote/test.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
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
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 mails...@swe-blog.net
wrote:
Hi,
I see a lot of
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 pbened...@apache.org wrote:
I have always used surefire for
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
@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
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
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,
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
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
Hi,
I'd like to fix MPIR-279 and by applying the logic from above. I am
having a hard time to find that spot which actually evalutes the snippet
above.
Does someone know?
Thanks,
Michael
-
To unsubscribe, e-mail:
Hi,
checked SHA1 Ok..
tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found.
So +1 from me...
Unfortunately the number of checkstyle errors has increased from 29 in
version 2.5 to 39 in version 2.6...created an appropriate jira for it
Hi,
here my +1...
Kind regards
Karl Heinz Marbaise
On 10/26/14 8:48 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 6 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=20685
There are still 2 issues left in JIRA:
Am 2014-10-28 um 20:31 schrieb Karl Heinz Marbaise:
Hi,
checked SHA1 Ok..
tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues found.
So +1 from me...
Unfortunately the number of checkstyle errors has increased from 29 in
version 2.5 to 39 in version 2.6...created an
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
Hi,
On 10/28/14 8:57 PM, Michael Osipov wrote:
Am 2014-10-28 um 20:31 schrieb Karl Heinz Marbaise:
Hi,
checked SHA1 Ok..
tested with Maven 2.2.1, 3.0.5, 3.1.1, 3.2.1, 3.2.2, 3.2.3 no issues
found.
So +1 from me...
Unfortunately the number of checkstyle errors has increased from 29 in
2014-10-28 17:54 GMT+01:00 Benson Margulies bimargul...@gmail.com:
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
Unfortunately filtering into tar/zip is broken
(http://jira.codehaus.org/browse/MASSEMBLY-722), and users of
filtering/line endings must use a previous version or wait for 2.5.1,
which will be released fairly soon.
Kristian
2014-10-27 5:50 GMT+01:00 Kristian Rosenvold
+1
2014-10-26 22:06 GMT+01:00 Michael Osipov micha...@apache.org:
Hi,
We solved 9 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325projectId=11761
There are still a couple of issues left in JIRA:
+1 (non binding), tested with my internal builds
On Tue, Oct 28, 2014 at 12:33 PM, Karl Heinz Marbaise khmarba...@gmx.de
wrote:
Hi,
here my +1...
Kind regards
Karl Heinz Marbaise
On 10/26/14 8:48 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 6 issues:
GitHub user Tibor17 opened a pull request:
https://github.com/apache/maven-surefire/pull/63
[SUREFIRE-1053] Suppress warning message if file.encoding is set using
argLine
Fix for http://jira.codehaus.org/browse/SUREFIRE-1053
You can merge this pull request into a Git repository by
+1
notice that the JDK requirement is Default target for maven-compiler-plugin
version 3.1 [1]: I don't know what it means nor why we have such result (first
time I see), but this is hard to understand
Regards,
Hervé
[1]
+1
Regards,
Hervé
Le dimanche 26 octobre 2014 22:06:40 Michael Osipov a écrit :
Hi,
We solved 9 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18325projectId=117
61
There are still a couple of issues left in JIRA:
see doxia-integration-tools DefaultSiteTool populateParentMenu(...) [1] and
populateModulesMenu(...) [2] called by getDecorationModel(...)
then getDecorationModel(...) is called from
AbstractSiteRenderingMojo.createSiteRenderingContext(...)
But looking at MPIR-279, I fear you're fighting
Le lundi 27 octobre 2014 09:13:47 Karl Heinz Marbaise a écrit :
Hi Michael,
On 10/27/14 7:23 AM, Michael Osipov wrote:
Am 2014-10-26 um 23:15 schrieb Karl Heinz Marbaise:
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version=
19853
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I see why we would release 3.0.6: Aether change force some users to stay to
3.0.x, and I started to define some backports I'd like to put in it [1]
But I don't see why we
+1
same strange Default target for maven-compiler-plugin version 3.1JDK
requirement [1] as Maven Clean Plugin
we'll probably have something to do to improve this, because it seems updated
parent pom puts this for every plugin...
Regards,
Hervé
[1]
+1 to that. Good idea imho..
manfred
Hervé BOUTEMY wrote on 28.10.2014 19:24:
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I see why we would release 3.0.6: Aether change force some users to stay to
3.0.x, and
+1
On Wed, Oct 29, 2014 at 10:22 AM, Manfred Moser manf...@mosabuam.com
wrote:
+1 to that. Good idea imho..
manfred
Hervé BOUTEMY wrote on 28.10.2014 19:24:
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I
+1 (non-binding)
Gary
On Tue, Oct 28, 2014 at 10:24 PM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I see why we would release 3.0.6: Aether change force some users to
+1
29. Okt. 2014 03:24 skrev Hervé BOUTEMY herve.bout...@free.fr følgende:
we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future
I see why we would release 3.0.6: Aether change force some users to stay to
3.0.x, and I
32 matches
Mail list logo
