[jira] [Created] (MSHADE-239) Shaded Source JAR not following finalName pattern
Diego Rivera created MSHADE-239:
---
Summary: Shaded Source JAR not following finalName pattern
Key: MSHADE-239
URL: https://issues.apache.org/jira/browse/MSHADE-239
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.4.3
Reporter: Diego Rivera
When enabling the and configurations,
while also using a custom naming scheme in , the sources JAR is
named incorrectly.
For instance, given the following configuration:
{code}
${project.artifactId}-${project.version}-${some-other-crap}-exe
true
true
true
exe
{code}
The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
while the source jar is named artifact-version-exe-sources.jar (note the
missing "-crapola", from the variable ${some-other-crap} in ). The
correct name should be artifact-version-crapola-exe-sources.jar (i.e.
${finalName}-sources.jar).
As a side note: it might be a good idea to enable the use of a
${shadedClassifierName} variable that can be referenced and interpolated within
the evaluation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHADE-239) Shaded Source JAR not following finalName pattern
[
https://issues.apache.org/jira/browse/MSHADE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated MSHADE-239:
Description:
When enabling the and configurations,
while also using a custom naming scheme in , the sources JAR is
named incorrectly.
For instance, given the following configuration:
{code}
${project.artifactId}-${project.version}-${some-other-crap}-exe
true
true
true
exe
{code}
The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
while the source jar is named artifact-version-exe-sources.jar (note the
missing "-crapola", from the variable $\{some-other-crap\} in ). The
correct name should be artifact-version-crapola-exe-sources.jar (i.e.
$\{finalName\}-sources.jar).
As a side note: it might be a good idea to enable the use of a
$\{shadedClassifierName\} variable that can be referenced and interpolated
within the evaluation.
was:
When enabling the and configurations,
while also using a custom naming scheme in , the sources JAR is
named incorrectly.
For instance, given the following configuration:
{code}
${project.artifactId}-${project.version}-${some-other-crap}-exe
true
true
true
exe
{code}
The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
while the source jar is named artifact-version-exe-sources.jar (note the
missing "-crapola", from the variable ${some-other-crap} in ). The
correct name should be artifact-version-crapola-exe-sources.jar (i.e.
${finalName}-sources.jar).
As a side note: it might be a good idea to enable the use of a
${shadedClassifierName} variable that can be referenced and interpolated within
the evaluation.
> Shaded Source JAR not following finalName pattern
> -
>
> Key: MSHADE-239
> URL: https://issues.apache.org/jira/browse/MSHADE-239
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Diego Rivera
>
> When enabling the and
> configurations, while also using a custom naming scheme in , the
> sources JAR is named incorrectly.
> For instance, given the following configuration:
> {code}
>
>
> ${project.artifactId}-${project.version}-${some-other-crap}-exe
> true
> true
> true
> exe
>
> {code}
> The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
> while the source jar is named artifact-version-exe-sources.jar (note the
> missing "-crapola", from the variable $\{some-other-crap\} in ).
> The correct name should be artifact-version-crapola-exe-sources.jar (i.e.
> $\{finalName\}-sources.jar).
> As a side note: it might be a good idea to enable the use of a
> $\{shadedClassifierName\} variable that can be referenced and interpolated
> within the evaluation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHADE-239) Shaded Source JAR not following finalName pattern
[
https://issues.apache.org/jira/browse/MSHADE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated MSHADE-239:
Attachment: source-jar-name.patch
Patch file for applying the same value to the sources JAR.
> Shaded Source JAR not following finalName pattern
> -
>
> Key: MSHADE-239
> URL: https://issues.apache.org/jira/browse/MSHADE-239
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Diego Rivera
> Attachments: source-jar-name.patch
>
>
> When enabling the and
> configurations, while also using a custom naming scheme in , the
> sources JAR is named incorrectly.
> For instance, given the following configuration:
> {code}
>
>
> ${project.artifactId}-${project.version}-${some-other-crap}-exe
> true
> true
> true
> exe
>
> {code}
> The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
> while the source jar is named artifact-version-exe-sources.jar (note the
> missing "-crapola", from the variable $\{some-other-crap\} in ).
> The correct name should be artifact-version-crapola-exe-sources.jar (i.e.
> $\{finalName\}-sources.jar).
> As a side note: it might be a good idea to enable the use of a
> $\{shadedClassifierName\} variable that can be referenced and interpolated
> within the evaluation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHADE-239) Shaded Source JAR not following finalName pattern
[
https://issues.apache.org/jira/browse/MSHADE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated MSHADE-239:
Attachment: (was: source-jar-name.patch)
> Shaded Source JAR not following finalName pattern
> -
>
> Key: MSHADE-239
> URL: https://issues.apache.org/jira/browse/MSHADE-239
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Diego Rivera
>
> When enabling the and
> configurations, while also using a custom naming scheme in , the
> sources JAR is named incorrectly.
> For instance, given the following configuration:
> {code}
>
>
> ${project.artifactId}-${project.version}-${some-other-crap}-exe
> true
> true
> true
> exe
>
> {code}
> The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
> while the source jar is named artifact-version-exe-sources.jar (note the
> missing "-crapola", from the variable $\{some-other-crap\} in ).
> The correct name should be artifact-version-crapola-exe-sources.jar (i.e.
> $\{finalName\}-sources.jar).
> As a side note: it might be a good idea to enable the use of a
> $\{shadedClassifierName\} variable that can be referenced and interpolated
> within the evaluation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MSHADE-239) Shaded Source JAR not following finalName pattern
[
https://issues.apache.org/jira/browse/MSHADE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated MSHADE-239:
Comment: was deleted
(was: Patch file for applying the same value to the sources JAR.)
> Shaded Source JAR not following finalName pattern
> -
>
> Key: MSHADE-239
> URL: https://issues.apache.org/jira/browse/MSHADE-239
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Diego Rivera
>
> When enabling the and
> configurations, while also using a custom naming scheme in , the
> sources JAR is named incorrectly.
> For instance, given the following configuration:
> {code}
>
>
> ${project.artifactId}-${project.version}-${some-other-crap}-exe
> true
> true
> true
> exe
>
> {code}
> The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
> while the source jar is named artifact-version-exe-sources.jar (note the
> missing "-crapola", from the variable $\{some-other-crap\} in ).
> The correct name should be artifact-version-crapola-exe-sources.jar (i.e.
> $\{finalName\}-sources.jar).
> As a side note: it might be a good idea to enable the use of a
> $\{shadedClassifierName\} variable that can be referenced and interpolated
> within the evaluation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSHADE-239) Shaded Source JAR not following finalName pattern
[
https://issues.apache.org/jira/browse/MSHADE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated MSHADE-239:
Attachment: source-jar-name.patch
Patch file for applying the same value to the sources and tests
shaded JARs.
> Shaded Source JAR not following finalName pattern
> -
>
> Key: MSHADE-239
> URL: https://issues.apache.org/jira/browse/MSHADE-239
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Diego Rivera
> Attachments: source-jar-name.patch
>
>
> When enabling the and
> configurations, while also using a custom naming scheme in , the
> sources JAR is named incorrectly.
> For instance, given the following configuration:
> {code}
>
>
> ${project.artifactId}-${project.version}-${some-other-crap}-exe
> true
> true
> true
> exe
>
> {code}
> The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
> while the source jar is named artifact-version-exe-sources.jar (note the
> missing "-crapola", from the variable $\{some-other-crap\} in ).
> The correct name should be artifact-version-crapola-exe-sources.jar (i.e.
> $\{finalName\}-sources.jar).
> As a side note: it might be a good idea to enable the use of a
> $\{shadedClassifierName\} variable that can be referenced and interpolated
> within the evaluation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSHADE-244) Avoid file copy and replacement when source and target files are the same file
Diego Rivera created MSHADE-244: --- Summary: Avoid file copy and replacement when source and target files are the same file Key: MSHADE-244 URL: https://issues.apache.org/jira/browse/MSHADE-244 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 2.4.3 Reporter: Diego Rivera Priority: Blocker When Shade::replaceFile() is invoked, and the source and target are the same, no work should be performed since this can result in an attempt at copying the same file upon itself, and the target will end up as a 0-byte file. Instead, the proposed patch (attached) adds a check to perform a best-attempt intercept of that condition and avoid any unnecessary work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHADE-244) Avoid file copy and replacement when source and target files are the same file
[ https://issues.apache.org/jira/browse/MSHADE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diego Rivera updated MSHADE-244: Attachment: shade.no-replace.patch Patch against version 2.4.3 (with another non-overlapping patch applied, so line numbers may not match) exactly > Avoid file copy and replacement when source and target files are the same file > -- > > Key: MSHADE-244 > URL: https://issues.apache.org/jira/browse/MSHADE-244 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Diego Rivera >Priority: Blocker > Attachments: shade.no-replace.patch > > > When Shade::replaceFile() is invoked, and the source and target are the same, > no work should be performed since this can result in an attempt at copying > the same file upon itself, and the target will end up as a 0-byte file. > Instead, the proposed patch (attached) adds a check to perform a best-attempt > intercept of that condition and avoid any unnecessary work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHADE-239) Shaded Source JAR not following finalName pattern
[
https://issues.apache.org/jira/browse/MSHADE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera updated MSHADE-239:
Priority: Blocker (was: Major)
> Shaded Source JAR not following finalName pattern
> -
>
> Key: MSHADE-239
> URL: https://issues.apache.org/jira/browse/MSHADE-239
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Diego Rivera
>Priority: Blocker
> Attachments: source-jar-name.patch
>
>
> When enabling the and
> configurations, while also using a custom naming scheme in , the
> sources JAR is named incorrectly.
> For instance, given the following configuration:
> {code}
>
>
> ${project.artifactId}-${project.version}-${some-other-crap}-exe
> true
> true
> true
> exe
>
> {code}
> The shaded artifact is appropriately named artifact-version-crapola-exe.jar,
> while the source jar is named artifact-version-exe-sources.jar (note the
> missing "-crapola", from the variable $\{some-other-crap\} in ).
> The correct name should be artifact-version-crapola-exe-sources.jar (i.e.
> $\{finalName\}-sources.jar).
> As a side note: it might be a good idea to enable the use of a
> $\{shadedClassifierName\} variable that can be referenced and interpolated
> within the evaluation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-244) Avoid file copy and replacement when source and target files are the same file
[
https://issues.apache.org/jira/browse/MSHADE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828563#comment-15828563
]
Diego Rivera commented on MSHADE-244:
-
Sure. This happens when one uses a configuration similar to the one below:
{code}
${project.artifactId}-${project.version}${build.number}-exe
true
true
false
true
exe
{code}
Thus, at some point the plugin will try to copy the produced file onto itself.
The patch works regardless by comparing the source and target files in the
invocation and if they're the same file, then it skips the copy altogether.
> Avoid file copy and replacement when source and target files are the same file
> --
>
> Key: MSHADE-244
> URL: https://issues.apache.org/jira/browse/MSHADE-244
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.3
>Reporter: Diego Rivera
>Priority: Blocker
> Attachments: shade.no-replace.patch
>
>
> When Shade::replaceFile() is invoked, and the source and target are the same,
> no work should be performed since this can result in an attempt at copying
> the same file upon itself, and the target will end up as a 0-byte file.
> Instead, the proposed patch (attached) adds a check to perform a best-attempt
> intercept of that condition and avoid any unnecessary work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-244) Avoid file copy and replacement when source and target files are the same file
[ https://issues.apache.org/jira/browse/MSHADE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828652#comment-15828652 ] Diego Rivera commented on MSHADE-244: - It may well be. I'm on Linux. The code simply checks to see if the source file and the target file are the same in the invocation to replaceFile(). If they're the same, no copy is made to avoid clobbering (i.e. a 0-length file). The rest of the patch is support code to help eliminate the possibility of mismatches (or false-matches) by ensuring each file is addressed by their canonical name (i.e. any symlinks or relative paths resolved, etc). > Avoid file copy and replacement when source and target files are the same file > -- > > Key: MSHADE-244 > URL: https://issues.apache.org/jira/browse/MSHADE-244 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Diego Rivera >Priority: Blocker > Attachments: shade.no-replace.patch > > > When Shade::replaceFile() is invoked, and the source and target are the same, > no work should be performed since this can result in an attempt at copying > the same file upon itself, and the target will end up as a 0-byte file. > Instead, the proposed patch (attached) adds a check to perform a best-attempt > intercept of that condition and avoid any unnecessary work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MSHADE-244) Avoid file copy and replacement when source and target files are the same file
[ https://issues.apache.org/jira/browse/MSHADE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828652#comment-15828652 ] Diego Rivera edited comment on MSHADE-244 at 1/18/17 7:44 PM: -- It may well be. I'm on Linux. The code simply checks to see if the source file and the target file are the same in the invocation to replaceFile(). If they're the same, no copy is made to avoid clobbering (i.e. a 0-length file). The rest of the patch is support code to help eliminate the possibility of false-positives (or false-negatives) by ensuring each file is addressed by their canonical name (i.e. any symlinks or relative paths resolved, etc). was (Author: diego.rivera...@gmail.com): It may well be. I'm on Linux. The code simply checks to see if the source file and the target file are the same in the invocation to replaceFile(). If they're the same, no copy is made to avoid clobbering (i.e. a 0-length file). The rest of the patch is support code to help eliminate the possibility of mismatches (or false-matches) by ensuring each file is addressed by their canonical name (i.e. any symlinks or relative paths resolved, etc). > Avoid file copy and replacement when source and target files are the same file > -- > > Key: MSHADE-244 > URL: https://issues.apache.org/jira/browse/MSHADE-244 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Diego Rivera >Priority: Blocker > Attachments: shade.no-replace.patch > > > When Shade::replaceFile() is invoked, and the source and target are the same, > no work should be performed since this can result in an attempt at copying > the same file upon itself, and the target will end up as a 0-byte file. > Instead, the proposed patch (attached) adds a check to perform a best-attempt > intercept of that condition and avoid any unnecessary work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSHADE-244) Avoid file copy and replacement when source and target files are the same file
[ https://issues.apache.org/jira/browse/MSHADE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830072#comment-15830072 ] Diego Rivera commented on MSHADE-244: - I understand your point, and I agree. However, the given configuration *should* have reproduced the error (on Linux). I'll test it again later today and validate the conditions under which this can happen. I do remember this was a source of frustration until I came up with this patch. Cheers. > Avoid file copy and replacement when source and target files are the same file > -- > > Key: MSHADE-244 > URL: https://issues.apache.org/jira/browse/MSHADE-244 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Diego Rivera >Priority: Blocker > Attachments: MSHADE-244_selfReplace.patch, shade.no-replace.patch > > > When Shade::replaceFile() is invoked, and the source and target are the same, > no work should be performed since this can result in an attempt at copying > the same file upon itself, and the target will end up as a 0-byte file. > Instead, the proposed patch (attached) adds a check to perform a best-attempt > intercept of that condition and avoid any unnecessary work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MCHANGES-327) JIRA session is not properly established using jiraUsername and jiraPassword
Diego Rivera created MCHANGES-327: - Summary: JIRA session is not properly established using jiraUsername and jiraPassword Key: MCHANGES-327 URL: https://jira.codehaus.org/browse/MCHANGES-327 Project: Maven Changes Plugin Issue Type: Bug Components: jira Affects Versions: 2.9 Reporter: Diego Rivera When using jiraUser and jiraPassword for authentication (in lieu of webUser and webPassword), the session cookie is not preserved in order to maintain the session authentication information for subsequent REST requests. This means that although authentication succeeds, subsequent REST requests don't benefit from the long-running session that was established. The JSESSIONID cookie value needs to be captured from the original auth request and preserved throughout all other REST invocations. Using webUser and webPassword works, though, so at least that workaround is there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-327) JIRA session is not properly established using jiraUser and jiraPassword
[ https://jira.codehaus.org/browse/MCHANGES-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diego Rivera updated MCHANGES-327: -- Summary: JIRA session is not properly established using jiraUser and jiraPassword (was: JIRA session is not properly established using jiraUsername and jiraPassword) > JIRA session is not properly established using jiraUser and jiraPassword > > > Key: MCHANGES-327 > URL: https://jira.codehaus.org/browse/MCHANGES-327 > Project: Maven Changes Plugin > Issue Type: Bug > Components: jira >Affects Versions: 2.9 >Reporter: Diego Rivera > > When using jiraUser and jiraPassword for authentication (in lieu of webUser > and webPassword), the session cookie is not preserved in order to maintain > the session authentication information for subsequent REST requests. > This means that although authentication succeeds, subsequent REST requests > don't benefit from the long-running session that was established. > The JSESSIONID cookie value needs to be captured from the original auth > request and preserved throughout all other REST invocations. > Using webUser and webPassword works, though, so at least that workaround is > there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
