[jira] Commented: (MNG-4982) Differences into transitive dependency scope resolution between Maven 3 and Maven 2
[
http://jira.codehaus.org/browse/MNG-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252920#action_252920
]
Renato Garcia commented on MNG-4982:
Correct, but the problem is with the transitive deps of fop. Take a look at
*org.apache.xmlgraphics:batik-svg-dom* for instance.
> Differences into transitive dependency scope resolution between Maven 3 and
> Maven 2
> ---
>
> Key: MNG-4982
> URL: http://jira.codehaus.org/browse/MNG-4982
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 10:58:10+1000)
> Java version: 1.6.0_17, vendor: Sun Microsystems Inc.
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000)
> Java version: 1.6.0_17
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Renato Garcia
> Attachments: test-projects.zip
>
>
> I'm getting different transitive dependency scope resolution when building
> with Maven 3. Transitive dependencies from a *provided* scope should be
> resolved to *provided* according to the
> [docs|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope],
> but it is resolving to *compile* as shown below. When building with Maven 2
> it works correctly.
> I tried to isolate the problem with a simpler scenario, but could only
> reproduce using the *org.apache.xmlgraphics:fop:jar:1.0* dependency.
> Maven 3 dependency output snippet:
> {noformat}
> [DEBUG] test:a:jar:1
> [DEBUG]test:a-deps:pom:1:provided
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-css:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-parser:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:compile
> [DEBUG] xml-apis:xml-apis:jar:1.3.04:compile
> [DEBUG] xml-apis:xml-apis-ext:jar:1.3.04:compile
> [DEBUG] org.apache.xmlgraphics:batik-bridge:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-script:jar:1.7:provided
> [DEBUG]org.apache.xmlgraphics:batik-js:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-xml:jar:1.7:compile
> [DEBUG] xalan:xalan:jar:2.6.0:compile
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-gvt:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-transcoder:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-svggen:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-extension:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-ext:jar:1.7:compile
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:provided
> {noformat}
> Maven 2 dependency output:
> {noformat}
> [DEBUG] test:a:jar:1 (selected for null)
> [DEBUG] test:a-deps:pom:1:provided (selected for provided)
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided (selected for
> provided)
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> (selected for provided)
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided (selected for
> provided)
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided
> (removed - causes a cycle in the graph)
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:provided (selected
> for provid
[jira] Commented: (MNG-4982) Differences into transitive dependency scope resolution between Maven 3 and Maven 2
[
http://jira.codehaus.org/browse/MNG-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252915#action_252915
]
Kari J. Niemi commented on MNG-4982:
In both dependency tree logs org.apache.xmlgraphics:fop:jar:1.0 has the scope
"provided". Hmmm... or is there something wrong with my eyes?
> Differences into transitive dependency scope resolution between Maven 3 and
> Maven 2
> ---
>
> Key: MNG-4982
> URL: http://jira.codehaus.org/browse/MNG-4982
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 10:58:10+1000)
> Java version: 1.6.0_17, vendor: Sun Microsystems Inc.
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000)
> Java version: 1.6.0_17
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Renato Garcia
> Attachments: test-projects.zip
>
>
> I'm getting different transitive dependency scope resolution when building
> with Maven 3. Transitive dependencies from a *provided* scope should be
> resolved to *provided* according to the
> [docs|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope],
> but it is resolving to *compile* as shown below. When building with Maven 2
> it works correctly.
> I tried to isolate the problem with a simpler scenario, but could only
> reproduce using the *org.apache.xmlgraphics:fop:jar:1.0* dependency.
> Maven 3 dependency output snippet:
> {noformat}
> [DEBUG] test:a:jar:1
> [DEBUG]test:a-deps:pom:1:provided
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-css:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-parser:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:compile
> [DEBUG] xml-apis:xml-apis:jar:1.3.04:compile
> [DEBUG] xml-apis:xml-apis-ext:jar:1.3.04:compile
> [DEBUG] org.apache.xmlgraphics:batik-bridge:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-script:jar:1.7:provided
> [DEBUG]org.apache.xmlgraphics:batik-js:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-xml:jar:1.7:compile
> [DEBUG] xalan:xalan:jar:2.6.0:compile
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-gvt:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-transcoder:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-svggen:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-extension:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-ext:jar:1.7:compile
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:provided
> {noformat}
> Maven 2 dependency output:
> {noformat}
> [DEBUG] test:a:jar:1 (selected for null)
> [DEBUG] test:a-deps:pom:1:provided (selected for provided)
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided (selected for
> provided)
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> (selected for provided)
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided (selected for
> provided)
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided
> (removed - causes a cycle in the graph)
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:provided (selected
>
[jira] Issue Comment Edited: (MASSEMBLY-543) japanese filenames cannot be correctly assembled by maven-assembly-plugin
[ http://jira.codehaus.org/browse/MASSEMBLY-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252895#action_252895 ] Eros Sy edited comment on MASSEMBLY-543 at 1/25/11 6:21 PM: oh! my attachment is also garbled. i will post here the sample Japanese file name. the content is not essential. I hope it supported Japanese file name: 新規テキスト ドキュメント.xml was (Author: gml.check.t...@gmail.com): oh! my attachment is also garbled. i will post here the sample Japanese file name. I hope it supported Japanese file name: 新規テキスト ドキュメント.xml > japanese filenames cannot be correctly assembled by maven-assembly-plugin > - > > Key: MASSEMBLY-543 > URL: http://jira.codehaus.org/browse/MASSEMBLY-543 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Windows XP SP3 Japanese, Eclipse Ganymede 3.4.2 >Reporter: Eros Sy > Attachments: 新規テキスト > ドキュメント.xml > > > I am successfully created the distribution zip file but when I add a file > which is in Japanese character file name, it is include in the zip file but > the file name was garbled. > How to reproduce: add a file to be included in the distribution which file > name is in Japanese character. i will provide a sample file. -- 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: (MASSEMBLY-543) japanese filenames cannot be correctly assembled by maven-assembly-plugin
[ http://jira.codehaus.org/browse/MASSEMBLY-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252895#action_252895 ] Eros Sy commented on MASSEMBLY-543: --- oh! my attachment is also garbled. i will post here the sample Japanese file name. I hope it supported Japanese file name: 新規テキスト ドキュメント.xml > japanese filenames cannot be correctly assembled by maven-assembly-plugin > - > > Key: MASSEMBLY-543 > URL: http://jira.codehaus.org/browse/MASSEMBLY-543 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Windows XP SP3 Japanese, Eclipse Ganymede 3.4.2 >Reporter: Eros Sy > Attachments: 新規テキスト > ドキュメント.xml > > > I am successfully created the distribution zip file but when I add a file > which is in Japanese character file name, it is include in the zip file but > the file name was garbled. > How to reproduce: add a file to be included in the distribution which file > name is in Japanese character. i will provide a sample file. -- 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: (MASSEMBLY-543) japanese filenames cannot be correctly assembled by maven-assembly-plugin
japanese filenames cannot be correctly assembled by maven-assembly-plugin - Key: MASSEMBLY-543 URL: http://jira.codehaus.org/browse/MASSEMBLY-543 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: Windows XP SP3 Japanese, Eclipse Ganymede 3.4.2 Reporter: Eros Sy Attachments: 新規テキスト ドキュメント.xml I am successfully created the distribution zip file but when I add a file which is in Japanese character file name, it is include in the zip file but the file name was garbled. How to reproduce: add a file to be included in the distribution which file name is in Japanese character. i will provide a sample file. -- 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-107) Output the dependencies in a consistent and natural order
[ http://jira.codehaus.org/browse/MDEP-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tuomas Kiviaho updated MDEP-107: Attachment: maven-dependency-plugin.patch maven-common-artifact-filters.patch Here are simple patches that preserve the natural order > Output the dependencies in a consistent and natural order > - > > Key: MDEP-107 > URL: http://jira.codehaus.org/browse/MDEP-107 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: tree >Affects Versions: 2.0 >Reporter: William Ferguson >Assignee: Brian Fox > Attachments: maven-common-artifact-filters.patch, > maven-dependency-plugin.patch > > > As of 2.0-alpha-5-SNAPSHOT 31-AUG-2007 the dependencies when output are in > random order as I suspect they come straight form a Set. > This makes it really difficult for a human to parse the dependencies. > Ordering them using the natural artifact order before output would be a great > improvement. > In particular dependency:tree is very hard to read when they are not ordered. > But if each level were ordered using the natural artifact ordering it would > be much easier to read and to work out where the dep problems lay. > [INFO] [dependency:tree] > [INFO] com.yarris.consol:consol-web:war:1.0-SNAPSHOT > [INFO]com.yarris:cielo:jar:1.5:compile > [INFO]javax.j2ee:j2ee:jar:1.3.1:compile > [INFO]commons-digester:commons-digester:jar:1.7:compile > [INFO]opensymphony:sitemesh:jar:2.2.1:compile > [INFO]commons-lang:commons-lang:jar:2.1:compile > [INFO]com.yarris.consol:consol-ejb:ejb:1.0-SNAPSHOT:compile > [INFO] org.apache.axis:axis:jar:1.4:compile > [INFO] backport-util-concurrent:backport-util-concurrent:jar:3.0:compile > [INFO] commons-discovery:commons-discovery:jar:0.2:compile > [INFO] commons-httpclient:commons-httpclient:jar:3.0:compile > [INFO] commons-codec:commons-codec:jar:1.3:compile > [INFO] commons-javaflow:commons-javaflow:jar:20060411:compile > [INFO] commons-pool:commons-pool:jar:1.1:compile > [INFO] xerces:xercesImpl:jar:2.0.2:compile > [INFO] com.yarris:hubbub-mail:jar:2.1:compile > [INFO] jasperreports:jasperreports:jar:1.3.0:compile > [INFO] xml-apis:xml-apis:jar:1.0.b2:compile > [INFO] eclipse:jdtcore:jar:3.1.0:compile > [INFO] org.apache.axis:axis-jaxrpc:jar:1.4:compile > [INFO] eclipse:jdt-compiler:jar:3.1.1:compile > [INFO] net.sourceforge.jexcelapi:jxl:jar:2.6.3:compile > [INFO] com.yarris:kapri:jar:1.0.1:compile > [INFO] org.ostermiller:ostermiller-utils:jar:1.04.00:compile > [INFO] com.pd4ml:pd4ml:jar:1.2.4:compile > [INFO] poi:poi-2.5.1-final:jar:20040804:compile > [INFO] javax.xml.soap:saaj-api:jar:1.2:compile > [INFO] com.yarris:samurai:jar:1.19:compile > [INFO] com.yarris:hubbub-log4j:jar:1.8:compile > [INFO] org.acegisecurity:acegi-security:jar:1.0.3:compile > [INFO] org.springframework:spring-remoting:jar:1.2.8:compile > [INFO]org.springframework:spring-dao:jar:1.2.8:compile > [INFO] org.springframework:spring-context:jar:1.2.8:compile > [INFO] org.springframework:spring-aop:jar:1.2.8:compile > [INFO]org.springframework:spring-webmvc:jar:1.2.8:compile > [INFO] org.springframework:spring-web:jar:1.2.8:compile > [INFO] org.springframework:spring-jdbc:jar:1.2.8:compile > [INFO]org.springframework:spring-beans:jar:1.2.8:compile > [INFO] org.springframework:spring-core:jar:1.2.8:compile > [INFO] org.springframework:spring-support:jar:1.2.8:runtime > [INFO] org.apache.velocity:velocity:jar:1.5:compile > [INFO] axis:axis-wsdl4j:jar:1.3:compile > [INFO] org.apache.ws:wss4j:jar:1.5.0:compile > [INFO] com.yarris:yarris-jms:jar:1.0:compile > [INFO] commons-io:commons-io:jar:1.2:compile > [INFO] opensymphony:oscache:jar:2.0.2:compile > [INFO] com.yarris.consol:consol-interfaces:jar:1.1:compile > [INFO] xmlbeans:xbean:jar:2.2.0:compile > [INFO]struts:struts-el:jar:1.1:compile > [INFO]com.yarris:sopho:jar:1.6:compile > [INFO] jdom:jdom:jar:1.0:compile > [INFO] log4j:log4j:jar:1.2.14:compile > [INFO] velocity:velocity-dep:jar:1.4:compile > [INFO]struts:struts:jar:1.1:compile > [INFO] struts:struts-legacy:jar:1.1:compile > [INFO] commons-validator:commons-validator:jar:1.0.2:compile > [INFO] oro:oro:jar:2.0.6:compile > [INFO] javax.sql:jdbc-stdext:jar:2.0:compile > [INFO]com.yarris:hubbub-web:jar:1.3:compile > [INFO]javax.servlet:jstl:jar:1.0.2:compile > [INFO]commons-fileupload:commons-fil
[jira] Commented: (SUREFIRE-639) Error inside systemOut parser: java.lang.IllegalStateException: testSetStarting called twice
[
http://jira.codehaus.org/browse/SUREFIRE-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252829#action_252829
]
Gin-Ting Chen commented on SUREFIRE-639:
This is occurring (again?) with 2.7.1.
This is running m3 with -T 1C (8 core build machine).
{code}[17:52:38]: [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test) on
project hornet-stinger: Error while executing forked tests.; nested exception
is java.lang.IllegalStateException: testSetCompleted called before
testSetStarting -> [Help 1]{code}
Seems like it doesn't happen as frequently as previously
> Error inside systemOut parser: java.lang.IllegalStateException:
> testSetStarting called twice
>
>
> Key: SUREFIRE-639
> URL: http://jira.codehaus.org/browse/SUREFIRE-639
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.6
> Environment: Windows 7
> java version "1.6.0_19"
> Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 16.2-b04, mixed mode)
> Maven 2.2.1
>Reporter: Michael Hinterseher
>Assignee: Kristian Rosenvold
> Fix For: 2.7
>
>
> After upgrading surefire/surefire report from 2.5 to 2.6 it fails after test
> are run with
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error while executing forked tests.; nested exception is
> org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException:
> Error
> inside systemOut parser
> testSetStarting called twice
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error while executing
> forked tests.; nested exception is
> org.apache.maven.surefire.booter.shade.org.code
> haus.plexus.util.cli.CommandLineException: Error inside systemOut parser
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error while
> executing forked tests.; nested exception is
> org.apache.maven.surefire.booter.shade.org.c
> odehaus.plexus.util.cli.CommandLineException: Error inside systemOut parser
> at
> org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:579)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException:
> Error while executing forked tests.; nested exception is
> org.apache.maven.surefire.boot
> er.shade.org.codehaus.plexus.util.cli.CommandLineException: Error inside
> systemOut parser
> at
> org.apache.maven.surefire.booter.SurefireBooter.fork(SurefireBooter.java:685)
> at
> org.apache.maven.surefire.booter.SurefireBooter.forkSui
[jira] Commented: (SCM-598) String index out of bounds while trying to commit limited file set to Git
[
http://jira.codehaus.org/browse/SCM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252825#action_252825
]
Aleksandr Zhuikov commented on SCM-598:
---
As you said: "f.getPath() might only return the relative path", but on line 57
you substring absolute path from this relative path.
I have to admit, that my fix seems to be wrong: if getPath() always returns
relative path, than the whole block does not make any sense.
Made simple test:
File file = new File("test.xml");
System.out.println(file.getPath());
System.out.println(file.getAbsolutePath());
Output:
test.xml
/home/aleksz/projects/koaba/SCMTest/test.xml
Out of bounds comes when you substring
"/home/aleksz/projects/koaba/SCMTest/".length() from "test.xml"
P.S
Ubuntu 10.10
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
> String index out of bounds while trying to commit limited file set to Git
> -
>
> Key: SCM-598
> URL: http://jira.codehaus.org/browse/SCM-598
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.4
> Environment: Ubuntu 10
>Reporter: Aleksandr Zhuikov
>Assignee: Olivier Lamy
> Fix For: 1.5
>
> Attachments: GitCommandLineUtils.java.patch, Screenshot.png
>
>
> I encountered String index out of bounds while trying to commit limited file
> set to Git.
> if statement was checking if file's absolute path was starting with working
> directory absoulute path, but stripping absoulute path from the value
> returned by getPath(). At least in Linux this getPath and getAbsolutePath did
> not return the same.
> I have actually submitted the fix to Github repo, but it appeared to be a
> wrong place :) Attachment has screenshot with diff from Github.
--
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: (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
http://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252814#action_252814
]
Bram commented on MRELEASE-511:
---
It looks like MapVersionsPhase.getNextVersion() is trying to be a bit too
smart. It tries to parse the current version number when it really shouldn't.
It should first check ReleaseDescriptor's releaseVersions map to see if it
contains a value for the next release. If not, then it should execute the
current flow.
I don't have time to create a patch for this now, and I don't know the release
plugin well enough to say if my above explanation is completely accurate, but
at first glance, I think it's close enough.
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: http://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
>
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.
[jira] Commented: (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
http://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252808#action_252808
]
Bram commented on MRELEASE-511:
---
Still present in 3.0 indeed. It fails on even the simplest versions, like
Test-1 or Test-1.0
What I don't get it why on earth the plugin tries to parse the version string
in the first place. I provided all required parameters (scm tag, release
version, next version) as command line options.
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: http://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
>
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> s
[jira] Commented: (SCM-598) String index out of bounds while trying to commit limited file set to Git
[ http://jira.codehaus.org/browse/SCM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252798#action_252798 ] Mark Struberg commented on SCM-598: --- another thing: can you please tell us what you got as parameter path and the getPath and getAbsolutePath values? txs! > String index out of bounds while trying to commit limited file set to Git > - > > Key: SCM-598 > URL: http://jira.codehaus.org/browse/SCM-598 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.4 > Environment: Ubuntu 10 >Reporter: Aleksandr Zhuikov >Assignee: Olivier Lamy > Fix For: 1.5 > > Attachments: GitCommandLineUtils.java.patch, Screenshot.png > > > I encountered String index out of bounds while trying to commit limited file > set to Git. > if statement was checking if file's absolute path was starting with working > directory absoulute path, but stripping absoulute path from the value > returned by getPath(). At least in Linux this getPath and getAbsolutePath did > not return the same. > I have actually submitted the fix to Github repo, but it appeared to be a > wrong place :) Attachment has screenshot with diff from Github. -- 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-598) String index out of bounds while trying to commit limited file set to Git
[ http://jira.codehaus.org/browse/SCM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252797#action_252797 ] Mark Struberg commented on SCM-598: --- hmm, to me the getAbsolutePath looks ok. The reason in the context is the following: f.getPath() _might_ only return the relative path (if no absolute is used in the configuration). Thus I use f.getAbsolutePath() to decide if we should get rid of the path prefix. This is needed because some git commands do not like absolute paths as parameters. What java version are you using, what linux version are you using? I successfully tested this with Sun java impls starting from 1.4.2 up to the latest 1.6.0_21 under Fedora 9-14 32 and 64 bit versions. LieGrue, strub > String index out of bounds while trying to commit limited file set to Git > - > > Key: SCM-598 > URL: http://jira.codehaus.org/browse/SCM-598 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.4 > Environment: Ubuntu 10 >Reporter: Aleksandr Zhuikov >Assignee: Olivier Lamy > Fix For: 1.5 > > Attachments: GitCommandLineUtils.java.patch, Screenshot.png > > > I encountered String index out of bounds while trying to commit limited file > set to Git. > if statement was checking if file's absolute path was starting with working > directory absoulute path, but stripping absoulute path from the value > returned by getPath(). At least in Linux this getPath and getAbsolutePath did > not return the same. > I have actually submitted the fix to Github repo, but it appeared to be a > wrong place :) Attachment has screenshot with diff from Github. -- 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-598) String index out of bounds while trying to commit limited file set to Git
[ http://jira.codehaus.org/browse/SCM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-598: - Patch Submitted: [Yes] > String index out of bounds while trying to commit limited file set to Git > - > > Key: SCM-598 > URL: http://jira.codehaus.org/browse/SCM-598 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.4 > Environment: Ubuntu 10 >Reporter: Aleksandr Zhuikov >Assignee: Olivier Lamy > Fix For: 1.5 > > Attachments: GitCommandLineUtils.java.patch, Screenshot.png > > > I encountered String index out of bounds while trying to commit limited file > set to Git. > if statement was checking if file's absolute path was starting with working > directory absoulute path, but stripping absoulute path from the value > returned by getPath(). At least in Linux this getPath and getAbsolutePath did > not return the same. > I have actually submitted the fix to Github repo, but it appeared to be a > wrong place :) Attachment has screenshot with diff from Github. -- 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-598) String index out of bounds while trying to commit limited file set to Git
[ http://jira.codehaus.org/browse/SCM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Zhuikov updated SCM-598: -- Attachment: GitCommandLineUtils.java.patch Attaching patch > String index out of bounds while trying to commit limited file set to Git > - > > Key: SCM-598 > URL: http://jira.codehaus.org/browse/SCM-598 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.4 > Environment: Ubuntu 10 >Reporter: Aleksandr Zhuikov >Assignee: Olivier Lamy > Fix For: 1.5 > > Attachments: GitCommandLineUtils.java.patch, Screenshot.png > > > I encountered String index out of bounds while trying to commit limited file > set to Git. > if statement was checking if file's absolute path was starting with working > directory absoulute path, but stripping absoulute path from the value > returned by getPath(). At least in Linux this getPath and getAbsolutePath did > not return the same. > I have actually submitted the fix to Github repo, but it appeared to be a > wrong place :) Attachment has screenshot with diff from Github. -- 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-107) Output the dependencies in a consistent and natural order
[ http://jira.codehaus.org/browse/MDEP-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252784#action_252784 ] Tuomas Kiviaho commented on MDEP-107: - To make things even worse this isn't just a human readability issue but actually a bug since build-classpath uses the same codebase and produces invalid output for big (over 32) dependency sets when hash algorithm that you anticipated kicks in and bollocks up the order. > Output the dependencies in a consistent and natural order > - > > Key: MDEP-107 > URL: http://jira.codehaus.org/browse/MDEP-107 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: tree >Affects Versions: 2.0 >Reporter: William Ferguson >Assignee: Brian Fox > > As of 2.0-alpha-5-SNAPSHOT 31-AUG-2007 the dependencies when output are in > random order as I suspect they come straight form a Set. > This makes it really difficult for a human to parse the dependencies. > Ordering them using the natural artifact order before output would be a great > improvement. > In particular dependency:tree is very hard to read when they are not ordered. > But if each level were ordered using the natural artifact ordering it would > be much easier to read and to work out where the dep problems lay. > [INFO] [dependency:tree] > [INFO] com.yarris.consol:consol-web:war:1.0-SNAPSHOT > [INFO]com.yarris:cielo:jar:1.5:compile > [INFO]javax.j2ee:j2ee:jar:1.3.1:compile > [INFO]commons-digester:commons-digester:jar:1.7:compile > [INFO]opensymphony:sitemesh:jar:2.2.1:compile > [INFO]commons-lang:commons-lang:jar:2.1:compile > [INFO]com.yarris.consol:consol-ejb:ejb:1.0-SNAPSHOT:compile > [INFO] org.apache.axis:axis:jar:1.4:compile > [INFO] backport-util-concurrent:backport-util-concurrent:jar:3.0:compile > [INFO] commons-discovery:commons-discovery:jar:0.2:compile > [INFO] commons-httpclient:commons-httpclient:jar:3.0:compile > [INFO] commons-codec:commons-codec:jar:1.3:compile > [INFO] commons-javaflow:commons-javaflow:jar:20060411:compile > [INFO] commons-pool:commons-pool:jar:1.1:compile > [INFO] xerces:xercesImpl:jar:2.0.2:compile > [INFO] com.yarris:hubbub-mail:jar:2.1:compile > [INFO] jasperreports:jasperreports:jar:1.3.0:compile > [INFO] xml-apis:xml-apis:jar:1.0.b2:compile > [INFO] eclipse:jdtcore:jar:3.1.0:compile > [INFO] org.apache.axis:axis-jaxrpc:jar:1.4:compile > [INFO] eclipse:jdt-compiler:jar:3.1.1:compile > [INFO] net.sourceforge.jexcelapi:jxl:jar:2.6.3:compile > [INFO] com.yarris:kapri:jar:1.0.1:compile > [INFO] org.ostermiller:ostermiller-utils:jar:1.04.00:compile > [INFO] com.pd4ml:pd4ml:jar:1.2.4:compile > [INFO] poi:poi-2.5.1-final:jar:20040804:compile > [INFO] javax.xml.soap:saaj-api:jar:1.2:compile > [INFO] com.yarris:samurai:jar:1.19:compile > [INFO] com.yarris:hubbub-log4j:jar:1.8:compile > [INFO] org.acegisecurity:acegi-security:jar:1.0.3:compile > [INFO] org.springframework:spring-remoting:jar:1.2.8:compile > [INFO]org.springframework:spring-dao:jar:1.2.8:compile > [INFO] org.springframework:spring-context:jar:1.2.8:compile > [INFO] org.springframework:spring-aop:jar:1.2.8:compile > [INFO]org.springframework:spring-webmvc:jar:1.2.8:compile > [INFO] org.springframework:spring-web:jar:1.2.8:compile > [INFO] org.springframework:spring-jdbc:jar:1.2.8:compile > [INFO]org.springframework:spring-beans:jar:1.2.8:compile > [INFO] org.springframework:spring-core:jar:1.2.8:compile > [INFO] org.springframework:spring-support:jar:1.2.8:runtime > [INFO] org.apache.velocity:velocity:jar:1.5:compile > [INFO] axis:axis-wsdl4j:jar:1.3:compile > [INFO] org.apache.ws:wss4j:jar:1.5.0:compile > [INFO] com.yarris:yarris-jms:jar:1.0:compile > [INFO] commons-io:commons-io:jar:1.2:compile > [INFO] opensymphony:oscache:jar:2.0.2:compile > [INFO] com.yarris.consol:consol-interfaces:jar:1.1:compile > [INFO] xmlbeans:xbean:jar:2.2.0:compile > [INFO]struts:struts-el:jar:1.1:compile > [INFO]com.yarris:sopho:jar:1.6:compile > [INFO] jdom:jdom:jar:1.0:compile > [INFO] log4j:log4j:jar:1.2.14:compile > [INFO] velocity:velocity-dep:jar:1.4:compile > [INFO]struts:struts:jar:1.1:compile > [INFO] struts:struts-legacy:jar:1.1:compile > [INFO] commons-validator:commons-validator:jar:1.0.2:compile > [INFO] oro:oro:jar:2.0.6:compile > [INFO] javax.sql:jdbc-stdext:jar:2.0:compile > [INFO]com.yarris:hubbub-web:jar:1.3:compile > [INFO]jav
[jira] Updated: (MSITE-546) "container" field of SiteDeployMojo not populated correctly -> NPE with servers containing configuration
[ http://jira.codehaus.org/browse/MSITE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-546: Component/s: Maven 3 Seems to be a m3 problem, it works with maven 2.2.1 and latest site plugin. > "container" field of SiteDeployMojo not populated correctly -> NPE with > servers containing configuration > > > Key: MSITE-546 > URL: http://jira.codehaus.org/browse/MSITE-546 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: Maven 3, site:deploy >Affects Versions: 3.0-beta-3 >Reporter: Carl Wilund > > In SiteDeployMojo, the field "container" is not populated correctly (version > skew with @Requirement?). When configureWagon is subsequently called, IFF the > site deploy server has an entry in settings.xml AND contains a > "configuration" subelement, there will be a NullPointerException thrown (line > 474) when container.lookup is called. > Simple repro: > settings.xml: > ... > > bogus > bogus > bogus > > > > ... > pom.xml: > ... > > > > org.apache.maven.plugins > maven-site-plugin > 3.0-beta-3 > > > > > > bogus > Bogus > sftp://bogus.bogus.org/bogus > > > ... > While this should obviously not work, it should not NPE at line 474. -- 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-266) Add parameter to configure copy-dependencies to also copy optional dependencies
[ http://jira.codehaus.org/browse/MDEP-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252782#action_252782 ] Tuomas Kiviaho commented on MDEP-266: - I draw hasty conclusions about this issue. Optional dependencies declared in project are included as per my personal tests but optional dependencies of project's transitive dependencies are not (unless they are re-declared in the project), if I'm correct this time around. This would be the standard procedure and I doubt that it would be trivial to include optional dependencies behind transitive dependencies since they are not available for the plugin when it starts the filtering PS. I noticed that there's currently no way to exclude optional dependencies (and their transitive dependencies) of the project. PPS. My problem with classpath seems to be reported already at MDEP-107 > Add parameter to configure copy-dependencies to also copy optional > dependencies > --- > > Key: MDEP-266 > URL: http://jira.codehaus.org/browse/MDEP-266 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: copy-dependencies >Affects Versions: 2.1 >Reporter: Andreas Sewe >Assignee: Brian Fox >Priority: Minor > > At the moment, copy-dependencies only copies non-optional dependencies. > However, one sometimes wants to copy *all* dependencies -- even the optional > ones. -- 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-598) String index out of bounds while trying to commit limited file set to Git
[ http://jira.codehaus.org/browse/SCM-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-598: - Patch Submitted: (was: [Yes]) Fix Version/s: 1.5 Assignee: Olivier Lamy yes please provide a patch with svn diff . > String index out of bounds while trying to commit limited file set to Git > - > > Key: SCM-598 > URL: http://jira.codehaus.org/browse/SCM-598 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.4 > Environment: Ubuntu 10 >Reporter: Aleksandr Zhuikov >Assignee: Olivier Lamy > Fix For: 1.5 > > Attachments: Screenshot.png > > > I encountered String index out of bounds while trying to commit limited file > set to Git. > if statement was checking if file's absolute path was starting with working > directory absoulute path, but stripping absoulute path from the value > returned by getPath(). At least in Linux this getPath and getAbsolutePath did > not return the same. > I have actually submitted the fix to Github repo, but it appeared to be a > wrong place :) Attachment has screenshot with diff from Github. -- 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
