I suppose you're right. I was sufficiently unfamiliar with rat to know that
it always fails the build, I was somehow hoping it would nag us initially
and we could make it stricter after some time. But the rat seems to be an
all or nothing kind of type
K
2. Nov. 2014 01:24 skrev Andreas Gudian
It has been nagging us for quite some time now, if you built with the
rat profile activated. In the latest parent release it was moved to be
a part of the normal build and to also fail the build. So the
situation is new, but you can't blame the rat for that - it was our
own decision :-)
The
Hi,
We solved 13 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11085version=19853
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20JXR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
Staging
On Sat, Nov 1, 2014 at 10:41 AM, Dennis Lundberg denn...@apache.org wrote:
Hi,
I'm just starting to look at toolchains, with the goal of using Java 5 for
jobs in latest Jenkins LTS version.
I have this working now.
Here are a few reflections from what I've read so far.
Great to have a
Le dimanche 2 novembre 2014 09:51:14 Dennis Lundberg a écrit :
Looking into this I'm a bit puzzled. Version 1.1-SNAPSHOT of
maven-toolchains-plugin bind by default to the validate phase, but it
doesn't run unless I specify an execution for it. If I have it
specified in build/plugins with
On Sun, Nov 2, 2014 at 10:41 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Le dimanche 2 novembre 2014 09:51:14 Dennis Lundberg a écrit :
Looking into this I'm a bit puzzled. Version 1.1-SNAPSHOT of
maven-toolchains-plugin bind by default to the validate phase, but it
doesn't run unless I
Hi,
I just added you in the correct group.
Should work now.
Cheers
Olivier
On 2 November 2014 05:50, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi,
am i not allowed to assign issue to me and solve them by a commit ?
Or did i miss a thing...
Or only allowed to PMC Chair ?
Kind regards
Hi Olivier,
On 11/2/14 12:48 PM, Olivier Lamy wrote:
Hi,
I just added you in the correct group.
Should work now.
Thank you...
Kind regards
Karl Heinz Marbaise
Cheers
Olivier
On 2 November 2014 05:50, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi,
am i not allowed to assign issue to me
Hi,
sha1 sum Ok.
Checked via: mvn -Prun-its clean verify
Environment:
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home:
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.8.5, arch:
+1 on committer side
-
BR, tibor17
--
View this message in context:
http://maven.40175.n5.nabble.com/VOTE-Release-Maven-Surefire-Plugin-version-2-18-Take-2-tp5812277p5812407.html
Sent from the Maven Developers mailing list archive at Nabble.com.
Karl, the README.txt will force the users to prepare for Maven 3.
IMHO the SUREFIRE 3.0 would completely switch to Maven 3.
Then we can use prerequisites with enforcer declaring the same min version
of Maven dist.
We will have chance to use Java Generics instead of using java.lang.Object
in public
For the record, maven2 does not have precise enough dependency
resolution to handle the somewhat crazy hoops we jump through to test
surefire with surefire itself. So although we're still 2.2.1
compatible, we've required 3.x to build for some time.
Kristian
2014-11-02 18:18 GMT+01:00 tibor17
Hi,
first to say trying to build surefire with Maven 2.2.1 will fail with a
circular dependency...problem (as Kristian mentioned)...so best would be
to require such things not by a README better by prerequisites/enforcer ...
Apart from the README.txt is intended for developers of Surefire
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.
Le samedi 1 novembre 2014 20:52:56 Robert Scholte a écrit :
Hi,
I've been working on the merger for Toolchains and my conclusion is that
we shouldn't add it to the settings.xml like it is specified right now.
Merging the settings.xml is quite easy: all complex types have a key,
which is
The difference is in the lifecycle.
The jar/war bundle may contain modified resources other than the classpath.
So testing the bundle is more closely to realistic testing of the entire
application.
If I have to test the WAR or whole web application with arquillian +
selenius + maven resolver +
16 matches
Mail list logo
