[jira] [Commented] (MNGSITE-360) upgrade archetype version to 1.4 to support Java 11
[ https://issues.apache.org/jira/browse/MNGSITE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713871#comment-16713871 ] Bernd Eckenfels commented on MNGSITE-360: - Also undo/delete https://github.com/apache/maven-site/pull/57 > upgrade archetype version to 1.4 to support Java 11 > --- > > Key: MNGSITE-360 > URL: https://issues.apache.org/jira/browse/MNGSITE-360 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Hervé Boutemy >Priority: Major > Labels: up-for-grabs > > once MARCHETYPES-63 & MARCHETYPES-64 fixed and version 1.4 released -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MARCHETYPES-63) upgrade plugins versions to avoid failure with Java 11
[
https://issues.apache.org/jira/browse/MARCHETYPES-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713869#comment-16713869
]
Bernd Eckenfels commented on MARCHETYPES-63:
Surefire 2.22.1 worked for me.
BTW: the site build also prints a warning about missing version and fails with
Java 11, should we describe that also or just fix it in 1.4?
Add:
{code:xml}
org.apache.maven.plugins
maven-project-info-reports-plugin
2.7
{code}
> upgrade plugins versions to avoid failure with Java 11
> --
>
> Key: MARCHETYPES-63
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-63
> Project: Maven Archetype Bundles
> Issue Type: Wish
> Components: Maven Quickstart Archetype
>Affects Versions: 1.3
>Reporter: Hervé Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.4
>
>
> projects created from current archetypes should build with Java 11, which is
> the current LTS
> tests show that at least maven-surefire-plugin has to be upgraded (currently
> using 2.20.1)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSITE-813) Broken link to codehaus wiki
Bernd Eckenfels created MSITE-813: - Summary: Broken link to codehaus wiki Key: MSITE-813 URL: https://issues.apache.org/jira/browse/MSITE-813 Project: Maven Site Plugin Issue Type: Bug Components: documentation Reporter: Bernd Eckenfels The currently deployed site for the maven-jar-plugin (MJAR) has a broken link to docs.codehaus.org/display/MAVENUSER/JAR+Plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJLINK-4) NPE on execution
[
https://issues.apache.org/jira/browse/MJLINK-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394636#comment-16394636
]
Bernd Eckenfels commented on MJLINK-4:
--
I can confirm the NPE is gone with
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-jlink-plugin/3.0.0-alpha-2-SNAPSHOT/
> NPE on execution
> -
>
> Key: MJLINK-4
> URL: https://issues.apache.org/jira/browse/MJLINK-4
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1
> Environment: Ubuntu 16.04.3 LTS
> Linux 4.4.0-93-generic
>Reporter: Johannes Boesl
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0-alpha-2
>
>
> When I try to run my maven build I get the following exception:
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:52)
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:48)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:109)
> at
> org.apache.maven.plugins.jlink.JLinkMojo.preparePaths(JLinkMojo.java:347)
> at org.apache.maven.plugins.jlink.JLinkMojo.execute(JLinkMojo.java:264)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 12 more{quote}
> {noformat}
> The cause seems to be that the following code in line 337 in JLinkMojo
> returns a collection with only 'null' entries:
> {{Collection dependencyArtifacts = getCompileClasspathElements(
> getProject() );}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJLINK-4) NPE on execution
[
https://issues.apache.org/jira/browse/MJLINK-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392183#comment-16392183
]
Bernd Eckenfels commented on MJLINK-4:
--
Just as an additional note, I had the same issue in alpha.1 and I noticed that
using the POM parent `com.soebes.smpp:smpp:2.3.0` would work around it. I guess
it updates some shared components or adds something to the model. Anyway..
waiting for alpha.2 :)
> NPE on execution
> -
>
> Key: MJLINK-4
> URL: https://issues.apache.org/jira/browse/MJLINK-4
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1
> Environment: Ubuntu 16.04.3 LTS
> Linux 4.4.0-93-generic
>Reporter: Johannes Boesl
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0-alpha-2
>
>
> When I try to run my maven build I get the following exception:
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink
> (default-jlink) on project jloadr-jre: Execution default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:196)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-jlink of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:52)
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:48)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:109)
> at
> org.apache.maven.plugins.jlink.JLinkMojo.preparePaths(JLinkMojo.java:347)
> at org.apache.maven.plugins.jlink.JLinkMojo.execute(JLinkMojo.java:264)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 12 more{quote}
> {noformat}
> The cause seems to be that the following code in line 337 in JLinkMojo
> returns a collection with only 'null' entries:
> {{Collection dependencyArtifacts = getCompileClasspathElements(
> getProject() );}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1475) PpidChecker.windows() assumes wmic is on the path
[
https://issues.apache.org/jira/browse/SUREFIRE-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366561#comment-16366561
]
Bernd Eckenfels commented on SUREFIRE-1475:
---
I tripped over this also. I would agree it should try first with full name,
then relative to PATH and in all cases analyse the exit code for errors - and
fall back to old method. Also the dump message could mention the wmic command
tried and the error code received.
[http://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html]
> PpidChecker.windows() assumes wmic is on the path
> -
>
> Key: SUREFIRE-1475
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1475
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1
> Environment: Windows
>Reporter: Anders Wallgren
>Assignee: Tibor Digana
>Priority: Major
>
>
> {{PpidChecker.windows()}} assumes that the wmic executable is on the path,
> which isn't always the case.
> A better approach would probably be to use
> {{%SystemRoot%\System32\Wbem\wmic}}.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5804) mvn.bat does not work in root directory on Windows
[
https://issues.apache.org/jira/browse/MNG-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated MNG-5804:
-
Description:
On Windows the new `mvn.cmd` script does not work if the current working
directory is the root dir of a drive. In that case it will initialize
`%MAVEN_PROJECTBASEDIR%` with a trailing `\` and that will break the java
command line as it escapes the following quote of
`"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"`.
It works on 3.2.1 and fails with 3.3.1:
{code}
c:\> cd /d C:\
c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T18:37:52+01:00)
Maven home: c:\devenv\apache-maven-3.2.1\bin\..
...
c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
Usage: java [-options] class [args...]
...
{code}
was:
On Windows the new `mvn.cmd` script does not work if the current working
directory is the root dir of a drive. In that case it will initialize
`%MAVEN_PROJECTBASEDIR%` with a trailing `\` and that will break the java
command line as it escapes the following quote of
`"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"`.
It works on 3.2.1 and fails with 3.3.1:
{code}
c:\> cd /d C:\
c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T18:37:52+01:00)
Maven home: c:\devenv\apache-maven-3.2.1\bin\..
...
c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
...
{code}
> mvn.bat does not work in root directory on Windows
> --
>
> Key: MNG-5804
> URL: https://issues.apache.org/jira/browse/MNG-5804
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.1
> Environment: Win7 x64 german
>Reporter: Bernd Eckenfels
>Priority: Minor
> Labels: windows,
>
> On Windows the new `mvn.cmd` script does not work if the current working
> directory is the root dir of a drive. In that case it will initialize
> `%MAVEN_PROJECTBASEDIR%` with a trailing `\` and that will break the java
> command line as it escapes the following quote of
> `"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"`.
> It works on 3.2.1 and fails with 3.3.1:
> {code}
> c:\> cd /d C:\
> c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:52+01:00)
> Maven home: c:\devenv\apache-maven-3.2.1\bin\..
> ...
> c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
> Usage: java [-options] class [args...]
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5804) mvn.bat does not work in root directory on Windows
[
https://issues.apache.org/jira/browse/MNG-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated MNG-5804:
-
Description:
On Windows the new `mvn.cmd` script does not work if the current working
directory is the root dir of a drive. In that case it will initialize
`%MAVEN_PROJECTBASEDIR%` with a trailing `\` and that will break the java
command line as it escapes the following quote of
`"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"`.
It works on 3.2.1 and fails with 3.3.1:
{code}
c:\> cd /d C:\
c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T18:37:52+01:00)
Maven home: c:\devenv\apache-maven-3.2.1\bin\..
...
c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
...
{code}
was:
On Windows the new mvn.bat script does not work if the current working
directory is the root dir of a drive. In that case it will initialize
%MAVEN_PROJECTBASEDIR% with a tryiling \ and that will break the java command
line as it escapes the following quote of
"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"
It works on 3.2.1 and fails with 3.3.1:
{code}
c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T18:37:52+01:00)
Maven home: c:\devenv\apache-maven-3.2.1\bin\..
...
c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
...
{code}
> mvn.bat does not work in root directory on Windows
> --
>
> Key: MNG-5804
> URL: https://issues.apache.org/jira/browse/MNG-5804
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.1
> Environment: Win7 x64 german
>Reporter: Bernd Eckenfels
>Priority: Minor
> Labels: windows,
>
> On Windows the new `mvn.cmd` script does not work if the current working
> directory is the root dir of a drive. In that case it will initialize
> `%MAVEN_PROJECTBASEDIR%` with a trailing `\` and that will break the java
> command line as it escapes the following quote of
> `"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"`.
> It works on 3.2.1 and fails with 3.3.1:
> {code}
> c:\> cd /d C:\
> c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:52+01:00)
> Maven home: c:\devenv\apache-maven-3.2.1\bin\..
> ...
> c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5804) mvn.bat does not work in root directory on Windows
Bernd Eckenfels created MNG-5804:
Summary: mvn.bat does not work in root directory on Windows
Key: MNG-5804
URL: https://issues.apache.org/jira/browse/MNG-5804
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.3.1
Environment: Win7 x64 german
Reporter: Bernd Eckenfels
Priority: Minor
On Windows the new mvn.bat script does not work if the current working
directory is the root dir of a drive. In that case it will initialize
%MAVEN_PROJECTBASEDIR% with a tryiling \ and that will break the java command
line as it escapes the following quote of
"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"
It works on 3.2.1 and fails with 3.3.1:
{code}
c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T18:37:52+01:00)
Maven home: c:\devenv\apache-maven-3.2.1\bin\..
...
c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
...
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MCHANGES-351) No paging when maxEntries is reached
[
https://jira.codehaus.org/browse/MCHANGES-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361840#comment-361840
]
Bernd Eckenfels commented on MCHANGES-351:
--
The ASF INFRA team does not want to raise that limit on their Jira instance:
https://issues.apache.org/jira/browse/INFRA-9059
> No paging when maxEntries is reached
>
>
> Key: MCHANGES-351
> URL: https://jira.codehaus.org/browse/MCHANGES-351
> Project: Maven Changes Plugin
> Issue Type: Wish
> Components: jira
>Affects Versions: 2.11
> Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
>Reporter: Bernd Eckenfels
>
> I try to generate a JIRA changes report for apache commons VFS. If I set the
> maxEntries to 600 it wont work. It looks like the Apache Instance only allows
> to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
> case there are 141 bugs in the current fixversion and the query finds 295).
> According to the JIRA docu you can query with different offsets, so would it
> be possible to query startAt=0-99,100-199,... and so on?
> Here is the request and the response:
> {code}
> Address: https://issues.apache.org/jira/rest/api/2/search
> Http-Method: POST
> Content-Type: application/json
> Headers: {Accept=[application/json], Content-Type=[application/json],
> Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
> (1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
> key DESC","maxResults":600,"fields":["*all"]...
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: \{Cache-Control=[no-cache, no-store, no-transform],
> connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
> Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
> Server=[Apache-Coyote/1.1],
> Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
> HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
> X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous],
> X-Content-Type-Options=[nosniff]}
> Messages:
> Message (saved to tmp file):
> Filename:
> C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
> (message truncated to 102400 bytes)
> Payload:
> {"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361570#comment-361570
]
Bernd Eckenfels edited comment on MNG-5686 at 1/21/15 5:59 PM:
---
here is a PR against master, it fixes mvn, mvnDebug and mvnyjp.
https://github.com/apache/maven/pull/35
was (Author: eckes):
here is a PR against master, it fixes mvn, mvnDebug and mvnyjp.
> mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
> ---
>
> Key: MNG-5686
> URL: https://jira.codehaus.org/browse/MNG-5686
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.3
> Environment: Mac OS X 10.9.4
>Reporter: Takayoshi Fujiki
>Assignee: Kristian Rosenvold
> Fix For: 3.2.5
>
> Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
> 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch,
> 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
>
>
> From 3.2.3, mvn cannot start and outputs the following error.
> {code}
> $ ./apache-maven-3.2.3/bin/mvn -version
> Error: JAVA_HOME is not defined correctly.
> We cannot execute /usr/libexec/java_home/bin/java
> {code}
> 3.2.2 doesn't have this problem.
> {code}
> $ ./apache-maven-3.2.2/bin/mvn -version
> Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
> 2014-06-17T22:51:42+09:00)
> Maven home: /Users/xxx/tmp/apache-maven-3.2.2
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> {code}
> When I modified {{bin/mvn}} like the following, this problem was gone.
> {code}
> --- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
> +++ bin/mvn 2014-09-10 03:34:18.0 +0900
> @@ -83,7 +83,7 @@
> #
> # Apple JDKs
> #
> - export JAVA_HOME=/usr/libexec/java_home
> + export JAVA_HOME="`/usr/libexec/java_home`"
> fi
> ;;
> esac
> {code}
> Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
> command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
> and {{$(command)}} is a style of [Command
> Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
> style is {{`command`}}).
> So removing "$()" breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361570#comment-361570
]
Bernd Eckenfels commented on MNG-5686:
--
here is a PR against master, it fixes mvn, mvnDebug and mvnyjp.
> mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
> ---
>
> Key: MNG-5686
> URL: https://jira.codehaus.org/browse/MNG-5686
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.3
> Environment: Mac OS X 10.9.4
>Reporter: Takayoshi Fujiki
>Assignee: Kristian Rosenvold
> Fix For: 3.2.5
>
> Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
> 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch,
> 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
>
>
> From 3.2.3, mvn cannot start and outputs the following error.
> {code}
> $ ./apache-maven-3.2.3/bin/mvn -version
> Error: JAVA_HOME is not defined correctly.
> We cannot execute /usr/libexec/java_home/bin/java
> {code}
> 3.2.2 doesn't have this problem.
> {code}
> $ ./apache-maven-3.2.2/bin/mvn -version
> Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
> 2014-06-17T22:51:42+09:00)
> Maven home: /Users/xxx/tmp/apache-maven-3.2.2
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> {code}
> When I modified {{bin/mvn}} like the following, this problem was gone.
> {code}
> --- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
> +++ bin/mvn 2014-09-10 03:34:18.0 +0900
> @@ -83,7 +83,7 @@
> #
> # Apple JDKs
> #
> - export JAVA_HOME=/usr/libexec/java_home
> + export JAVA_HOME="`/usr/libexec/java_home`"
> fi
> ;;
> esac
> {code}
> Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
> command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
> and {{$(command)}} is a style of [Command
> Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
> style is {{`command`}}).
> So removing "$()" breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-351) No paging when maxEntries is reached
[
https://jira.codehaus.org/browse/MCHANGES-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated MCHANGES-351:
-
Issue Type: Wish (was: Bug)
> No paging when maxEntries is reached
>
>
> Key: MCHANGES-351
> URL: https://jira.codehaus.org/browse/MCHANGES-351
> Project: Maven Changes Plugin
> Issue Type: Wish
> Components: jira
>Affects Versions: 2.11
> Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
>Reporter: Bernd Eckenfels
>
> I try to generate a JIRA changes report for apache commons VFS. If I set the
> maxEntries to 600 it wont work. It looks like the Apache Instance only allows
> to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
> case there are 141 bugs in the current fixversion and the query finds 295).
> According to the JIRA docu you can query with different offsets, so would it
> be possible to query startAt=0-99,100-199,... and so on?
> Here is the request and the response:
> {code}
> Address: https://issues.apache.org/jira/rest/api/2/search
> Http-Method: POST
> Content-Type: application/json
> Headers: {Accept=[application/json], Content-Type=[application/json],
> Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
> (1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
> key DESC","maxResults":600,"fields":["*all"]...
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: \{Cache-Control=[no-cache, no-store, no-transform],
> connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
> Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
> Server=[Apache-Coyote/1.1],
> Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
> HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
> X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous],
> X-Content-Type-Options=[nosniff]}
> Messages:
> Message (saved to tmp file):
> Filename:
> C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
> (message truncated to 102400 bytes)
> Payload:
> {"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-351) No paging when maxEntries is reached
[
https://jira.codehaus.org/browse/MCHANGES-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361397#comment-361397
]
Bernd Eckenfels commented on MCHANGES-351:
--
I think MCHANGES-98 is about missing output paging / better representation.
This Bug is about the input (RESAT query) paging.
But I agree you can also call this a missing feature not a bug (in any case its
not useable for my project).
> No paging when maxEntries is reached
>
>
> Key: MCHANGES-351
> URL: https://jira.codehaus.org/browse/MCHANGES-351
> Project: Maven Changes Plugin
> Issue Type: Wish
> Components: jira
>Affects Versions: 2.11
> Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
>Reporter: Bernd Eckenfels
>
> I try to generate a JIRA changes report for apache commons VFS. If I set the
> maxEntries to 600 it wont work. It looks like the Apache Instance only allows
> to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
> case there are 141 bugs in the current fixversion and the query finds 295).
> According to the JIRA docu you can query with different offsets, so would it
> be possible to query startAt=0-99,100-199,... and so on?
> Here is the request and the response:
> {code}
> Address: https://issues.apache.org/jira/rest/api/2/search
> Http-Method: POST
> Content-Type: application/json
> Headers: {Accept=[application/json], Content-Type=[application/json],
> Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
> (1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
> key DESC","maxResults":600,"fields":["*all"]...
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: \{Cache-Control=[no-cache, no-store, no-transform],
> connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
> Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
> Server=[Apache-Coyote/1.1],
> Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
> HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
> X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous],
> X-Content-Type-Options=[nosniff]}
> Messages:
> Message (saved to tmp file):
> Filename:
> C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
> (message truncated to 102400 bytes)
> Payload:
> {"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-351) No paging when maxEntries is reached
[
https://jira.codehaus.org/browse/MCHANGES-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361397#comment-361397
]
Bernd Eckenfels edited comment on MCHANGES-351 at 1/19/15 8:54 AM:
---
I think MCHANGES-98 is about missing output paging / better representation.
This Bug is about the input (REST query) paging.
But I agree you can also call this a missing feature not a bug (in any case its
not useable for my project).
was (Author: eckes):
I think MCHANGES-98 is about missing output paging / better representation.
This Bug is about the input (RESAT query) paging.
But I agree you can also call this a missing feature not a bug (in any case its
not useable for my project).
> No paging when maxEntries is reached
>
>
> Key: MCHANGES-351
> URL: https://jira.codehaus.org/browse/MCHANGES-351
> Project: Maven Changes Plugin
> Issue Type: Wish
> Components: jira
>Affects Versions: 2.11
> Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
>Reporter: Bernd Eckenfels
>
> I try to generate a JIRA changes report for apache commons VFS. If I set the
> maxEntries to 600 it wont work. It looks like the Apache Instance only allows
> to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
> case there are 141 bugs in the current fixversion and the query finds 295).
> According to the JIRA docu you can query with different offsets, so would it
> be possible to query startAt=0-99,100-199,... and so on?
> Here is the request and the response:
> {code}
> Address: https://issues.apache.org/jira/rest/api/2/search
> Http-Method: POST
> Content-Type: application/json
> Headers: {Accept=[application/json], Content-Type=[application/json],
> Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
> (1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
> key DESC","maxResults":600,"fields":["*all"]...
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: \{Cache-Control=[no-cache, no-store, no-transform],
> connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
> Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
> Server=[Apache-Coyote/1.1],
> Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
> HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
> X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous],
> X-Content-Type-Options=[nosniff]}
> Messages:
> Message (saved to tmp file):
> Filename:
> C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
> (message truncated to 102400 bytes)
> Payload:
> {"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-351) No paging when maxEntries is reached
[
https://jira.codehaus.org/browse/MCHANGES-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated MCHANGES-351:
-
Description:
I try to generate a JIRA changes report for apache commons VFS. If I set the
maxEntries to 600 it wont work. It looks like the Apache Instance only allows
to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
case there are 141 bugs in the current fixversion and the query finds 295).
According to the JIRA docu you can query with different offsets, so would it be
possible to query startAt=0-99,100-199,... and so on?
Here is the request and the response:
{code}
Address: https://issues.apache.org/jira/rest/api/2/search
Http-Method: POST
Content-Type: application/json
Headers: {Accept=[application/json], Content-Type=[application/json],
Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
(1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
key DESC","maxResults":600,"fields":["*all"]...
Response-Code: 200
Encoding: UTF-8
Content-Type: application/json;charset=UTF-8
Headers: \{Cache-Control=[no-cache, no-store, no-transform],
connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
Server=[Apache-Coyote/1.1],
Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous], X-Content-Type-Options=[nosniff]}
Messages:
Message (saved to tmp file):
Filename:
C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
(message truncated to 102400 bytes)
Payload:
{"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
{code}
was:
I try to generate a JIRA changes report for apache commons VFS. If I set the
maxEntries to 600 it wont work. It looks like the Apache Instance only allows
to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
case there are 141 bugs in the current fixversion and the query finds 295).
According to the JIRA docu you can query with different offsets, so would it be
possible to query startAt=0-99,100-199,... and so on?
Here is the request and the response:
{quote}
Address: https://issues.apache.org/jira/rest/api/2/search
Http-Method: POST
Content-Type: application/json
Headers: {Accept=[application/json], Content-Type=[application/json],
Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
(1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
key DESC","maxResults":600,"fields":["*all"]}
Response-Code: 200
Encoding: UTF-8
Content-Type: application/json;charset=UTF-8
Headers: {Cache-Control=[no-cache, no-store, no-transform],
connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
Server=[Apache-Coyote/1.1],
Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous], X-Content-Type-Options=[nosniff]}
Messages:
Message (saved to tmp file):
Filename:
C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
(message truncated to 102400 bytes)
Payload:
{"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
{quote}
> No paging when maxEntries is reached
>
>
> Key: MCHANGES-351
> URL: https://jira.codehaus.org/browse/MCHANGES-351
> Project: Maven Changes Plugin
> Issue Type: Bug
> Components: jira
>Affects Versions: 2.11
> Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
>Reporter: Bernd Eckenfels
>
> I try to generate a JIRA changes report for apache commons VFS. If I set the
> maxEntries to 600 it wont work. It looks like the Apache Instance only allows
> to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
> case there are 141 bugs in the current fixversion and the query finds 295).
> According to the JIRA docu you can query with different offsets, so would it
> be possible to query startAt=0-99,100-199,... and so on?
> Here is the request and the response:
> {code}
> Address: https://issues.apache.org/jira/rest/api/2/search
> Http-Method: POST
> Content-Type: application/json
> Headers: {Accept=[application/json], Content-Type=[application/json],
> Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
> (1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
> key DESC","maxResults":600,"fields":["*all"]...
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: \{Cache-Control=[no-cache, no-store, no-tr
[jira] (MCHANGES-351) No paging when maxEntries is reached
Bernd Eckenfels created MCHANGES-351:
Summary: No paging when maxEntries is reached
Key: MCHANGES-351
URL: https://jira.codehaus.org/browse/MCHANGES-351
Project: Maven Changes Plugin
Issue Type: Bug
Components: jira
Affects Versions: 2.11
Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
Reporter: Bernd Eckenfels
I try to generate a JIRA changes report for apache commons VFS. If I set the
maxEntries to 600 it wont work. It looks like the Apache Instance only allows
to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
case there are 141 bugs in the current fixversion and the query finds 295).
According to the JIRA docu you can query with different offsets, so would it be
possible to query startAt=0-99,100-199,... and so on?
Here is the request and the response:
{quote}
Address: https://issues.apache.org/jira/rest/api/2/search
Http-Method: POST
Content-Type: application/json
Headers: {Accept=[application/json], Content-Type=[application/json],
Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
(1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
key DESC","maxResults":600,"fields":["*all"]}
Response-Code: 200
Encoding: UTF-8
Content-Type: application/json;charset=UTF-8
Headers: {Cache-Control=[no-cache, no-store, no-transform],
connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
Server=[Apache-Coyote/1.1],
Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous], X-Content-Type-Options=[nosniff]}
Messages:
Message (saved to tmp file):
Filename:
C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
(message truncated to 102400 bytes)
Payload:
{"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-757) Project encoding properties is not checked
[ https://jira.codehaus.org/browse/SUREFIRE-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356230#comment-356230 ] Bernd Eckenfels commented on SUREFIRE-757: -- I can try to come up with a patch to fix the warning message (if this is possible, nut sure if it is a shared component). At a minimum I guess using "Output file encoding" or similiar (maybe naming setting). > Project encoding properties is not checked > -- > > Key: SUREFIRE-757 > URL: https://jira.codehaus.org/browse/SUREFIRE-757 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 2.9 > Environment: windows 7 SP1 64bit. CentOS 5.6 64bit >Reporter: Croydon >Assignee: Tibor Digana >Priority: Trivial > > We do have the file encoding > *UTF-8* set in > our parent project properties. > We added the failsafe plugin for our integration tests and start seeing the > following warning message > On Windows - *[WARNING] File encoding has not been set, using platform > encoding Cp1252, i.e. build is platform dependent!* > On CentOS - *[WARNING] File encoding has not been set, using platform > encoding UTF-8, i.e. build is platform dependent!* -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-595) Add surefire:force-test mojo to postpone tests
[ https://jira.codehaus.org/browse/SUREFIRE-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356201#comment-356201 ] Bernd Eckenfels commented on SUREFIRE-595: -- I agree that the force-tests it not well fitting the maven style. @Dan But just an option for you, did you try to overwride the surefire config with a fixed falsefalse to ignore the properties. (not sure if this works). > Add surefire:force-test mojo to postpone tests > -- > > Key: SUREFIRE-595 > URL: https://jira.codehaus.org/browse/SUREFIRE-595 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Dan Fabulich >Assignee: Tibor Digana > > The standard lifecycle does all testing before installing artifacts in the > local repository. When running our experimental concurrent Maven, we find > that doing compiling/packaging/installing before testing can promote better > concurrency. > It would be helpful to have a surefire:force-test mojo, which simply extends > the standard mojo but ignores the -DskipTests and -Dmaven.test.skip > properties. That way, you could run the build like this: > mvn install -DskipTests surefire:force-test > The tests would be skipped during the install lifecycle, and then run > separately at the end of the build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-851) javaHome is ignored and inherited unexpected
[
https://jira.codehaus.org/browse/MRELEASE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334626#comment-334626
]
Bernd Eckenfels commented on MRELEASE-851:
--
Seems I forgot the link, added it. I will also add a sample pom which can
reproduce the problem (but I am not familiar with testing harness to make a
unit test out of it)
> javaHome is ignored and inherited unexpected
>
>
> Key: MRELEASE-851
> URL: https://jira.codehaus.org/browse/MRELEASE-851
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Bernd Eckenfels
>
> The release: mojos have a configuration which defaults to
> ${java.home}. From reading the documentation it seems like this is used to
> propagate the JAVA version of the marent process to the invoked build of
> prepare and perform. This inheritance is important in order to properly
> support compiles. The documentation does not mention that the option is
> ignored.
> The following proposed patch might be able to solve the problem by setting
> the JAVA_HOME variable as documented. This also helps some situations where
> CI servers not reliable replicate builds.
> The patch does not include it, but most likely it should also be noted that
> MAVEN_SKIP_RC=true should be added to the child's env.
> https://github.com/apache/maven-release/pull/5
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-851) javaHome is ignored and inherited unexpected
[
https://jira.codehaus.org/browse/MRELEASE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated MRELEASE-851:
-
Description:
The release: mojos have a configuration which defaults to
${java.home}. From reading the documentation it seems like this is used to
propagate the JAVA version of the marent process to the invoked build of
prepare and perform. This inheritance is important in order to properly support
compiles. The documentation does not mention that the option is ignored.
The following proposed patch might be able to solve the problem by setting the
JAVA_HOME variable as documented. This also helps some situations where CI
servers not reliable replicate builds.
The patch does not include it, but most likely it should also be noted that
MAVEN_SKIP_RC=true should be added to the child's env.
https://github.com/apache/maven-release/pull/5
was:
The release: mojos have a configuration which defaults to
${java.home}. From reading the documentation it seems like this is used to
propagate the JAVA version of the marent process to the invoked build of
prepare and perform. This inheritance is important in order to properly support
compiles. The documentation does not mention that the option is ignored.
The following proposed patch might be able to solve the problem by setting the
JAVA_HOME variable as documented. This also helps some situations where CI
servers not reliable replicate builds.
The patch does not include it, but most likely it should also be noted that
MAVEN_SKIP_RC=true should be added to the child's env.
> javaHome is ignored and inherited unexpected
>
>
> Key: MRELEASE-851
> URL: https://jira.codehaus.org/browse/MRELEASE-851
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Bernd Eckenfels
>
> The release: mojos have a configuration which defaults to
> ${java.home}. From reading the documentation it seems like this is used to
> propagate the JAVA version of the marent process to the invoked build of
> prepare and perform. This inheritance is important in order to properly
> support compiles. The documentation does not mention that the option is
> ignored.
> The following proposed patch might be able to solve the problem by setting
> the JAVA_HOME variable as documented. This also helps some situations where
> CI servers not reliable replicate builds.
> The patch does not include it, but most likely it should also be noted that
> MAVEN_SKIP_RC=true should be added to the child's env.
> https://github.com/apache/maven-release/pull/5
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-851) javaHome is ignored and inherited unexpected
Bernd Eckenfels created MRELEASE-851:
Summary: javaHome is ignored and inherited unexpected
Key: MRELEASE-851
URL: https://jira.codehaus.org/browse/MRELEASE-851
Project: Maven Release Plugin
Issue Type: Bug
Affects Versions: 2.4.1
Reporter: Bernd Eckenfels
The release: mojos have a configuration which defaults to
${java.home}. From reading the documentation it seems like this is used to
propagate the JAVA version of the marent process to the invoked build of
prepare and perform. This inheritance is important in order to properly support
compiles. The documentation does not mention that the option is ignored.
The following proposed patch might be able to solve the problem by setting the
JAVA_HOME variable as documented. This also helps some situations where CI
servers not reliable replicate builds.
The patch does not include it, but most likely it should also be noted that
MAVEN_SKIP_RC=true should be added to the child's env.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
