[jira] (WAGON-409) Wagon-webdav-jackrabbit throws Class Not Found Exception.
[ https://jira.codehaus.org/browse/WAGON-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340562#comment-340562 ] Eric Barboni commented on WAGON-409: Thanks for the informations. It is working now. > Wagon-webdav-jackrabbit throws Class Not Found Exception. > - > > Key: WAGON-409 > URL: https://jira.codehaus.org/browse/WAGON-409 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 2.5, 2.6 > Environment: Maven 3.1.1, fedora, jenkins >Reporter: Eric Barboni >Priority: Critical > Attachments: log.txt > > > I try to upgrade to the 2.6 version of jackrabbit wagon on a previoulsy > working project (with version 2.4). > During instantiation of MultiThreadedHttpConnectionManager the LogFactory > class is not available and break deploy. > The removal of dependencies wagon-http-shared after 2.4 seems to be the cause > of the issue. http-shared was providing commons logging as transitive > dependencies ofr jackrabbit. > Best Regards > I copy paste extract from the jenkins logs in attachement. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-409) Wagon-webdav-jackrabbit throws Class Not Found Exception.
[ https://jira.codehaus.org/browse/WAGON-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Barboni closed WAGON-409. -- Resolution: Not A Bug Pierre url reformat make it work. This is a hard to find convention in the wagon docs. > Wagon-webdav-jackrabbit throws Class Not Found Exception. > - > > Key: WAGON-409 > URL: https://jira.codehaus.org/browse/WAGON-409 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 2.5, 2.6 > Environment: Maven 3.1.1, fedora, jenkins >Reporter: Eric Barboni >Priority: Critical > Attachments: log.txt > > > I try to upgrade to the 2.6 version of jackrabbit wagon on a previoulsy > working project (with version 2.4). > During instantiation of MultiThreadedHttpConnectionManager the LogFactory > class is not available and break deploy. > The removal of dependencies wagon-http-shared after 2.4 seems to be the cause > of the issue. http-shared was providing commons logging as transitive > dependencies ofr jackrabbit. > Best Regards > I copy paste extract from the jenkins logs in attachement. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-463) ClassCastException when using testng suiteXmlFile and forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340567#comment-340567 ] Andreas Höhmann commented on SUREFIRE-463: -- I'm using 2.16. and this bug is back :-) mvn help:effective-pom ... maven-surefire-plugin 2.16 default-test test test 2.5C true none false true **/Abstract*Test.java **/Abstract*TestCase.java D:\DEV\ws_hscm\hscm-vaadin-webapp/src/test/resources/Testsuite.xml true ... > ClassCastException when using testng suiteXmlFile and forkMode=always > - > > Key: SUREFIRE-463 > URL: https://jira.codehaus.org/browse/SUREFIRE-463 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4.2 > Environment: linux 2.6.22-1-mepis-smp >Reporter: Andreas Andreou > Fix For: 2.4.3 > > Attachments: SUREFIRE-463__handle_TestNG_xmlTestSuites.patch, > surefire-bug.zip > > > The related pom part is: > > browser > > > > org.apache.maven.plugins > maven-surefire-plugin > > > > src/test/resources/testng-browser.xml > > > > > > > Issuing mvn -Pbrowser test results in the exception: > java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:403) > at > org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249) > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:492) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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) > Any workarounds for this? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-457) Clarify documentation around module.name and module.dir
Konrad Windszus created ARCHETYPE-457: - Summary: Clarify documentation around module.name and module.dir Key: ARCHETYPE-457 URL: https://jira.codehaus.org/browse/ARCHETYPE-457 Project: Maven Archetype Issue Type: Bug Reporter: Konrad Windszus >From the reference at >https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html#class_module > is is unclear how the attribute name is evaluated. For me the following >behaviour would make sense - dir: the name of the source directory (from which the new module will be created) - name: the name of the module directory (destination). Usually is equivalent to artifactId. Currently the name does not seem to be evaluated at all. That way no placeholder replacement on the weird syntax would need to take place on the dir entry, but rather that would just specify from where to copy the files for the module (this can always be hardcoded). The placeholder mechanism (i.e. the regular one with the $ syntax would then only be necessary on id and name attributes. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-457) Clarify documentation around module.name and module.dir
[ https://jira.codehaus.org/browse/ARCHETYPE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated ARCHETYPE-457: -- Affects Version/s: 2.2 > Clarify documentation around module.name and module.dir > --- > > Key: ARCHETYPE-457 > URL: https://jira.codehaus.org/browse/ARCHETYPE-457 > Project: Maven Archetype > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Konrad Windszus > > From the reference at > https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html#class_module > is is unclear how the attribute name is evaluated. For me the following > behaviour would make sense > - dir: the name of the source directory (from which the new module will be > created) > - name: the name of the module directory (destination). Usually is equivalent > to artifactId. Currently the name does not seem to be evaluated at all. > That way no placeholder replacement on the weird syntax would > need to take place on the dir entry, but rather that would just specify from > where to copy the files for the module (this can always be hardcoded). The > placeholder mechanism (i.e. the regular one with the $ syntax would then only > be necessary on id and name attributes. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation
[
https://jira.codehaus.org/browse/MASSEMBLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340589#comment-340589
]
Benson Margulies commented on MASSEMBLY-671:
Make a file set with a directory like:
{project.build.directory}/foo
something
you will be rewarded with _no_ specific error message about the nonexistence of
{project.build.directory} (note the missing $} and that spew in the log.
> Cryptic debug warning message needs improvement and/or documentation
>
>
> Key: MASSEMBLY-671
> URL: https://jira.codehaus.org/browse/MASSEMBLY-671
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2.1, 2.4
> Environment: irrelevant
>Reporter: Steve Cohen
>
> I have used the assembly plugin both versions 2.4 and 2.2.1. While the
> plugin basically works, I have some problems with it, (see MASSEMBLY-670),
> which I suspect may be related to the following message that shows up when
> running Maven in debug mode (-X):
> {noformat}
> [DEBUG] All known ContainerDescriptorHandler components: [plexus,
> metaInf-spring, metaInf-services, file-aggregator]
> [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException
> role: org.apache.maven.artifact.resolver.ArtifactResolver
> roleHint: project-cache-aware
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at
> com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
> at
> com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
> at
> org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
> at
> org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
> at
> org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.li
