[jira] (MASSEMBLY-665) OS dependent behaviour while packaging
Jörg Sesterhenn created MASSEMBLY-665: - Summary: OS dependent behaviour while packaging Key: MASSEMBLY-665 URL: https://jira.codehaus.org/browse/MASSEMBLY-665 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: sles 11 / windows 7 Reporter: Jörg Sesterhenn Given this part of a assembly descriptor: src/main/script bin true * /src/main/conf conf * Under windows 7 this packages everything as (I) expected: src/ main/ conf/ script/ Under linux the package misses the directory 'conf': src/ main/ script/ Linux seems to interpret the directory as absolute path due to the leading slash. Please either - accept the above config and build the same package on any system, or - fail the build with an invalid descriptor error, or - (at least) log a warning that due to the config builds are depending on the OS. -- 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] (MASSEMBLY-665) OS dependent behaviour while packaging
[
https://jira.codehaus.org/browse/MASSEMBLY-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Sesterhenn updated MASSEMBLY-665:
--
Description:
Given this part of a assembly descriptor:
{code}
src/main/script
bin
true
*
/src/main/conf
conf
*
{code}
Under windows 7 this packages everything as (I) expected:
{code}
src/
main/
conf/
script/
{code}
Under linux the package misses the directory 'conf':
{code}
src/
main/
script/
{code}
Linux seems to interpret the directory as absolute path due to the leading
slash.
Please either
* accept the above config and build the same package on any system, or
* fail the build with an invalid descriptor error, or
* (at least) log a warning that due to the config builds are depending on the
OS.
was:
Given this part of a assembly descriptor:
src/main/script
bin
true
*
/src/main/conf
conf
*
Under windows 7 this packages everything as (I) expected:
src/
main/
conf/
script/
Under linux the package misses the directory 'conf':
src/
main/
script/
Linux seems to interpret the directory as absolute path due to the leading
slash.
Please either
- accept the above config and build the same package on any system, or
- fail the build with an invalid descriptor error, or
- (at least) log a warning that due to the config builds are depending on the
OS.
> OS dependent behaviour while packaging
> --
>
> Key: MASSEMBLY-665
> URL: https://jira.codehaus.org/browse/MASSEMBLY-665
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: sles 11 / windows 7
>Reporter: Jörg Sesterhenn
>
> Given this part of a assembly descriptor:
> {code}
>
>
> src/main/script
> bin
> true
>
> *
>
>
>
> /src/main/conf
> conf
>
> *
>
>
>
> {code}
> Under windows 7 this packages everything as (I) expected:
> {code}
> src/
> main/
> conf/
> script/
> {code}
>
> Under linux the package misses the directory 'conf':
> {code}
> src/
> main/
> script/
> {code}
> Linux seems to interpret the directory as absolute path due to the leading
> slash.
> Please either
> * accept the above config and build the same package on any system, or
> * fail the build with an invalid descriptor error, or
> * (at least) log a warning that due to the config builds are depending on the
> OS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[
https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332845#comment-332845
]
Robert Munteanu commented on MRELEASE-431:
--
[~rfscholte] - thanks for the info, I just wanted to know if you'd like any
changes made in the short term. I fully agree that - being published API - we
need to get it right the first time.
{quote} Another thing on my mind: should the API support methods to make it a
major, minor or bugversion increase, or leave that up to the
implementation{quote}
I guess we could, but maybe as part of another utility class, to keep the
VersionPolicyManager API clean. Not sure if that needs to be API though, or we
could simply provide it as a convenience for implementors.
> Configuration of policy for calculating next (release) version
> --
>
> Key: MRELEASE-431
> URL: https://jira.codehaus.org/browse/MRELEASE-431
> Project: Maven Release Plugin
> Issue Type: New Feature
> Components: prepare
>Affects Versions: 2.0-beta-8
>Reporter: Carsten Ziegeler
>Assignee: Robert Scholte
> Fix For: 2.5
>
> Attachments:
> 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch,
> MRELEASE-431.patch, MRELEASE-431-v2.patch
>
>
> Currently, when preparing the release, the version to release is always the
> next version which usually is the current version without the snapshot
> extension.
> There are quiet a lot projects (Apache Felix, Sling and others) following an
> even release numbering policy. So while the current development version is
> odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4.
> It would be nice if this could be made configuration through some
> configuration property like
> next-even (with possible values being: next
> (default, as-is), next-even, next-odd
> I briefly scanned through the code and it seems that adding support for this
> requires changes in both, the release-manager and the release-plugin.
> If this feature gets accepted and if someone could give me some minor hints
> how/where to add this I could come up with a patch.
--
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] (MWAR-306) [regression] Filtering doesn't work if an lone @ is found a line to interpolate
Fred Bricon created MWAR-306:
Summary: [regression] Filtering doesn't work if an lone @ is found
a line to interpolate
Key: MWAR-306
URL: https://jira.codehaus.org/browse/MWAR-306
Project: Maven WAR Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.4
Reporter: Fred Bricon
Attachments: web-filtering.zip
If you try to filter a file containing say :
{quote} ${project.artifactId} @ ${project.version}{quote}
It'll be rendered as 'foo @ ${project.version}', when you expect 'foo @ 1.0.0'
This used to work in maven-war-plugin <= 2.3, so I suspect this is caused by
the upgrade to maven-filtering:1.1.
Note that this bug has affected filtering using maven-resource-plugin for quite
some time now, so the root cause is definitely somewhere in the filtering
component. Opening the bug here to keep track of the regression in m-w-p
--
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] (MWAR-306) [regression] Filtering doesn't work if a lone @ is found in a line to interpolate
[
https://jira.codehaus.org/browse/MWAR-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fred Bricon updated MWAR-306:
-
Summary: [regression] Filtering doesn't work if a lone @ is found in a line
to interpolate (was: [regression] Filtering doesn't work if a lone @ is found
a line to interpolate)
> [regression] Filtering doesn't work if a lone @ is found in a line to
> interpolate
> -
>
> Key: MWAR-306
> URL: https://jira.codehaus.org/browse/MWAR-306
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.4
>Reporter: Fred Bricon
> Attachments: web-filtering.zip
>
>
> If you try to filter a file containing say :
> {quote} ${project.artifactId} @ ${project.version}{quote}
> It'll be rendered as 'foo @ ${project.version}', when you expect 'foo @
> 1.0.0'
> This used to work in maven-war-plugin <= 2.3, so I suspect this is caused by
> the upgrade to maven-filtering:1.1.
> Note that this bug has affected filtering using maven-resource-plugin for
> quite some time now, so the root cause is definitely somewhere in the
> filtering component. Opening the bug here to keep track of the regression in
> m-w-p
--
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] (MWAR-306) [regression] Filtering doesn't work if a lone @ is found a line to interpolate
[
https://jira.codehaus.org/browse/MWAR-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fred Bricon updated MWAR-306:
-
Summary: [regression] Filtering doesn't work if a lone @ is found a line to
interpolate (was: [regression] Filtering doesn't work if an lone @ is found a
line to interpolate)
> [regression] Filtering doesn't work if a lone @ is found a line to interpolate
> --
>
> Key: MWAR-306
> URL: https://jira.codehaus.org/browse/MWAR-306
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.4
>Reporter: Fred Bricon
> Attachments: web-filtering.zip
>
>
> If you try to filter a file containing say :
> {quote} ${project.artifactId} @ ${project.version}{quote}
> It'll be rendered as 'foo @ ${project.version}', when you expect 'foo @
> 1.0.0'
> This used to work in maven-war-plugin <= 2.3, so I suspect this is caused by
> the upgrade to maven-filtering:1.1.
> Note that this bug has affected filtering using maven-resource-plugin for
> quite some time now, so the root cause is definitely somewhere in the
> filtering component. Opening the bug here to keep track of the regression in
> m-w-p
--
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] (MWAR-306) [regression] Filtering doesn't work if a lone @ is found in a line to interpolate
[
https://jira.codehaus.org/browse/MWAR-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fred Bricon updated MWAR-306:
-
Description:
If you try to filter a file containing say :
{quote}$\{project.artifactId\} @ $\{project.version\}{quote}
It'll be rendered as 'foo @ $\{project.version\}', when you expect 'foo @
1.0.0'
This used to work in maven-war-plugin <= 2.3, so I suspect this is caused by
the upgrade to maven-filtering:1.1.
Note that this bug has affected filtering using maven-resource-plugin for quite
some time now, so the root cause is definitely somewhere in the filtering
component. Opening the bug here to keep track of the regression in m-w-p
was:
If you try to filter a file containing say :
{quote} ${project.artifactId} @ ${project.version}{quote}
It'll be rendered as 'foo @ ${project.version}', when you expect 'foo @ 1.0.0'
This used to work in maven-war-plugin <= 2.3, so I suspect this is caused by
the upgrade to maven-filtering:1.1.
Note that this bug has affected filtering using maven-resource-plugin for quite
some time now, so the root cause is definitely somewhere in the filtering
component. Opening the bug here to keep track of the regression in m-w-p
> [regression] Filtering doesn't work if a lone @ is found in a line to
> interpolate
> -
>
> Key: MWAR-306
> URL: https://jira.codehaus.org/browse/MWAR-306
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.4
>Reporter: Fred Bricon
> Attachments: web-filtering.zip
>
>
> If you try to filter a file containing say :
> {quote}$\{project.artifactId\} @ $\{project.version\}{quote}
> It'll be rendered as 'foo @ $\{project.version\}', when you expect 'foo @
> 1.0.0'
> This used to work in maven-war-plugin <= 2.3, so I suspect this is caused by
> the upgrade to maven-filtering:1.1.
> Note that this bug has affected filtering using maven-resource-plugin for
> quite some time now, so the root cause is definitely somewhere in the
> filtering component. Opening the bug here to keep track of the regression in
> m-w-p
--
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] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
Benson Margulies created SUREFIRE-1034: -- Summary: dependencesToScan versus classifiers: what's the scoop? Key: SUREFIRE-1034 URL: https://jira.codehaus.org/browse/SUREFIRE-1034 Project: Maven Surefire Issue Type: Bug Reporter: Benson Margulies # The doc could really use an example of dependenciesToScan # The doc should tell me the syntax for using classifiers # if classifiers don't work, please make them work. -- 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] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reassigned SUREFIRE-1034: -- Assignee: Benson Margulies > dependencesToScan versus classifiers: what's the scoop? > --- > > Key: SUREFIRE-1034 > URL: https://jira.codehaus.org/browse/SUREFIRE-1034 > Project: Maven Surefire > Issue Type: Bug >Reporter: Benson Margulies >Assignee: Benson Margulies > > # The doc could really use an example of dependenciesToScan > # The doc should tell me the syntax for using classifiers > # if classifiers don't work, please make them work. -- 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] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed SUREFIRE-1034. -- Resolution: Fixed Fix Version/s: 2.17 I added more documentation. > dependencesToScan versus classifiers: what's the scoop? > --- > > Key: SUREFIRE-1034 > URL: https://jira.codehaus.org/browse/SUREFIRE-1034 > Project: Maven Surefire > Issue Type: Bug >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.17 > > > # The doc could really use an example of dependenciesToScan > # The doc should tell me the syntax for using classifiers > # if classifiers don't work, please make them work. -- 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] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reopened SUREFIRE-1034: > dependencesToScan versus classifiers: what's the scoop? > --- > > Key: SUREFIRE-1034 > URL: https://jira.codehaus.org/browse/SUREFIRE-1034 > Project: Maven Surefire > Issue Type: Bug >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.17 > > > # The doc could really use an example of dependenciesToScan > # The doc should tell me the syntax for using classifiers > # if classifiers don't work, please make them work. -- 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] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332861#comment-332861 ] Benson Margulies commented on SUREFIRE-1034: Classifiers are not supported, so that will need to be fixed. > dependencesToScan versus classifiers: what's the scoop? > --- > > Key: SUREFIRE-1034 > URL: https://jira.codehaus.org/browse/SUREFIRE-1034 > Project: Maven Surefire > Issue Type: Bug >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.17 > > > # The doc could really use an example of dependenciesToScan > # The doc should tell me the syntax for using classifiers > # if classifiers don't work, please make them work. -- 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] (SUREFIRE-1031) Temp files are not deleted properly
[
https://jira.codehaus.org/browse/SUREFIRE-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332875#comment-332875
]
Sergei Ivanov commented on SUREFIRE-1031:
-
I believe this issue is a root cause of temporary partition overfilling on our
Jenkins host.
Some of our projects contain hundreds of unit tests and they produce a lot of
output, which results in /tmp quickly filling up with files like
{{stdout9077800675661040491deferred}}.
For the time being, we had to set up a cron job to purge those files, but a
more robust implementation inside a plugin would be very welcome. Ideally, the
plugin must take responsibility for good housekeeping and remove the temporary
output files when they are no longer needed.
> Temp files are not deleted properly
> ---
>
> Key: SUREFIRE-1031
> URL: https://jira.codehaus.org/browse/SUREFIRE-1031
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.16
>Reporter: Vjatseslav Rosin
> Fix For: 2.17
>
>
> After the SUREFIRE-938 fix was introduced in version 2.15 there is a problem
> of two much temp files created in the temp folder. This is related to this
> issue in DeferredFileOutputStream of common-io:
> https://issues.apache.org/jira/browse/IO-397
> As a workaround it would be nice to have a configuration option for memory
> threshold size instead of hardcoded 1MB.
> Another solutions would be do delete the temp file explicitly (if it exists)
> before closing the DeferredFileOutputStream.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-431) Configuration of policy for calculating next (release) version
[
https://jira.codehaus.org/browse/MRELEASE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332878#comment-332878
]
Robert Scholte commented on MRELEASE-431:
-
It looks like we don't now yet if the arguments are complete. I think we can
expect more arguments. For that reason I'd like to introduce the
{{VersionPolicyRequest}} a simple pojo. This way the signatures of the manager
will always stay the same, we just add fields to this requestobject if we want.
> Configuration of policy for calculating next (release) version
> --
>
> Key: MRELEASE-431
> URL: https://jira.codehaus.org/browse/MRELEASE-431
> Project: Maven Release Plugin
> Issue Type: New Feature
> Components: prepare
>Affects Versions: 2.0-beta-8
>Reporter: Carsten Ziegeler
>Assignee: Robert Scholte
> Fix For: 2.5
>
> Attachments:
> 0001-MRELEASE-431-Configuration-of-policy-for-calculating.patch,
> MRELEASE-431.patch, MRELEASE-431-v2.patch
>
>
> Currently, when preparing the release, the version to release is always the
> next version which usually is the current version without the snapshot
> extension.
> There are quiet a lot projects (Apache Felix, Sling and others) following an
> even release numbering policy. So while the current development version is
> odd (like 1.2.3-SNAPSHOT), the next released version will be 1.2.4.
> It would be nice if this could be made configuration through some
> configuration property like
> next-even (with possible values being: next
> (default, as-is), next-even, next-odd
> I briefly scanned through the code and it seems that adding support for this
> requires changes in both, the release-manager and the release-plugin.
> If this feature gets accepted and if someone could give me some minor hints
> how/where to add this I could come up with a patch.
--
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] (SUREFIRE-1034) dependencesToScan versus classifiers: what's the scoop?
[ https://jira.codehaus.org/browse/SUREFIRE-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332881#comment-332881 ] Andreas Gudian commented on SUREFIRE-1034: -- See also SUREFIRE-1004. > dependencesToScan versus classifiers: what's the scoop? > --- > > Key: SUREFIRE-1034 > URL: https://jira.codehaus.org/browse/SUREFIRE-1034 > Project: Maven Surefire > Issue Type: Bug >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.17 > > > # The doc could really use an example of dependenciesToScan > # The doc should tell me the syntax for using classifiers > # if classifiers don't work, please make them work. -- 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] (MDEPLOY-167) Occasionally deploy fails "Failed to deploy metadata: Could not transfer metadata "
[
https://jira.codehaus.org/browse/MDEPLOY-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332887#comment-332887
]
Jigar Joshi commented on MDEPLOY-167:
-
not a deploy plugin issue, closing it
Going to assume that nexus web end point manages synchronization to write to
disk (until it fails again)
Thanks!
> Occasionally deploy fails "Failed to deploy metadata: Could not transfer
> metadata "
> ---
>
> Key: MDEPLOY-167
> URL: https://jira.codehaus.org/browse/MDEPLOY-167
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.7
> Environment: maven 3.1-SNAPSHOT at revision:1521204, nexus-2.6.2-01,
> jdk 1.6.37
>Reporter: Jigar Joshi
>Priority: Minor
>
> Maven deploy fails occasionally with following error message
> {code}
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to deploy
> metadata: Could not transfer metadata
> {code}
> - user has permission to connect to nexus with scp all the time
> - nexus is running all the time
> - nexus isn't running out of disk space
> According to this thread
> :http://mail-archives.apache.org/mod_mbox/maven-users/201101.mbox/%3c1294417752462-3332094.p...@n5.nabble.com%3E
> It could be related to legacy format of metadata, which could be the case,
> tried passing
> {code}
> -Dmaven.metadata.legacy=true
> {code}
> still it fails occasionally
> {code}
> Caused by: org.apache.maven.wagon.TransferFailedException: Error occurred
> while deploying '/maven-metadata.xml' to remote repository:
> scp:///home//sonatype-work/nexus/storage/snapshots:
> Unexpected end of data
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.handleIOException(ScpWagon.java:416)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.finishPutTransfer(ScpWagon.java:108)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:423)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:402)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:376)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
> build 13-Sep-2013 13:17:15at
> org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:811)
> build 13-Sep-2013 13:17:15... 22 more
> build 13-Sep-2013 13:17:15Caused by: java.io.IOException: Unexpected end
> of data
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.checkAck(ScpWagon.java:130)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.finishPutTransfer(ScpWagon.java:100)
> {code}
>
> (some of) other posts about this issue:
> -
> http://forums.jfrog.org/Maven-fails-to-deploy-occationally-Could-not-transfer-metadata-quot-Access-denied-to-quot-error-td6713183.html
> - http://mojo.10943.n7.nabble.com/Problem-to-release-perform-td40059.html
> I would be ready to provide more helpful information if required
--
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] (MDEPLOY-167) Occasionally deploy fails "Failed to deploy metadata: Could not transfer metadata "
[
https://jira.codehaus.org/browse/MDEPLOY-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-167.
--
Resolution: Not A Bug
Assignee: Robert Scholte
> Occasionally deploy fails "Failed to deploy metadata: Could not transfer
> metadata "
> ---
>
> Key: MDEPLOY-167
> URL: https://jira.codehaus.org/browse/MDEPLOY-167
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.7
> Environment: maven 3.1-SNAPSHOT at revision:1521204, nexus-2.6.2-01,
> jdk 1.6.37
>Reporter: Jigar Joshi
>Assignee: Robert Scholte
>Priority: Minor
>
> Maven deploy fails occasionally with following error message
> {code}
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to deploy
> metadata: Could not transfer metadata
> {code}
> - user has permission to connect to nexus with scp all the time
> - nexus is running all the time
> - nexus isn't running out of disk space
> According to this thread
> :http://mail-archives.apache.org/mod_mbox/maven-users/201101.mbox/%3c1294417752462-3332094.p...@n5.nabble.com%3E
> It could be related to legacy format of metadata, which could be the case,
> tried passing
> {code}
> -Dmaven.metadata.legacy=true
> {code}
> still it fails occasionally
> {code}
> Caused by: org.apache.maven.wagon.TransferFailedException: Error occurred
> while deploying '/maven-metadata.xml' to remote repository:
> scp:///home//sonatype-work/nexus/storage/snapshots:
> Unexpected end of data
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.handleIOException(ScpWagon.java:416)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.finishPutTransfer(ScpWagon.java:108)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:423)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:402)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:376)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
> build 13-Sep-2013 13:17:15at
> org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:811)
> build 13-Sep-2013 13:17:15... 22 more
> build 13-Sep-2013 13:17:15Caused by: java.io.IOException: Unexpected end
> of data
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.checkAck(ScpWagon.java:130)
> build 13-Sep-2013 13:17:15at
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon.finishPutTransfer(ScpWagon.java:100)
> {code}
>
> (some of) other posts about this issue:
> -
> http://forums.jfrog.org/Maven-fails-to-deploy-occationally-Could-not-transfer-metadata-quot-Access-denied-to-quot-error-td6713183.html
> - http://mojo.10943.n7.nabble.com/Problem-to-release-perform-td40059.html
> I would be ready to provide more helpful information if required
--
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] (MJAR-170) please add property 'maven.jar.classifier'
ryenus created MJAR-170:
---
Summary: please add property 'maven.jar.classifier'
Key: MJAR-170
URL: https://jira.codehaus.org/browse/MJAR-170
Project: Maven JAR Plugin
Issue Type: Improvement
Affects Versions: 2.4
Reporter: ryenus
For maven-source-plugin, adding a classifier to the source jar file name is as
simple as:
# setup property jdk6-sources
# setup the right version of Maven source plugin, e.g. version 2.2.1
And that's enough.
But to add a classifier to the binary jar file name, we must use the very
verbose way of configuring the maven-jar-plugin, as below:
{code:xml}
maven-jar-plugin
package
jar
jdk6
{code}
By adding support for the {{maven.jar.classifier}} property, it would be much
more straightforward and consistent.
--
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] (MJAVADOC-376) please add property 'maven.javadoc.classifier'
ryenus created MJAVADOC-376:
---
Summary: please add property 'maven.javadoc.classifier'
Key: MJAVADOC-376
URL: https://jira.codehaus.org/browse/MJAVADOC-376
Project: Maven Javadoc Plugin
Issue Type: Improvement
Reporter: ryenus
We need an easier way to customize the name of the generated javadoc jar file.
* For maven-jar-plugin, there's a {{classifier}} attribute.
* For maven-source-plugin, it's even better, there's a
{{maven.source.classifier}} property
But for maven-javadoc-plugin, there's NOTHING, I guess we have to use the
assembly plugin to do it.
By adding support for the {{maven.javadoc.classifier}} property, it would be
much more straightforward and consistent.
Thanks
--
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] (MDEP-430) Dependency plugin does not seem to respect profile specific copy goals
Kamaldeep Tumkur created MDEP-430: - Summary: Dependency plugin does not seem to respect profile specific copy goals Key: MDEP-430 URL: https://jira.codehaus.org/browse/MDEP-430 Project: Maven Dependency Plugin Issue Type: Bug Components: copy Affects Versions: 2.1 Environment: Mac OSX Mountain Lion 10.8.4 Reporter: Kamaldeep Tumkur I am using the dependency plugin inside a swf type project that builds using Maven. Ant is currently being used to copy the target files to the destination directories, but my hope is to use the dependency plugin so that everything is included inside the POM. Here's my rough POM structure:
[jira] (MSITE-697) Add ability to filter site resources
Dennis Lundberg created MSITE-697: - Summary: Add ability to filter site resources Key: MSITE-697 URL: https://jira.codehaus.org/browse/MSITE-697 Project: Maven Site Plugin Issue Type: New Feature Affects Versions: 3.3 Reporter: Dennis Lundberg It would be great if it was possible to filter the site resources, similar to how you can filter web resources in the WAR Plugin. This feature would need to be configurable and default to being off, for backwards compatibility. There should also be a configuration parameter for which file extensions should be excluded from the filtering process. That should have a good default value covering the standard image formats (gif, jpg and png) and also PDFs. -- 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
