[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-tabpanelfocusedCommentId=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.ConstructorBindingImpl.create(ConstructorBindingImpl.java:96)
[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-tabpanelfocusedCommentId=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.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:94)
at
[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-tabpanelfocusedCommentId=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: (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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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: (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-tabpanelfocusedCommentId=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
developerConnectionscm:svn:svn://host/path/project/trunk/developerConnection
/scm
{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] 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] 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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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] Created: (MSITE-586) maven-site-plugin 2.0 breaks Doxia sink th / elements
maven-site-plugin 2.0 breaks Doxia sink th / 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 th / elements outside of the table / 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
