[jira] (WAGON-388) remove wagon-http-shared4 dependency on httpclient
[ https://jira.codehaus.org/browse/WAGON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319828#comment-319828 ] Olivier Lamy commented on WAGON-388: @Hervé currently master doesn't use HtmlFileListParser with jsoup This one is in http-shared4 module. > remove wagon-http-shared4 dependency on httpclient > -- > > Key: WAGON-388 > URL: https://jira.codehaus.org/browse/WAGON-388 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.0, 2.4 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.5 > > > AbstractHttpClientWagon uses classes from > [HttpClient|http://hc.apache.org/httpcomponents-client-ga/httpclient/index.html] > Lightweight wagon extends AbstractHttpClientWagon but uses JRE java.net > classes > AbstractHttpClientWagon should not depend on httpclient: it can depend on > [HttpCore|http://hc.apache.org/httpcomponents-core-ga/index.html], if useful > to share some utilities between wagon-http and wagon-http-lightweight, but > not HttpClient > Such separation, possible now that HttpComponents has 2 separate layers, will > ease maintenance -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-384) Maven fails to download artifacts larger than 2 GB
[ https://jira.codehaus.org/browse/WAGON-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-384. -- Resolution: Fixed Fix Version/s: 2.5 Assignee: Olivier Lamy pr applied https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=88214c85 Thanks ! > Maven fails to download artifacts larger than 2 GB > -- > > Key: WAGON-384 > URL: https://jira.codehaus.org/browse/WAGON-384 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 2.2 > Environment: This issue is not dependent on the operating system and > hardware. >Reporter: Robert Baker >Assignee: Olivier Lamy > Fix For: 2.5 > > Attachments: AbstractWagon.java, AbstractWagon.java > > > If a Maven build includes a dependency for an artifact that is larger than 2 > GB in size, the download of the artifact during the build terminates at 2 GB > and the following error is reported by Maven: > [WARNING] Checksum validation failed, expected > 5b0fafa21f2b3e9c4e3b7ef3c5306f82bcb9fc85 but is > e9ef494d39de097b9a02531993688ceebdce39e1 > Maven repeats the download a second time with the same error result, then > build fails. > The failure is caused when the transfer method in AbstractWagon.java receives > maxSize parameter, which is an integer, set to Integer.MAX_VALUE, rather than > the actual size of the artifact. This value is then decremented to zero, > which causes the download to terminate prematurely. The attached file > (AbstractWagon.java) contains changes in the transfer method that use the > value Integer.MAX_VALUE as a trigger that causes the routine to ignore the > maxSize parameter's value and download the artifact until an EOF is detected, > regardless of its size. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-354) Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
[
https://jira.codehaus.org/browse/WAGON-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Koch updated WAGON-354:
---
Attachment: 0001-WAGON-354-Site-deployment-always-fails-with-StringIn.patch
I agree with Juergens analysis and conclusion that {{SftpWagon.putDirectory}}
should not fail if the {{destinationDirectory}} ends with a {{"/"}}. I've
attached a patch which changes {{ScpHelper.getResourceFilename}} to return a
{{"."}} instead of {{""}} if the resource path ends with a {{"/"}}. This fixes
the site deployment for me.
> Site deployment always fails with StringIndexOutOfBoundsException in SftpWagon
> --
>
> Key: WAGON-354
> URL: https://jira.codehaus.org/browse/WAGON-354
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
>Affects Versions: 1.0, 2.0
> Environment: Maven 3.0.3, Site-Plugin 3.0, Wagon 2.0
>Reporter: Juergen Kellerer
>Priority: Critical
> Fix For: backlog
>
> Attachments:
> 0001-WAGON-354-Site-deployment-always-fails-with-StringIn.patch
>
>
> I always get StringIndexOutOfBoundsException on the attempt to deploy a site
> with SFTP using Maven 3 + Site Plugin 3.
> Calling *"mvn site-deploy"* causes:
> {noformat}
> ...
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading
> site
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:464)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deploy(AbstractDeployMojo.java:296)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.deployTo(AbstractDeployMojo.java:257)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.execute(AbstractDeployMojo.java:165)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Error occurred
> while deploying 'c:\Projects\OS\doxia-include\target\site' to remo
> te repository:
> sftp://web.sourceforge.net/home/groups/d/do/doxia-include/htdocs/:
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:286)
> at
> org.apache.maven.plugins.site.AbstractDeployMojo.push(AbstractDeployMojo.java:447)
> ... 24 more
> Caused by: 4:
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1713)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.mkdir(SftpWagon.java:204)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.ftpRecursivePut(SftpWagon.java:300)
> at
> org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:277)
> ... 25 more
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: 0
> at java.lang.String.charAt(String.java:686)
> at
> com.jcraft.jsch.ChannelSftp.remoteAbsolutePath(ChannelSftp.java:2367)
> at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1691)
> ... 28 more
> {noformat}
> *The configuration is*:
> {code:xml}
>
> doxia-include
>
>
>
> ${application.id}.shell.sourceforge.net
> ${application.id}.shell.sourceforge.net
>
> sftp://web.sourceforge.net/home/groups/d/do/${application.id}/htdocs
>
> {code}
> (Btw. I tried variuous urls, "../htdocs", "../htdocs/" and "../htdocs/." but
> the site plugin always normalizes them to "../htdocs/", which is actually the
> right thing to do.)
> *My assumption why it happens:*
> I looked at the sources of wagon (particularly to the methods mentioned in
> the stack trace), and I think the issue seems to be that:
> - Site Plugin 3 always normalizes the remote directory to end with a trailing
> slash.
> - WagonSftp.putDirectory:277 calls ScpHelper.getResourceFilename(
> destinationDirectory ) on this directory which returns an empty string.
> - WagonSfto.ftpRecursivePut:300 calls mkdir with an empty string which causes
> the exception.
> Actually it looks as if older site plugins added a trailing "/." to the path
> instead of just "/" as otherwise it would have been broken before (I did not
> verify this). Nevertheless I think the bug is in the Wagon implementation as
> it should not fail if the destination is given like this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-951) Better handling of file.encoding system property
[
https://jira.codehaus.org/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319824#comment-319824
]
Stephan Schroevers commented on SUREFIRE-951:
-
Another property that only takes effect when set using {{}} (i.e., not
when using {{}}) is
[{{jdk.map.althashing.threshold}}|http://docs.oracle.com/javase/7/docs/technotes/guides/collections/changes7.html].
(Perhaps I should create a separate ticket for that?)
> Better handling of file.encoding system property
>
>
> Key: SUREFIRE-951
> URL: https://jira.codehaus.org/browse/SUREFIRE-951
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.13
> Environment: Any environment in which the file encoding is distinct
> from ${project.build.sourceEncoding}.
>Reporter: Stephan Schroevers
> Attachments: file-encoding-example.tbz
>
>
> It appears that Surefire doesn't (correctly) set
> {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} prior to running the
> tests. As a result the JVM will derive {{file.encoding}} from the
> environment's file encoding. This affects the return value of
> {{java.nio.charset.Charset#defaultCharset()}}, which reads the
> {{file.encoding}} system property exactly once, and is invoked very early on.
> Concretely this means that the unit tests are unnecessarily platform
> dependent.
> Thus I have two requests:
> # Make {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} the default.
> That is, the following configuration setting should be implied:
> {noformat}
> -Dfile.encoding=${project.build.sourceEncoding}
> {noformat}
> # Extend the method
> {{org.apache.maven.plugin.surefire.SurefireProperties#verifyLegalSystemProperties(org.apache.maven.plugin.logging.Log)}}
> such that is warns about users attempting to set the {{file.encoding}}
> property through the {{systemPropertyVariables}} configuration setting. Like
> with {{java.library.path}}, this does _not_ work.
> I have [attached|^file-encoding-example.tbz] a sample project that
> demonstrates the issue (simply run {{`mvn test`}}). Please have a look at the
> comments I added to the POM. I have tested this sample project only on Linux,
> but a colleague has confirmed that an instance of this issue can also be
> recreated on Windows.
> TIA for looking into this!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2063) deprecate expression, add system-property
[ https://jira.codehaus.org/browse/MNG-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-2063. -- Resolution: Duplicate Assignee: (was: Jason van Zyl) > deprecate expression, add system-property > - > > Key: MNG-2063 > URL: https://jira.codehaus.org/browse/MNG-2063 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter > Fix For: Issues to be reviewed for 3.x > > > expression is confusing. It is used for both default-value, and to allow > configuration of what system property to accept. However, now that > default-value takes expressions, it is redundant for that and can be > confusing, and because of its legacy in handling that, it is in the wrong > order for system property handling (see MNG-2062). > I propose we deprecate expression in favour of default-value, and add > system-property="someProperty" as the way to configure what command line > option can be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319821#comment-319821
]
Robert Scholte edited comment on MNG-5289 at 2/16/13 10:30 AM:
---
options have been renamed to {{--llr}}, {{-legacy-local-repository}} and
{{-Dmaven.legacyLocalRepository}}
was (Author: rfscholte):
options has been renamed to {{--llr}}, {{-legacy-local-repository}} and
{{-Dmaven.legacyLocalRepository}}
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5289) -Dmaven.repo.local not honored
[
https://jira.codehaus.org/browse/MNG-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319821#comment-319821
]
Robert Scholte commented on MNG-5289:
-
options has been renamed to {{--llr}}, {{-legacy-local-repository}} and
{{-Dmaven.legacyLocalRepository}}
> -Dmaven.repo.local not honored
> --
>
> Key: MNG-5289
> URL: https://jira.codehaus.org/browse/MNG-5289
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
> Environment: Linux
>Reporter: Ondrej Zizka
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> STR:
> 1) Checkout a multimodule project, e.g. JBoss AS 7
> {code}git clone git://github.com/jbossas/jboss-as.git{code}
> 2) {code}mvn -Dmaven.repo.local=foo dependencies:go-offline clean install
> -DallTests -DskipTests{code}
> 3) {code}mvn -Dmaven.repo.local=foo -o install -DallTests -DskipTests{code}
> This will complain about not having artifact XYZ.
> 4) On the other hand, this works:
> {code}
> mv ~/.m2/repository ~/.m2/repository_
> ln -s `pwd`/localRepo ~/.m2/repository
> mvn -o install
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories contains other repository ids than requested
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319822#comment-319822
]
Robert Scholte commented on MNG-5185:
-
options have been renamed to --llr, -legacy-local-repository and
-Dmaven.legacyLocalRepository
> Improve "missing dependency" error message when _maven.repositories contains
> other repository ids than requested
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0.2, 3.0.3, 3.0.4
>Reporter: Mark Derricutt
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from remote repositories. Unfortunately, when "conflicts"
> arise ( GAV is cached in local repo, but POM has no matching repository id
> declared ), Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5349) NullPointerException if missing id in org.apache.maven.lifecycle.Lifecycle
[
https://jira.codehaus.org/browse/MNG-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319818#comment-319818
]
Robert Scholte commented on MNG-5349:
-
AFAIK, if you have 2 or more components, the is required, so Plexus can
uniquely idententify every component. Since you didn't follow the requirements,
you got the NPE.
> NullPointerException if missing id in org.apache.maven.lifecycle.Lifecycle
> --
>
> Key: MNG-5349
> URL: https://jira.codehaus.org/browse/MNG-5349
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.4
> Environment: Ubuntu Precise, Maven 3.0.4
>Reporter: John Riedl
>Priority: Minor
> Attachments: components.xml, lifecycles.xml, phase-test.tar, pom.xml
>
>
> I've been working with custom lifecycles, and accidentally left the "id" out
> of one of them. You can see it in this example where I commented out the key
> line (everything works fine if this line is uncommented):
> {code:xml}
>
>
>
> org.apache.maven.lifecycle.mapping.LifecycleMapping
> phase-test
>
> org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
>
>
>
> org.apache.maven.lifecycle.Lifecycle
> phase-test
> org.apache.maven.lifecycle.Lifecycle
>
>
>
> tp-pre-new-phase
> tp-new-phase
> tp-post-new-phase
>
>
>
> org.riedl:phase-test-maven-plugin:greet
>
>
>
>
>
> ~
> {code}
> Here's most of the stack trace:
> {noformat}
> (macro: ~/Src/lenskit-projects/tryout-phase-test-plugin) mvn tp-post-new-phase
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: java.lang.NullPointerException
> at java.lang.String.compareTo(String.java:1167)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:144)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:140)
> at java.util.Arrays.mergeSort(Arrays.java:1270)
> at java.util.Arrays.sort(Arrays.java:1210)
> at java.util.Collections.sort(Collections.java:159)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getOrderedLifecycles(DefaultLifecyclePluginAnalyzer.java:139)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:96)
> at
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:63)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:397)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:371)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:560)
> {noformat}
> The NullPointerException happens with most attempts to run the project, such
> as "mvn foo". I've attached the pom.xml, lifecycles.xml, components.xml, and
> the Java for the plugin. I think only components.xml is relevant.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5349) NullPointerException if missing id in org.apache.maven.lifecycle.Lifecycle
[
https://jira.codehaus.org/browse/MNG-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5349:
Description:
I've been working with custom lifecycles, and accidentally left the "id" out of
one of them. You can see it in this example where I commented out the key line
(everything works fine if this line is uncommented):
{code:xml}
org.apache.maven.lifecycle.mapping.LifecycleMapping
phase-test
org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
org.apache.maven.lifecycle.Lifecycle
phase-test
org.apache.maven.lifecycle.Lifecycle
tp-pre-new-phase
tp-new-phase
tp-post-new-phase
org.riedl:phase-test-maven-plugin:greet
~
{code}
Here's most of the stack trace:
{noformat}
(macro: ~/Src/lenskit-projects/tryout-phase-test-plugin) mvn tp-post-new-phase
[INFO] Scanning for projects...
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NullPointerException
at java.lang.String.compareTo(String.java:1167)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:144)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer$1.compare(DefaultLifecyclePluginAnalyzer.java:140)
at java.util.Arrays.mergeSort(Arrays.java:1270)
at java.util.Arrays.sort(Arrays.java:1210)
at java.util.Collections.sort(Collections.java:159)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getOrderedLifecycles(DefaultLifecyclePluginAnalyzer.java:139)
at
org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:96)
at
org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:63)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:397)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:371)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:560)
{noformat}
The NullPointerException happens with most attempts to run the project, such as
"mvn foo". I've attached the pom.xml, lifecycles.xml, components.xml, and the
Java for the plugin. I think only components.xml is relevant.
was:
I've been working with custom lifecycles, and accidentally left the "id" out of
one of them. You can see it in this example where I commented out the key line
(everything works fine if this line is uncommented):
org.apache.maven.lifecycle.mapping.LifecycleMapping
phase-test
org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
org.apache.maven.lifecycle.Lifecycle
phase-test
org.apache.maven.lifecycle.Lifecycle
tp-pre-new-phase
tp-new-phase
tp-post-new-phase
org.riedl:phase-test-maven-plugin:greet
~
Here's most of the stack trace:
(macro: ~/Src/lenskit-projects/tryout-phase-test-plugin) mvn tp-post-new-phase
[INFO] Scanning for projects...
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main
[jira] (MNG-4188) Add a 'finally' phase.
[
https://jira.codehaus.org/browse/MNG-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319817#comment-319817
]
Robert Scholte commented on MNG-4188:
-
Maybe a {{finally}}-phase is not the right solution.
There are several phases which always belong together:
* pre-integration-test, integration-test, post-integration-test
* pre-clean, clean, post-clean
* pre-site, site, post-site
In all these cases it makes more sense to have the following construction:
{code}
try
{
// execute pre-
// execute
}
finally
{
// execute post-
}
{code}
But we would still need a mechanism for those users who really, really want to
execute up until the specified phase.
Maybe something like {{mvn integration-test.}} //notice the end-dot!
> Add a 'finally' phase.
> --
>
> Key: MNG-4188
> URL: https://jira.codehaus.org/browse/MNG-4188
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Plugins and Lifecycle
>Affects Versions: Issues to be reviewed for 3.x
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: Issues to be reviewed for 3.x
>
>
> When Maven executes a lifecycle, it does not execute any phases succeeding a
> failing phase. It would be great if Maven supports a 'finally' phase, which
> is guaranteed to run regardless of the state of the lifecycle just like a
> Java 'finally' block. The use case I would need such a phase for is the
> following:
> {code}
>
> sourceforge-shell
>
> false
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.apache.ant
> ant-jsch
> 1.7.1
>
>
>
>
> create-sourceforge-shell
> validate
>
> run
>
>
>
> username="${sf.username},${sf.project}" password="${sf.password}"
> command="create" timeout="30" />
>
>
>
>
> create-sourceforge-shell-site
> pre-site
>
> run
>
>
>
> username="${sf.username},${sf.project}" password="${sf.password}"
> command="create" timeout="30" />
>
>
>
>
> shutdown-sourceforge-shell
> deploy
>
> run
>
>
>
> username="${sf.username},${sf.project}" password="${sf.password}"
> command="shutdown" timeout="30" />
>
>
>
>
>
>
> shutdown-sourceforge-shell-site
> site-deploy
>
> run
>
>
>
> username="${sf.username},${sf.project}" password="${sf.password}"
> command="shutdown" timeout="30" />
>
>
>
>
>
>
>
>
>
>
> {code}
> I am currently using this profile when deploying to sourceforge. The problem
> is, that the shell won't get shutdown, whenever a build fails. It needs to
> get shutdown, so that a build for another SF project can succeed. In the
> example above, the two executions 'shutdown-sourceforge-shell' and
> 'shutdown-sourceforge-shell-site' could be bound to a 'finally' phase and
> could shutdown the shell regardless of the outcome of the build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5320) java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment
[
https://jira.codehaus.org/browse/MNG-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5320.
---
Resolution: Incomplete
Assignee: Robert Scholte
No feedback, so closing it.
FYI, current most recent version of the Maven Changelog Plugin is 2.2
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment
> --
>
> Key: MNG-5320
> URL: https://jira.codehaus.org/browse/MNG-5320
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Sites & Reporting
>Affects Versions: 3.0.4
> Environment: Mac OS X, Maven 3.0.4, java version "1.6.0_33"
> Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-10M3720)
> Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)
>Reporter: Elliotte Rusty Harold
>Assignee: Robert Scholte
>Priority: Minor
>
> Attempting to build jaxen from
> https://fisheye.codehaus.org/browse/jaxen/trunk/jaxen/pom.xml?r=1382
> This may well be caused by a plugin mismatch problem, but since the error
> message asked that I report it here you go.
> {noformat}
> [WARNING] An issue has occurred with report
> org.apache.maven.plugin.changelog.DeveloperActivityReport, skip LinkageError
> org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V, please
> report an issue to Maven dev team.
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V
> at
> org.apache.maven.scm.provider.svn.svnexe.command.SvnCommandLineUtils.getBaseSvnCommandLine(SvnCommandLineUtils.java:82)
> at
> org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.createCommandLine(SvnChangeLogCommand.java:121)
> at
> org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:77)
> at
> org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:68)
> at
> org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:101)
> at
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
> at
> org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:371)
> at
> org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.changelog(AbstractSvnScmProvider.java:274)
> at
> org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:250)
> at
> org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:226)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:534)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:393)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.m
[jira] (MNG-5320) java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment
[
https://jira.codehaus.org/browse/MNG-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5320:
Description:
Attempting to build jaxen from
https://fisheye.codehaus.org/browse/jaxen/trunk/jaxen/pom.xml?r=1382
This may well be caused by a plugin mismatch problem, but since the error
message asked that I report it here you go.
{noformat}
[WARNING] An issue has occurred with report
org.apache.maven.plugin.changelog.DeveloperActivityReport, skip LinkageError
org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V, please report
an issue to Maven dev team.
java.lang.NoSuchMethodError:
org.codehaus.plexus.util.cli.Commandline.addSystemEnvironment()V
at
org.apache.maven.scm.provider.svn.svnexe.command.SvnCommandLineUtils.getBaseSvnCommandLine(SvnCommandLineUtils.java:82)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.createCommandLine(SvnChangeLogCommand.java:121)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:77)
at
org.apache.maven.scm.provider.svn.svnexe.command.changelog.SvnChangeLogCommand.executeChangeLogCommand(SvnChangeLogCommand.java:68)
at
org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:101)
at
org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:58)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:371)
at
org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.changelog(AbstractSvnScmProvider.java:274)
at
org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:250)
at
org.apache.maven.scm.provider.AbstractScmProvider.changeLog(AbstractScmProvider.java:226)
at
org.apache.maven.plugin.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:534)
at
org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:393)
at
org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Generating "File Activity" report--- maven-changelog-plugin:2.1
[INFO] Generating changed sets xml to: /Volumes/Macintosh
HD/Users/elharo/Projects/workspace/jaxen/target/changelog.xml
[WARNING] An issue has occurred with report
org.apache.maven
[jira] (MNG-864) Fail the build with a nice error message if a property to be interpolated in pom.xml is not defined
[
https://jira.codehaus.org/browse/MNG-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-864.
--
Resolution: Won't Fix
Fix Version/s: (was: Issues to be reviewed for 3.x)
Assignee: Robert Scholte
This is superseded by the Maven Enforcer Plugin,
http://maven.apache.org/enforcer/enforcer-rules/
It has the {{requireEnvironmentVariable}}, so you have full control over which
variables are required and what the message should be.
> Fail the build with a nice error message if a property to be interpolated in
> pom.xml is not defined
> ---
>
> Key: MNG-864
> URL: https://jira.codehaus.org/browse/MNG-864
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 2.0-alpha-3
>Reporter: Vincent Massol
>Assignee: Robert Scholte
>Priority: Minor
>
> There are uses cases with pom.xml requiring an environment-specific property
> to be defined. If those property are not provided by the user in a
> settings.xm, profiles.xml or a command-line system property then m2 should
> fail the build with a nice error explaiing the reason.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-712) using maven-scm-plugin to checkin folder and file
[
https://jira.codehaus.org/browse/SCM-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-712:
---
Description:
step 1.Checkout Content
{code:xml}
checkout folder
process-resources
/home/checking-folder
app.data.revision
scm:svn:https://www.test.com/project-folder
${svn.username}
${svn.password}
checkout
{code}
step 2. jar adding
{code:xml}
add jar
process-resources
*.*
**/*
/home/checking-folder
scm:svn:https://www.test.com/project-folder
${svn.username}
${svn.password}
add
{code}
step 3. checkin in new folder and jar
{code:xml}
checkin- jar
process-resources
scm:svn:https://www.test.com/project-folder
${rdpv.chk.message}
/home/checking-folder
app.data.revision
${svn.username}
${svn.password}
checkin
{code}
After checking out using step 1, I am creating one New folder in
"/home/checking-folder", after that i am moving one jar inside that New folder.
while running the 2nd step and 3rd step it shows "new created folder is not
working copy".
Please help me to check-in jar with new created folder.
was:
step 1.Checkout Content
checkout folder
process-resources
/home/checking-folder
app.data.revision
scm:svn:https://www.test.com/project-folder
${svn.username}
${svn.password}
checkout
step 2. jar adding
add jar
process-resources
*.*
**/*
/home/checking-folder
scm:svn:https://www.test.com/project-folder
${svn.username}
${svn.password}
add
step 3. checkin in new folder and jar
checkin- jar
process-resources
scm:svn:https://www.test.com/project-folder
${rdpv.chk.message}
/home/checking-folder
app.data.revision
${svn.username}
${svn.password}
checkin
After checking out using step 1, I am creating one New folder in
"/home/checking-folder", after that i am moving one jar inside that New folder.
while running the 2nd step and 3rd step it shows "new created folder is not
working copy".
Please help me to check-in jar with new created folder.
> using maven-scm-plugin to checkin folder and file
> -
>
> Key: SCM-712
> URL: https://jira.codehaus.org/browse/SCM-712
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
> Environment: software platform
>Reporter: Rajasekar
>
> step 1.Checkout Content
> {code:xml}
>
> checkout folder
> process-resources
>
> /home/checking-folder
> app.data.revision
>
> scm:svn:https://www.test.com/project-folder
> ${svn.username}
> ${svn.password}
>
>
> checkout
>
>
> {code}
> step 2. jar adding
> {code:xml}
>
> add jar
> process-resources
>
> *.*
> **/*
> /home/checking-folder
>
> scm:svn:https://www.test.com/project-folder
> ${svn.username}
> ${svn.password}
>
>
> add
>
>
> {code}
> step 3. checkin in new folder and jar
> {code:xml}
>
> checkin- jar
> process-resources
>
>
> scm:svn:https://www.test.com/project-folder
> ${rdpv.chk.message}
> /home/checking-folder
> app.data.revision
> ${svn.username}
> ${svn.password}
>
>
> checkin
>
>
> {code}
> After checking out using step 1, I am creating one New folder in
> "/home/checking-folder", after that i am moving one jar inside that New
> folder. while running the 2nd step and 3rd step it shows "new created folder
> is not working copy".
> Please help me to check-in jar with new created folder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-712) using maven-scm-plugin to checkin folder and file
[
https://jira.codehaus.org/browse/SCM-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MNG-5223 to SCM-712:
-
Component/s: (was: Errors)
(was: Plugin API)
maven-plugin
Affects Version/s: (was: 2.2.1)
Key: SCM-712 (was: MNG-5223)
Project: Maven SCM (was: Maven 2 & 3)
> using maven-scm-plugin to checkin folder and file
> -
>
> Key: SCM-712
> URL: https://jira.codehaus.org/browse/SCM-712
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-plugin
> Environment: software platform
>Reporter: Rajasekar
>
> step 1.Checkout Content
>
> checkout folder
> process-resources
>
> /home/checking-folder
> app.data.revision
>
> scm:svn:https://www.test.com/project-folder
> ${svn.username}
> ${svn.password}
>
>
> checkout
>
>
> step 2. jar adding
>
> add jar
> process-resources
>
> *.*
> **/*
> /home/checking-folder
>
> scm:svn:https://www.test.com/project-folder
> ${svn.username}
> ${svn.password}
>
>
> add
>
>
> step 3. checkin in new folder and jar
>
> checkin- jar
> process-resources
>
>
> scm:svn:https://www.test.com/project-folder
> ${rdpv.chk.message}
> /home/checking-folder
> app.data.revision
> ${svn.username}
> ${svn.password}
>
>
> checkin
>
>
> After checking out using step 1, I am creating one New folder in
> "/home/checking-folder", after that i am moving one jar inside that New
> folder. while running the 2nd step and 3rd step it shows "new created folder
> is not working copy".
> Please help me to check-in jar with new created folder.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3131) Error message is misleading if a missing plugin parameter is of a type like List
[
https://jira.codehaus.org/browse/MNG-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-3131.
---
Resolution: Fixed
Fix Version/s: (was: Issues to be reviewed for 3.x)
3.0.5
Assignee: Robert Scholte
Fixed in http://git-wip-us.apache.org/repos/asf/maven/commit/56cd921f
> Error message is misleading if a missing plugin parameter is of a type like
> List
>
>
> Key: MNG-3131
> URL: https://jira.codehaus.org/browse/MNG-3131
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: Dennis Lundberg
>Assignee: Robert Scholte
> Fix For: 3.0.5
>
>
> Here is a sample output I got when I was working on the changes-plugin:
> {code}
> [INFO] One or more required plugin parameters are invalid/missing for
> 'changes:announcement-mail'
> [0] inside the definition for plugin: 'maven-changes-plugin'specify the
> following:
>
> ...
> VALUE
> .
> [1] inside the definition for plugin: 'maven-changes-plugin'specify the
> following:
>
> ...
> VALUE
> .
> {code}
> Notice the second parameter toAdresses. It is of the type List, so the
> correct configuration would be something like this
> {code}
>
> ...
>
> VALUE
>
> .
> {code}
> I haven't found where in the code base the handling of List/Map/Array
> parameters is. That code could probably be borrowed/reused in
> maven-core/src/main/java/org/apache/maven/plugin/PluginParameterException.java
> which is the class responsible for formating the above messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
