[jira] (SUREFIRE-1136) Current working directory propagation in forked mode
[ https://jira.codehaus.org/browse/SUREFIRE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361431#comment-361431 ] Norbert Wnuk commented on SUREFIRE-1136: Pull request attached: https://github.com/apache/maven-surefire/pull/80 Current working directory propagation in forked mode Key: SUREFIRE-1136 URL: https://jira.codehaus.org/browse/SUREFIRE-1136 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Affects Versions: 2.18.1 Reporter: Norbert Wnuk Priority: Minor Surefire plugin does not resolve surefire.forkNumber variable for working directory so that the same invalid directory is set for all forked JVMs. The same time user.dir property is propagated properly which leads to inconsistent behavior in JDK API - http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java -- 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-tabpanelfocusedCommentId=361387#comment-361387
]
Michael Osipov edited comment on MCHANGES-351 at 1/19/15 7:08 AM:
--
Bernd, this isn't a bug because the changes plugin does not have paging support
at all. See: MCHANGES-98
was (Author: michael-o):
Bernd, this isn't a bug because the changes plugin does not hat paging support
at all. See: MCHANGES-98
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-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-tabpanelfocusedCommentId=361387#comment-361387
]
Michael Osipov commented on MCHANGES-351:
-
Bernd, this isn't a bug because the changes plugin does not hat paging support
at all. See: MCHANGES-98
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-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-5756) Java home output in mvn -v is misleading
[
https://jira.codehaus.org/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Description:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( Java home: ).append( System.getProperty( java.home,
unknown java home ) ).append( ls );
{code}
which is using property java.home to fetch java home. However, java.home
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv(JAVA_HOME).
Either that should be used or current output should be changed so it wouldn't
be so misleading.
was:
For example on my windows box, mvn -v prints the following:
`Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre`
But my JAVA_HOME is actually
{code}
echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( Java home: ).append( System.getProperty( java.home,
unknown java home ) ).append( ls );
{code}
which is using property java.home to fetch java home. However, java.home
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv(JAVA_HOME).
Either that should be used or current output should be changed so it wouldn't
be so misleading.
Java home output in mvn -v is misleading
Key: MNG-5756
URL: https://jira.codehaus.org/browse/MNG-5756
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.2.5
Environment: any
Reporter: Jarkko Rantavuori
Priority: Minor
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program
[jira] (MNG-5756) Java home output in mvn -v is misleading
[
https://jira.codehaus.org/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Description:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( Java home: ).append( System.getProperty( java.home,
unknown java home ) ).append( ls );
{code}
which is using property java.home to fetch java home. However, java.home
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv(JAVA_HOME).
Either that should be used or current output should be changed so it wouldn't
be so misleading.
was:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( Java home: ).append( System.getProperty( java.home,
unknown java home ) ).append( ls );
{code}
which is using property java.home to fetch java home. However, java.home
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv(JAVA_HOME).
Either that should be used or current output should be changed so it wouldn't
be so misleading.
Java home output in mvn -v is misleading
Key: MNG-5756
URL: https://jira.codehaus.org/browse/MNG-5756
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.2.5
Environment: any
Reporter: Jarkko Rantavuori
Priority: Minor
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (MNG-5756) Java home output in mvn -v is misleading
[
https://jira.codehaus.org/browse/MNG-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarkko Rantavuori updated MNG-5756:
---
Description:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java#l63
{code}
version.append( Java home: ).append( System.getProperty( java.home,
unknown java home ) ).append( ls );
{code}
which is using property java.home to fetch java home. However, java.home
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv(JAVA_HOME).
Either that should be used or current output should be changed so it wouldn't
be so misleading.
was:
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre
{code}
But my JAVA_HOME is actually
{code}
echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( Java home: ).append( System.getProperty( java.home,
unknown java home ) ).append( ls );
{code}
which is using property java.home to fetch java home. However, java.home
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv(JAVA_HOME).
Either that should be used or current output should be changed so it wouldn't
be so misleading.
Java home output in mvn -v is misleading
Key: MNG-5756
URL: https://jira.codehaus.org/browse/MNG-5756
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.2.5
Environment: any
Reporter: Jarkko Rantavuori
Priority: Minor
For example on my windows box, mvn -v prints the following:
{code}
Java home: C:\Program Files
[jira] (MNG-5756) Java home output in mvn -v is misleading
Jarkko Rantavuori created MNG-5756:
--
Summary: Java home output in mvn -v is misleading
Key: MNG-5756
URL: https://jira.codehaus.org/browse/MNG-5756
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.2.5
Environment: any
Reporter: Jarkko Rantavuori
Priority: Minor
For example on my windows box, mvn -v prints the following:
`Java home: C:\Program Files (x86)\Java\jdk1.7.0_51\jre`
But my JAVA_HOME is actually
{code}
echo %JAVA_HOME%
C:\Program Files (x86)\Java\jdk1.7.0_51
{code}
In the source code, the line comes from:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/java/org/apache/maven/cli/CLIReportingUtils.java
{code}
version.append( Java home: ).append( System.getProperty( java.home,
unknown java home ) ).append( ls );
{code}
which is using property java.home to fetch java home. However, java.home
property is not JAVA_HOME! This is explained in detail in here:
http://javahowto.blogspot.fi/2006/05/javahome-vs-javahome.html
To quote:
{quote}
What's the difference between JAVA_HOME and java.home?
JAVA_HOME is the JDK install directory, e.g., C:\jdk5. It's meant to be set
as an environment variable and referenced in Windows batch files or Unix
scripts. I always have it in my Windows Control Panel and .tcsh files,along
with other common environment variables. Some Java applications use the name
jdk.home for this purpose, which I think is a better name. But JAVA_HOME has
been used since the beginning and is now a convention.
java.home is the JRE install directory, e.g., C:\jdk5\jre, or C:\Program
Files\Java\jre1.5.0_06. Unlike JAVA_HOME, I never seen java.home as an
environment variable. java.home is a build-in Java system property, whose value
is the JRE install directory. Since all Java system properties are also exposed
as Ant build properties, you can also use ${java.home} in build files.
Would jre.home be a better name? Maybe, but I don't think Sun will change
it.
{quote}
This is a source of constant confusion. Some stackoverflow threads to
illustrate:
http://stackoverflow.com/questions/15279586/java-home-in-maven/15279640
http://stackoverflow.com/questions/17620531/maven-pointing-to-jre-instead-of-jdk
The correct way to print JAVA_HOME would be to use System.getenv(JAVA_HOME).
Either that should be used or current output should be changed so it wouldn't
be so misleading.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-399) Upgrade to Maven 2.2.1 compatiblity
[ https://jira.codehaus.org/browse/MSHARED-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-399: Fix Version/s: file-management-1.2.2 Upgrade to Maven 2.2.1 compatiblity --- Key: MSHARED-399 URL: https://jira.codehaus.org/browse/MSHARED-399 Project: Maven Shared Components Issue Type: Improvement Components: file-management Reporter: Karl-Heinz Marbaise Fix For: file-management-1.2.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-399) Upgrade to Maven 2.2.1 compatiblity
Karl-Heinz Marbaise created MSHARED-399: --- Summary: Upgrade to Maven 2.2.1 compatiblity Key: MSHARED-399 URL: https://jira.codehaus.org/browse/MSHARED-399 Project: Maven Shared Components Issue Type: Improvement Components: file-management Reporter: Karl-Heinz Marbaise -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-400) Upgrade maven-shared-utils to 0.7
Karl-Heinz Marbaise created MSHARED-400: --- Summary: Upgrade maven-shared-utils to 0.7 Key: MSHARED-400 URL: https://jira.codehaus.org/browse/MSHARED-400 Project: Maven Shared Components Issue Type: Improvement Components: file-management Affects Versions: file-management-1.2.2 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-401) Remove dependency plexus-container-default:1.0-alpha-9-stable-1
Karl-Heinz Marbaise created MSHARED-401: --- Summary: Remove dependency plexus-container-default:1.0-alpha-9-stable-1 Key: MSHARED-401 URL: https://jira.codehaus.org/browse/MSHARED-401 Project: Maven Shared Components Issue Type: Improvement Components: file-management Affects Versions: file-management-1.2.2 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-401) Remove dependency plexus-container-default:1.0-alpha-9-stable-1
[ https://jira.codehaus.org/browse/MSHARED-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-401: Fix Version/s: file-management-1.2.2 Remove dependency plexus-container-default:1.0-alpha-9-stable-1 --- Key: MSHARED-401 URL: https://jira.codehaus.org/browse/MSHARED-401 Project: Maven Shared Components Issue Type: Improvement Components: file-management Affects Versions: file-management-1.2.2 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: file-management-1.2.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-400) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-400. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653091|http://svn.apache.org/r1653091] Upgrade maven-shared-utils to 0.7 - Key: MSHARED-400 URL: https://jira.codehaus.org/browse/MSHARED-400 Project: Maven Shared Components Issue Type: Improvement Components: file-management Affects Versions: file-management-1.2.2 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: file-management-1.2.2 -- 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-tabpanelfocusedCommentId=361415#comment-361415
]
Michael Osipov commented on MCHANGES-351:
-
I think MCHANGES-98 can handle both with a config parameter.
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] (MSHARED-399) Upgrade to Maven 2.2.1 compatiblity
[ https://jira.codehaus.org/browse/MSHARED-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-399. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653087|http://svn.apache.org/r1653087] Followup in [r1653089|http://svn.apache.org/r1653089] Upgrade to Maven 2.2.1 compatiblity --- Key: MSHARED-399 URL: https://jira.codehaus.org/browse/MSHARED-399 Project: Maven Shared Components Issue Type: Improvement Components: file-management Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Fix For: file-management-1.2.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-400) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-400: Fix Version/s: file-management-1.2.2 Upgrade maven-shared-utils to 0.7 - Key: MSHARED-400 URL: https://jira.codehaus.org/browse/MSHARED-400 Project: Maven Shared Components Issue Type: Improvement Components: file-management Affects Versions: file-management-1.2.2 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: file-management-1.2.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-401) Remove dependency plexus-container-default:1.0-alpha-9-stable-1
[ https://jira.codehaus.org/browse/MSHARED-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-401. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653092|http://svn.apache.org/r1653092] Remove dependency plexus-container-default:1.0-alpha-9-stable-1 --- Key: MSHARED-401 URL: https://jira.codehaus.org/browse/MSHARED-401 Project: Maven Shared Components Issue Type: Improvement Components: file-management Affects Versions: file-management-1.2.2 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: file-management-1.2.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-199) Support PMD functionality on JSP files
[ https://jira.codehaus.org/browse/MPMD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=361412#comment-361412 ] Tom Williamson commented on MPMD-199: - Great, I am tuning up the patch and I hope to have it ready today or tomorrow. Support PMD functionality on JSP files -- Key: MPMD-199 URL: https://jira.codehaus.org/browse/MPMD-199 Project: Maven PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 3.3 Reporter: Tom Williamson Priority: Minor It would be great if this plugin would either support PMD functionality for JSP files, or simply enable them as part of the Java support. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-402) Upgrade to Maven 2.2.1 compatiblity
[ https://jira.codehaus.org/browse/MSHARED-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-402. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653102|http://svn.apache.org/r1653102] Upgrade to Maven 2.2.1 compatiblity --- Key: MSHARED-402 URL: https://jira.codehaus.org/browse/MSHARED-402 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-resolver Affects Versions: maven-artifact-resolver-1.1 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: maven-artifact-resolver-1.1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-403) Upgrade to Maven 2.2.1 compatiblity
Karl-Heinz Marbaise created MSHARED-403: --- Summary: Upgrade to Maven 2.2.1 compatiblity Key: MSHARED-403 URL: https://jira.codehaus.org/browse/MSHARED-403 Project: Maven Shared Components Issue Type: Improvement Components: maven-common-artifact-filters Affects Versions: maven-common-artifact-filters-1.5 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-403) Upgrade to Maven 2.2.1 compatiblity
[ https://jira.codehaus.org/browse/MSHARED-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-403: Fix Version/s: maven-common-artifact-filters-1.5 Upgrade to Maven 2.2.1 compatiblity --- Key: MSHARED-403 URL: https://jira.codehaus.org/browse/MSHARED-403 Project: Maven Shared Components Issue Type: Improvement Components: maven-common-artifact-filters Affects Versions: maven-common-artifact-filters-1.5 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: maven-common-artifact-filters-1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-404) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-404: Fix Version/s: maven-common-artifact-filters-1.5 Upgrade maven-shared-utils to 0.7 - Key: MSHARED-404 URL: https://jira.codehaus.org/browse/MSHARED-404 Project: Maven Shared Components Issue Type: Improvement Components: maven-common-artifact-filters Affects Versions: maven-common-artifact-filters-1.5 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: maven-common-artifact-filters-1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-404) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-404. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653107|http://svn.apache.org/r1653107] Upgrade maven-shared-utils to 0.7 - Key: MSHARED-404 URL: https://jira.codehaus.org/browse/MSHARED-404 Project: Maven Shared Components Issue Type: Improvement Components: maven-common-artifact-filters Affects Versions: maven-common-artifact-filters-1.5 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: maven-common-artifact-filters-1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-405) Upgrade maven-shared-utils to 0.7
Karl-Heinz Marbaise created MSHARED-405: --- Summary: Upgrade maven-shared-utils to 0.7 Key: MSHARED-405 URL: https://jira.codehaus.org/browse/MSHARED-405 Project: Maven Shared Components Issue Type: Improvement Components: maven-verifier Affects Versions: maven-verifier-1.6 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-405) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-405. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653110|http://svn.apache.org/r1653110] Upgrade maven-shared-utils to 0.7 - Key: MSHARED-405 URL: https://jira.codehaus.org/browse/MSHARED-405 Project: Maven Shared Components Issue Type: Improvement Components: maven-verifier Affects Versions: maven-verifier-1.6 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: maven-verifier-1.6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-405) Upgrade maven-shared-utils to 0.7
[ https://jira.codehaus.org/browse/MSHARED-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-405: Fix Version/s: maven-verifier-1.6 Upgrade maven-shared-utils to 0.7 - Key: MSHARED-405 URL: https://jira.codehaus.org/browse/MSHARED-405 Project: Maven Shared Components Issue Type: Improvement Components: maven-verifier Affects Versions: maven-verifier-1.6 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: maven-verifier-1.6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-402) Upgrade to Maven 2.2.1 compatiblity
Karl-Heinz Marbaise created MSHARED-402: --- Summary: Upgrade to Maven 2.2.1 compatiblity Key: MSHARED-402 URL: https://jira.codehaus.org/browse/MSHARED-402 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-resolver Affects Versions: maven-artifact-resolver-1.1 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-402) Upgrade to Maven 2.2.1 compatiblity
[ https://jira.codehaus.org/browse/MSHARED-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MSHARED-402: Fix Version/s: maven-artifact-resolver-1.1 Upgrade to Maven 2.2.1 compatiblity --- Key: MSHARED-402 URL: https://jira.codehaus.org/browse/MSHARED-402 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-resolver Affects Versions: maven-artifact-resolver-1.1 Reporter: Karl-Heinz Marbaise Priority: Minor Fix For: maven-artifact-resolver-1.1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-403) Upgrade to Maven 2.2.1 compatiblity
[ https://jira.codehaus.org/browse/MSHARED-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MSHARED-403. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1653105|http://svn.apache.org/r1653105] Upgrade to Maven 2.2.1 compatiblity --- Key: MSHARED-403 URL: https://jira.codehaus.org/browse/MSHARED-403 Project: Maven Shared Components Issue Type: Improvement Components: maven-common-artifact-filters Affects Versions: maven-common-artifact-filters-1.5 Reporter: Karl-Heinz Marbaise Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: maven-common-artifact-filters-1.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-404) Upgrade maven-shared-utils to 0.7
Karl-Heinz Marbaise created MSHARED-404: --- Summary: Upgrade maven-shared-utils to 0.7 Key: MSHARED-404 URL: https://jira.codehaus.org/browse/MSHARED-404 Project: Maven Shared Components Issue Type: Improvement Components: maven-common-artifact-filters Affects Versions: maven-common-artifact-filters-1.5 Reporter: Karl-Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1136) Current working directory propagation in forked mode
Norbert Wnuk created SUREFIRE-1136: -- Summary: Current working directory propagation in forked mode Key: SUREFIRE-1136 URL: https://jira.codehaus.org/browse/SUREFIRE-1136 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Affects Versions: 2.18.1 Reporter: Norbert Wnuk Priority: Minor Surefire plugin does not resolve surefire.forkNumber variable for working directory so that the same invalid directory is set for all forked JVMs. The same time user.dir property is propagated properly which leads to inconsistent behavior in JDK API - http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java -- This message was sent by Atlassian JIRA (v6.1.6#6162)
