Works on several of my projects, forked (-T) and not forked; junit,
arquillian, tomee.
+1 non-binding
On Thu, Oct 30, 2014 at 5:08 PM, Andreas Gudian
wrote:
> Hi,
>
>
> We solved 31 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=20175
>
> There are still lots
The staging is not available
http://maven.apache.org/surefire-archives/surefire-2.18/maven-surefire-plugin/index.html
Should not it be instead?
http://maven.apache.org/surefire-archives/maven-surefire-2.18/maven-surefire-plugin/index.html
-
BR, tibor17
--
View this message in context:
http:
+1
2014-10-30 22:08 GMT+01:00 Andreas Gudian :
> Hi,
>
>
> We solved 31 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=20175
>
> There are still lots of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=pro
Hi,
We solved 31 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=20175
There are still lots of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+upda
-1 on changing the JDK for M3.0.x
+1 for removal of the M3.1.x download from the mainpage
Op Thu, 30 Oct 2014 20:23:28 +0100 schreef Stephen Connolly
:
I am also -1 on changing the JDK for an existing line.
I seem to remember communicating that we would have at least a minor
version bump i
Link for this week's hangout:
https://plus.google.com/u/0/b/113247990055413254822/events/cgf1lmf8br4gqj8ohi4712n4mf8
4PM EDT on Thursday
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/
Github user michael-o commented on the pull request:
https://github.com/apache/maven/pull/28#issuecomment-61159553
Why do we need this? There is a batch mode, minimal transfer output.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHu
Github user michael-o commented on the pull request:
https://github.com/apache/maven/pull/28#issuecomment-61156846
I agree with Hervé, this could be default in batch mode. No need for
another option.
---
If your project is set up for it, you can reply to this email and have your
rep
I am also -1 on changing the JDK for an existing line.
I seem to remember communicating that we would have at least a minor
version bump if we were upping the JVM requirement when communicating the
JVM version bump for 3.2.x
On Thursday, October 30, 2014, Dennis Lundberg wrote:
> I am -1 on c
Github user hboutemy commented on a diff in the pull request:
https://github.com/apache/maven/pull/28#discussion_r19627615
--- Diff: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
---
@@ -924,7 +924,7 @@ else if ( profileAction.startsWith( "+" ) )
Github user hboutemy commented on a diff in the pull request:
https://github.com/apache/maven/pull/28#discussion_r19627514
--- Diff: maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
---
@@ -137,6 +139,7 @@ public CLIManager()
options.addOption( OptionB
Github user hboutemy commented on the pull request:
https://github.com/apache/maven/pull/28#issuecomment-61146020
I like the idea of quiet transfert
but does it deserve an additional option: shouldn't this quiet transfert be
activated in existing batch mode = non-interactive = no i
I am -1 on changing JDK level in a patch version, either in core or another
one of our products. That is bad form, since the release is not backwards
compatible.
--
Dennis Lundberg
Den 29 okt 2014 08:04 skrev "Kristian Rosenvold" <
kristian.rosenv...@gmail.com>:
> Personally I think we could cons
On Thursday, 30 October 2014 at 16:41, Kristian Rosenvold wrote:
> O-kay. Now I understand the precedence in question; it is based on
> "container type":
>
> The handlers for the different assembly phases are wired in with
>
> @Requirement( role = AssemblyArchiverPhase.class )
> private List asse
Github user JigarJoshi commented on the pull request:
https://github.com/apache/maven/pull/28#issuecomment-61130522
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and
O-kay. Now I understand the precedence in question; it is based on
"container type":
The handlers for the different assembly phases are wired in with
@Requirement( role = AssemblyArchiverPhase.class )
private List assemblyPhases;
With maven 3.2.3 this will evaluate to an order of repository >
de
GitHub user martin-g opened a pull request:
https://github.com/apache/maven/pull/28
MNG-5486 hiding transfer logs
The latest patch from https://jira.codehaus.org/browse/MNG-5486 as a Pull
Request as requested by Jason van Zyl.
You can merge this pull request into a Git repository b
FYI
reported and fixed: https://jira.codehaus.org/browse/MNG-5707
Regards,
Hervé
Le mardi 28 octobre 2014 07:43:10 Michael Osipov a écrit :
> 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.hel
I found a bit ugly line in IT logs:
[ERROR] null
I found the reason, the JUnit passed "null" String in Description in Suite
runner.
Nothing is broken, only the lines are not nice with null. I'd like to
prevent from users reporting new JIRA issue.
I am pushing to ASF now...
-
BR, tibor17
--
V
But I really think the feature is legit; it just doesnt work very
well, and the precedence in the link I sent seems ill-though through.
Using order from the assembly specification sounds much more
understandable. And to be honest, I really dont think anyone can rely
on this order actually working i
I agree with Anders, no surprise principle. Fail early. I spent a good
while trying to figure out what the heck is happening with this --
http://jira.codehaus.org/browse/MASSEMBLY-724
Dawid
On Thu, Oct 30, 2014 at 1:05 PM, Anders Hammar wrote:
> Wouldn't it make sense to fail the build in case o
Wouldn't it make sense to fail the build in case of this instead? As I see
it, there's something wrong in the descriptor and it should be fixed.
Also, doing this change (intead of just altering the algorithm) would make
the plugin upgrade "better" (no suprises in the result). A failed build
with a
+1 to switching to JDK 6 and for dropping the 3.1.x line.
Regards
Mirko
--
Sent from my mobile
On Oct 29, 2014 8:04 AM, "Kristian Rosenvold"
wrote:
> Personally I think we could consider releasing 3.0.6 with jdk6
> requirement and leave jdk5 altogether. And that's for plugins too :)
>
> Kristia
There's a truckload of jira issues related to the inclusion algorithm,
and there just seems to be so many simpler ways of handling this ?
filesets/dependencysets/files processed in descriptor order (or
reverse descriptor) order, first file wins. Reversing descriptor order
would make "last" file wi
Reading the instructions on
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html
makes me wonder, why on earth has this precedence been chosen for the
assembly plugin ??? Especially case 2 is odd.
There'
Great, I'll start with that tonight.
Am Mittwoch, 29. Oktober 2014 schrieb tibor17 :
> Hi Andreas
>
> Thx for your patience.
> It looks like we can start making the release.
>
>
>
> -
> BR, tibor17
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Release-Plan-for-SUREF
26 matches
Mail list logo
