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:
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'
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
+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 kristian.rosenv...@gmail.com
wrote:
Personally I think we could consider releasing 3.0.6 with jdk6
requirement and leave jdk5 altogether. And that's for
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
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 and...@hammar.net wrote:
Wouldn't it make sense to fail
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 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
--
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,
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
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 ListAssemblyArchiverPhase assemblyPhases;
With maven 3.2.3 this will evaluate to an
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
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
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 consider
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(
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( + ) )
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 denn...@apache.org
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
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
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
-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
stephen.alan.conno...@gmail.com:
I am also -1 on changing the JDK for an existing line.
I seem to remember communicating that we would have
Hi,
We solved 31 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20175
There are still lots of issues left in JIRA:
+1
2014-10-30 22:08 GMT+01:00 Andreas Gudian andreas.gud...@gmail.com:
Hi,
We solved 31 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20175
There are still lots of issues left in JIRA:
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:
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
andreas.gud...@gmail.com wrote:
Hi,
We solved 31 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=20175
25 matches
Mail list logo
