[jira] Closed: (MINVOKER-61) Allow to ignore failures
[
http://jira.codehaus.org/browse/MINVOKER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MINVOKER-61.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 1.3
Done in [r691066|http://svn.apache.org/viewvc?view=rev&revision=691066].
> Allow to ignore failures
>
>
> Key: MINVOKER-61
> URL: http://jira.codehaus.org/browse/MINVOKER-61
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.2.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 1.3
>
>
> Similar to Surefire's
> {{[testFailureIgnore|http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testFailureIgnore]}}
> flag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-409) Windows path length limitations can be overcome by feeding an absolute path to SVN (checkout command)
[ http://jira.codehaus.org/browse/SCM-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-409. Resolution: Fixed fixed in rev 691064. > Windows path length limitations can be overcome by feeding an absolute path > to SVN (checkout command) > - > > Key: SCM-409 > URL: http://jira.codehaus.org/browse/SCM-409 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.1 > Environment: Windows OS >Reporter: Dominique Jean-Prost >Assignee: Olivier Lamy > Fix For: 1.1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try to > the same path again only as an absolute path and it will successfully > complete the transaction. > This bug was originally fixed for the update command, but still remains for > the checkout command. There may be other command that are affected by this > bug. > 1. cd c:\a\very\long\paht\under\windows\xp\or\windows\2000 > 2. mvn scm:checkout -DconnectionUrl=scm:svn:http://myUrlHere > --> It says > [INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout > http://myUrlHere checkout" > [INFO] Working directory: c:\a\very\long\paht\under\windows\xp\or\windows\2000 > [ERROR] Provider message: > [ERROR] The svn command failed. > [ERROR] Command output: > [ERROR] svn: Your .svn/tmp directory may be missing or corrupt; run 'svn > cleanup' and try again > svn: Can't open file 'checkout\blablasvn-base': Le chemin d'accès > spécifié est introuvable. > 3. If I execute svn --non-interactive checkout http://myUrlHere > c:\a\very\long\paht\under\windows\xp\or\windows\2000\checkout : it works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINVOKER-61) Allow to ignore failures
Allow to ignore failures
Key: MINVOKER-61
URL: http://jira.codehaus.org/browse/MINVOKER-61
Project: Maven 2.x Invoker Plugin
Issue Type: New Feature
Affects Versions: 1.2.1
Reporter: Benjamin Bentmann
Priority: Minor
Similar to Surefire's
{{[testFailureIgnore|http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testFailureIgnore]}}
flag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-50) Version rule with dashes are not inspected correctly
Version rule with dashes are not inspected correctly Key: MENFORCER-50 URL: http://jira.codehaus.org/browse/MENFORCER-50 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0-alpha-3 Reporter: Paul Benedict Assignee: Brian Fox I know it's possible to say [2.0,) for anything within the 2.0 series. The same was not possible with the latest Maven 2.1 release: [2.1.0-M1,) does not pass for version 2.1.0-M1-RC12 I should be accepting anything within the M1 build range. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-179) Ability to use an alternate repository at copy and unpack mojo's execution time
[
http://jira.codehaus.org/browse/MDEP-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146638#action_146638
]
Dan Tran commented on MDEP-179:
---
the patch basically requires all access to the top level "local" variable to go
thru getLocal() method, and the base class of copy and unpack mojo overwrites
the getLocal() method to instantiate the alternate local repo base the the
existing of "alternateLocalRepostory" configuration.
> Ability to use an alternate repository at copy and unpack mojo's execution
> time
> ---
>
> Key: MDEP-179
> URL: http://jira.codehaus.org/browse/MDEP-179
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: copy, unpack
>Affects Versions: 2.0
> Environment: windows, unixes
>Reporter: Dan Tran
>Assignee: Brian Fox
> Attachments: MDEP-179.patch
>
>
> The motivation behind this enhancement is to copy/unpack very large
> artifacts without polluting the current
> local repository especially with snapshot artifacts. The new
> alternateLocalRepository is likely under ${project.build.directory} to be
> cleaned up with "mvn clean".
> This is a very specialized use case since the artifact must always at remote
> repo. or user must implement some sort of profile to switch this mode when
> the artifact already in the currently repo ( ie it was built together as a
> multi modules build)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-179) Ability to use an alternate repository at copy and unpack mojo's execution time
[
http://jira.codehaus.org/browse/MDEP-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Tran updated MDEP-179:
--
Attachment: MDEP-179.patch
Please review the patch + tests, usage doc will follow.
Give me a thumb up i will apply it
> Ability to use an alternate repository at copy and unpack mojo's execution
> time
> ---
>
> Key: MDEP-179
> URL: http://jira.codehaus.org/browse/MDEP-179
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: copy, unpack
>Affects Versions: 2.0
> Environment: windows, unixes
>Reporter: Dan Tran
>Assignee: Brian Fox
> Attachments: MDEP-179.patch
>
>
> The motivation behind this enhancement is to copy/unpack very large
> artifacts without polluting the current
> local repository especially with snapshot artifacts. The new
> alternateLocalRepository is likely under ${project.build.directory} to be
> cleaned up with "mvn clean".
> This is a very specialized use case since the artifact must always at remote
> repo. or user must implement some sort of profile to switch this mode when
> the artifact already in the currently repo ( ie it was built together as a
> multi modules build)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-179) Ability to use an alternate repository at copy and unpack mojo's execution time
Ability to use an alternate repository at copy and unpack mojo's execution time
---
Key: MDEP-179
URL: http://jira.codehaus.org/browse/MDEP-179
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: copy, unpack
Affects Versions: 2.0
Environment: windows, unixes
Reporter: Dan Tran
Assignee: Brian Fox
The motivation behind this enhancement is to copy/unpack very large artifacts
without polluting the current
local repository especially with snapshot artifacts. The new
alternateLocalRepository is likely under ${project.build.directory} to be
cleaned up with "mvn clean".
This is a very specialized use case since the artifact must always at remote
repo. or user must implement some sort of profile to switch this mode when the
artifact already in the currently repo ( ie it was built together as a multi
modules build)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-361) make cvs tag -F optional
[ http://jira.codehaus.org/browse/SCM-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-361. --- Assignee: Vincent Siveton Resolution: Fixed Patch applied in [r691002|http://svn.apache.org/viewvc?rev=691002&view=rev]. Thanks! > make cvs tag -F optional > - > > Key: SCM-361 > URL: http://jira.codehaus.org/browse/SCM-361 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-cvs >Affects Versions: 1.0 >Reporter: Benoit Decherf >Assignee: Vincent Siveton > Fix For: 1.1.1 > > Attachments: patch_useForceTag > > > In our cvs server a tag cannot be moved. This is useful to ensure that there > is only one version of a component with a same tag. Now, i wan't to integrate > all our components to continuum and use it to create releases. The problem is > that the scm try to tag the release using "cvs tag -F" and this fails. > I check the code and see that it is hardcoded (in > maven-scm-provider-cvs-commons/src/main/java/org/apache/maven/scm/provider/cvslib/command/tag/AbstractCvsTagCommand.java). > Is it possible to make it optional ? Or what is the reason to enforce it ? > I make a patch to add the option useForceTag. This works, but in case of a > conflict with an existing flag, the cvs tag won't failed. (the tag is not > set). Is this acceptable ? > Or maybe I should check for Warning messages in the output and the command > should fail if there are any warnings ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-517) Invalid classpath order with classesDirectory and testClassesDirectory
[ http://jira.codehaus.org/browse/SUREFIRE-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated SUREFIRE-517: Attachment: SUREFIRE-517.diff Proposed fix > Invalid classpath order with classesDirectory and testClassesDirectory > -- > > Key: SUREFIRE-517 > URL: http://jira.codehaus.org/browse/SUREFIRE-517 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Igor Fedorenko > Attachments: SUREFIRE-517.diff, SUREFIRE-517.zip > > > Surefire plugin adds classesDirectory and testClassesDirectory at the end of > classpath which makes it impossible to "override" any classes/resources > available in project dependencies with test version of class/resource. This > problem is closely related to SUREFIRE-333. I will attach sample project and > a trivial fix shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-517) Invalid classpath order with classesDirectory and testClassesDirectory
[ http://jira.codehaus.org/browse/SUREFIRE-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated SUREFIRE-517: Attachment: SUREFIRE-517.zip sample project that demonstrates the problem > Invalid classpath order with classesDirectory and testClassesDirectory > -- > > Key: SUREFIRE-517 > URL: http://jira.codehaus.org/browse/SUREFIRE-517 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Igor Fedorenko > Attachments: SUREFIRE-517.zip > > > Surefire plugin adds classesDirectory and testClassesDirectory at the end of > classpath which makes it impossible to "override" any classes/resources > available in project dependencies with test version of class/resource. This > problem is closely related to SUREFIRE-333. I will attach sample project and > a trivial fix shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-517) Invalid classpath order with classesDirectory and testClassesDirectory
Invalid classpath order with classesDirectory and testClassesDirectory -- Key: SUREFIRE-517 URL: http://jira.codehaus.org/browse/SUREFIRE-517 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.4.3 Reporter: Igor Fedorenko Surefire plugin adds classesDirectory and testClassesDirectory at the end of classpath which makes it impossible to "override" any classes/resources available in project dependencies with test version of class/resource. This problem is closely related to SUREFIRE-333. I will attach sample project and a trivial fix shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-410) Replace deprecated Commandline#createArgument()
[ http://jira.codehaus.org/browse/SCM-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-410. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1.1 Fixed in [r690997|http://svn.apache.org/viewvc?rev=690997&view=rev] > Replace deprecated Commandline#createArgument() > --- > > Key: SCM-410 > URL: http://jira.codehaus.org/browse/SCM-410 > Project: Maven SCM > Issue Type: Task >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1.1 > > > Need to be replaced by Commandline#createArg() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-86) add timeout to HttpUtils/wagon
[ http://jira.codehaus.org/browse/WAGON-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146624#action_146624 ] Wendy Smoak commented on WAGON-86: -- >From #maven: How would I specify the connection timeout for maven artifact downloads (as per http://jira.codehaus.org/browse/WAGON-86) brett: via in the element of settings.xml, but that won't be available until Maven 2.1.0 is out > add timeout to HttpUtils/wagon > -- > > Key: WAGON-86 > URL: http://jira.codehaus.org/browse/WAGON-86 > Project: Maven Wagon > Issue Type: Improvement >Reporter: Brett Porter >Assignee: nicolas de loof >Priority: Minor > Fix For: 1.0-beta-3 > > Attachments: WAGON-86.patch, WAGON-86.patch > > > in httputils (and heavyweight http wagon), add a configurable timeout for > requests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-410) Replace deprecated Commandline#createArgument()
Replace deprecated Commandline#createArgument() --- Key: SCM-410 URL: http://jira.codehaus.org/browse/SCM-410 Project: Maven SCM Issue Type: Task Affects Versions: 1.1 Reporter: Vincent Siveton Need to be replaced by Commandline#createArg() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-360) CVS Tag command doesn't use FileSet (list of files), tagging ALL files in working directory
[ http://jira.codehaus.org/browse/SCM-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-360. --- Assignee: Vincent Siveton Resolution: Fixed Applied in [r690993|http://svn.apache.org/viewvc?rev=690993&view=rev]. Thanks. For your next patch, please use the Maven code style. > CVS Tag command doesn't use FileSet (list of files), tagging ALL files in > working directory > --- > > Key: SCM-360 > URL: http://jira.codehaus.org/browse/SCM-360 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.x, 2.0 >Reporter: Andrei Solntsev >Assignee: Vincent Siveton > Fix For: 1.1.1 > > Attachments: scm.diff > > > I want to tag ONE file in the working directory. > I don't want to tag ALL files. > I call SCM Plugin with a FileSet instance which contains only one file. > However, CVS provider doesn't use it and tags ALL files in the working > directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-346) Recursive flag is not implemented in the check out command
[
http://jira.codehaus.org/browse/SCM-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-346.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fixed in [r690992|http://svn.apache.org/viewvc?rev=690992&view=rev]
For the next time, please provide a diff file like described in [1]
[1]
http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patch
> Recursive flag is not implemented in the check out command
> --
>
> Key: SCM-346
> URL: http://jira.codehaus.org/browse/SCM-346
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
>Priority: Blocker
> Fix For: 1.1.1
>
> Attachments: AbstractCheckOutCommand.java, SvnCheckOutCommand.java
>
>
> The recursive flag is not use in the SvnCheckOutCommand class.
> Here is a small Java code to reproduce it.
> {code:title=Sample.java|borderStyle=solid}
> String url = "scm:svn:https://svn.apache.org/repos/asf/maven/trunks";;
> boolean recursive = true;
> ScmManager scmManager = (ScmManager) lookup( ScmManager.ROLE );
> ScmRepository repository = scmManager.makeScmRepository( url );
> CheckOutScmResult result = scmManager.checkOut( repository, new ScmFileSet(
> workingDir ), recursive );
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MNG-3738. Assignee: Wendy Smoak Resolution: Fixed > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3739) Perform multiple web requests simultaneously.
Perform multiple web requests simultaneously. - Key: MNG-3739 URL: http://jira.codehaus.org/browse/MNG-3739 Project: Maven 2 Issue Type: Improvement Components: Performance Affects Versions: 2.0.9 Reporter: Maarten Billemont Maven's dependency downloading is horribly slow. It appears to only make one request at a time; often to slow mirrors which take seconds to respond. This is not so much of an issue when you use a local repository to keep and manage your dependencies; though it becomes one again once you leave the network of that repository and try to access it over the internet. Maven should make multiple (5 or so; configurable perhaps) requests simultaneously so that while several are establishing connection, others are at least already using the available bandwidth. And should mirrors be capped; other artifacts can already be downloaded from other mirrors to make optimal use of the bandwidth. Currently only a fraction of the bandwidth capacity is used; causing an initial build of a large project without a local repository available to take *for* *ever*. The project I'm working on; I need to make sure to reserve a day at least should I want to build the code with a client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146620#action_146620 ] Wendy Smoak commented on MNG-3738: -- The user list would be a better place to ask questions like this. You can find subscription info on this page: http://maven.apache.org/mail-lists.html > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3738) Maven Update Depenedency!
Maven Update Depenedency! - Key: MNG-3738 URL: http://jira.codehaus.org/browse/MNG-3738 Project: Maven 2 Issue Type: Task Components: Artifacts and Repositories Affects Versions: 2.0.9 Reporter: prashant p Priority: Blocker Hi , We are facing issue with maven update dependency.When multiple depevlopers run maven ,it takes hours of time in updating dependency from artifactory located in remote.Is it because of network issue causing this slow.I tried to change localhost in setting.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2194) Synch repo.magnolia.info
Synch repo.magnolia.info
Key: MAVENUPLOAD-2194
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2194
Project: Maven Upload Requests
Issue Type: Wish
Reporter: Grégory Joseph
Our info:
{noformat}
"info.magnolia","[EMAIL PROTECTED]:synched-to-central","rsync_ssh","Grégory
Joseph","[EMAIL PROTECTED]",,
{noformat}
Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGSITE-62) Maven SCM plugin guide page 404s.
[ http://jira.codehaus.org/browse/MNGSITE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146604#action_146604 ] Vincent Siveton commented on MNGSITE-62: What is the original page? > Maven SCM plugin guide page 404s. > - > > Key: MNGSITE-62 > URL: http://jira.codehaus.org/browse/MNGSITE-62 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: Haikal Saadh >Priority: Minor > > http://maven.apache.org/scm/plugins/guide/index.html, as linked from the left > sidebar (from 'Guides'), 404s. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-63) Multiple broken mirror links
[ http://jira.codehaus.org/browse/MNGSITE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNGSITE-63. -- Assignee: Vincent Siveton Resolution: Fixed Fixed in [r690957|http://svn.apache.org/viewvc?rev=690957&view=rev] Added a new wiki page http://docs.codehaus.org/display/MAVENUSER/Mirrors+Repositories > Multiple broken mirror links > > > Key: MNGSITE-63 > URL: http://jira.codehaus.org/browse/MNGSITE-63 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: Matthew Beermann >Assignee: Vincent Siveton >Priority: Critical > > http://maven.apache.org/guides/mini/guide-mirror-settings.html > Several of the mirrors listed on this page no longer appear to exist, meaning > that anyone who uses the provided settings file is in for a nasty surprise. > :( Specifically... > http://ibiblio.lsu.edu/main/pub/packages/maven2 > http://maven.sateh.com/repository > http://ftp.ggi-project.org/pub/packages/maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2193) Please, synchronize addressing.sourceforge.net
Please, synchronize addressing.sourceforge.net -- Key: MAVENUPLOAD-2193 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2193 Project: Maven Upload Requests Issue Type: Wish Reporter: Rodrigo Ruiz Here is the information: "net.sourceforge.addressing","[EMAIL PROTECTED]:/home/groups/a/ad/addressing/htdocs/maven2-releases","rsync_ssh","Rodrigo Ruiz","[EMAIL PROTECTED]",, Thanks in advance, Rodrigo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-191) Ability to filter filenames (rename files) during project generation
[ http://jira.codehaus.org/browse/ARCHETYPE-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146593#action_146593 ] Raphaël Piéroni commented on ARCHETYPE-191: --- Hi Pat, My last comment was a proposition of solution. Now i know it is what is desired, i will try to implement it. Thanks Raphaël > Ability to filter filenames (rename files) during project generation > > > Key: ARCHETYPE-191 > URL: http://jira.codehaus.org/browse/ARCHETYPE-191 > Project: Maven Archetype > Issue Type: New Feature > Components: Generator >Affects Versions: 2.0-alpha-3 >Reporter: Wendy Smoak > > When generating a new project from an archetype, I need to filter not only > values within files, but the names of the files themselves. > For example, in .NET projects, the project files (.sln, .csproj) match the > name of the solution or project rather than having a fixed name like Maven's > pom.xml does. > Another user raised a similar issue on the mailing list, the ability to > filter in the name of Java source code files. > See: http://www.nabble.com/Archetype%2C-define-file-name-ts18430983.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-409) Windows path length limitations can be overcome by feeding an absolute path to SVN (checkout command)
[ http://jira.codehaus.org/browse/SCM-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-409: - Fix Version/s: 1.1.1 Component/s: (was: maven-scm-api) maven-scm-provider-svn Summary: Windows path length limitations can be overcome by feeding an absolute path to SVN (checkout command) (was: Windows path length limitations can be overcome by feeding an absolute path to SVN) > Windows path length limitations can be overcome by feeding an absolute path > to SVN (checkout command) > - > > Key: SCM-409 > URL: http://jira.codehaus.org/browse/SCM-409 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.1 > Environment: Windows OS >Reporter: Dominique Jean-Prost > Fix For: 1.1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try to > the same path again only as an absolute path and it will successfully > complete the transaction. > This bug was originally fixed for the update command, but still remains for > the checkout command. There may be other command that are affected by this > bug. > 1. cd c:\a\very\long\paht\under\windows\xp\or\windows\2000 > 2. mvn scm:checkout -DconnectionUrl=scm:svn:http://myUrlHere > --> It says > [INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout > http://myUrlHere checkout" > [INFO] Working directory: c:\a\very\long\paht\under\windows\xp\or\windows\2000 > [ERROR] Provider message: > [ERROR] The svn command failed. > [ERROR] Command output: > [ERROR] svn: Your .svn/tmp directory may be missing or corrupt; run 'svn > cleanup' and try again > svn: Can't open file 'checkout\blablasvn-base': Le chemin d'accès > spécifié est introuvable. > 3. If I execute svn --non-interactive checkout http://myUrlHere > c:\a\very\long\paht\under\windows\xp\or\windows\2000\checkout : it works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-409) Windows path length limitations can be overcome by feeding an absolute path to SVN
Windows path length limitations can be overcome by feeding an absolute path to SVN -- Key: SCM-409 URL: http://jira.codehaus.org/browse/SCM-409 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Affects Versions: 1.1 Environment: Windows OS Reporter: Dominique Jean-Prost When calling Subversion with relative paths there is a limit of 255 characters to the path length. If you call Subversion with an absolute path that no longer applies and you now have access to 32K chars. I have tried this myself and it does work. Try feeding SVN a path that is relative and is over 255 chars. It will not be able to complete the transaction. Now, try to the same path again only as an absolute path and it will successfully complete the transaction. This bug was originally fixed for the update command, but still remains for the checkout command. There may be other command that are affected by this bug. 1. cd c:\a\very\long\paht\under\windows\xp\or\windows\2000 2. mvn scm:checkout -DconnectionUrl=scm:svn:http://myUrlHere --> It says [INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout http://myUrlHere checkout" [INFO] Working directory: c:\a\very\long\paht\under\windows\xp\or\windows\2000 [ERROR] Provider message: [ERROR] The svn command failed. [ERROR] Command output: [ERROR] svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file 'checkout\blablasvn-base': Le chemin d'accès spécifié est introuvable. 3. If I execute svn --non-interactive checkout http://myUrlHere c:\a\very\long\paht\under\windows\xp\or\windows\2000\checkout : it works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146592#action_146592 ] Emmanuel Venisse commented on SCM-368: -- oh, you're right, it was done only for the update command. File a new issue for the checkout command. > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[
http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146590#action_146590
]
Dominique Jean-Prost commented on SCM-368:
--
Well, I think I use it :
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-plugin:1.1:checkout' -->
[DEBUG] (f) basedir = C:\temp\{BF39BA21-A67B-47D4-931D-446F746DF0AC}\jre\bin
[DEBUG] (s) checkoutDirectory =
C:\temp\{BF39BA21-A67B-47D4-931D-446F746DF0AC}\jre\bin\target\checkout
[DEBUG] (f) connectionType = connection
[DEBUG] (s) connectionUrl =
scm:svn:http://vsrigel:8080/svn/tags/sofaxis-protocoleconvention-root-1.0.4/
[DEBUG] (f) developerConnectionUrl =
scm:svn:http://vsrigel:8080/svn/tags/sofaxis-protocoleconvention-root-1.0.4/
[DEBUG] (f) settings = [EMAIL PROTECTED]
[DEBUG] (f) skipCheckoutIfExists = false
[DEBUG] -- end configuration --
[INFO] [scm:checkout]
[INFO] Removing
C:\temp\{BF39BA21-A67B-47D4-931D-446F746DF0AC}\jre\bin\target\checkout
[INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout http://myUrl/
checkout"
[INFO] Working directory:
C:\temp\{BF39BA21-A67B-47D4-931D-446F746DF0AC}\jre\bin\target
...
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: Your .svn/tmp directory may be missing or corrupt; run 'svn
cleanup' and try again
svn: Can't open file 'checkout\blabla.svn-base': Le chemin d'accès spécifié est
introuvable.
I think the command line shoud be svn --non-interactive checkout http://myUrl/
${checkoutDirectory} where checkoutDirectory is absolute instead of svn
--non-interactive checkout http://myUrl/ checkout where checkout is relative.
What do you think ?
> Windows path length limitations can be overcome by feeding an absolute path
> to SVN
> --
>
> Key: SCM-368
> URL: http://jira.codehaus.org/browse/SCM-368
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-api
>Affects Versions: 1.0
> Environment: Any Windows machine
>Reporter: Kurt Tometich
>Assignee: Emmanuel Venisse
>Priority: Minor
> Fix For: 1.1
>
>
> When calling Subversion with relative paths there is a limit of 255
> characters to the path length. If you call Subversion with an absolute path
> that no longer applies and you now have access to 32K chars. I have tried
> this myself and it does work. Try feeding SVN a path that is relative and is
> over 255 chars. It will not be able to complete the transaction. Now, try
> to the same path again only as an absolute path and it will successfully
> complete the transaction. Here is a link to the forum where I found this
> information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146588#action_146588 ] Emmanuel Venisse commented on SCM-368: -- Are you sure you use maven-scm-plugin 1.1? Run the command with '-X' option to look at the version used. > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146585#action_146585 ] Dominique Jean-Prost commented on SCM-368: -- Well, I've just tested as the plugin has been released, and I still meet the problem. Here what I do : 1. cd c:\a\very\long\paht\under\windows\xp\or\windows\2000 2. mvn scm:checkout -DconnectionUrl=scm:svn:http://myUrlHere --> It says [INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout http://myUrlHere checkout" [INFO] Working directory: c:\a\very\long\paht\under\windows\xp\or\windows\2000 [ERROR] Provider message: [ERROR] The svn command failed. [ERROR] Command output: [ERROR] svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file 'checkout\blablasvn-base': Le chemin d'accès spécifié est introuvable. 3. If I execute svn --non-interactive checkout http://myUrlHere c:\a\very\long\paht\under\windows\xp\or\windows\2000\checkout : it works. Can you look at this please ? PS : my test was done by using the release plugin. It failed for the same reason, then I tested directly the scm plugin. > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
