[jira] [Commented] (MPOM-47) Source release assembly can't do tar.gz only
[ https://issues.apache.org/jira/browse/MPOM-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329792#comment-14329792 ] Christopher Tubbs commented on MPOM-47: --- Bumping apache-source-release-assembly-descriptor to 1.0.5, as described in MPOM-70, should do the trick. > Source release assembly can't do tar.gz only > > > Key: MPOM-47 > URL: https://issues.apache.org/jira/browse/MPOM-47 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Reporter: Christopher Tubbs > Fix For: ASF-17 > > > The source-release-assembly execution of the maven-assembly-plugin doesn't > offer any way to specify to build a tarball (tar.gz) only. By default, it > builds a zip file. > One can override the plugin execution to force it to build both a zip and a > tarball, by setting sourceReleaseAssemblyDescriptor to > "source-release-zip-tar". > However, there's no way to get it to build only the tarball, unless you do > convoluted things like in [this > example|http://search.maven.org/remotecontent?filepath=org/apache/accumulo/accumulo-project/1.5.0/accumulo-project-1.5.0.pom], > or if you override the apache-release profile entirely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MPOM-47) Source release assembly can't do tar.gz only
[ https://issues.apache.org/jira/browse/MPOM-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated MPOM-47: -- Fix Version/s: ASF-17 > Source release assembly can't do tar.gz only > > > Key: MPOM-47 > URL: https://issues.apache.org/jira/browse/MPOM-47 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Reporter: Christopher Tubbs > Fix For: ASF-17 > > > The source-release-assembly execution of the maven-assembly-plugin doesn't > offer any way to specify to build a tarball (tar.gz) only. By default, it > builds a zip file. > One can override the plugin execution to force it to build both a zip and a > tarball, by setting sourceReleaseAssemblyDescriptor to > "source-release-zip-tar". > However, there's no way to get it to build only the tarball, unless you do > convoluted things like in [this > example|http://search.maven.org/remotecontent?filepath=org/apache/accumulo/accumulo-project/1.5.0/accumulo-project-1.5.0.pom], > or if you override the apache-release profile entirely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MPOM-70) Bump apache-source-release-assembly-descriptor to 1.0.5
[ https://issues.apache.org/jira/browse/MPOM-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs closed MPOM-70. - Resolution: Duplicate Fix Version/s: (was: ASF-17) Shouldn't have opened a new one. This duplicates MPOM-47. > Bump apache-source-release-assembly-descriptor to 1.0.5 > --- > > Key: MPOM-70 > URL: https://issues.apache.org/jira/browse/MPOM-70 > Project: Maven POMs > Issue Type: Task >Reporter: Christopher Tubbs > > apache-source-release-assembly-descriptor is currently set to version 1.0.4 > in the maven-assembly-plugin's configuration in the apache-release profile. > It should be bumped to 1.0.5 to support tarball-only generation (MASFRES-9). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MPOM-70) Bump apache-source-release-assembly-descriptor to 1.0.5
Christopher Tubbs created MPOM-70: - Summary: Bump apache-source-release-assembly-descriptor to 1.0.5 Key: MPOM-70 URL: https://issues.apache.org/jira/browse/MPOM-70 Project: Maven POMs Issue Type: Task Reporter: Christopher Tubbs Fix For: ASF-17 apache-source-release-assembly-descriptor is currently set to version 1.0.4 in the maven-assembly-plugin's configuration in the apache-release profile. It should be bumped to 1.0.5 to support tarball-only generation (MASFRES-9). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MJAVADOC-418) References from Test Javadoc to Main Javadoc Broken
[
https://jira.codehaus.org/browse/MJAVADOC-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=363712#comment-363712
]
Brett Okken commented on MJAVADOC-418:
--
Does it work if you use the fully qualified class name in the link? I seem to
recall seeing that behavior in previous versions.
> References from Test Javadoc to Main Javadoc Broken
> ---
>
> Key: MJAVADOC-418
> URL: https://jira.codehaus.org/browse/MJAVADOC-418
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: Shelley Baker
> Attachments: MJAVADOC-418.zip
>
>
> Javadoc references from the test javadoc to the main source javadoc are no
> longer able to be found. This is a regression between 2.10 and 2.10.1.
> For example, the following {{@link}} worked in 2.10, but no longer works in
> 2.10.1:
> {code:java}
> package org.apache.maven.test;
> /**
> * Foo.
> */
> public class Foo {}
> {code}
> {code:java}
> package org.apache.maven.test;
> /**
> * Tests {@link Foo}.
> */
> public class FooTest {}
> {code}
> {noformat}
> [WARNING]
> /home/user/test-project/src/test/java/org/apache/maven/test/FooTest.java:6:
> warning - Tag @link: reference not found: Foo
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1145) Surfire test listener disregards final counter adjustments
WarGoth created SUREFIRE-1145: - Summary: Surfire test listener disregards final counter adjustments Key: SUREFIRE-1145 URL: https://jira.codehaus.org/browse/SUREFIRE-1145 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.18.1 Reporter: WarGoth I have testng tests with retry analizer the way it's described here: http://seleniumeasy.com/testng-tutorials/execute-only-failed-test-cases-using-iretryanalyzer I also have a test listener which adjusts final test results respecting retrials the way it's described here: http://stackoverflow.com/a/18374673/331212 Maven surfire plugin fails anyway since it has its own test listener which maintains its own counters and disregards final results. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5772) upgrade to sisu 0.3.0 and sisu guice 3.2.5
[ https://jira.codehaus.org/browse/MNG-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5772. --- Resolution: Fixed Fix Version/s: 3.2.6 Assignee: Igor Fedorenko https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bdb4c32ec4acd734d1e385731ae2f67e8ed0d4ac > upgrade to sisu 0.3.0 and sisu guice 3.2.5 > -- > > Key: MNG-5772 > URL: https://jira.codehaus.org/browse/MNG-5772 > Project: Maven > Issue Type: Improvement >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.2.6 > > > just to keep dependencies current -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5772) upgrade to sisu 0.3.0 and sisu guice 3.2.5
Igor Fedorenko created MNG-5772: --- Summary: upgrade to sisu 0.3.0 and sisu guice 3.2.5 Key: MNG-5772 URL: https://jira.codehaus.org/browse/MNG-5772 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko just to keep dependencies current -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko closed MNG-5771.
---
Resolution: Fixed
reading extension exported packages and artifacts from
META-INF/maven/extension.xml descriptor
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8631d79ca3b2f08a610196ac04a7b7cde4832c4a
loading user-defined core extensions from
${maven.projectBasedir}/.mvn/extensions.xml
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6efacdb3fc5e8369fa3586c0603184dc785303da
> user-configurable core extensions mechanism
> ---
>
> Key: MNG-5771
> URL: https://jira.codehaus.org/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.2.6
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> $M2_HOME/lib/ext directory. It is also possible to specify component jars
> using -Dmaven.ext.class.path command line parameter. Neither of the
> mechanisms is user friendly. In both cases the user is expected to manually
> locate and download all required jar file. In both cases this has to be done
> on all systems where the extensions are needed. In both cases all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
> specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-159) encoding when filtering resources
[ https://jira.codehaus.org/browse/MEAR-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Kaigorodov updated MEAR-159: - Attachment: maven-ear-plugin-2.10-test-project-resources-encoding.zip An updated sample attached. > encoding when filtering resources > - > > Key: MEAR-159 > URL: https://jira.codehaus.org/browse/MEAR-159 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Alex Kaigorodov > Fix For: waiting-for-feedback > > Attachments: > maven-ear-plugin-2.10-test-project-resources-encoding.zip, > maven-ear-plugin-test-project-resources-encoding.zip > > > Resources of our ear project contain non-ascii characters. This xml-files in > windows-1251. We use filtering resources when building ear. > Building in the dev environment (Windows, file.encoding = Cp1251) goes well. > The build at the CI-server (Linux, file.encoding = UTF-8) non-ascii > characters in xml-files are replaced with a sequence of bytes 'efbfbd'. > It would be convenient to be able to specify the encoding for the ear > resources, similar to how we can do it in the maven-resources-plugin. > Sample project attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-159) encoding when filtering resources
[ https://jira.codehaus.org/browse/MEAR-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=363695#comment-363695 ] Alex Kaigorodov commented on MEAR-159: -- Yes, the problem is reproduced with 2.10 > encoding when filtering resources > - > > Key: MEAR-159 > URL: https://jira.codehaus.org/browse/MEAR-159 > Project: Maven Ear Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Alex Kaigorodov > Fix For: waiting-for-feedback > > Attachments: maven-ear-plugin-test-project-resources-encoding.zip > > > Resources of our ear project contain non-ascii characters. This xml-files in > windows-1251. We use filtering resources when building ear. > Building in the dev environment (Windows, file.encoding = Cp1251) goes well. > The build at the CI-server (Linux, file.encoding = UTF-8) non-ascii > characters in xml-files are replaced with a sequence of bytes 'efbfbd'. > It would be convenient to be able to specify the encoding for the ear > resources, similar to how we can do it in the maven-resources-plugin. > Sample project attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko reassigned MNG-5771:
---
Assignee: Igor Fedorenko
> user-configurable core extensions mechanism
> ---
>
> Key: MNG-5771
> URL: https://jira.codehaus.org/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.2.6
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> $M2_HOME/lib/ext directory. It is also possible to specify component jars
> using -Dmaven.ext.class.path command line parameter. Neither of the
> mechanisms is user friendly. In both cases the user is expected to manually
> locate and download all required jar file. In both cases this has to be done
> on all systems where the extensions are needed. In both cases all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
> specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko updated MNG-5771:
Fix Version/s: 3.2.6
> user-configurable core extensions mechanism
> ---
>
> Key: MNG-5771
> URL: https://jira.codehaus.org/browse/MNG-5771
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Reporter: Igor Fedorenko
> Fix For: 3.2.6
>
>
> As of version 3.2.5 maven provides two mechanisms to contribute additional
> components to maven core runtime. It is possible to add component jars to
> $M2_HOME/lib/ext directory. It is also possible to specify component jars
> using -Dmaven.ext.class.path command line parameter. Neither of the
> mechanisms is user friendly. In both cases the user is expected to manually
> locate and download all required jar file. In both cases this has to be done
> on all systems where the extensions are needed. In both cases all extra jars
> are loaded into single classloader so all extensions must agree of the same
> set of dependencies.
> This jira is to track changes needed to make it possible to configure core
> extensions in terms of groupId/artifactId/version and share set of required
> extensions across multiple systems.
> More specifically,
> * introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
> specify list of extensions. Initially, the descriptor will only allow
> specification of extension groupId/artifactId/version, but can be extended to
> support dependency includes/excludes mechanism and configuration parameters
> later
> {code}
>
>
>
> ...
> ...
> ...
>
> ...
> ...
>
> {code}
> * change maven to read and load core extensions in separate class realms as
> part of plexus container setup.
> * provide mechanism for extensions to declare exported artifacts and packages
> using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
Igor Fedorenko created MNG-5771:
---
Summary: user-configurable core extensions mechanism
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
$M2_HOME/lib/ext directory. It is also possible to specify component jars using
-Dmaven.ext.class.path command line parameter. Neither of the mechanisms is
user friendly. In both cases the user is expected to manually locate and
download all required jar file. In both cases this has to be done on all
systems where the extensions are needed. In both cases all extra jars are
loaded into single classloader so all extensions must agree of the same set of
dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code}
...
...
...
...
...
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5767) project-specific default jvm options and command line parameters
[ https://jira.codehaus.org/browse/MNG-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5767. --- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8ed9a1caa8890773b45c6c408a4e40acf4f4b0fd > project-specific default jvm options and command line parameters > > > Key: MNG-5767 > URL: https://jira.codehaus.org/browse/MNG-5767 > Project: Maven > Issue Type: Improvement >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.2.6 > > > Some of the projects builds I work on require special jvm options, like > minimal -Xmx value, and specific command line parameters, like --builder. > Currently, I have to manually configure these every time run the build, which > is rather annoying and error prone. This manual configuration also makes it > harder for new or external developers to build the projects and many simply > give up trying after "mvn package" does not work from the first try. > This enhancement request proposes to introduce two new optional configuration > files .mvn/jvm.config and .mvn/maven.config, located at the base directory of > project source tree. If present, these files will provide default jvm and > maven options. Because these files are part of the project source tree, they > will be present in all project checkouts and will be automatically used every > time the project is build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5768) specify execution-id for direct plugin goal invocation from command line
[ https://jira.codehaus.org/browse/MNG-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5768. --- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=ee7dbab69dd87d219031b0715105527cdbf12639 > specify execution-id for direct plugin goal invocation from command line > > > Key: MNG-5768 > URL: https://jira.codehaus.org/browse/MNG-5768 > Project: Maven > Issue Type: Improvement >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.2.6 > > > When invoking plugin goal from command line, it is possible to configure the > goal using special 'default-cli' pom.xml execution id. This has two obvious > limitations. First, it is not possible to have more than one configuration > for command line use. Second, it is not possible to share configuration > between direct plugin invocation and execution bound to lifecycle phase. > To address this, I propose to extend direct plugin invocation syntax to allow > optional @execution-id parameter, e.g., > org.apache.maven.plugins:maven-remote-resources-plugin:1.0:process@executionId. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-330) conflict with commons-beanutils, commons-collections, commons-logging
Brandenberger Juerg created MPIR-330: Summary: conflict with commons-beanutils, commons-collections, commons-logging Key: MPIR-330 URL: https://jira.codehaus.org/browse/MPIR-330 Project: Maven Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.8 Environment: Win7, maven 2.3.5, running mvn site for EE6 i.e. Websphere 8.5.5 Reporter: Brandenberger Juerg Attachments: dependency-convergence.html On changing to version 2.8 conflicts with the mentioned modules happens. The modules are used by tomahawk21.jar, which inturn is required for file-upload with jsf 2.1. See attachment. switching back to version 2.7 no error and 100% convergence is signaled. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-479) Find duplicate properties
chibbe ... created MDEP-479: --- Summary: Find duplicate properties Key: MDEP-479 URL: https://jira.codehaus.org/browse/MDEP-479 Project: Maven Dependency Plugin Issue Type: New Feature Reporter: chibbe ... Would be good if a used property duplicated properties can be found as well. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-792) ClearCase Provider and Changelog Plugin- Revision is null
[
https://jira.codehaus.org/browse/SCM-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bohn updated SCM-792:
Description:
{{ClearCaseChangeLogConsumer#processGetRevision}}
The revision is only set to the currentChangeSet, not the currentFile (line
219) (it should only be set to currentFile, because cleartool lshistory output
is file based)
{{org.apache.maven.scm.ChangeSet#toXml}}
The revision is only read from the ChangeFile entries (line 536)
So an entry in changlog.xml has revision set to null:
{noformat}
2015-02-13
08:33:56
src\main\resources\xyz
null
{noformat}
was:
ClearCaseChangeLogConsumer#processGetRevision
The revision is only set to the currentChangeSet, not the currentFile (line 219)
org.apache.maven.scm.ChangeSet#toXml
The revision is only read from the ChangeFile entries (line 536)
So an entry in changlog.xml has revision set to null:
{noformat}
2015-02-13
08:33:56
src\main\resources\xyz
null
{noformat}
> ClearCase Provider and Changelog Plugin- Revision is null
> --
>
> Key: SCM-792
> URL: https://jira.codehaus.org/browse/SCM-792
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.9.2
>Reporter: Stefan Bohn
>
> {{ClearCaseChangeLogConsumer#processGetRevision}}
> The revision is only set to the currentChangeSet, not the currentFile (line
> 219) (it should only be set to currentFile, because cleartool lshistory
> output is file based)
> {{org.apache.maven.scm.ChangeSet#toXml}}
> The revision is only read from the ChangeFile entries (line 536)
> So an entry in changlog.xml has revision set to null:
> {noformat}
>
> 2015-02-13
> 08:33:56
>
>
> src\main\resources\xyz
> null
>
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-792) ClearCase Provider and Changelog Plugin- Revision is null
Stefan Bohn created SCM-792:
---
Summary: ClearCase Provider and Changelog Plugin- Revision is null
Key: SCM-792
URL: https://jira.codehaus.org/browse/SCM-792
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-clearcase
Affects Versions: 1.9.2
Reporter: Stefan Bohn
ClearCaseChangeLogConsumer#processGetRevision
The revision is only set to the currentChangeSet, not the currentFile (line 219)
org.apache.maven.scm.ChangeSet#toXml
The revision is only read from the ChangeFile entries (line 536)
So an entry in changlog.xml has revision set to null:
{noformat}
2015-02-13
08:33:56
src\main\resources\xyz
null
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5770) mvn can't find Oracle jdk8 on mac
Weizhi Yao created MNG-5770: --- Summary: mvn can't find Oracle jdk8 on mac Key: MNG-5770 URL: https://jira.codehaus.org/browse/MNG-5770 Project: Maven Issue Type: Bug Components: Command Line Affects Versions: 3.2.5 Environment: macos x 10.10.2 Oracle jdk8 Reporter: Weizhi Yao Line 85 export JAVA_HOME=/usr/libexec/java_home should be changed to export JAVA_HOME=`/usr/libexec/java_home` -- This message was sent by Atlassian JIRA (v6.1.6#6162)
