Re: Thoughts on MR-Jar support in Maven

2017-03-24 Thread Hervé BOUTEMY 
not really IMHO
the question here is to create one multi-release jar, not how to maintain many 
(one-)release jars from one sourcecode: MR jars are done to avoid the release-
specific jar approach (that preprocessing makes viable)

Regards,

Hervé

Le vendredi 24 mars 2017, 11:08:49 CET Aldrin Leal a écrit :
> Wouldn't preprocessing help?
> 
> https://blog.jooq.org/2016/03/01/how-to-support-java-6-8-9-in-a-single-api/
> 
> --
> -- Aldrin Leal,  / http://about.me/aldrinleal
> 
> On Fri, Mar 24, 2017 at 11:01 AM, Andreas Sewe <
> 
> s...@st.informatik.tu-darmstadt.de> wrote:
> > Hi,
> > 
> > > I would have thought that it was not Maven's responsibility to ascertain
> > > that test passed in various JDKs, old and new.
> > 
> > I agree that is is not Maven's responsibility to (out of the box)
> > execute the tests against multiple JREs. If you think it is, one can
> > just as well argue that it should run tests for OSGi bundles built with
> > Maven using all different permutations that the bundle's Import-Package
> > version ranges allow.
> > 
> > Yes, there are projects where that level of double-checking is
> > warranted, but IMHO this is the domain of Jenkins matrix projects or
> > similar mechanisms.
> > 
> > The bigger issue with the "multiple source folder per project" approach
> > is whether popular IDEs can express the fact that src/main/java needs to
> > be compiled against one JRE whereas src/main/java-9 needs to be compiled
> > against another.
> > 
> > Just my two cents.
> > 
> > Andreas



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

2017-03-24 Thread Hervé BOUTEMY 
ok, let's share what I know from embedded ITs (sorry, long email, but IMHO 
useful to share some details):

- by default, Verifier forks for every IT and launches Maven with the shell 
script through ForkedLauncher [1]

- in embedded mode, there is no fork but use of MavenCli.doMain(String[] args, 
workingDir, stdin, stdout) by Embedded3xLauncher [2], which will recreate a 
Classworlds classloader context in the current JVM: AFAIK, this makes the 
embedded situation really the same as forked one from a classloader point of 
view, with CLI args passed, working dir, stdin and stdout

- a few ITs require shell script and don't have any meaning without it: in 
this case, even if the build is in embedded mode, the IT forces the Verifier to 
used forked execution, for example in mng5889 [3]

- every IT that we want absolutely not to be embedded has to do this 
"verifier.setForkJvm( true );" call, or the IT won't be in expected situation: 
as you point out, mng4625 currently does not do this call, then may not be 
really effective with the embedded profile. This can be considered as a bug and 
explains why currently this IT fails in my "embedded-ITs" branch => I'll 
improve now the IT to support the embedded profile by forcing forked execution 
:)


Now that I wrote this, summarizing what I knew and what was already reported 
as issues, it looks to me that embedded mode may trigger a few failures that 
can and should be fixed by forcing forked execution (which won't change the 
overall effect: most ITs will run embedded then execution time will be a lot 
lower than full forked execution)

the only risk is that some ITs don't fail when run in embedded mode but in 
fact don't really test what they are supposed to test

This seems a reasonable risk to take here, given the benefit: we'll improve ITs 
if necessary.
If nobody objects, I'll do the merge to master in a few days

Regards,

Hervé

[1] http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/
ForkedLauncher.html#L60

[2] http://maven.apache.org/ref/3.5.0-beta-1/maven-embedder/xref/org/apache/
maven/cli/MavenCli.html#L262

[3] 
https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/
MavenITmng5889CoreExtensionsTest.java#L57

