[jira] Updated: (MRESOURCES-70) Filter does not process nested ${} variables
[
http://jira.codehaus.org/browse/MRESOURCES-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MRESOURCES-70:
--
Fix Version/s: (was: 2.5)
2.6
> Filter does not process nested ${} variables
>
>
> Key: MRESOURCES-70
> URL: http://jira.codehaus.org/browse/MRESOURCES-70
> Project: Maven 2.x Resources Plugin
> Issue Type: New Feature
> Components: delimiters
>Affects Versions: 2.2
>Reporter: Matt Steele
> Fix For: 2.6
>
> Attachments: MRESOURCES-70.zip
>
>
> When I try filtering this under src/main/resources:
> jms.username=${${env}.jms.username}
> with this filtering strategy:
>
>
> src/main/resources
> true
>
>
> Setting the property (from command line, , etc.) fails to properly
> filter the nested element:
> jms.username=${${env}.jms.username}
> For example, I'd like the filter to convert to this (using a property of
> -Denv=dev):
> jms.username=${dev.jms.username}
--
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: (MRESOURCES-91) File last modified property is changed when copied as resource
[ http://jira.codehaus.org/browse/MRESOURCES-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-91: -- Fix Version/s: (was: 2.5) 2.6 > File last modified property is changed when copied as resource > -- > > Key: MRESOURCES-91 > URL: http://jira.codehaus.org/browse/MRESOURCES-91 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 2.3 > Environment: Ubuntu 9.04 x64 > Sun JDK 1.6.0_12 > Maven 2.1.0 >Reporter: Noam Y. Tenne > Fix For: 2.6 > > > This occurs when no filter is being used. > When a resource is copied to the target directory, the file's last modified > property is changed to the time of copy. -- 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: (MRESOURCES-83) Improved diagnostics on failures
[ http://jira.codehaus.org/browse/MRESOURCES-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-83: -- Fix Version/s: (was: 2.5) 2.6 > Improved diagnostics on failures > > > Key: MRESOURCES-83 > URL: http://jira.codehaus.org/browse/MRESOURCES-83 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: Maven 2.0.9, AIX, IBM JVM 1.5.x >Reporter: Dave Meibusch > Fix For: 2.6 > > > Background: > The JVM and class libraries are not forgiving if you attempt to filter a > resource with an incorrect encoding. > For example, if a file contains an invalid UTF-8 character > sun.io.ByteToCharUTF8 throws a MalformedInputException. > The resource plugin in this scenario reports (in trace with mvn -X) "Error > copying resource", but with no indication which file or even which set of > resources in the project caused the error. > With very large number of resources (in my case, several thousand files), it > is challenging to find the corrupted/incorrectly encoded file. > Suggested improvement is more contextual information in the debug output. -- 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: (MRESOURCES-108) filter delimiter config that includes ${filter:*} will be changed to ${*} as of 2.4.1, causes NPE in 2.4
[
http://jira.codehaus.org/browse/MRESOURCES-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MRESOURCES-108:
---
Fix Version/s: (was: 2.5)
2.6
> filter delimiter config that includes ${filter:*} will be changed to ${*} as
> of 2.4.1, causes NPE in 2.4
>
>
> Key: MRESOURCES-108
> URL: http://jira.codehaus.org/browse/MRESOURCES-108
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Components: delimiters
>Affects Versions: 2.4, 2.4.1
>Reporter: John Casey
> Fix For: 2.6
>
>
> This is the continuation of the problem expressed in MRESOURCES-105, for the
> more general case. It has something to do with the way the
> PluginParameterExpressionEvaluator and plexus itself resolves list-style
> plugin parameters.
--
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: (MRESOURCES-22) Being able to filter resources based on solely the filter files ?
[ http://jira.codehaus.org/browse/MRESOURCES-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MRESOURCES-22: -- Fix Version/s: (was: 2.5) 2.6 > Being able to filter resources based on solely the filter files ? > - > > Key: MRESOURCES-22 > URL: http://jira.codehaus.org/browse/MRESOURCES-22 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Reporter: Grégory Joseph > Fix For: 2.6 > > > I'd like to be able to switch the interpolation of pom and system properties, > so that the filtering uses only the properties in > Specifically, I think it comes down to enable/disabling lines 198-202 in > ResourcesMojo > // System properties > filterProperties.putAll( System.getProperties() ); > > // Project properties > filterProperties.putAll( project.getProperties() ); > > Alternatively, being able to specify the token delimiters to use could also > make my day. (lines 255/258 still in ResourcesMojo) > WDYT? -- 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] Closed: (MRESOURCES-92) Resource plugin is mightly loud when there are no resources at all
[ http://jira.codehaus.org/browse/MRESOURCES-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRESOURCES-92. - Resolution: Won't Fix Fix Version/s: (was: 2.5) > Resource plugin is mightly loud when there are no resources at all > -- > > Key: MRESOURCES-92 > URL: http://jira.codehaus.org/browse/MRESOURCES-92 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Benson Margulies > > As of 2.1.0, the super-pommed version of the resource plugin gives warnings > in a project that doesn't have a src/main/resources directory. > It seems a bit unkind to require explicit POM configuration to shut this up. > If there is no explicit config in the POM, and no directories, > it seems as if the plugin should do nothing, quietly. -- 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] Closed: (DOXIA-420) 1.1 is not supposed to generate anchors for section titles, but it does
[
http://jira.codehaus.org/browse/DOXIA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-420.
---
Resolution: Not A Bug
Assignee: Lukas Theussl
> 1.1 is not supposed to generate anchors for section titles, but it does
> ---
>
> Key: DOXIA-420
> URL: http://jira.codehaus.org/browse/DOXIA-420
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Apt
>Affects Versions: 1.1.4
>Reporter: SebbASF
>Assignee: Lukas Theussl
>
> According to
> http://maven.apache.org/doxia/references/doxia-apt.html#Anchors_for_section_titles
> "Contrary to the original APT format, section titles are not implicitly
> defined anchors. If you want an anchor for a section title you need to define
> it explicitly as such:"
> However, Doxia *does* generate anchors for section headers.
> This is clear from the URL above; the underlying HTML is:
> Anchors for section titles name="Anchors_for_section_titles">
> Compare with the code for
> http://maven.apache.org/doxia/references/doxia-apt.html#Enhancements_to_the_APT_format
> at the top of the page, and then compare with the APT source:
> http://svn.apache.org/viewvc/maven/doxia/site/src/site/apt/references/doxia-apt.apt?revision=985438&view=markup
> which does not have {} round the initial section header, yet the anchor is
> still generated.
> Headers with {} around them have 2 anchors.
--
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: (DOXIASITETOOLS-53) SiteRender generates double anchors for section headers
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256823#action_256823 ] sebbaz+ch commented on DOXIASITETOOLS-53: - Exactly, which is why I suggested making it optional not to generate anchors for section headers. But generating double anchors for headers is always wrong, and should be fixed regardless. > SiteRender generates double anchors for section headers > --- > > Key: DOXIASITETOOLS-53 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-53 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.1.4 >Reporter: SebbASF > > The SiteRenderer adds anchors to section headers, even if they have already > been added. > See http://jira.codehaus.org/browse/DOXIA-420 which has examples of > double-anchors on the Maven site. -- 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: (MRELEASE-655) Maven Release Plugin Fails to perform the Release when using TFS scm
Maven Release Plugin Fails to perform the Release when using TFS scm Key: MRELEASE-655 URL: http://jira.codehaus.org/browse/MRELEASE-655 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: Windows 7 64 bit, Maven 3.0.1, Java 1.6_23, TFS 2010 Reporter: Nikhil Jain Priority: Blocker Attachments: keymanager-release.log, Release_Command.txt We are able to prepare a build successfully using Prepare release but while performing release the release plugin is not able to perform release using TFS 2010. It errors due to incorrect sequence of SCM commands for TFS. The output of perform release is attached. For performing release we are issuing a command while specifies to use edit mode, Provides anew TFS workspace to map and a working directory to checkout code to perform a release. We are using the release plugin with TFS as suggested on Teamprise site http://kb.teamprise.com/article/view/95 -- 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] Closed: (SCM-607) extend scm:blame BlameLines with author AND committer information
[ http://jira.codehaus.org/browse/SCM-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed SCM-607. - Resolution: Fixed > extend scm:blame BlameLines with author AND committer information > -- > > Key: SCM-607 > URL: http://jira.codehaus.org/browse/SCM-607 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-api, maven-scm-provider-git >Affects Versions: 1.4 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.5 > > > Currently the BlameLine contains only an author field. In some SCMs we > additionally get the information about the committer. For such SCMs, we > should provide both informations. If no separate information is available, > then the committer field should also be filled with the author information. -- 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: (MPLUGIN-181) Escape HTML entities in javadoc
Escape HTML entities in javadoc
---
Key: MPLUGIN-181
URL: http://jira.codehaus.org/browse/MPLUGIN-181
Project: Maven 2.x Plugin Tools
Issue Type: New Feature
Components: Plugin Plugin
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_23
Java home: D:\java\jdk\jre
Default locale: cs_CZ, platform encoding: Cp1250
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Petr Prochazka
Hello,
I am creating plugin, which has as parameter search mask in format
{noformat}**/*.xml{noformat}
And I have problem, that sequence of chars */ is parsed as end of javadoc
comment. So I created HTML escape sequence of / (/), see example for field:
{noformat} /**
* Comma separated list of mask to include.
*
* @parameter expression="${includes}" default-value="**/*.xml"
*/
private String includes;{noformat}
I will be very happy if HTML escape sequence was unescaped back in calling
{{descriptor}} goal :-).
Best regards
Petr Prochazka
--
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: (MDEP-301) Allow build-classpath to output to property
Allow build-classpath to output to property --- Key: MDEP-301 URL: http://jira.codehaus.org/browse/MDEP-301 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: build-classpath Affects Versions: 2.1 Reporter: Bjorn Beskow Assignee: Brian Fox Attachments: build-path-to-property.patch I frequently have the need to set the bootClasspath for the compiler plugin, and would like to do it from project dependencies. Hence I would like to be able to get the output of build-classpath to a property instead of a file. Attached is a patch which adds an "outputProperty" property, and assigns the classpath value to it if specified. -- 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: (MNG-5017) Register VersionScheme as Plexus Component
[
http://jira.codehaus.org/browse/MNG-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Patrick Floyd updated MNG-5017:
Attachment: VersionSchemePatch.txt
This patch provides the functionality I am requesting. I verified that the
current Maven 3.0.3 code base works as expected with this patch.
However, I have used maven-core/META-INF/plexus/components.xml to register
org.sonatype.aether.util.version.GenericVersionScheme . This is probably a bad
place, it should be done in aether-util but I didn't want to create patches for
more than one code base.
> Register VersionScheme as Plexus Component
> --
>
> Key: MNG-5017
> URL: http://jira.codehaus.org/browse/MNG-5017
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
>Reporter: Sean Patrick Floyd
>Priority: Minor
> Attachments: VersionSchemePatch.txt
>
>
> I would like to implement custom {{VersionConstraints}}, and have thought of
> creating a subclass of {{GenericVersionScheme}} to achieve that. However, I
> had to realize that {{GenericVersionScheme}} is instantiated via {{new
> GenericVersionScheme()}} instead of dependency injection.
> Please register {{GenericVersionScheme}} as a Plexus Component with the role
> {{org.sonatype.aether.version.VersionScheme}}, and use the injected version,
> that way I can write extensions that provide a wrapped version.
> Here are the affected instantiations that I could find:
> GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
> isMavenVersion(String) : boolean -
> org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
> MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
> resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
> VersionRangeResult -
> org.apache.maven.repository.internal.DefaultVersionRangeResolver
> selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
> Versions) : void -
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-606) UnsupportedOperationException on blame GIT
[
http://jira.codehaus.org/browse/SCM-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256795#action_256795
]
Fabien Bousquet commented on SCM-606:
-
Thanks Mark for this fix !
> UnsupportedOperationException on blame GIT
> --
>
> Key: SCM-606
> URL: http://jira.codehaus.org/browse/SCM-606
> Project: Maven SCM
> Issue Type: Wish
> Components: maven-scm-provider-git
>Affects Versions: 1.4
>Reporter: Fabien Bousquet
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 1.5
>
> Attachments: GitBlame_UnsupportedOperationException.patch,
> SCM606_bis.patch
>
>
> Sometimes, running the blame command for GIT return an error for exit code.
> In this case, Maven SCM throw an
> UnsupportedOperationException :
> {code}
> Caused by: java.lang.UnsupportedOperationException
> at
> org.apache.maven.scm.provider.git.gitexe.command.blame.GitBlameCommand.executeBlameCommand(GitBlameCommand.java:46)
> etc...
> {code}
> Is it possible to have the same way that others providers (SVN or TFS for
> example) which is to return a
> result (with a success to false) ?
> In other word replace :
> {code}
> throw new UnsupportedOperationException();
> {code}
> by :
> {code}
> return new BlameScmResult(cl.toString(), "The git command failed.",
> stderr.getOutput(), false);
> {code}
> Another reason is that we do not know that this UnsupportedOperationException
> may be raised because is
> a RuntimeException.
> A similar problem : http://jira.codehaus.org/browse/SONARPLUGINS-618
> Do you agree with that ?
--
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-5017) Register VersionScheme as Plexus Component
[
http://jira.codehaus.org/browse/MNG-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256777#action_256777
]
Sean Patrick Floyd commented on MNG-5017:
-
PS: Obviously the line {{MytoysGenericVersionScheme -
de.mytoys.maven.version.resolver}}
is not from the Maven codebase. Sorry.
> Register VersionScheme as Plexus Component
> --
>
> Key: MNG-5017
> URL: http://jira.codehaus.org/browse/MNG-5017
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
>Reporter: Sean Patrick Floyd
>Priority: Minor
>
> I would like to implement custom {{VersionConstraints}}, and have thought of
> creating a subclass of {{GenericVersionScheme}} to achieve that. However, I
> had to realize that {{GenericVersionScheme}} is instantiated via {{new
> GenericVersionScheme()}} instead of dependency injection.
> Please register {{GenericVersionScheme}} as a Plexus Component with the role
> {{org.sonatype.aether.version.VersionScheme}}, and use the injected version,
> that way I can write extensions that provide a wrapped version.
> Here are the affected instantiations that I could find:
> GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
> isMavenVersion(String) : boolean -
> org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
> MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
> resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
> VersionRangeResult -
> org.apache.maven.repository.internal.DefaultVersionRangeResolver
> selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
> Versions) : void -
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
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: (MNG-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[
http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256775#action_256775
]
Sei Syvalta edited comment on MNG-5006 at 2/18/11 7:48 AM:
---
{quote}
- org.apache.maven.model.building.DefaultModelBuilder.readParentExternally
fails because of that (no repositories)
- parent is not found from local repository because the key in repo tracking
properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key
"test-parent-pom-1.0.1.pom>".{quote}
The difference to the working direct SNAPSHOT reference (i.e. non-range) is the
list of repositories. The local repo lookup fails also in that case, but parent
will be found from remote repo.
was (Author: bugittaa):
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally
fails because of that (no repositories)
> parent is not found from local repository because the key in repo tracking
> properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key
> "test-parent-pom-1.0.1.pom>".
The difference to the working direct SNAPSHOT reference (i.e. non-range) is the
list of repositories. The local repo lookup fails also in that case, but parent
will be found from remote repo.
> M3 attempts to get released parent pom from snapshot repository when a
> dependency has range
> ---
>
> Key: MNG-5006
> URL: http://jira.codehaus.org/browse/MNG-5006
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.2
> Environment: WinXP SP3, Java 6u20
>Reporter: Kristoffer Peterhansel
> Attachments: mvn-verify-fixed-version.log, mvn-verify-offline.log,
> mvn-verify-range-version.log
>
>
> I have a bit of a strange issue. When running under Maven 3.0.2 I am getting
> build errors when I try to build one of our projects when one of their
> dependencies have a range version. But when setting it to a specific version
> it seems to work. The same project works without a hitch in Maven 2.2.1.
> As can be seen from the first included verbose trace
> (mvn-verify-range-version.log). Maven attempts to get the pom from our
> snapshot repository. That will, obviously, not work for a released artefact.
> Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems
> to skip that step completely. Even though it resolves to the same version in
> the end. As seen in the other verbose trace (mvn-verify-fixed-version.log)
--
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-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256775#action_256775 ] Sei Syvalta commented on MNG-5006: -- > org.apache.maven.model.building.DefaultModelBuilder.readParentExternally > fails because of that (no repositories) > parent is not found from local repository because the key in repo tracking > properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key > "test-parent-pom-1.0.1.pom>". The difference to the working direct SNAPSHOT reference (i.e. non-range) is the list of repositories. The local repo lookup fails also in that case, but parent will be found from remote repo. > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Attachments: mvn-verify-fixed-version.log, mvn-verify-offline.log, > mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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: (MNG-5017) Register VersionScheme as Plexus Component
[
http://jira.codehaus.org/browse/MNG-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256768#action_256768
]
Sean Patrick Floyd edited comment on MNG-5017 at 2/18/11 7:41 AM:
--
My specific goal is to implement a solution for
[MNG-3092|http://jira.codehaus.org/browse/MNG-3092], but even without this
specific scenario, I'd call it a bad practice (tight coupling) to instantiate a
specific type of a key interface when IOC is available.
My solution involves writing a replacement for {{GenericVersionScheme}}
(actually, a wrapper around it) that creates {{VersionConstraint}} objects
decorated with additional behavior to exclude snapshot versions from version
ranges unless they are explicitly specified.
was (Author: seanizer):
My specific goal is to implement a solution for
[MNG-3092|http://jira.codehaus.org/browse/MNG-3092], but even without this
specific scenario, I'd call it a bad practice (tight coupling) to instantiate a
specific type of a key interface when IOC is available.
My solution involves writing a replacement for {{{GenericVersionScheme}}}
(actually, a wrapper around it) that creates {{{VersionConstraint}}} objects
decorated with additional behavior to exclude snapshot versions from version
ranges unless they are explicitly specified.
> Register VersionScheme as Plexus Component
> --
>
> Key: MNG-5017
> URL: http://jira.codehaus.org/browse/MNG-5017
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
>Reporter: Sean Patrick Floyd
>Priority: Minor
>
> I would like to implement custom {{VersionConstraints}}, and have thought of
> creating a subclass of {{GenericVersionScheme}} to achieve that. However, I
> had to realize that {{GenericVersionScheme}} is instantiated via {{new
> GenericVersionScheme()}} instead of dependency injection.
> Please register {{GenericVersionScheme}} as a Plexus Component with the role
> {{org.sonatype.aether.version.VersionScheme}}, and use the injected version,
> that way I can write extensions that provide a wrapped version.
> Here are the affected instantiations that I could find:
> GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
> isMavenVersion(String) : boolean -
> org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
> MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
> resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
> VersionRangeResult -
> org.apache.maven.repository.internal.DefaultVersionRangeResolver
> selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
> Versions) : void -
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
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-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256772#action_256772 ] Sei Syvalta commented on MNG-5006: -- Adding my post to the user list here too: I'm running into this too. I tried to create a test project but unfortunately the problem didn't reproduce there. Some background: - dependency to artifact with version range [1.0.1, 2.0), matching versions [1.0.1, 1.0.2, 1.0.3-SNAPSHOT]. - problems occurs when 1.0.3-SNAPSHOT tries to load it's _released_ parent pom. - if parent of 1.0.3-SNAPSHOT is changed to a snapshot the build succeeds. Some observations: - when SNAPSHOT is resolved from local repository it's list of repositories is empty. Also when it's parent is resolved it's list of repositories is empty. - org.apache.maven.model.building.DefaultModelBuilder.readParentExternally fails because of that (no repositories) - parent is not found from local repository because the key in repo tracking properties is "test-parent-pom-1.0.1.pom>releases" but is searched with key "test-parent-pom-1.0.1.pom>". Stack trace from one point of execution: org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(org.sonatype.aether.RepositorySystemSession, java.util.Collection) line: 237 org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactRequest) line: 214 org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(java.lang.String, java.lang.String, java.lang.String) line: 115 org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 819 org.apache.maven.model.building.DefaultModelBuilder.readParent(org.apache.maven.model.Model, org.apache.maven.model.building.ModelBuildingRequest, org.apache.maven.model.building.DefaultModelProblemCollector) line: 670 org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest, java.util.Collection) line: 308 org.apache.maven.model.building.DefaultModelBuilder.build(org.apache.maven.model.building.ModelBuildingRequest) line: 232 org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest, org.sonatype.aether.resolution.ArtifactDescriptorResult) line: 308 org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.resolution.ArtifactDescriptorRequest) line: 173 org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectResult, java.util.LinkedList, java.util.List, java.util.List, org.sonatype.aether.collection.DependencySelector, org.sonatype.aether.collection.DependencyManager, org.sonatype.aether.collection.DependencyTraverser, org.sonatype.aether.impl.internal.DataPool) line: 419 org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(org.sonatype.aether.RepositorySystemSession, org.sonatype.aether.collection.CollectRequest) line: 233 > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Attachments: mvn-verify-fixed-version.log, mvn-verify-offline.log, > mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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,
[jira] Commented: (MNG-5017) Register VersionScheme as Plexus Component
[
http://jira.codehaus.org/browse/MNG-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256768#action_256768
]
Sean Patrick Floyd commented on MNG-5017:
-
My specific goal is to implement a solution for
[MNG-3092|http://jira.codehaus.org/browse/MNG-3092], but even without this
specific scenario, I'd call it a bad practice (tight coupling) to instantiate a
specific type of a key interface when IOC is available.
My solution involves writing a replacement for {{{GenericVersionScheme}}}
(actually, a wrapper around it) that creates {{{VersionConstraint}}} objects
decorated with additional behavior to exclude snapshot versions from version
ranges unless they are explicitly specified.
> Register VersionScheme as Plexus Component
> --
>
> Key: MNG-5017
> URL: http://jira.codehaus.org/browse/MNG-5017
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
>Reporter: Sean Patrick Floyd
>Priority: Minor
>
> I would like to implement custom {{VersionConstraints}}, and have thought of
> creating a subclass of {{GenericVersionScheme}} to achieve that. However, I
> had to realize that {{GenericVersionScheme}} is instantiated via {{new
> GenericVersionScheme()}} instead of dependency injection.
> Please register {{GenericVersionScheme}} as a Plexus Component with the role
> {{org.sonatype.aether.version.VersionScheme}}, and use the injected version,
> that way I can write extensions that provide a wrapped version.
> Here are the affected instantiations that I could find:
> GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
> isMavenVersion(String) : boolean -
> org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
> MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
> resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
> VersionRangeResult -
> org.apache.maven.repository.internal.DefaultVersionRangeResolver
> selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
> Versions) : void -
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
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-5017) Register VersionScheme as Plexus Component
[
http://jira.codehaus.org/browse/MNG-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256757#action_256757
]
Benjamin Bentmann commented on MNG-5017:
You might want to describe your specific use case and needs some more as
otherwise the big picture and component interactions aren't clear.
> Register VersionScheme as Plexus Component
> --
>
> Key: MNG-5017
> URL: http://jira.codehaus.org/browse/MNG-5017
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
>Reporter: Sean Patrick Floyd
>Priority: Minor
>
> I would like to implement custom {{VersionConstraints}}, and have thought of
> creating a subclass of {{GenericVersionScheme}} to achieve that. However, I
> had to realize that {{GenericVersionScheme}} is instantiated via {{new
> GenericVersionScheme()}} instead of dependency injection.
> Please register {{GenericVersionScheme}} as a Plexus Component with the role
> {{org.sonatype.aether.version.VersionScheme}}, and use the injected version,
> that way I can write extensions that provide a wrapped version.
> Here are the affected instantiations that I could find:
> GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
> isMavenVersion(String) : boolean -
> org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
> MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
> resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
> VersionRangeResult -
> org.apache.maven.repository.internal.DefaultVersionRangeResolver
> selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
> Versions) : void -
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
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: (MNG-5017) Register VersionScheme as Plexus Component
[
http://jira.codehaus.org/browse/MNG-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-5017:
---
Description:
I would like to implement custom {{VersionConstraints}}, and have thought of
creating a subclass of {{GenericVersionScheme}} to achieve that. However, I had
to realize that {{GenericVersionScheme}} is instantiated via {{new
GenericVersionScheme()}} instead of dependency injection.
Please register {{GenericVersionScheme}} as a Plexus Component with the role
{{org.sonatype.aether.version.VersionScheme}}, and use the injected version,
that way I can write extensions that provide a wrapped version.
Here are the affected instantiations that I could find:
GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
isMavenVersion(String) : boolean -
org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
VersionRangeResult -
org.apache.maven.repository.internal.DefaultVersionRangeResolver
selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
Versions) : void -
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
was:
I would like to implement custom {{{VersionConstraints}}}, and have thought of
creating a subclass of {{{GenericVersionScheme}}} to achieve that. However, I
had to realize that {{{GenericVersionScheme}}} is instantiated via {{{new
GenericVersionScheme()}}} instead of dependency injection.
Please register {{{GenericVersionScheme}}} as a Plexus Component with the role
{{{org.sonatype.aether.version.VersionScheme}}}, and use the injected version,
that way I can write extensions that provide a wrapped version.
Here are the affected instantiations that I could find:
GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
isMavenVersion(String) : boolean -
org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
VersionRangeResult -
org.apache.maven.repository.internal.DefaultVersionRangeResolver
selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
Versions) : void -
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
> Register VersionScheme as Plexus Component
> --
>
> Key: MNG-5017
> URL: http://jira.codehaus.org/browse/MNG-5017
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
>Reporter: Sean Patrick Floyd
>Priority: Minor
>
> I would like to implement custom {{VersionConstraints}}, and have thought of
> creating a subclass of {{GenericVersionScheme}} to achieve that. However, I
> had to realize that {{GenericVersionScheme}} is instantiated via {{new
> GenericVersionScheme()}} instead of dependency injection.
> Please register {{GenericVersionScheme}} as a Plexus Component with the role
> {{org.sonatype.aether.version.VersionScheme}}, and use the injected version,
> that way I can write extensions that provide a wrapped version.
> Here are the affected instantiations that I could find:
> GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
> isMavenVersion(String) : boolean -
> org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
> MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
> resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
> VersionRangeResult -
> org.apache.maven.repository.internal.DefaultVersionRangeResolver
> selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
> Versions) : void -
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
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: (MNG-5017) Register VersionScheme as Plexus Component
[
http://jira.codehaus.org/browse/MNG-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-5017:
---
Component/s: (was: Bootstrap & Build)
(was: Design, Patterns & Best Practices)
Artifacts and Repositories
> Register VersionScheme as Plexus Component
> --
>
> Key: MNG-5017
> URL: http://jira.codehaus.org/browse/MNG-5017
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
>Reporter: Sean Patrick Floyd
>Priority: Minor
>
> I would like to implement custom {{{VersionConstraints}}}, and have thought
> of creating a subclass of {{{GenericVersionScheme}}} to achieve that.
> However, I had to realize that {{{GenericVersionScheme}}} is instantiated via
> {{{new GenericVersionScheme()}}} instead of dependency injection.
> Please register {{{GenericVersionScheme}}} as a Plexus Component with the
> role {{{org.sonatype.aether.version.VersionScheme}}}, and use the injected
> version, that way I can write extensions that provide a wrapped version.
> Here are the affected instantiations that I could find:
> GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
> isMavenVersion(String) : boolean -
> org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
> MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
> resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
> VersionRangeResult -
> org.apache.maven.repository.internal.DefaultVersionRangeResolver
> selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
> Versions) : void -
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
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: (MNG-5017) Register VersionScheme as Plexus Component
Register VersionScheme as Plexus Component
--
Key: MNG-5017
URL: http://jira.codehaus.org/browse/MNG-5017
Project: Maven 2 & 3
Issue Type: Wish
Components: Bootstrap & Build, Design, Patterns & Best Practices
Affects Versions: 3.0.2
Reporter: Sean Patrick Floyd
Priority: Minor
I would like to implement custom {{{VersionConstraints}}}, and have thought of
creating a subclass of {{{GenericVersionScheme}}} to achieve that. However, I
had to realize that {{{GenericVersionScheme}}} is instantiated via {{{new
GenericVersionScheme()}}} instead of dependency injection.
Please register {{{GenericVersionScheme}}} as a Plexus Component with the role
{{{org.sonatype.aether.version.VersionScheme}}}, and use the injected version,
that way I can write extensions that provide a wrapped version.
Here are the affected instantiations that I could find:
GenericVersionScheme() - org.sonatype.aether.util.version.GenericVersionScheme
isMavenVersion(String) : boolean -
org.apache.maven.rtinfo.internal.DefaultRuntimeInformation
MytoysGenericVersionScheme - de.mytoys.maven.version.resolver
resolveVersionRange(RepositorySystemSession, VersionRangeRequest) :
VersionRangeResult -
org.apache.maven.repository.internal.DefaultVersionRangeResolver
selectVersion(DefaultPluginVersionResult, PluginVersionRequest,
Versions) : void -
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver
--
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: (SUREFIRE-701) showSuccess option for test reports: show reports only for failed tests
[ http://jira.codehaus.org/browse/SUREFIRE-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-701: Issue Type: New Feature (was: Improvement) > showSuccess option for test reports: show reports only for failed tests > --- > > Key: SUREFIRE-701 > URL: http://jira.codehaus.org/browse/SUREFIRE-701 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Affects Versions: 2.7.3 >Reporter: Alexander Klimetschek > Attachments: showsuccess.patch > > > Use case: > When you have a few tests, and some of them fail during > development/refactoring, you find yourself repeatedly looking into > target/surefire-reports to open the test report (txt) files with the errors > and stack traces to analyze them. However, by default reports will be written > also for successful tests, and both in txt and xml format (the xml files can > already be omitted using disableXmlReport=false). This makes it hard to find > the files that contain the failed tests. > Solution proposal: > Just as the maven-surefire-report-plugin already has a showSuccess option, > that, if set to "false", will not report successful tests, the same should be > available for the maven-surefire-plugin and the normal test goal. > Either set "-DshowSuccess=false" on the command line or define > "false" in the maven-surefire-plugin configuration > of the pom, and reports for successful tests should not be written to the > reports directory. -- 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
