[jira] Commented: (MWAR-253) Inherit dependencies from a WAR type dependency when it is overlayed.
[ http://jira.codehaus.org/browse/MWAR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269528#action_269528 ] Stephane Nicoll commented on MWAR-253: -- Yes I got that but a bug is something that is supposed to be provided by the plugin. What you are describing was never implemented. I am just trying to understand > Inherit dependencies from a WAR type dependency when it is overlayed. > - > > Key: MWAR-253 > URL: http://jira.codehaus.org/browse/MWAR-253 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Maarten Billemont > > When WAR artifact B depends on WAR artifact A, and also defines an overlay of > A, B should inherit all A's dependencies. > This issue is related to MNG-1991, but can be resolved without much > discussion as it's unrelated to skinny WARs and such. > Classes in B are guaranteed to have runtime access to all A's declared > dependencies when A is an overlay of B. -- 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: (MSITE-586) maven-site-plugin > 2.0 breaks Doxia sink elements
maven-site-plugin > 2.0 breaks Doxia sink elements - Key: MSITE-586 URL: http://jira.codehaus.org/browse/MSITE-586 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 2.0.1 Reporter: Joshua Hyde Attachments: doxia-bug-test.zip For reasons that I've been unable to yet discern, my reporting plugin fails to work properly if anything in the 2.x stream (beyond 2.0) is present in the POM. I'm attaching a project that demonstrates this. Run "mvn clean test site" and view the "JETM Timing Report" under Project Reports. Then, run "mvn clean test site -Pbreak" and view the same report - the generated HTML has the elements outside of the definition. -- 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: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ http://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated MRRESOURCES-55: --- Attachment: MRRESOURCES-55-remote-resources-patch.txt This the patch (including unit and integration tests) for the RR plugin itself. The other patch (MRRESOURCES-55-preserve-original-codepath-patch.txt) is for the maven-downloader. > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: http://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are 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: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[
http://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269512#action_269512
]
Andrew Phillips commented on MRRESOURCES-55:
Implementation note: the suggested patch completely preserves the original
codepath, for minimum impact on existing code. A "cleaner" implementation could
let
{noformat}
ProcessRemoteResourcesMojo.downloadBundles
{noformat}
*always* call the new 7-arg version of {{Downloader.download}}
{noformat}
public File download(groupId, artifactId, version, type, classifier,
localRepository, remoteRepositories)
{noformat}
Equally, {{DefaultDownloader.download}} itself could always call
{noformat}
artifactFactory.createDependencyArtifact(groupId, artifactId, versionRange,
type, classifier, scope)
{noformat}
but then the defaulting logic ("if no type then type = 'jar' etc.") that is
currently in {{ArtifactFactory}} would have to be "lifted up" to
{{DefaultDownloader}} or even {{ProcessRemoteResourcesMojo}}, which seems like
abstraction leakage.
> Support groupId:artifactId:version:type and
> groupId:artifactId:version:type:classifier as resource bundle references
>
>
> Key: MRRESOURCES-55
> URL: http://jira.codehaus.org/browse/MRRESOURCES-55
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.2
>Reporter: Andrew Phillips
> Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt
>
>
> Currently, the RR plugin only support groupId:artifactId:version as an
> identifier for a remote bundle. However, there are quite a few use cases
> (e.g. platform-specific bundles) where it would be very useful to be able to
> identify bundles additionally by classifier. The current workaround we use -
> different versions - works, but isn't particularly elegant or semantically
> accurate.
> The proposal therefore is to also allow identifiers of the type
> groupId:artifactId:version:type:classifier
> As Brett pointed out in an IRC chat, this automatically adds the type to the
> identifier as well. One could ignore it or enforce 'jar' (the current
> default), but on the other hand there seems to be no reason *not* to allow
> types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much
> sense.
> Two potential implementations, with tests, are 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: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269511#action_269511 ] Paul Gier commented on MDEPLOY-48: -- Hi Ruben, you should create a new issue since this one is already closed. > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet >Assignee: Paul Gier > Fix For: 2.6 > > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- 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: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ http://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated MRRESOURCES-55: --- Attachment: MRRESOURCES-55-preserve-original-codepath-patch.txt > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: http://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are 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] Created: (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references Key: MRRESOURCES-55 URL: http://jira.codehaus.org/browse/MRRESOURCES-55 Project: Maven 2.x Remote Resources Plugin Issue Type: New Feature Affects Versions: 1.2 Reporter: Andrew Phillips Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt Currently, the RR plugin only support groupId:artifactId:version as an identifier for a remote bundle. However, there are quite a few use cases (e.g. platform-specific bundles) where it would be very useful to be able to identify bundles additionally by classifier. The current workaround we use - different versions - works, but isn't particularly elegant or semantically accurate. The proposal therefore is to also allow identifiers of the type groupId:artifactId:version:type:classifier As Brett pointed out in an IRC chat, this automatically adds the type to the identifier as well. One could ignore it or enforce 'jar' (the current default), but on the other hand there seems to be no reason *not* to allow types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much sense. Two potential implementations, with tests, are 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: (MRELEASE-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
http://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269509#action_269509
]
Claus Gebert commented on MRELEASE-679:
---
Well, our main project is such a project (multimodule and lots of inheritance),
but actually we see this error only for the projects with just one module and
no module inheritance.
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: http://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Assignee: Brett Porter
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
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] Issue Comment Edited: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269506#action_269506 ] Ruben Garat edited comment on MDEPLOY-48 at 6/3/11 2:20 PM: Hi, would it be reasonable to have support for an arbitrary number of attached artifacts? I have to deploy some artifacts that have the main jar, javadoc, sources, and different artifacts for natives for different OS using classifiers to indicate the OS. In this case I still have the same problem that this but tried to solve for the natives, and there is no good solution that supports maven 2 and maven 3 for deploying this artifacts as separate steps (if I use uniqueVersions=false then maven 3 doesn't update the snapshots even when forcing it, if I use uniqueVersion=true then when using maven 2 it fails to resolve the main jar because the pom has a different timestamp than the jar) something like: -attached classifier:artifactpath and allowing this command to be repeated would work I think. EDIT: is this request ok here, or should I create another issue? was (Author: ruben01): Hi, would it be reasonable to have support for an arbitrary number of attached artifacts? I have to deploy some artifacts that have the main jar, javadoc, sources, and different artifacts for natives for different OS using classifiers to indicate the OS. In this case I still have the same problem that this but tried to solve for the natives, and there is no good solution that supports maven 2 and maven 3 for deploying this artifacts as separate steps (if I use uniqueVersions=false then maven 3 doesn't update the snapshots even when forcing it, if I use uniqueVersion=true then when using maven 2 it fails to resolve the main jar because the pom has a different timestamp than the jar) something like: -attached classifier:artifactpath and allowing this command to be repeated would work I think. > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet >Assignee: Paul Gier > Fix For: 2.6 > > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- 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: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269506#action_269506 ] Ruben Garat commented on MDEPLOY-48: Hi, would it be reasonable to have support for an arbitrary number of attached artifacts? I have to deploy some artifacts that have the main jar, javadoc, sources, and different artifacts for natives for different OS using classifiers to indicate the OS. In this case I still have the same problem that this but tried to solve for the natives, and there is no good solution that supports maven 2 and maven 3 for deploying this artifacts as separate steps (if I use uniqueVersions=false then maven 3 doesn't update the snapshots even when forcing it, if I use uniqueVersion=true then when using maven 2 it fails to resolve the main jar because the pom has a different timestamp than the jar) something like: -attached classifier:artifactpath and allowing this command to be repeated would work I think. > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet >Assignee: Paul Gier > Fix For: 2.6 > > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- 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-681) maven throws a java.lang.NullPointerException at the end of a release:perform
[ http://jira.codehaus.org/browse/MRELEASE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269502#action_269502 ] Dennis Lundberg commented on MRELEASE-681: -- Which version of Maven Release Plugin has this bug? You have indicated 2.2 as the "Affects version/s" but in the "Description" you talk about 2.1. > maven throws a java.lang.NullPointerException at the end of a release:perform > - > > Key: MRELEASE-681 > URL: http://jira.codehaus.org/browse/MRELEASE-681 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.2 > Environment: maven 2.2.1, java 1.6_23 on windows 7 64 bit >Reporter: Khai Do >Priority: Minor > Attachments: maven-log.txt > > > I'm getting java.lang.NullPointerException when building when i reference > maven-release-plugin in my pom.xml, It doesn't seem to matter which version > of the plugin i reference. i'm using maven 2.2.1, java 1.6_23 on windows 7 64 > bit. I can also repro on linux. > The only way it works without error is if I specify 2.0-beta-9 from the > command line: > mvn org.apache.maven.plugins:maven-release-plugin:2.0-beta-9:perform > -DconnectionUrl=.. > It fails if I do this: > mvn org.apache.maven.plugins:maven-release-plugin:2.1:perform > -DconnectionUrl=.. > It also fails when I reference 2.0-beta-9 in my pom.xml then run: > mvn relase:perform -DconnectionUrl=.. -- 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: (DOXIA-432) doxia-maven-plugin:1.2 fails with NoClassDefFoundError
[
http://jira.codehaus.org/browse/DOXIA-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269471#action_269471
]
Lukas Theussl commented on DOXIA-432:
-
I probably only deployed doxia-maven-plugin:1.3-SNAPSHOT but other
doxia-*-1.3-SNAPSHOTs were not deployed yet. I just deployed the whole trunk
now.
> doxia-maven-plugin:1.2 fails with NoClassDefFoundError
> --
>
> Key: DOXIA-432
> URL: http://jira.codehaus.org/browse/DOXIA-432
> Project: Maven Doxia
> Issue Type: Bug
> Components: Maven plugin
>Affects Versions: 1.2
> Environment: mac:maui km$ mvn --version
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/share/maven
> Java version: 1.6.0_22, vendor: Apple Inc.
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.5.8", arch: "x86_64", family: "mac"
> This fails also on Ubunutu with the same Maven version.
>Reporter: Karl Heinz Marbaise
>Assignee: Lukas Theussl
> Fix For: 1.3
>
>
> I'm trying to use the maven-doxia-plugin to generate different formats and
> got the following failure if i use maven-doxia-plugin 1.2..if i use version
> 1.1.4 instead it does not produce this failure.
> {code}
> [INFO]
> [INFO] --- doxia-maven-plugin:1.2:render-books (default) @ maui ---
> May 29, 2011 7:12:52 PM org.sonatype.guice.bean.reflect.NamedClass
> WARNING: Error injecting: org.apache.maven.doxia.tools.DefaultSiteTool
> java.lang.NoClassDefFoundError:
> org/codehaus/plexus/util/interpolation/ValueSource
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
> at java.lang.Class.getDeclaredConstructors(Class.java:1836)
> at
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:243)
> at
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:96)
> at
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:628)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:835)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:769)
> at
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:254)
> at
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:205)
> at
> com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:843)
> at
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:957)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:990)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:951)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1003)
> at
> org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:47)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1021)
> 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:40)
> at
> com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:968)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1021)
> at
> com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:964)
> at
> org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:79)
> at
> org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:53)
> at
> org.sonatype.guice.plexus.binders.PlexusRequirements$RequirementProvider.get(PlexusRequirements.java:221)
> at
> org.sonatype.guice.plexus.binders.ProvidedPropertyBinding.injectProperty(ProvidedPropertyBinding.java:49)
> at
> org.sonatype.guice.bean.inject.BeanInjector.doInjection(BeanInjector.java:105)
> at
> org.sonatype.guice.bean.inject.BeanInjector.injectMembers(BeanInjector.java:66)
> at
> com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:120)
> at
> com.google.
[jira] Commented: (DOXIA-432) doxia-maven-plugin:1.2 fails with NoClassDefFoundError
[
http://jira.codehaus.org/browse/DOXIA-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269468#action_269468
]
Karl Heinz Marbaise commented on DOXIA-432:
---
I tested with the 1.3-SNAPSHOT but i got:
{code}
mac:maui km$ mvn clean site
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building MaUI Test Guide 0.1-SNAPSHOT
[INFO]
Downloading:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/doxia/doxia-maven-plugin/1.3-SNAPSHOT/maven-metadata.xml
Downloaded:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/doxia/doxia-maven-plugin/1.3-SNAPSHOT/maven-metadata.xml
(784 B at 0.3 KB/sec)
Downloading:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/doxia/doxia-maven-plugin/1.3-SNAPSHOT/doxia-maven-plugin-1.3-20110530.080228-1.pom
Downloaded:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/doxia/doxia-maven-plugin/1.3-SNAPSHOT/doxia-maven-plugin-1.3-20110530.080228-1.pom
(6 KB at 11.3 KB/sec)
Downloading:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/doxia/doxia/1.3-SNAPSHOT/maven-metadata.xml
Downloading:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/doxia/doxia/1.3-SNAPSHOT/doxia-1.3-SNAPSHOT.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 5.636s
[INFO] Finished at: Fri Jun 03 12:11:13 CEST 2011
[INFO] Final Memory: 7M/528M
[INFO]
[ERROR] Plugin org.apache.maven.doxia:doxia-maven-plugin:1.3-SNAPSHOT or one of
its dependencies could not be resolved: Failed to read artifact descriptor for
org.apache.maven.doxia:doxia-maven-plugin:jar:1.3-SNAPSHOT: Could not find
artifact org.apache.maven.doxia:doxia:pom:1.3-SNAPSHOT in apache.snapshots
(https://repository.apache.org/content/repositories/snapshots/) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{code}
Either i missed something in the configuration...but i've taken a look into the
repo the doxia.pom (1.3-SNAPSHOT) seemed to be not released there and could not
be found...
(I've rechecked; fixed my configuration; but the artifact is not deployed to
that repo).
Afterwards i checkout the
http://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/ (r1130970) and did a
mvn install and tried it with this it works perferct without any error
message.
> doxia-maven-plugin:1.2 fails with NoClassDefFoundError
> --
>
> Key: DOXIA-432
> URL: http://jira.codehaus.org/browse/DOXIA-432
> Project: Maven Doxia
> Issue Type: Bug
> Components: Maven plugin
>Affects Versions: 1.2
> Environment: mac:maui km$ mvn --version
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /usr/share/maven
> Java version: 1.6.0_22, vendor: Apple Inc.
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.5.8", arch: "x86_64", family: "mac"
> This fails also on Ubunutu with the same Maven version.
>Reporter: Karl Heinz Marbaise
>Assignee: Lukas Theussl
> Fix For: 1.3
>
>
> I'm trying to use the maven-doxia-plugin to generate different formats and
> got the following failure if i use maven-doxia-plugin 1.2..if i use version
> 1.1.4 instead it does not produce this failure.
> {code}
> [INFO]
> [INFO] --- doxia-maven-plugin:1.2:render-books (default) @ maui ---
> May 29, 2011 7:12:52 PM org.sonatype.guice.bean.reflect.NamedClass
> WARNING: Error injecting: org.apache.maven.doxia.tools.DefaultSiteTool
> java.lang.NoClassDefFoundError:
> org/codehaus/plexus/util/interpolation/ValueSource
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
> at java.lang.Class.getDeclaredConstructors(Class.java:1836)
> at
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:243)
> at
> com.google.inject.internal.ConstructorBind