Le vendredi 24 mars 2017, 21:29:38 CET Olivier Lamy a écrit :
> sure tempting :-)
> But is is the same classloader mechanism as a "normal" Maven run? (should
> be really close but not sure exactly so maybe we can miss some cases)
> 
> On Fri, 24 Mar 2017 at 6:47 pm, Stephen Connolly <
> 
> stephen.alan.conno...@gmail.com> wrote:
> > Have we some of the tests running in both modes?
> > 
> > Specifically at least 4625 as it caught some interesting CLI parsing
> > issues, but there may be a couple more
> > 
> > On Fri 24 Mar 2017 at 07:15, Hervé Boutemy  wrote:
> > > as you can see, in embedded mode, core ITs can run in 17 minutes, when
> > > in
> > > classic mode they run in 1h30
> > > 
> > > any objection to merge this embedded mode into master?
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> > > > See
> > > 
> > > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/embedded-ITs/3/
> > > 
> > > 
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > --
> > 
> > Sent from my phone



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Christian Schulte 
We really need Solaris and OSX Jenkins build nodes :-)


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Christian Schulte 
Am 03/25/17 um 01:30 schrieb Christian Schulte:
> Am 03/24/17 um 23:28 schrieb Stephen Connolly:
>> Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
>> ) is not available
> 
> Thanks for pointing this out. Our launchers have this in the first line:
> 
> #!/bin/sh
> 
> /bin/sh should be a POSIX compatible shell. On the BSDs, OSX and Solaris
> (IIRC) this is some kind of ksh. The man page on OpenBSD explicitly
> states this:
> 
> This version of sh is actually ksh in disguise. As such, it also
> supports the features described in ksh(1). This manual page describes
> only the parts relevant to a POSIX compliant sh. If portability is a
> concern, use only those features described in this page.
> 
> They provide different man pages for sh and ksh although /bin/sh is ksh.
> 
> http://man.openbsd.org/sh
> http://man.openbsd.org/ksh
> 
> Can you provide a link to some BourneShell man page (a real one, not
> bash)? We should fix the launchers in 3.5.0 once and for all.
> 
> Currently reading the "Shell & Utilities" volume from here:
> 
> 
> 
> This is what we should be compatible to. Did not find anything about
> "readlink" in there so we should not be using it and find a compliant
> solution.
> 
> Regards,
> 

Seems we really should be using "`pwd -P`" as you suggested.




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Christian Schulte 
Am 03/24/17 um 23:28 schrieb Stephen Connolly:
> Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
> ) is not available

Thanks for pointing this out. Our launchers have this in the first line:

#!/bin/sh

/bin/sh should be a POSIX compatible shell. On the BSDs, OSX and Solaris
(IIRC) this is some kind of ksh. The man page on OpenBSD explicitly
states this:

This version of sh is actually ksh in disguise. As such, it also
supports the features described in ksh(1). This manual page describes
only the parts relevant to a POSIX compliant sh. If portability is a
concern, use only those features described in this page.

They provide different man pages for sh and ksh although /bin/sh is ksh.

http://man.openbsd.org/sh
http://man.openbsd.org/ksh

Can you provide a link to some BourneShell man page (a real one, not
bash)? We should fix the launchers in 3.5.0 once and for all.

Currently reading the "Shell & Utilities" volume from here:



This is what we should be compatible to. Did not find anything about
"readlink" in there so we should not be using it and find a compliant
solution.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Stephen Connolly 
Keep in mind that AIUI we aim to be BourneShell compatible in which case $(
) is not available

On Fri 24 Mar 2017 at 22:15, Christian Schulte  wrote:

