[jira] (SCM-747) [PERFORCE] Support SSL
[ https://jira.codehaus.org/browse/SCM-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-747: - Fix Version/s: 1.10 > [PERFORCE] Support SSL > -- > > Key: SCM-747 > URL: https://jira.codehaus.org/browse/SCM-747 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-perforce >Affects Versions: 1.9 >Reporter: Dan Tran > Fix For: 1.10 > > > P4PORT is now support ssl via ssl:host:port. We need to get perforce > provider to accept this format -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-747) [PERFORCE] Support SSL
[ https://jira.codehaus.org/browse/SCM-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-747: - Summary: [PERFORCE] Support SSL (was: Support SSL) > [PERFORCE] Support SSL > -- > > Key: SCM-747 > URL: https://jira.codehaus.org/browse/SCM-747 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-perforce >Affects Versions: 1.9 >Reporter: Dan Tran > > P4PORT is now support ssl via ssl:host:port. We need to get perforce > provider to accept this format -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-747) Support SSL
Dan Tran created SCM-747: Summary: Support SSL Key: SCM-747 URL: https://jira.codehaus.org/browse/SCM-747 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-perforce Affects Versions: 1.9 Reporter: Dan Tran P4PORT is now support ssl via ssl:host:port. We need to get perforce provider to accept this format -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345163#comment-345163
]
Diwaker Gupta commented on MCHECKSTYLE-225:
---
OK so one difference in my setup is that the checkstyle config is specified in
the top-level pom (via pluginManagement) instead of the submodule pom (e.g. in
the integration test instead of in core/pom.xml it should have been in
top-level pom.xml).
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>Assignee: Robert Scholte
> Fix For: 2.12.1
>
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345162#comment-345162
]
Diwaker Gupta commented on MCHECKSTYLE-225:
---
[~rfsholte] apologies; I did get the email updates but verifying the fix wasn't
on top of my priority list. I will check the integration test and update.
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>Assignee: Robert Scholte
> Fix For: 2.12.1
>
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-179) deployAtEnd bypassed in case of pluginRepository definition
Ryan Parrish created MDEPLOY-179:
Summary: deployAtEnd bypassed in case of pluginRepository
definition
Key: MDEPLOY-179
URL: https://jira.codehaus.org/browse/MDEPLOY-179
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.8.1, 2.9
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 05:51:28-0800)
Java version: 1.7.0_45, vendor: Oracle Corporation
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Ryan Parrish
Priority: Minor
h2. Summary
If there is a pluginRepository defined in the POM, and the deployAtEnd
configuration is true, the actual repo deployment at the end of the build is
skipped.
Expectation is that the repo deployment at the end of the build would work
regardless of pluginRepository configuration.
h2. Steps
# In the
[trunk/2.9-SNAPSHOT|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin]
project, run {{mvn deploy}} the deploy-at-end-pass integration test. The
deploy happens successfully at the end of the build.
# Add a pluginRepository definition to deploy-at-end-pass/pom.xml, such as
{code}
central
Maven Plugin Repository
http://repo1.maven.org/maven2
default
{code}
# Re-run the {{mvn deploy}}. Observe that the deploy to repo is not performed.
h2. Workaround
Define the pluginRepositories in settings.xml, not in the current POM lineage.
The deployAtEnd works as expected in this case.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINSTALL-105) deployAtEnd bypassed in case of pluginRepository definition
[
https://jira.codehaus.org/browse/MINSTALL-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Parrish closed MINSTALL-105.
-
Resolution: Not A Bug
Intended to clone and move to MDEPLOY, but I cannot move it.
> deployAtEnd bypassed in case of pluginRepository definition
> ---
>
> Key: MINSTALL-105
> URL: https://jira.codehaus.org/browse/MINSTALL-105
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 2.5, 2.6
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 05:51:28-0800)
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Ryan Parrish
>Priority: Minor
>
> h2. Summary
> If there is a pluginRepository defined in the POM, and the installAtEnd
> configuration is true, the actual local repo installation at the end of the
> build is skipped.
> Expectation is that the local repo installation at the end of the build would
> work regardless of pluginRepository configuration.
> h2. Steps
> # In the
> [trunk/2.6-SNAPSHOT|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin]
> project, run {{mvn install}} the install-at-end-pass integration test. The
> install happens successfully at the end of the build (see console output
> attached).
> # Add a pluginRepository definition to install-at-end-pass/pom.xml, such as
> {code}
>
>
> central
> Maven Plugin Repository
> http://repo1.maven.org/maven2
> default
>
>
> {code}
> # Re-run the {{mvn install}}. Observe that the install to local repo is not
> performed (see attached install-at-end-pass_withpluginrepo.txt console
> output).
> h2. Workaround
> Define the pluginRepositories in settings.xml, not in the current POM
> lineage. The installAtEnd works as expected in this case.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINSTALL-105) deployAtEnd bypassed in case of pluginRepository definition
Ryan Parrish created MINSTALL-105:
-
Summary: deployAtEnd bypassed in case of pluginRepository
definition
Key: MINSTALL-105
URL: https://jira.codehaus.org/browse/MINSTALL-105
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.5, 2.6
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 05:51:28-0800)
Java version: 1.7.0_45, vendor: Oracle Corporation
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Ryan Parrish
Priority: Minor
h2. Summary
If there is a pluginRepository defined in the POM, and the installAtEnd
configuration is true, the actual local repo installation at the end of the
build is skipped.
Expectation is that the local repo installation at the end of the build would
work regardless of pluginRepository configuration.
h2. Steps
# In the
[trunk/2.6-SNAPSHOT|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin]
project, run {{mvn install}} the install-at-end-pass integration test. The
install happens successfully at the end of the build (see console output
attached).
# Add a pluginRepository definition to install-at-end-pass/pom.xml, such as
{code}
central
Maven Plugin Repository
http://repo1.maven.org/maven2
default
{code}
# Re-run the {{mvn install}}. Observe that the install to local repo is not
performed (see attached install-at-end-pass_withpluginrepo.txt console output).
h2. Workaround
Define the pluginRepositories in settings.xml, not in the current POM lineage.
The installAtEnd works as expected in this case.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINSTALL-104) installAtEnd bypassed in case of pluginRepository definition
Ryan Parrish created MINSTALL-104:
-
Summary: installAtEnd bypassed in case of pluginRepository
definition
Key: MINSTALL-104
URL: https://jira.codehaus.org/browse/MINSTALL-104
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 2.5, 2.6
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 05:51:28-0800)
Java version: 1.7.0_45, vendor: Oracle Corporation
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Ryan Parrish
Priority: Minor
Attachments: install-at-end-pass_original.txt,
install-at-end-pass_withpluginrepo.txt
h2. Summary
If there is a pluginRepository defined in the POM, and the installAtEnd
configuration is true, the actual local repo installation at the end of the
build is skipped.
Expectation is that the local repo installation at the end of the build would
work regardless of pluginRepository configuration.
h2. Steps
# In the
[trunk/2.6-SNAPSHOT|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin]
project, run {{mvn install}} the install-at-end-pass integration test. The
install happens successfully at the end of the build (see console output
attached).
# Add a pluginRepository definition to install-at-end-pass/pom.xml, such as
{code}
central
Maven Plugin Repository
http://repo1.maven.org/maven2
default
{code}
# Re-run the {{mvn install}}. Observe that the install to local repo is not
performed (see attached install-at-end-pass_withpluginrepo.txt console output).
h2. Workaround
Define the pluginRepositories in settings.xml, not in the current POM lineage.
The installAtEnd works as expected in this case.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-387) Handle JDK8 -Xdoclint
[
https://jira.codehaus.org/browse/MJAVADOC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345159#comment-345159
]
Stephen Colebourne commented on MJAVADOC-387:
-
Based on observation, the real issue seems to be trying to get a build to work
in both JDK 8 and earlier JDKs. IIUC, the -X flag is not accepted by earlier
javadocs, so the only approach is the tedious and non-helpful fixing of Javadoc
to Oracle's artificial standards.
> Handle JDK8 -Xdoclint
> -
>
> Key: MJAVADOC-387
> URL: https://jira.codehaus.org/browse/MJAVADOC-387
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Reporter: Stephen Colebourne
>
> The Oracle team have added the doclint tool to JDK 8. The tool validates
> Javadoc as part of a standard Javadoc run. Unfortunately, with the default
> settings, it rejects many HTML elements that are perfectly acceptable to
> browsers, and all invalid Javadoc references (@links). This is likely to
> prove very unpopular with developers.
> Action needed:
> 1) Provide a maven-javadoc-plugin configuration item and property that can
> control the doclint tool (currently this requires using additionalparam
> AFAICT).
> 2) Apply the {{-Xdoclint:none}} option by default, so that doclint is opt-in,
> not opt-out (ie. fix Oracle's messed up default). This will also make it much
> easier for developers to handle migration to JDK 8.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
[
https://jira.codehaus.org/browse/MJAVADOC-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-395:
--
Patch Submitted: Yes
> Add JDK8 support to maven-javadoc-plugin
>
>
> Key: MJAVADOC-395
> URL: https://jira.codehaus.org/browse/MJAVADOC-395
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: MJAVADOC-395.patch
>
>
> The {{maven-javadoc-plugin}} plugin needs some additional minor work to
> ensure that it can recognize when it is running in a 1.8 JDK environment.
> For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}}
> needs to be updated appropriately, as does the {{getDefaultJavadocApiLink()}}
> method.
> Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
> {{src/main/resources}} to enable existing tests to pass.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
[
https://jira.codehaus.org/browse/MJAVADOC-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-395:
--
Attachment: MJAVADOC-395.patch
Submitted a patch file (from the root of the {{maven-javadoc-plugin}} source
tree using {{diff -runP}}) that incorporates the changes necessary to include
javadoc 8 support.
> Add JDK8 support to maven-javadoc-plugin
>
>
> Key: MJAVADOC-395
> URL: https://jira.codehaus.org/browse/MJAVADOC-395
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: MJAVADOC-395.patch
>
>
> The {{maven-javadoc-plugin}} plugin needs some additional minor work to
> ensure that it can recognize when it is running in a 1.8 JDK environment.
> For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}}
> needs to be updated appropriately, as does the {{getDefaultJavadocApiLink()}}
> method.
> Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
> {{src/main/resources}} to enable existing tests to pass.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
[
https://jira.codehaus.org/browse/MJAVADOC-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-395:
--
Description:
The {{maven-javadoc-plugin}} plugin needs some additional minor work to ensure
that it can recognize when it is running in a 1.8 JDK environment.
For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}} needs
to be updated appropriately, as does the {{getDefaultJavadocApiLink()}} method.
Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
{{src/main/resources}} to enable existing tests to pass.
Patch forthcoming.
was:
The {{maven-javadoc-plugin}} plugin needs some additional minor work to ensure
that it can recognize when it is running in a 1.8 JDK environment.
For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}} needs
to be updated appropriately, as does the {{getDefaultJavadocApiLink()}} method.
Patch forthcoming.
> Add JDK8 support to maven-javadoc-plugin
>
>
> Key: MJAVADOC-395
> URL: https://jira.codehaus.org/browse/MJAVADOC-395
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
>
> The {{maven-javadoc-plugin}} plugin needs some additional minor work to
> ensure that it can recognize when it is running in a 1.8 JDK environment.
> For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}}
> needs to be updated appropriately, as does the {{getDefaultJavadocApiLink()}}
> method.
> Additionally, the JDK 1.8 {{package-list}} file needs to be saved to
> {{src/main/resources}} to enable existing tests to pass.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8
[
https://jira.codehaus.org/browse/MJAVADOC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-393:
--
Patch Submitted: Yes
> -link option values have their trailing slash removed; breaks javadoc 8
> ---
>
> Key: MJAVADOC-393
> URL: https://jira.codehaus.org/browse/MJAVADOC-393
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.MJAVADOC-393.patch
>
>
> The version of {{javadoc}} that ships with Java 8 has changed such that any
> value supplied to the {{-link}} option must have a trailing slash (at least
> on my Mac).
> Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the
> trailing slashes from the {{links}} property elements, ensuring that
> {{javadoc}} version 8 cannot process its {{-link}} options properly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8
[
https://jira.codehaus.org/browse/MJAVADOC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-393:
--
Attachment: AbstractJavadocMojo.java.MJAVADOC-393.patch
Submitted a patch correcting the trailing-slash-stripping behavior now that
javadoc 1.8 no longer deals properly with non-slash-terminated {{-link}}
options.
> -link option values have their trailing slash removed; breaks javadoc 8
> ---
>
> Key: MJAVADOC-393
> URL: https://jira.codehaus.org/browse/MJAVADOC-393
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.MJAVADOC-393.patch
>
>
> The version of {{javadoc}} that ships with Java 8 has changed such that any
> value supplied to the {{-link}} option must have a trailing slash (at least
> on my Mac).
> Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the
> trailing slashes from the {{links}} property elements, ensuring that
> {{javadoc}} version 8 cannot process its {{-link}} options properly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-395) Add JDK8 support to maven-javadoc-plugin
Laird Nelson created MJAVADOC-395:
-
Summary: Add JDK8 support to maven-javadoc-plugin
Key: MJAVADOC-395
URL: https://jira.codehaus.org/browse/MJAVADOC-395
Project: Maven Javadoc Plugin
Issue Type: Improvement
Affects Versions: 2.9.1
Reporter: Laird Nelson
The {{maven-javadoc-plugin}} plugin needs some additional minor work to ensure
that it can recognize when it is running in a 1.8 JDK environment.
For example, in {{AbstractJavadocMojo.java}}, {{DEFAULT_JAVA_API_LINKS}} needs
to be updated appropriately, as does the {{getDefaultJavadocApiLink()}} method.
Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
[
https://jira.codehaus.org/browse/MJAVADOC-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345156#comment-345156
]
Laird Nelson commented on MJAVADOC-394:
---
For completeness, a workaround without changing code is to define the following
in your {{$HOME/.mavenrc}} file (on OSX only, obviously):
{code:lang=none}
export JAVA_HOME=`/usr/libexec/java_home`
{code}
> javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
> -
>
> Key: MJAVADOC-394
> URL: https://jira.codehaus.org/browse/MJAVADOC-394
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Mac OSX, JDK 1.7+
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.patch
>
>
> The logic to detect where the {{javadoc}} script is located is not correct
> for Oracle's JVM 1.7 and higher on Mac OSX.
> The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
> running on OSX (line 3534):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> But as of JDK 1.7 as distributed by Oracle, the default "else" block should
> apply here (line 3538):
> {code:title=AbstractJavadocMojo.java}
> else
> {
> javadocExe =
> new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> }
> {code}
> The solution might be to modify line 3534 as follows (or perhaps also check
> for Oracle's vendor string as well--anyway, you get the idea):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT
> < 1.7f )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
[
https://jira.codehaus.org/browse/MJAVADOC-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-394:
--
Description:
The logic to detect where the {{javadoc}} script is located is not correct for
Oracle's JVM 1.7 and higher on Mac OSX.
The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
running on OSX (line 3534):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
But as of JDK 1.7 as distributed by Oracle, the default "else" block should
apply here (line 3538):
{code:title=AbstractJavadocMojo.java}
else
{
javadocExe =
new File( SystemUtils.getJavaHome() + File.separator + ".." +
File.separator + "bin", javadocCommand );
}
{code}
The solution might be to modify line 3534 as follows (or perhaps also check for
Oracle's vendor string as well--anyway, you get the idea):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT <
1.7f )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
Patch forthcoming.
was:
The logic to detect where the {{javadoc}} script is located is not correct for
Oracle's JVM 1.7 and higher on Mac OSX.
The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
running on OSX (line 3534):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
But as of JDK 1.7 as distributed by Oracle, the default "else" block should
apply here (line 3538):
{code:title=AbstractJavadocMojo.java}
else
{
javadocExe =
new File( SystemUtils.getJavaHome() + File.separator + ".." +
File.separator + "bin", javadocCommand );
}
{code}
The solution might be to modify line 3534 as follows (or perhaps also check for
Oracle's vendor string as wellâanyway, you get the idea):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT <
1.7f )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
Patch forthcoming.
Patch Submitted: Yes
> javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
> -
>
> Key: MJAVADOC-394
> URL: https://jira.codehaus.org/browse/MJAVADOC-394
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Mac OSX, JDK 1.7+
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.patch
>
>
> The logic to detect where the {{javadoc}} script is located is not correct
> for Oracle's JVM 1.7 and higher on Mac OSX.
> The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
> running on OSX (line 3534):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> But as of JDK 1.7 as distributed by Oracle, the default "else" block should
> apply here (line 3538):
> {code:title=AbstractJavadocMojo.java}
> else
> {
> javadocExe =
> new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> }
> {code}
> The solution might be to modify line 3534 as follows (or perhaps also check
> for Oracle's vendor string as well--anyway, you get the idea):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT
> < 1.7f )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
[
https://jira.codehaus.org/browse/MJAVADOC-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laird Nelson updated MJAVADOC-394:
--
Attachment: AbstractJavadocMojo.java.patch
Submitted a patch file ensuring that the proper default resolution of the
{{javadoc}} script occurs on Mac OSX.
> javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
> -
>
> Key: MJAVADOC-394
> URL: https://jira.codehaus.org/browse/MJAVADOC-394
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Mac OSX, JDK 1.7+
>Reporter: Laird Nelson
> Attachments: AbstractJavadocMojo.java.patch
>
>
> The logic to detect where the {{javadoc}} script is located is not correct
> for Oracle's JVM 1.7 and higher on Mac OSX.
> The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
> running on OSX (line 3534):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> But as of JDK 1.7 as distributed by Oracle, the default "else" block should
> apply here (line 3538):
> {code:title=AbstractJavadocMojo.java}
> else
> {
> javadocExe =
> new File( SystemUtils.getJavaHome() + File.separator + ".." +
> File.separator + "bin", javadocCommand );
> }
> {code}
> The solution might be to modify line 3534 as follows (or perhaps also check
> for Oracle's vendor string as wellâanyway, you get the idea):
> {code:title=AbstractJavadocMojo.java}
> else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT
> < 1.7f )
> {
> javadocExe = new File( SystemUtils.getJavaHome() + File.separator
> + "bin", javadocCommand );
> }
> {code}
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-394) javadoc is not found properly by default under Oracle's JDK 7+ on Mac OSX
Laird Nelson created MJAVADOC-394:
-
Summary: javadoc is not found properly by default under Oracle's
JDK 7+ on Mac OSX
Key: MJAVADOC-394
URL: https://jira.codehaus.org/browse/MJAVADOC-394
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Mac OSX, JDK 1.7+
Reporter: Laird Nelson
The logic to detect where the {{javadoc}} script is located is not correct for
Oracle's JVM 1.7 and higher on Mac OSX.
The logic inside of {{AbstractJavadocMojo}} currently special-cases all JVMs
running on OSX (line 3534):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
But as of JDK 1.7 as distributed by Oracle, the default "else" block should
apply here (line 3538):
{code:title=AbstractJavadocMojo.java}
else
{
javadocExe =
new File( SystemUtils.getJavaHome() + File.separator + ".." +
File.separator + "bin", javadocCommand );
}
{code}
The solution might be to modify line 3534 as follows (or perhaps also check for
Oracle's vendor string as wellâanyway, you get the idea):
{code:title=AbstractJavadocMojo.java}
else if ( SystemUtils.IS_OS_MAC_OSX && SystemUtils.JAVA_VERSION_FLOAT <
1.7f )
{
javadocExe = new File( SystemUtils.getJavaHome() + File.separator +
"bin", javadocCommand );
}
{code}
Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345152#comment-345152
]
Robert Scholte commented on MCHECKSTYLE-225:
It would have nice if you had tested this once it was marked as resolved. Also,
[~dennislundberg] has added an integration-test which should reflect your
usecase:
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/it/MCHECKSTYLE-225-customHeader/
I'm wondering what's the difference.
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>Assignee: Robert Scholte
> Fix For: 2.12.1
>
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-225) headerLocation no longer sets checkstyle.header.file
[
https://jira.codehaus.org/browse/MCHECKSTYLE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345151#comment-345151
]
Diwaker Gupta commented on MCHECKSTYLE-225:
---
FYI I see the exact same error and failure with checkstyle 2.12.1
> headerLocation no longer sets checkstyle.header.file
>
>
> Key: MCHECKSTYLE-225
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-225
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: JDK 7u51 on OS X with Maven 3.1.0
>Reporter: Diwaker Gupta
>Assignee: Robert Scholte
> Fix For: 2.12.1
>
>
> We use a multi-module configuration as described at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
> This morning I tried upgraded to checkstyle-plugin 2.12 and our builds
> started failing with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.12:check (default-cli) on
> project common: Failed during checkstyle execution: Failed during checkstyle
> configuration: unable to read /path/to/common/target/checkstyle-checker.xml -
> unable to parse configuration stream - Property ${checkstyle.header.file} has
> not been set -> [Help 1]
> {noformat}
> Our config hasn't changed in almost two years. We are currently using v2.11
> so this seems like a regression in 2.12
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIA-490) Add line breaks in generated output
[ https://jira.codehaus.org/browse/DOXIA-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIA-490. --- Resolution: Duplicate Assignee: Herve Boutemy > Add line breaks in generated output > --- > > Key: DOXIA-490 > URL: https://jira.codehaus.org/browse/DOXIA-490 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Apt >Reporter: SebbASF >Assignee: Herve Boutemy > > The generated output from APT can have some extremely long lines (e.g. over > 20K characters). This makes it very difficult to review, and if the output is > checked into a CMS the commit messages are all but useless. > Ideally the output should be broken into smaller chunks. > For example, adding a new line before and after , similarly with > . > There are other possible approaches, such as folding lines that are longer > than say 200 characters (though of course this won't work for blocks) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIATOOLS-45) An incomplete fix for the resource leak bugs in LatexBookRenderer.java
[
https://jira.codehaus.org/browse/DOXIATOOLS-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy moved DOXIA-461 to DOXIATOOLS-45:
---
Component/s: (was: Module - Latex)
Doxia Book Renderer
Key: DOXIATOOLS-45 (was: DOXIA-461)
Project: Maven Doxia Tools (was: Maven Doxia)
> An incomplete fix for the resource leak bugs in LatexBookRenderer.java
> --
>
> Key: DOXIATOOLS-45
> URL: https://jira.codehaus.org/browse/DOXIATOOLS-45
> Project: Maven Doxia Tools
> Issue Type: Bug
> Components: Doxia Book Renderer
>Reporter: Guangtai Liang
>Priority: Critical
>
> The fix revision 740164 was aimed to remove resource leak bugs on the
> FileWriter object "writer"(created in line 204) and the FileReader object
> "reader" (created in line 219) in the method "writeSection()"of the file "
> /maven/doxia/doxia/trunk/doxia-book/src/main/java/org/apache/maven/doxia/book/services/renderer/LatexBookRenderer.java"
> , but it is incomplete.
> There are some problems:
> 1. the LatexBookSink object "sink" is not closed.
> 2. when the statements at lines 206-215 throw some exception, "writer" will
> be leaked.
> The best way to close such resource objects is putting such close operations
> for all resource objects in the finaly block of a try-catch-finally structure.
> Although a later fix (rev1003021) try to close "sink", the problems still
> exists in the head revision. The buggy code is copied as bellows ("sink" and
> "writer" will be leaked when the statements at lines 202-207 throw some
> exception):
> {code}
>private SectionInfo writeSection( Section section, BookContext context )
> throws IOException, BookDoxiaException
> {
> File file = new File( context.getOutputDirectory(), ( section.getId()
> + ".tex" ) );
> 198Writer writer = WriterFactory.newWriter( file,
> context.getOutputEncoding() );
> 200LatexBookSink sink = new LatexBookSink( writer );
> BookContext.BookFile bookFile = (BookContext.BookFile)
> context.getFiles().get( section.getId() );
> if ( bookFile == null )
> {
> throw new BookDoxiaException( "No document that matches section
> with id="
> + section.getId() + "." );
> }
> Reader reader = null;
> try
> {
> reader = ReaderFactory.newReader( bookFile.getFile(),
> context.getInputEncoding() );
> doxia.parse( reader, bookFile.getParserId(), sink );
> }
> catch ( ParserNotFoundException e )
> {
> throw new BookDoxiaException( "Parser not found: "
> + bookFile.getParserId() + ".", e );
> }
> catch ( ParseException e )
> {
> throw new BookDoxiaException( "Error while parsing document: "
> + bookFile.getFile().getAbsolutePath() + ".", e );
> }
> catch ( FileNotFoundException e )
> {
> throw new BookDoxiaException( "Could not find document: "
> + bookFile.getFile().getAbsolutePath() + ".", e );
> }
> finally
> {
> 233sink.flush();
> 234sink.close();
> 236IOUtil.close( reader );
> 237IOUtil.close( writer );
> }
> SectionInfo info = new SectionInfo();
> info.id = section.getId();
> info.title = sink.getTitle();
> return info;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-330) add StringUtils.endsWithIgnoreCase()
[ https://jira.codehaus.org/browse/MSHARED-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHARED-330. - Resolution: Fixed Fix Version/s: maven-shared-utils-0.7 Assignee: Herve Boutemy done in [r1588924|http://svn.apache.org/r1588924] > add StringUtils.endsWithIgnoreCase() > > > Key: MSHARED-330 > URL: https://jira.codehaus.org/browse/MSHARED-330 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.6 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: maven-shared-utils-0.7 > > > case insensitive can be tricky (with turkish i), so having this convenience > method here could really help -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-330) add StringUtils.endsWithIgnoreCase()
Herve Boutemy created MSHARED-330: - Summary: add StringUtils.endsWithIgnoreCase() Key: MSHARED-330 URL: https://jira.codehaus.org/browse/MSHARED-330 Project: Maven Shared Components Issue Type: New Feature Components: maven-shared-utils Affects Versions: maven-shared-utils-0.6 Reporter: Herve Boutemy case insensitive can be tricky (with turkish i), so having this convenience method here could really help -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-443) dependency tree should be the same when using verbose or not
[
https://jira.codehaus.org/browse/MDEP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MDEP-443.
--
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Herve Boutemy
documentation updated and warning added in
[r1588916|http://svn.apache.org/r1588916]
> dependency tree should be the same when using verbose or not
>
>
> Key: MDEP-443
> URL: https://jira.codehaus.org/browse/MDEP-443
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: tree
>Reporter: Cintia DR
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 2.9
>
>
> When running dependency tree (version 2.8) using maven 3, the generated tree
> is consistent with what maven is using.
> If you enable -Dverbose, I have a [maven 2 dependency
> tree|https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution]:
> {code}
> if ( verbose )
> {
> // verbose mode force Maven 2 dependency tree component use
> dependencyTreeString =
> serializeVerboseDependencyTree(
> dependencyTreeBuilder.buildDependencyTree( project,
>
> localRepository,
>
> artifactFilter ) );
> }
> else
> {
> // non-verbose mode use dependency graph component, which
> gives consistent results with Maven version
> // running
> rootNode = dependencyGraphBuilder.buildDependencyGraph(
> project, artifactFilter );
> dependencyTreeString = serializeDependencyTree( rootNode );
> }
> {code}
> It's very misleading. Even the
> [documentation|http://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#verbose]
> doesn't mention it.
> Probably there's a good reason to not use Aether for the verbose mode, but I
> guess at least it should print a warning at the end of the process and
> explicitly say it in the documentation.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-443) dependency tree should be the same when using verbose or not
[
https://jira.codehaus.org/browse/MDEP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy moved MSHARED-329 to MDEP-443:
Component/s: (was: maven-dependency-tree)
tree
Key: MDEP-443 (was: MSHARED-329)
Project: Maven Dependency Plugin (was: Maven Shared Components)
> dependency tree should be the same when using verbose or not
>
>
> Key: MDEP-443
> URL: https://jira.codehaus.org/browse/MDEP-443
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: tree
>Reporter: Cintia DR
>Priority: Minor
>
> When running dependency tree (version 2.8) using maven 3, the generated tree
> is consistent with what maven is using.
> If you enable -Dverbose, I have a [maven 2 dependency
> tree|https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution]:
> {code}
> if ( verbose )
> {
> // verbose mode force Maven 2 dependency tree component use
> dependencyTreeString =
> serializeVerboseDependencyTree(
> dependencyTreeBuilder.buildDependencyTree( project,
>
> localRepository,
>
> artifactFilter ) );
> }
> else
> {
> // non-verbose mode use dependency graph component, which
> gives consistent results with Maven version
> // running
> rootNode = dependencyGraphBuilder.buildDependencyGraph(
> project, artifactFilter );
> dependencyTreeString = serializeDependencyTree( rootNode );
> }
> {code}
> It's very misleading. Even the
> [documentation|http://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#verbose]
> doesn't mention it.
> Probably there's a good reason to not use Aether for the verbose mode, but I
> guess at least it should print a warning at the end of the process and
> explicitly say it in the documentation.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-696) Internal Regexp Error with Windows Paths
[
https://jira.codehaus.org/browse/MASSEMBLY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345135#comment-345135
]
Kenney Westerhof edited comment on MASSEMBLY-696 at 4/21/14 8:52 AM:
-
I'm referencing old code because the bug has been in there that long.
I don't understand your question. What do you need the revision for? And what
revision exactly?
The patch will work against any revision after 1073964, when that line of code
was introduced (svn blame/praise/annotate/ann). -And {{trunk}} is a symbolic
name referencing the latest revision in any subversion repository-
{color:grey}my bad, I should have said {{HEAD}}{color} (1588817 at the time of
this writing); I was being sarcastic, my apologies, this doesn't always come
across on digital media!
Also, it's really not necessary to make an integration test for this one. It's
the _unit_ tests for that code that are incomplete as they only check Unix
style pathnames, while the code explicitly attempts to deal with windows style
paths aswell.
In any case, I've concocted an integration test as per your request.
It took me quite a while to figure out what exactly triggers this code. It
occurs when specifying {{true}} dependencies and either
specifying a non-default value for {{}} or {{}}. I
added some debug to the assembly plugin, and it breaks when {{fixRelativeRefs}}
is called with {{.\log4j-1.2.17.jar/}}. That this doesn't happen more often is
because most code calling {{fixRelativeRefs}} duplicates code from that method
(i.e. stripping {{./}}, {{../}} etc).
was (Author: kenneyw):
I'm referencing old code because the bug has been in there that long.
I don't understand your question. What do you need the revision for? And what
revision exactly?
The patch will work against any revision after 1073964, when that line of code
was introduced (svn blame/praise/annotate/ann). And {{trunk}} is a symbolic
name referencing the latest revision in any subversion repository (1588817 at
the time of this writing); I was being sarcastic, my apologies, this doesn't
always come across on digital media!
Also, it's really not necessary to make an integration test for this one. It's
the _unit_ tests for that code that are incomplete as they only check Unix
style pathnames, while the code explicitly attempts to deal with windows style
paths aswell.
In any case, I've concocted an integration test as per your request.
It took me quite a while to figure out what exactly triggers this code. It
occurs when specifying {{true}} dependencies and either
specifying a non-default value for {{}} or {{}}. I
added some debug to the assembly plugin, and it breaks when {{fixRelativeRefs}}
is called with {{.\log4j-1.2.17.jar/}}. That this doesn't happen more often is
because most code calling {{fixRelativeRefs}} duplicates code from that method
(i.e. stripping {{./}}, {{../}} etc).
I've never had to do so much work to simply add {{\\}} to an obviously broken
line of code! ;-) I could have commited the fix in svn this myself, but since
I've not been involved in the project recently I though it wise to be polite
and follow the proper channels.
> Internal Regexp Error with Windows Paths
>
>
> Key: MASSEMBLY-696
> URL: https://jira.codehaus.org/browse/MASSEMBLY-696
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Windows 7
> maven-assembly-plugin trunk@e785abb
>Reporter: Kenney Westerhof
> Attachments: MASSEMBLY-696.patch, MASSEMBLY-696.tar.gz
>
>
> On windows the Assembly plugin shows this error:
> {code}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single
> (default-cli) on project myproject: Execution default-cli of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.5-SNAPSHOT:single failed:
> Unexpected internal error near index 1
> \
> ^
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
>
> Caused by: java.util.regex.PatternSyntaxException: Unexpected internal error
> near index 1
> \
> ^
> at java.util.regex.Pattern.error(Pattern.java:1924)
> at java.util.regex.Pattern.compile(Pattern.java:1671)
> at java.util.regex.Pattern.(Pattern.java:1337)
> at java.util.regex.Pattern.compile(Pattern.java:1022)
> at java.lang.String.split(String.java:2313)
> at java.lang.String.split(String.java:2355)
> at
> org.apache.maven.plugin.assembly.utils.AssemblyFormatUtils.fixRelativeRefs(AssemblyFormatUtils.java:509)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
