[jira] Created: (CONTINUUM-1556) Empty Group Description causes Freemarker error in Group Edit mode
Empty Group Description causes Freemarker error in Group Edit mode
--
Key: CONTINUUM-1556
URL: http://jira.codehaus.org/browse/CONTINUUM-1556
Project: Continuum
Issue Type: Bug
Reporter: Andreas Guther
Cannot edit Group if description field is initially empty. Below copy of email
exchange with more details. I have also attached at the bottom of the entry
the Freemarker error stack.
-Original Message-
From: Andreas Guther [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09, 2007 4:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [1.1-beta-3] Description: $build.buildDefinition.description
That seems to be a bug. First I think if the description is empty than there
should be an empty entry in the email rather than the variable name.
Then I noticed that when trying to add the description later with Edit under
Group I cannot save the changes but see a huge FreeMarker Template Error stack
in yellow.
I will file a bug on this.
Andreas
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09, 2007 1:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [1.1-beta-3] Description: $build.buildDefinition.description
Edit the build definition used by your project (project group or project level)
and set the description field.
Emmanuel
Andreas Guther a écrit :
> I see the following line in my build status mail notifications:
>
> Description: $build.buildDefinition.description
>
> It comes up under the Build Definition section. Where is this entry
> defined or missing so I can add the missing content?
>
> Andreas
>
>
>
>
> Build Defintion:
>
>
> POM filename: pom.xml
> Goals: clean install
> Arguments: --batch-mode --non-recursive
> Build Fresh: false
> Always Build: false
> Default Build Definition: true
> Schedule: DEFAULT_SCHEDULE
> Description: $build.buildDefinition.description
>
>
FreeMarker Error Stack
===
FreeMarker template error!
Error on line 48, column 13 in template/simple/select.ftl
stack.findString(parameters.listValue) is undefined.
It cannot be assigned to itemValue
The problematic instruction:
--
==> assignment: itemValue=stack.findString(parameters.listValue) [on line
48, column 13 in template/simple/select.ftl]
in user-directive ww.iterator [on line 40, column 1 in
template/simple/select.ftl]
in include "/${parameters.templateDir}/simple/select.ftl" [on line 2, column 1
in template/default/select.ftl]
--
Java backtrace for programmers:
--
freemarker.core.InvalidReferenceException: Error on line 48, column 13 in
template/simple/select.ftl
stack.findString(parameters.listValue) is undefined.
It cannot be assigned to itemValue
at freemarker.core.Assignment.accept(Assignment.java:111)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.IfBlock.accept(IfBlock.java:82)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.visit(Environment.java:233)
at freemarker.core.UnifiedCall.accept(UnifiedCall.java:116)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.include(Environment.java:1375)
at freemarker.core.Include.accept(Include.java:155)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.process(Environment.java:176)
at freemarker.template.Template.process(Template.java:231)
at
com.opensymphony.webwork.components.template.FreemarkerTemplateEngine.renderTemplate(FreemarkerTemplateEngine.java:126)
at
com.opensymphony.webwork.components.UIBean.mergeTemplate(UIBean.java:642)
at com.opensymphony.webwork.components.UIBean.end(UIBean.java:596)
at
com.opensymphony.webwork.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:21)
at
org.apache.jsp.WEB_002dINF.jsp.projectGroupEdit_jsp._jspx_meth_ww_select_0(projectGroupEdit_jsp.java:698)
at
org.apache.jsp.WEB_002dINF.jsp.projectGroupEdit_jsp._jspx_meth_ww_iterator_0(projectGroupEdit_jsp.java:596)
at
org.apache.jsp.WEB_002dINF.jsp.projectGroupEdit_jsp._jspx_meth_ww_form_0(projectGroupEdit_jsp.java:286)
a
[jira] Created: (CONTINUUM-1555) Password set by Administrator is not verified against security rules
Password set by Administrator is not verified against security rules Key: CONTINUUM-1555 URL: http://jira.codehaus.org/browse/CONTINUUM-1555 Project: Continuum Issue Type: Bug Reporter: Andreas Guther I have created user accounts using an administration account. The password entered here is not verified against the security rules (at least one number). I entered simple passwords and enabled that the user has to change the password. User complained that their given password does not work. It appears that Continuum is not accepting the password if it does not follow the rules during logon check. Expected: The admin user set-up must have the same password validation checks as for the normal users when they change their password. I am not sure if my impression is correct that the logon does not validate the password against the system if the password does not conform with the password pattern rules. But if that is the case, the system should not validate the password during logon against the rule. It should only check the password against the stored one. -- 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: (MSUREFIRE-185) Typo in JavaDoc comment of deprecated classorg.apache.maven.test.SurefirePlugin
Typo in JavaDoc comment of deprecated classorg.apache.maven.test.SurefirePlugin --- Key: MSUREFIRE-185 URL: http://jira.codehaus.org/browse/MSUREFIRE-185 Project: Maven 2.x Surefire Plugin Issue Type: Bug Components: documentation Affects Versions: 2.3 Reporter: Andreas Guther Priority: Trivial Attachments: patch.txt The deprecated documentation for "use instead" of the JavaDoc has a typo: the package name contains a letter s. Patch attached. -- 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-2340) Incorrect dependency version downloaded
[ http://jira.codehaus.org/browse/MNG-2340?page=comments#action_81469 ]
Andreas Guther commented on MNG-2340:
-
I was not aware that this is also a problem in the mvn site generating plug-in.
Does an entry for this problem exist for the maven site plug-in as well?
> Incorrect dependency version downloaded
> ---
>
> Key: MNG-2340
> URL: http://jira.codehaus.org/browse/MNG-2340
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.0.4
>Reporter: Adrian
>Priority: Critical
> Fix For: 2.1
>
> Attachments: MNGECLIPSE-131.zip
>
>
> I have a parent pom with a dependency management section specifying the
> version of an artifact to use. In the child project, I override this version.
> The maven plugin ignores the overriding version and downloads the version
> specified by the parent pom.
> For example, in the parent pom
> {code}
>
> lucene
> lucene
> 1.4.3
>
> {code}
> in the project pom, inheriting the parent pom
> {code}
>
> lucene
> lucene
> 2.0
>
> {code}
> The maven eclipse plugin downloads version 1.4.3 for my project
--
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: (MECLIPSE-107) Dependency Version Incorrectly Taken from DependencyManagement
[ http://jira.codehaus.org/browse/MECLIPSE-107?page=comments#action_81468 ] Andreas Guther commented on MECLIPSE-107: - Managed dependencies need to be taken into account, but they need to be overwritten by the component pom in those cases where the component pom needs to specify the version against the definition in the parent pom. This is the behavior in Maven and must be the same in the Eclipse plugin. I have the scenario where we manage our version in a parent pom with the dependencyManagement section. Usually our components do not specify the version which then is taken as specified in the parent pom. Just today I had the situation where I needed to overwrite the version in only one component for test reasons. Getting the fix is highly appreciated. > Dependency Version Incorrectly Taken from DependencyManagement > -- > > Key: MECLIPSE-107 > URL: http://jira.codehaus.org/browse/MECLIPSE-107 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.2 >Reporter: Stephen Duncan Jr >Priority: Critical > Attachments: dmtest.zip > > > The version used when generating .classpath is taken from > dependencyManagement even though the child pom sets the dependency version, > which should override what is in dependencyManagement. This is a regression > from the correct behaviour in 2.1. > The attached project demonstrates the problem. The .classpath file generated > for the "child" project should specify log4j-1.2.13, but instead specifies > 1.28. -- 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: (MPWAR-67) Classifier in jar file name is removed once assembled into war file
Classifier in jar file name is removed once assembled into war file --- Key: MPWAR-67 URL: http://jira.codehaus.org/browse/MPWAR-67 Project: maven-war-plugin Issue Type: Bug Environment: Maven 2.0.4, JDK 1.5, maven-war-plugin version 2.0 Reporter: Andreas Guther We use the Maven classifier to distinguish between different jar files of the same version build for different purposes. An example would be the classifier used for TestNG to distinguish between jdk15 and jdk14 jar files. I noticed that the jar file (for example test-1.0-classifier.jar) ends up in the WEB-INF/lib folder with the classifier removed (i.e. following the example test.1.0.jar). This is unexpected and confusing. Since there is very little documentation about the expected behavior while using classifiers, it is not clear if this is intenionally or a bug. If intenionally, it should be mentioned in the maven-war-plugin documentation. Maybe in that case it would be an enhancement to configure if the classifier should be preserved or removed. However, the current behavior is undocumented and unexpected. -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_74371 ] Andreas Guther commented on MCOMPILER-22: - Hi, is this patch already applied and maybe available with a SNAPSHOT version? Andreas > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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:585) > 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.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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: (MSUREFIRE-98) JUnit Tests are not executed if TestNG configuration file is used to invoke TestNG tests
[ http://jira.codehaus.org/browse/MSUREFIRE-98?page=comments#action_64573 ] Andreas Guther commented on MSUREFIRE-98: - Correction regarding environment: Actually the environment was not listed correctly. I am running with Java 1.5 but generate 1.4 code. TestNG is configured with JavaDoc annotations. > JUnit Tests are not executed if TestNG configuration file is used to invoke > TestNG tests > > > Key: MSUREFIRE-98 > URL: http://jira.codehaus.org/browse/MSUREFIRE-98 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.4, Java 1.4, Surefire from Snapshot server > Reporter: Andreas Guther > Attachments: my-app.zip > > > I have JUnit tests and TestNG unit tests in the same project. If I use a > TestNG XML configurartion file only the files (TestNG) listed in the > configuration file are executed. JUnit test files are ignored. TestNG > allows to include JUnit tests in the configuration, but I would expect that > JUnit tests should be found based on the standard naming pattern and in > addition TestNG classes as listed in the TestNG XML config file are executed > as well. > Expected that JUnit files are executed and in addition TestNG files. It > should be possible to use different test frameworks in the same project. > I will attach the example project. > Output: > C:\workspace\my-app>mvn test > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Are JUnit Tests Ignored if TestNG Config XML is used? > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [surefire:test] > [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports > --- > T E S T S > --- > Running Test with JavaDoc Annotations under Java 1.4 > com.mycompany.app.JavaOneFourTngSample: beforeClass > com.mycompany.app.JavaOneFourTngSample: beforeMethod > com.mycompany.app.JavaOneFourTngSample: someTestMethod > com.mycompany.app.JavaOneFourTngSample: beforeMethod > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec <<< > FAILURE! > Results : > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 > [ERROR] There are test failures. > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Tue May 02 09:38:59 PDT 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- 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: (MSUREFIRE-98) JUnit Tests are not executed if TestNG configuration file is used to invoke TestNG tests
[ http://jira.codehaus.org/browse/MSUREFIRE-98?page=all ] Andreas Guther updated MSUREFIRE-98: Attachment: my-app.zip > JUnit Tests are not executed if TestNG configuration file is used to invoke > TestNG tests > > > Key: MSUREFIRE-98 > URL: http://jira.codehaus.org/browse/MSUREFIRE-98 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.4, Java 1.4, Surefire from Snapshot server > Reporter: Andreas Guther > Attachments: my-app.zip > > > I have JUnit tests and TestNG unit tests in the same project. If I use a > TestNG XML configurartion file only the files (TestNG) listed in the > configuration file are executed. JUnit test files are ignored. TestNG > allows to include JUnit tests in the configuration, but I would expect that > JUnit tests should be found based on the standard naming pattern and in > addition TestNG classes as listed in the TestNG XML config file are executed > as well. > Expected that JUnit files are executed and in addition TestNG files. It > should be possible to use different test frameworks in the same project. > I will attach the example project. > Output: > C:\workspace\my-app>mvn test > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Are JUnit Tests Ignored if TestNG Config XML is used? > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [surefire:test] > [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports > --- > T E S T S > --- > Running Test with JavaDoc Annotations under Java 1.4 > com.mycompany.app.JavaOneFourTngSample: beforeClass > com.mycompany.app.JavaOneFourTngSample: beforeMethod > com.mycompany.app.JavaOneFourTngSample: someTestMethod > com.mycompany.app.JavaOneFourTngSample: beforeMethod > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec <<< > FAILURE! > Results : > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 > [ERROR] There are test failures. > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Tue May 02 09:38:59 PDT 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- 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: (MSUREFIRE-98) JUnit Tests are not executed if TestNG configuration file is used to invoke TestNG tests
JUnit Tests are not executed if TestNG configuration file is used to invoke TestNG tests Key: MSUREFIRE-98 URL: http://jira.codehaus.org/browse/MSUREFIRE-98 Project: Maven 2.x Surefire Plugin Type: Bug Environment: Windows XP, Maven 2.0.4, Java 1.4, Surefire from Snapshot server Reporter: Andreas Guther Attachments: my-app.zip I have JUnit tests and TestNG unit tests in the same project. If I use a TestNG XML configurartion file only the files (TestNG) listed in the configuration file are executed. JUnit test files are ignored. TestNG allows to include JUnit tests in the configuration, but I would expect that JUnit tests should be found based on the standard naming pattern and in addition TestNG classes as listed in the TestNG XML config file are executed as well. Expected that JUnit files are executed and in addition TestNG files. It should be possible to use different test frameworks in the same project. I will attach the example project. Output: C:\workspace\my-app>mvn test [INFO] Scanning for projects... [INFO] [INFO] Building Are JUnit Tests Ignored if TestNG Config XML is used? [INFO]task-segment: [test] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports --- T E S T S --- Running Test with JavaDoc Annotations under Java 1.4 com.mycompany.app.JavaOneFourTngSample: beforeClass com.mycompany.app.JavaOneFourTngSample: beforeMethod com.mycompany.app.JavaOneFourTngSample: someTestMethod com.mycompany.app.JavaOneFourTngSample: beforeMethod Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec <<< FAILURE! Results : Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 [ERROR] There are test failures. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue May 02 09:38:59 PDT 2006 [INFO] Final Memory: 4M/508M [INFO] -- 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: (MSUREFIRE-97) TestNG tests are not executed if invoked by */*Test.java naming pattern
[ http://jira.codehaus.org/browse/MSUREFIRE-97?page=all ] Andreas Guther updated MSUREFIRE-97: Attachment: my-app-2.zip > TestNG tests are not executed if invoked by */*Test.java naming pattern > --- > > Key: MSUREFIRE-97 > URL: http://jira.codehaus.org/browse/MSUREFIRE-97 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.4, Surefire from snapshot server > Reporter: Andreas Guther > Attachments: my-app-2.zip > > > I created an example project and added two testng tests, one ending with > *Test.java, one with a not Test containing name. Surefire seems to be able > to find the test but does not execute the tests inside the class (one should > succeed, one should fail). The console output is below. I will attach my > example project in zip format to the issue report. > C:\workspace\my-app>mvn test > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > Compiling 2 source files to C:\workspace\my-app\target\test-classes > [INFO] [surefire:test] > [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports > --- > T E S T S > --- > Running com.mycompany.app.AppTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec > Running com.mycompany.app.TestNgJavaOneTngTest > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec > Results : > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Tue May 02 07:14:11 PDT 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- 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: (MSUREFIRE-97) TestNG tests are not executed if invoked by */*Test.java naming pattern
TestNG tests are not executed if invoked by */*Test.java naming pattern --- Key: MSUREFIRE-97 URL: http://jira.codehaus.org/browse/MSUREFIRE-97 Project: Maven 2.x Surefire Plugin Type: Bug Environment: Windows XP, Maven 2.0.4, Surefire from snapshot server Reporter: Andreas Guther I created an example project and added two testng tests, one ending with *Test.java, one with a not Test containing name. Surefire seems to be able to find the test but does not execute the tests inside the class (one should succeed, one should fail). The console output is below. I will attach my example project in zip format to the issue report. C:\workspace\my-app>mvn test [INFO] Scanning for projects... [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [test] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 2 source files to C:\workspace\my-app\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports --- T E S T S --- Running com.mycompany.app.AppTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running com.mycompany.app.TestNgJavaOneTngTest Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue May 02 07:14:11 PDT 2006 [INFO] Final Memory: 4M/508M [INFO] -- 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: (MSUREFIRE-85) Surefire does not run TestNG tests with JavaDoc annotations under Java 5
[ http://jira.codehaus.org/browse/MSUREFIRE-85?page=all ] Andreas Guther updated MSUREFIRE-85: Attachment: my-app.zip > Surefire does not run TestNG tests with JavaDoc annotations under Java 5 > - > > Key: MSUREFIRE-85 > URL: http://jira.codehaus.org/browse/MSUREFIRE-85 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.3, Surefire plug-in, TestNG 4.7, Java 5 > Reporter: Andreas Guther > Assignee: Brett Porter > Attachments: my-app.zip > > > I have TestNG tests with Java 1.4 JavaDoc annotations. The tests are > executed with a testng.xml file. I need to be able to execute those tests > under Java 5. As it appears Surefire seems not to be able to recognize those > TestNG tests with Java 1.4 annotations and does not execute a single test > listed in the TestNG.xml test suite file. > Relevant parts of my configuration are as follows: > > org.testng > testng > 4.7 > test > jdk14 > > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.4 > 1.4 > > > > maven-surefire-plugin > > > true > > > src/test/resources/testng-xml-export.xml > > > > ... > > > apache.snapshots > > http://cvs.apache.org/maven-snapshot-repository > > > Maven Snapshots > http://snapshots.maven.codehaus.org/maven2/ > > true > > > false > > > > testng.xml > > > > >name="mt.ztelligence.questionnaire.SurveyProjectXMlDataInjectorTestNg" /> > >name="mt.ztelligence.survey.util.SurveyBuilderDataExtractorTestNg"/> > > > -- 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: (MSUREFIRE-85) Surefire does not run TestNG tests with JavaDoc annotations under Java 5
[ http://jira.codehaus.org/browse/MSUREFIRE-85?page=comments#action_64562 ] Andreas Guther commented on MSUREFIRE-85: - I must admit that I can now (?) run the tests as expected as well. I created a sample project and added two TestNG classes, one ending with Test and one without. The one with Test at the end was run but the tests (two) were not executed: C:\workspace\my-app>mvn test [INFO] Scanning for projects... [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [test] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 2 source files to C:\workspace\my-app\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports --- T E S T S --- Running com.mycompany.app.AppTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running com.mycompany.app.TestNgJavaOneTngTest Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue May 02 07:14:11 PDT 2006 [INFO] Final Memory: 4M/508M [INFO] When I use a testng configuration file the tests are executed: --- T E S T S --- Running Test with JavaDoc Annotations under Java 1.4 com.mycompany.app.JavaOneFourTngSample: beforeClass com.mycompany.app.JavaOneFourTngSample: beforeMethod com.mycompany.app.JavaOneFourTngSample: someTestMethod com.mycompany.app.JavaOneFourTngSample: beforeMethod Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec <<< FAILURE! Results : Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 [ERROR] There are test failures. It also appears that the JUnit test is not ignored. Is there only an either/or but not JUnit and TestNG together? I know, I can include JUnit tests in the TestNG file, but finding them based on a pattern and executing them both would be nice. I will attache my example project with configuration and files. > Surefire does not run TestNG tests with JavaDoc annotations under Java 5 > - > > Key: MSUREFIRE-85 > URL: http://jira.codehaus.org/browse/MSUREFIRE-85 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.3, Surefire plug-in, TestNG 4.7, Java 5 > Reporter: Andreas Guther > Assignee: Brett Porter > > > I have TestNG tests with Java 1.4 JavaDoc annotations. The tests are > executed with a testng.xml file. I need to be able to execute those tests > under Java 5. As it appears Surefire seems not to be able to recognize those > TestNG tests with Java 1.4 annotations and does not execute a single test > listed in the TestNG.xml test suite file. > Relevant parts of my configuration are as follows: > > org.testng > testng > 4.7 > test > jdk14 > > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.4 > 1.4 > > > > maven-surefire-plugin > > > true > > > src/test/resources/testng-xml-export.xml > > > > ... > > > apache.snapshots > > http://cvs.apache.org/maven-snapshot-repository > > > Maven Snapshots > http://snapshots.maven.codehaus.org/maven2/ >
[jira] Commented: (MSUREFIRE-85) Surefire does not run TestNG tests with JavaDoc annotations under Java 5
[ http://jira.codehaus.org/browse/MSUREFIRE-85?page=comments#action_64524 ] Andreas Guther commented on MSUREFIRE-85: - Brett, Thank you very much for looking into this. Unfortunately I have the impression that you might have looked at the issue from a different scenario than the one I have described. I certainly did not try the scenario with classes with the naming pattern of */*Test.java. The point is that there should not be a naming pattern necessary if a testng XML configuration file is present and referenced in the way I have documented it - unless the testng XML configuration file is not evaluated at all. If you look at the testng config file you will see that there are three classes listed that should be executed as tests. If I need to use a naming pattern (default or configured) then the testng config file is worthless and that I believe would have to be stated in the documentation. >From information gathered from mailing lists I am under the impression that >the surefire configuration part is for specifying the testng xml file. Please >correct if this is a wrong impression. I would like to suggest to re-open the issue and investigate against a setting with a non standard naming pattern and with classes only listed in the testng XML configuration file. Please let me know if you need more information. > Surefire does not run TestNG tests with JavaDoc annotations under Java 5 > - > > Key: MSUREFIRE-85 > URL: http://jira.codehaus.org/browse/MSUREFIRE-85 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.3, Surefire plug-in, TestNG 4.7, Java 5 > Reporter: Andreas Guther > Assignee: Brett Porter > > > I have TestNG tests with Java 1.4 JavaDoc annotations. The tests are > executed with a testng.xml file. I need to be able to execute those tests > under Java 5. As it appears Surefire seems not to be able to recognize those > TestNG tests with Java 1.4 annotations and does not execute a single test > listed in the TestNG.xml test suite file. > Relevant parts of my configuration are as follows: > > org.testng > testng > 4.7 > test > jdk14 > > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.4 > 1.4 > > > > maven-surefire-plugin > > > true > > > src/test/resources/testng-xml-export.xml > > > > ... > > > apache.snapshots > > http://cvs.apache.org/maven-snapshot-repository > > > Maven Snapshots > http://snapshots.maven.codehaus.org/maven2/ > > true > > > false > > > > testng.xml > > > > >name="mt.ztelligence.questionnaire.SurveyProjectXMlDataInjectorTestNg" /> > >name="mt.ztelligence.survey.util.SurveyBuilderDataExtractorTestNg"/> > > > -- 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-40) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/WAGON-40?page=comments#action_64017 ] Andreas Guther commented on WAGON-40: - The described behavior seems to be gone with Maven 2.0.4. Today I used the command line to distribute different sites multiple times and all deployments went through without problems. I still have the same scenario with deploying via the file system and mapped drives to a different server. > Does not deploy to existing folder > -- > > Key: WAGON-40 > URL: http://jira.codehaus.org/browse/WAGON-40 > Project: wagon > Type: Bug > Components: wagon-file > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Assignee: Henry S. Isidro > Priority: Critical > Fix For: 1.0-beta-1 > Attachments: site.error.txt > > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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:585) > 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 uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- This message is automatically generated by
[jira] Created: (MNG-2202) Improve pom to handle daylight saving changes
Improve pom to handle daylight saving changes - Key: MNG-2202 URL: http://jira.codehaus.org/browse/MNG-2202 Project: Maven 2 Type: Improvement Reporter: Andreas Guther Priority: Minor It would be great if the timezone element in Maven 2 could be extendend in a way that makes it able to determine the offset own its own as well as to be able to make adjustments to daylight savings. The following suggestion from the Maven Users mailing list seems to be an interesting approach. Note: In addition to the posting from Ian Stewart I would like to add that I believe that the offset element is not needed in case the timezone has a name and the dayligh savings element. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 6:36 AM To: Maven Users List Subject: Re: TimeZone Element in pom.xml Note that the observation of Summertime/Daylight Savings Time does not change the timezone where a developer resides. Instead of changing everybody's timezone twice a year, I would recommend making the timezone element its own complex type, more inline with the java.util.TimeZone class: Eastern -5 true It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 "Andreas Guther" <[EMAIL PROTECTED]To: "Maven Users List" ttools.com> cc: Subject: TimeZone Element in pom.xml 04/04/2006 12:43 AM Please respond to "Maven Users List" Hi, Is there a way in Maven to adjust the TimeZone element in the pom.xml to daylight savings time? We have an international team and I like the fact that we can see on the maven generated web site's team list what time it is for a specific developer. What I am missing is the automatic adjustment for example for my time zone which is in winter times -8 and in summer times -7. I just made a global search and replace in my pom.xml but actually it would be more convenient maven could do that for me. Is there anything that helps me solving the problem or is this worth an enhancement request? Andreas -- 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: (MSUREFIRE-85) Surefire does not run TestNG tests with JavaDoc annotations under Java 5
Surefire does not run TestNG tests with JavaDoc annotations under Java 5 - Key: MSUREFIRE-85 URL: http://jira.codehaus.org/browse/MSUREFIRE-85 Project: Maven 2.x Surefire Plugin Type: Bug Environment: Windows XP, Maven 2.0.3, Surefire plug-in, TestNG 4.7, Java 5 Reporter: Andreas Guther I have TestNG tests with Java 1.4 JavaDoc annotations. The tests are executed with a testng.xml file. I need to be able to execute those tests under Java 5. As it appears Surefire seems not to be able to recognize those TestNG tests with Java 1.4 annotations and does not execute a single test listed in the TestNG.xml test suite file. Relevant parts of my configuration are as follows: org.testng testng 4.7 test jdk14 org.apache.maven.plugins maven-compiler-plugin 1.4 1.4 maven-surefire-plugin true src/test/resources/testng-xml-export.xml ... apache.snapshots http://cvs.apache.org/maven-snapshot-repository Maven Snapshots http://snapshots.maven.codehaus.org/maven2/ true false testng.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] Commented: (MSITE-107) Does not deploy to existing folder
[ http://jira.codehaus.org/browse/MSITE-107?page=comments#action_61955 ] Andreas Guther commented on MSITE-107: -- I need to add that I have the following configuration for the distribution management: ztel.trunk zTelligence Trunk file://W:/projects/ztel-trunk > Does not deploy to existing folder > -- > > Key: MSITE-107 > URL: http://jira.codehaus.org/browse/MSITE-107 > Project: Maven 2.x Site Plugin > Type: Bug > Environment: Windows XP, Windows 2003 server, Maven 2.0.2 > Reporter: Andreas Guther > Attachments: site.error.txt > > > I have mapped a drive to our site deployment server on a windows 2003 server. > The deploy works fine if the target folder does not exist. If the project > was previously deployed the deploy target will fail with the error as > included below. I would expect that the deploy overwrites the content in an > existing folder. > C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building zTelligence > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > file://W:/projects/ztel-trunk - Session: Opened > file://W:/projects/ztel-trunk - Session: Disconnecting > file://W:/projects/ztel-trunk - Session: Disconnected > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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:585) > 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 uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.wagon.TransferFailedException: Could not make > directory 'W:\projects\ztel-trunk\.'. > at > org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) > ... 18 more > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Adminis
[jira] Created: (MSITE-107) Does not deploy to existing folder
Does not deploy to existing folder -- Key: MSITE-107 URL: http://jira.codehaus.org/browse/MSITE-107 Project: Maven 2.x Site Plugin Type: Bug Environment: Windows XP, Windows 2003 server, Maven 2.0.2 Reporter: Andreas Guther Attachments: site.error.txt I have mapped a drive to our site deployment server on a windows 2003 server. The deploy works fine if the target folder does not exist. If the project was previously deployed the deploy target will fail with the error as included below. I would expect that the deploy overwrites the content in an existing folder. C:\workspace\dev.ztel.mt.trunk>mvn site:deploy -e + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'site'. [INFO] [INFO] Building zTelligence [INFO]task-segment: [site:deploy] [INFO] [INFO] [site:deploy] file://W:/projects/ztel-trunk - Session: Opened file://W:/projects/ztel-trunk - Session: Disconnecting file://W:/projects/ztel-trunk - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Could not make directory 'W:\projects\ztel-trunk\.'. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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:585) 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 uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:162) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.apache.maven.wagon.TransferFailedException: Could not make directory 'W:\projects\ztel-trunk\.'. at org.apache.maven.wagon.providers.file.FileWagon.putDirectory(FileWagon.java:113) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:154) ... 18 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sat Mar 25 09:22:14 PST 2006 [INFO] Final Memory: 4M/508M [INFO] -- 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