> Am 03/24/17 um 22:51 schrieb Stephen Connolly:
> > I am concerned that there are some quoting issues in mvn.
> >
> > In some cases we use var=`command` and in others we use var="`command`"
> >
> > Additionally we have a mixture of backtick and $(...) style. My
> > understanding is that the backticks are for older shells...
> > but if that is the case we should use backticks consistently
> >
> > line 64: saveddir=`pwd`
> > should be? saveddir="`pwd`"
> >
> > line 66: MAVEN_HOME=`dirname "$PRG"`/..
> > should be? MAVEN_HOME="`dirname "$PRG"`/.."
> >
> > line 69: MAVEN_HOME=`cd "$MAVEN_HOME" && pwd`
> > should be? MAVEN_HOME="`cd "$MAVEN_HOME" && pwd`"
> >
> > line 105: CLASSWORLDS_JAR=`echo
> > "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`
> > should be? CLASSWORLDS_JAR="`echo
> > "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`"
> >
> > line 128:  basedir=$wdir
> > should be?  basedir="$wdir"
> >
> > line 145: basedir=$(dirname "$(readlink -f "${arg}")")
> > should be? basedir="$(dirname "$(readlink -f "${arg}")")"
> > (or perhaps)basedir="$(cd "$(dirname "${arg}")" && pwd -P)"
> >
> > line 178:  MAVEN_PROJECTBASEDIR=`cygpath --path --windows
> > "$MAVEN_PROJECTBASEDIR"`
> > should be?  MAVEN_PROJECTBASEDIR="`cygpath --path --windows
> > "$MAVEN_PROJECTBASEDIR"`"
> >
> > /me got tired looking at the file after this point in time!
> >
>
> According to the "Expansion" section from the sh man page
> () the double quotes should be there to
> disable field splitting.
>
> [...]
> Command expansion has a command executed in a subshell and the results
> output in its place.  The basic format is:
>
> $(command)
>
>   or
>
> `command`
>
> The results are subject to field splitting and pathname expansion; no
> other form of expansion happens.  If command is contained within double
> quotes, field splitting does not happen either.  Within backquotes, a
> backslash is treated literally unless it follows a dollar sign,
> backquote, or another backslash.  Commands can be nested, though the
> backquoted version requires backslashes before the backquotes. If
> command is run in a subshell in the bracketed version, the syntax is
> identical to that of arithmetic expansion. In that case the shell
> attempts arithmetic expansion first, then attempts command substitution
> if that fails.  Or a non-ambiguous version can be used:
>
> $( (command) )
>
> Arithmetic expansion works similarly, with an arithmetic expression
> being evaluated and substituted. The format is:
>
> $((expression))
>
> Where expression is an integer, parameter name, or array reference,
> optionally combined with any of the operators described below, listed
> and grouped according to precedence:
> [...]
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Christian Schulte 
Am 03/24/17 um 22:51 schrieb Stephen Connolly:
> I am concerned that there are some quoting issues in mvn.
> 
> In some cases we use var=`command` and in others we use var="`command`"
> 
> Additionally we have a mixture of backtick and $(...) style. My
> understanding is that the backticks are for older shells...
> but if that is the case we should use backticks consistently
> 
> line 64: saveddir=`pwd`
> should be? saveddir="`pwd`"
> 
> line 66: MAVEN_HOME=`dirname "$PRG"`/..
> should be? MAVEN_HOME="`dirname "$PRG"`/.."
> 
> line 69: MAVEN_HOME=`cd "$MAVEN_HOME" && pwd`
> should be? MAVEN_HOME="`cd "$MAVEN_HOME" && pwd`"
> 
> line 105: CLASSWORLDS_JAR=`echo
> "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`
> should be? CLASSWORLDS_JAR="`echo
> "${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`"
> 
> line 128:  basedir=$wdir
> should be?  basedir="$wdir"
> 
> line 145: basedir=$(dirname "$(readlink -f "${arg}")")
> should be? basedir="$(dirname "$(readlink -f "${arg}")")"
> (or perhaps)basedir="$(cd "$(dirname "${arg}")" && pwd -P)"
> 
> line 178:  MAVEN_PROJECTBASEDIR=`cygpath --path --windows
> "$MAVEN_PROJECTBASEDIR"`
> should be?  MAVEN_PROJECTBASEDIR="`cygpath --path --windows
> "$MAVEN_PROJECTBASEDIR"`"
> 
> /me got tired looking at the file after this point in time!
>

According to the "Expansion" section from the sh man page
() the double quotes should be there to
disable field splitting.

[...]
Command expansion has a command executed in a subshell and the results
output in its place.  The basic format is:

$(command)

  or

`command`

The results are subject to field splitting and pathname expansion; no
other form of expansion happens.  If command is contained within double
quotes, field splitting does not happen either.  Within backquotes, a
backslash is treated literally unless it follows a dollar sign,
backquote, or another backslash.  Commands can be nested, though the
backquoted version requires backslashes before the backquotes. If
command is run in a subshell in the bracketed version, the syntax is
identical to that of arithmetic expansion. In that case the shell
attempts arithmetic expansion first, then attempts command substitution
if that fails.  Or a non-ambiguous version can be used:

$( (command) )

Arithmetic expansion works similarly, with an arithmetic expression
being evaluated and substituted. The format is:

$((expression))

Where expression is an integer, parameter name, or array reference,
optionally combined with any of the operators described below, listed
and grouped according to precedence:
[...]

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Stephen Connolly 
I am concerned that there are some quoting issues in mvn.

In some cases we use var=`command` and in others we use var="`command`"

Additionally we have a mixture of backtick and $(...) style. My
understanding is that the backticks are for older shells...
but if that is the case we should use backticks consistently

line 64: saveddir=`pwd`
should be? saveddir="`pwd`"

line 66: MAVEN_HOME=`dirname "$PRG"`/..
should be? MAVEN_HOME="`dirname "$PRG"`/.."

line 69: MAVEN_HOME=`cd "$MAVEN_HOME" && pwd`
should be? MAVEN_HOME="`cd "$MAVEN_HOME" && pwd`"

line 105: CLASSWORLDS_JAR=`echo
"${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`
should be? CLASSWORLDS_JAR="`echo
"${MAVEN_HOME}"/boot/plexus-classworlds-*.jar`"

line 128:  basedir=$wdir
should be?  basedir="$wdir"

line 145: basedir=$(dirname "$(readlink -f "${arg}")")
should be? basedir="$(dirname "$(readlink -f "${arg}")")"
(or perhaps)basedir="$(cd "$(dirname "${arg}")" && pwd -P)"

line 178:  MAVEN_PROJECTBASEDIR=`cygpath --path --windows
"$MAVEN_PROJECTBASEDIR"`
should be?  MAVEN_PROJECTBASEDIR="`cygpath --path --windows
"$MAVEN_PROJECTBASEDIR"`"

/me got tired looking at the file after this point in time!


On 24 March 2017 at 21:07, Christian Schulte  wrote:

> Am 03/24/17 um 11:45 schrieb Stephen Connolly:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%
> 20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> 20DESC%2C%20created%20ASC
> >
> > Here is my opinions:
> >
> > https://issues.apache.org/jira/browse/MNG-6168 - If this is available
> and
> > ready quickly (i.e. in the next week), we can review the changes and
> assess
> > the risk
>
> Branch is here:
>  shortlog;h=refs/heads/MNG-6168>
>
> Commit is here:
>  0931bb2cc7630cc79adb98407db13315b4a709ee>
>
> Will merge to master, as soon as the build job succeeds. It's just
> updates to use the try-with-resources statement instead of
> try-catch-finally with IOUtil.close.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Christian Schulte 
Am 03/24/17 um 11:45 schrieb Stephen Connolly:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> Here is my opinions:
> 
> https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
> ready quickly (i.e. in the next week), we can review the changes and assess
> the risk

Branch is here:


Commit is here:


Will merge to master, as soon as the build job succeeds. It's just
updates to use the try-with-resources statement instead of
try-catch-finally with IOUtil.close.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

2017-03-24 Thread Christian Schulte 
Am 03/24/17 um 16:54 schrieb Karl Heinz Marbaise:
> Hi,
> 
> On 24/03/17 02:17, Hervé BOUTEMY wrote:
>> we have absolutely no OSX user building Maven core ITs on his personal
>> computer?
>> seriously?
>> Or is there no core IT that shows the issue? then it has to be discovered by
>> hand?
> 
> I can test today evening or tomorrow...on my Mac..

You'd need to find an alternative to "readlink -f" on OSX. There are
solutions available on stackoverflow. Nothing of this can be done
without being able to test.

> If this helps?

Indeed. Thanks.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

2017-03-24 Thread Chas Honton 
Not testing maven core ITs.  Using multi-module project with 562 goal 
invocations (50 unique goals) including three integration test suites run with 
invoker plugin. 

+1 tested on OS X 10.12.3, Java 1.8.0_074

++1: 3.5.0 warned about a dependent Pom problem which was not found with 3.3.9

Chas

> On Mar 24, 2017, at 8:54 AM, Karl Heinz Marbaise  wrote:
> 
> Hi,
> 
>> On 24/03/17 02:17, Hervé BOUTEMY wrote:
>> we have absolutely no OSX user building Maven core ITs on his personal
>> computer?
>> seriously?
>> Or is there no core IT that shows the issue? then it has to be discovered by
>> hand?
> 
> I can test today evening or tomorrow...on my Mac..
> 
> If this helps?
> 
> Kind regards
> Karl Heinz Marbaise
>> 
>> Notice: to me, this does not mean we need a beta-2: 3.5.0 will have bugs, 
>> like
>> any past or future release
>> 
>> Regards,
>> 
>> Hervé
>> 
>> Le jeudi 23 mars 2017, 19:21:45 CET Christian Schulte a écrit :
 Am 03/23/17 um 19:20 schrieb Christian Schulte:
> Am 03/23/17 um 10:08 schrieb Stephen Connolly:
> Hervé do you think this ordering issue is serious enough to drop and run
> a
> beta-2?
> 
> IMHO no as it is just a beta and we can add it as a known issue in the
> release notes.
 
 Unrelated to this issue there has been another report regarding the
 launcher scripts: MNG-6191
 
 We maybe should do a -beta-2 before the final release with this fixed as
 well.
 
 Seems "readlink" does not support the "-f" option on OSX. Can someone
 with a OSX installation take a look please? The launcher scripts are in
 scope for 3.5.0.
 
 Regards,
>>> 
>>> This would not have happened with an OSX Jenkins build node, BTW.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Thoughts on MR-Jar support in Maven

2017-03-24 Thread Aldrin Leal 
Wouldn't preprocessing help?

https://blog.jooq.org/2016/03/01/how-to-support-java-6-8-9-in-a-single-api/

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Fri, Mar 24, 2017 at 11:01 AM, Andreas Sewe <
s...@st.informatik.tu-darmstadt.de> wrote:

> Hi,
>
> > I would have thought that it was not Maven's responsibility to ascertain
> > that test passed in various JDKs, old and new.
>
> I agree that is is not Maven's responsibility to (out of the box)
> execute the tests against multiple JREs. If you think it is, one can
> just as well argue that it should run tests for OSGi bundles built with
> Maven using all different permutations that the bundle's Import-Package
> version ranges allow.
>
> Yes, there are projects where that level of double-checking is
> warranted, but IMHO this is the domain of Jenkins matrix projects or
> similar mechanisms.
>
> The bigger issue with the "multiple source folder per project" approach
> is whether popular IDEs can express the fact that src/main/java needs to
> be compiled against one JRE whereas src/main/java-9 needs to be compiled
> against another.
>
> Just my two cents.
>
> Andreas
>
>

Re: Thoughts on MR-Jar support in Maven

2017-03-24 Thread Andreas Sewe 
Hi,

> I would have thought that it was not Maven's responsibility to ascertain
> that test passed in various JDKs, old and new.

I agree that is is not Maven's responsibility to (out of the box)
execute the tests against multiple JREs. If you think it is, one can
just as well argue that it should run tests for OSGi bundles built with
Maven using all different permutations that the bundle's Import-Package
version ranges allow.

Yes, there are projects where that level of double-checking is
warranted, but IMHO this is the domain of Jenkins matrix projects or
similar mechanisms.

The bigger issue with the "multiple source folder per project" approach
is whether popular IDEs can express the fact that src/main/java needs to
be compiled against one JRE whereas src/main/java-9 needs to be compiled
against another.

Just my two cents.

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

2017-03-24 Thread Karl Heinz Marbaise 

Hi,

On 24/03/17 02:17, Hervé BOUTEMY wrote:

we have absolutely no OSX user building Maven core ITs on his personal
computer?
seriously?
Or is there no core IT that shows the issue? then it has to be discovered by
hand?


I can test today evening or tomorrow...on my Mac..

If this helps?

Kind regards
Karl Heinz Marbaise


Notice: to me, this does not mean we need a beta-2: 3.5.0 will have bugs, like
any past or future release

Regards,

Hervé

Le jeudi 23 mars 2017, 19:21:45 CET Christian Schulte a écrit :

Am 03/23/17 um 19:20 schrieb Christian Schulte:

Am 03/23/17 um 10:08 schrieb Stephen Connolly:

Hervé do you think this ordering issue is serious enough to drop and run
a
beta-2?

IMHO no as it is just a beta and we can add it as a known issue in the
release notes.


Unrelated to this issue there has been another report regarding the
launcher scripts: MNG-6191

We maybe should do a -beta-2 before the final release with this fixed as
well.

Seems "readlink" does not support the "-f" option on OSX. Can someone
with a OSX installation take a look please? The launcher scripts are in
scope for 3.5.0.

Regards,


This would not have happened with an OSX Jenkins build node, BTW.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Thoughts on MR-Jar support in Maven

2017-03-24 Thread Robert Scholte 

On Fri, 24 Mar 2017 12:20:16 +0100, Ceki Gülcü  wrote:

I would have thought that it was not Maven's responsibility to ascertain  
that test passed in various JDKs, old and new.


With the classic setup there's only one JDK and all tests are at least  
executed with that JDK, all out-of-the-box. In this case you can call it  
Maven's responsibility to execute all tests.
I hope we can figure out a way to easy add the MRJAR feature to a project  
where everybody can keep the same assumptions as a classic jar. Up until  
now the multimodule setup can do that, but I have to admit, it is not  
perfect.


Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Robert Scholte 
On Fri, 24 Mar 2017 14:51:22 +0100, Stephen Connolly  
 wrote:



On 24 March 2017 at 10:51, Robert Scholte  wrote:


On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

https://issues.apache.org/jira/issues/?jql=project%20%3D%

20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20r
esolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%
20priority%20DESC%2C%20created%20ASC

Here is my opinions:

https://issues.apache.org/jira/browse/MNG-6167 - it's too late now.  
punt

to
3.5.1

https://issues.apache.org/jira/browse/MNG-6168 - If this is available  
and

ready quickly (i.e. in the next week), we can review the changes and
assess
the risk

https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged
and
released upstream yet... punt to 3.5.1

https://issues.apache.org/jira/browse/MNG-6188 - it's too late now.  
punt

to
3.5.1 (anyway I see similar issues with other native tooling that uses
console colouring)

https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.
punt
to 3.5.1

https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a
javadoc
change. If available quickly should be ok

If there is agreement then I will move MNG-6185 and MNG-6168 into fix  
for

3.5.0 and the rest to 3.5.1-candidates



I agree on MNG-6185 and MNG-6168.

IMHO if MNG-6186 isn't fixed upstream upstream, we should fix it with  
our

own proposed patch. If users see that their diskspace is decreasing and
discover that the lib/ext if full of temporary files, they have a fair
point to complain.



I think the remaining bit open there is to remove the duplicate code once
upstream has the required functionality. the disk space issue has been
fixed IIUC



Confirmed, I see apache-maven-3.5.0-beta-1/lib/jansi-native.
In that case let's push this one to 3.5.1





All others can be pushed to 3.5.1

Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Stephen Connolly 
On 24 March 2017 at 10:51, Robert Scholte  wrote:

> On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20r
>> esolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%
>> 20priority%20DESC%2C%20created%20ASC
>>
>> Here is my opinions:
>>
>> https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt
>> to
>> 3.5.1
>>
>> https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
>> ready quickly (i.e. in the next week), we can review the changes and
>> assess
>> the risk
>>
>> https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged
>> and
>> released upstream yet... punt to 3.5.1
>>
>> https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt
>> to
>> 3.5.1 (anyway I see similar issues with other native tooling that uses
>> console colouring)
>>
>> https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.
>> punt
>> to 3.5.1
>>
>> https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a
>> javadoc
>> change. If available quickly should be ok
>>
>> If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
>> 3.5.0 and the rest to 3.5.1-candidates
>>
>
> I agree on MNG-6185 and MNG-6168.
>
> IMHO if MNG-6186 isn't fixed upstream upstream, we should fix it with our
> own proposed patch. If users see that their diskspace is decreasing and
> discover that the lib/ext if full of temporary files, they have a fair
> point to complain.
>

I think the remaining bit open there is to remove the duplicate code once
upstream has the required functionality. the disk space issue has been
fixed IIUC


>
> All others can be pushed to 3.5.1
>
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Thoughts on MR-Jar support in Maven

2017-03-24 Thread Ceki Gülcü 


Hi Robert,

I would have thought that it was not Maven's responsibility to ascertain 
that test passed in various JDKs, old and new.


Nevertheless,  there is no doubt that once you pay attention to the 
details, things can get messy awfully quick.


BTW, thank you for your previous response.

--
Ceki


On 3/24/2017 11:45, Robert Scholte wrote:

Hi Ceki,

the compilation-part isn't the real issue (it is acutally the easy
part), but e.g. the testing-part is.
You must ensure that surefire is also executed at least twice: once for
pre-java9 and for java9.
And what to do with other plugins which are part of the lifecycle up
until the package-phase? Very likely they need to be executed twice as
well.
If you look closer you'll see that you're actually executing 2 build
lifecycles which are in the end packaged to a single jar.
The demo-project is the purest form but comes with overhead.
Maven has a forking mechanism, but I don't think it is strong enough
(yet) to fully support this.

thanks,
Robert

On Fri, 24 Mar 2017 11:34:20 +0100, Ceki Gülcü  wrote:



Hi All,

Currently in the process modularizing the SLF4J project in preperation
for Java 9/Jigsaw, I ran into many wrinkles most of which are due to
my own ignorance about Java 9 modules. Now that the initial phase of
modularization is done, I am looking into creating mutlti-release
jars (MR-Jars).

Herve's mutli-version demo project [1] (thanks Hervé) while
instructional, shows that MR-Jar support in Maven is perhaps lacking
at the moment.

As a developer, I really don't want to muck about with multiple maven
project modules or learn the intricacies of the maven assembly plugin
just to add module-info.java to my project's artifact.

As a moderately-skilled Maven user, I would like to see MR-Jar
supported by way of directory layout conventions, perhaps along the
lines of:

src/main/java/  -> target/classes
src/test/java/  -> target/test/classes
src/main/java-9/ -> target/classes/META-INF/versions/9
src/test/java-9/ -> target/test-classes/META-INF/versions/9

Thus, I would need to change little in my pom.xml files to support
MR-jars. Most of the leg work would be done by the compiler plug-in
and Maven conventions.

Comments?

--
Ceki

[1] https://github.com/hboutemy/maven-jep238

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Robert Scholte 
On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly  
 wrote:



https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Here is my opinions:

https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt  
to

3.5.1

https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
ready quickly (i.e. in the next week), we can review the changes and  
assess

the risk

https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged  
and

released upstream yet... punt to 3.5.1

https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt  
to

3.5.1 (anyway I see similar issues with other native tooling that uses
console colouring)

https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.  
punt

to 3.5.1

https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a  
javadoc

change. If available quickly should be ok

If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
3.5.0 and the rest to 3.5.1-candidates


I agree on MNG-6185 and MNG-6168.

IMHO if MNG-6186 isn't fixed upstream upstream, we should fix it with our  
own proposed patch. If users see that their diskspace is decreasing and  
discover that the lib/ext if full of temporary files, they have a fair  
point to complain.


All others can be pushed to 3.5.1

Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Thoughts on MR-Jar support in Maven

2017-03-24 Thread Robert Scholte 

Hi Ceki,

the compilation-part isn't the real issue (it is acutally the easy part),  
but e.g. the testing-part is.
You must ensure that surefire is also executed at least twice: once for  
pre-java9 and for java9.
And what to do with other plugins which are part of the lifecycle up until  
the package-phase? Very likely they need to be executed twice as well.
If you look closer you'll see that you're actually executing 2 build  
lifecycles which are in the end packaged to a single jar.

The demo-project is the purest form but comes with overhead.
Maven has a forking mechanism, but I don't think it is strong enough (yet)  
to fully support this.


thanks,
Robert

On Fri, 24 Mar 2017 11:34:20 +0100, Ceki Gülcü  wrote:



Hi All,

Currently in the process modularizing the SLF4J project in preperation
for Java 9/Jigsaw, I ran into many wrinkles most of which are due to
my own ignorance about Java 9 modules. Now that the initial phase of
modularization is done, I am looking into creating mutlti-release
jars (MR-Jars).

Herve's mutli-version demo project [1] (thanks Hervé) while
instructional, shows that MR-Jar support in Maven is perhaps lacking
at the moment.

As a developer, I really don't want to muck about with multiple maven
project modules or learn the intricacies of the maven assembly plugin
just to add module-info.java to my project's artifact.

As a moderately-skilled Maven user, I would like to see MR-Jar
supported by way of directory layout conventions, perhaps along the
lines of:

src/main/java/  -> target/classes
src/test/java/  -> target/test/classes
src/main/java-9/ -> target/classes/META-INF/versions/9
src/test/java-9/ -> target/test-classes/META-INF/versions/9

Thus, I would need to change little in my pom.xml files to support
MR-jars. Most of the leg work would be done by the compiler plug-in
and Maven conventions.

Comments?

--
Ceki

[1] https://github.com/hboutemy/maven-jep238

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

What to do with the 6 issues left as 3.5.0-candidates?

2017-03-24 Thread Stephen Connolly 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Here is my opinions:

https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt to
3.5.1

https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
ready quickly (i.e. in the next week), we can review the changes and assess
the risk

https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged and
released upstream yet... punt to 3.5.1

https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt to
3.5.1 (anyway I see similar issues with other native tooling that uses
console colouring)

https://issues.apache.org/jira/browse/MNG-6169 - definitely too late. punt
to 3.5.1

https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a javadoc
change. If available quickly should be ok

If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
3.5.0 and the rest to 3.5.1-candidates

Thoughts on MR-Jar support in Maven

2017-03-24 Thread Ceki Gülcü 


Hi All,

Currently in the process modularizing the SLF4J project in preperation
for Java 9/Jigsaw, I ran into many wrinkles most of which are due to
my own ignorance about Java 9 modules. Now that the initial phase of
modularization is done, I am looking into creating mutlti-release
jars (MR-Jars).

Herve's mutli-version demo project [1] (thanks Hervé) while
instructional, shows that MR-Jar support in Maven is perhaps lacking
at the moment.

As a developer, I really don't want to muck about with multiple maven
project modules or learn the intricacies of the maven assembly plugin
just to add module-info.java to my project's artifact.

As a moderately-skilled Maven user, I would like to see MR-Jar
supported by way of directory layout conventions, perhaps along the
lines of:

src/main/java/  -> target/classes
src/test/java/  -> target/test/classes
src/main/java-9/ -> target/classes/META-INF/versions/9
src/test/java-9/ -> target/test-classes/META-INF/versions/9

Thus, I would need to change little in my pom.xml files to support
MR-jars. Most of the leg work would be done by the compiler plug-in
and Maven conventions.

Comments?

--
Ceki

[1] https://github.com/hboutemy/maven-jep238

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

2017-03-24 Thread Olivier Lamy 
sure tempting :-)
But is is the same classloader mechanism as a "normal" Maven run? (should
be really close but not sure exactly so maybe we can miss some cases)

On Fri, 24 Mar 2017 at 6:47 pm, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Have we some of the tests running in both modes?
>
> Specifically at least 4625 as it caught some interesting CLI parsing
> issues, but there may be a couple more
>
> On Fri 24 Mar 2017 at 07:15, Hervé Boutemy  wrote:
>
> > as you can see, in embedded mode, core ITs can run in 17 minutes, when in
> > classic mode they run in 1h30
> >
> > any objection to merge this embedded mode into master?
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> > > See
> > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/embedded-ITs/3/
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone
>

JDK 9 EA Build 162 is available on java.net

2017-03-24 Thread Rory O'Donnell 


Hi Robert ,

*JDK 9 Early Access* b162   is 
available on java.net, summary of  changes are listed here 
.


There is one fix for a bug reported by Open Source projects since the 
last availability email  :


 * b161 - JDK 8176265 Method overload resolution on a covariant base
   type doesn't work in 9

Other change that maybe of interest:

 * b162 - JDK 8176503 security-libs Disable SHA-1 TLS Server Certificates


*Better tools for adjusting to strong encapsulation -* please read Mark 
Reinhold's email on this topic [1]

*
* *Quality Outreach Report for March 2017 *is available [2], many thanks 
for your continued support

and welcome to the new projects!

***Schedule - **JDK 9 Rampdown Phase 2*: Proposal accepted [3].
The overall goal of this process is to ensure that we fix just the bugs 
that must be fixed in order to ensure a successful release.


Oracle's JRE and JDK Cryptographic Roadmap has been updated since last 
availability email [4]


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
[2] 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2017

[3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005689.html
[4] https://www.java.com/en/jre-jdk-cryptoroadmap.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[RESULT] [VOTE] Release Apache Maven 3.5.0-beta-1

2017-03-24 Thread Stephen Connolly 
On 20 March 2017 at 18:18, Stephen Connolly  wrote:

> Hi,
>
> We solved 15 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12316922=12339665=Text
>
> There are still 10  issues left in JIRA for 3.5.0, but I do not think any
> of those are blocking an beta release and perhaps could be descoped for
> 3.5.0:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> In addition there are 313 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1325
>
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/
>
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-
> maven-3.5.0-beta-1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.0-beta-1-src.tar.gz sha1: 6f24770bfff1882ab7ff7120cda677
> 4332c452ff
> apache-maven-3.5.0-beta-1-src.zip sha1: c4ea6e55687f4c02338490dbe99bab
> 9eca027841
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 214540c2ae5431645bb927d6dc5498ebafc27359
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
+1: Stephen Connolly (binding), Karl Heins Marbase (binding), Dejan
Stojadinović, Mark Derricutt, Arnaud Héritier (binding), Thomas Collignon,
Olivier Lamy (binding), Hervé Boutemy (binding), Robert Scholte (binding)
+0:
-1:

This vote has passed and we have at least three binding votes. I will
proceed with the release process.

Apologies if I have missed counting your vote. Thank you very much to
everyone who has contributed to this release.


>
> Thanks,
> -Stephen
>

Re: [VOTE] Release Apache Maven 3.5.0-beta-1

2017-03-24 Thread Robert Scholte 

+1

On Mon, 20 Mar 2017 19:18:06 +0100, Stephen Connolly  
 wrote:



Hi,

We solved 15 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12339665=Text

There are still 10  issues left in JIRA for 3.5.0, but I do not think any
of those are blocking an beta release and perhaps could be descoped for
3.5.0:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

In addition there are 313 issues left in JIRA for Maven core:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Staging repo:
https://repository.apache.org/content/repositories/maven-1325

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/

Specifically the zip, tarball, and source archives can be found here:
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-bin.zip
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-bin.tar.gz
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-src.zip
https://repository.apache.org/content/repositories/maven-1325/org/apache/maven/apache-maven/3.5.0-beta-1/apache-maven-3.5.0-beta-1-src.tar.gz

Source release checksum(s):
apache-maven-3.5.0-beta-1-src.tar.gz sha1:
6f24770bfff1882ab7ff7120cda6774332c452ff
apache-maven-3.5.0-beta-1-src.zip sha1:
c4ea6e55687f4c02338490dbe99bab9eca027841

Git tag:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=214540c2ae5431645bb927d6dc5498ebafc27359

Staging site:
https://maven.apache.org/components/ref/3-LATEST/

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


Thanks,
-Stephen


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MSHADE-209: 'too expensive test'

2017-03-24 Thread Robert Scholte 

I see no reason why this is done, maybe Karl Heinz remembers it.
I see that a different constructor is used for the filter, must have to do  
with that, although I see mocks too, which I consider cheap.
In general, if tests are too expensive, then the code is probably too  
complex and should be split up so you can make more lightweight tests,  
when possible of course.


Robert

On Thu, 23 Mar 2017 17:41:47 +0100, Benson Margulies  
 wrote:



There's a good patch in a PR. It has no test, and the author references

https://github.com/apache/maven-plugins/blame/8762d5746501b894cf766f38111fc514938be280/maven-shade-plugin/src/test/java/org/apache/maven/plugins/shade/filter/MinijarFilterTest.java

containing a commented out test case marked 'too expensive'.

Could anyone comment on the decision process here? We have a lot of
expensive tests, what's so bad about this one?


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

2017-03-24 Thread Stephen Connolly 
Have we some of the tests running in both modes?

Specifically at least 4625 as it caught some interesting CLI parsing
issues, but there may be a couple more

On Fri 24 Mar 2017 at 07:15, Hervé Boutemy  wrote:

> as you can see, in embedded mode, core ITs can run in 17 minutes, when in
> classic mode they run in 1h30
>
> any objection to merge this embedded mode into master?
>
> Regards,
>
> Hervé
>
> Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> > See
> https://builds.apache.org/job/maven-3.x-jenkinsfile/job/embedded-ITs/3/
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

2017-03-24 Thread Hervé Boutemy 
as you can see, in embedded mode, core ITs can run in 17 minutes, when in 
classic mode they run in 1h30

any objection to merge this embedded mode into master?

Regards,

Hervé

Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/embedded-ITs/3/



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org