[jira] Commented: (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226525#action_226525 ] Mark Derricutt commented on MNG-3092: - When using the nightly maven 3 builds from https://grid.sonatype.org/ci/job/maven-3.0.x-bootstrap/jdk=1.5,label=ubuntu I still see version ranges including SNAPSHOT versions ( which for my integration tests is a good thing, but not for releases ). Can anyone else confirm that this change works in current M3 builds? Is the old behavior able to be reenabled at all? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: http://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 3.0-beta-1 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-397) Cannot link to javadoc methods
[
http://jira.codehaus.org/browse/DOXIA-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226532#action_226532
]
Lukas Theussl commented on DOXIA-397:
-
A link like
{noformat}
{{{../apidocs/groovyx/.}}}
{noformat}
is not a Doxia id because it contains slashes.
bq. just complain (emit a warning message) but don't munge it.
It is assumed that site builders have control over both target ids and links
for internal and local links, ie if Doxia fixes an invalid id, the developer
should be forced to fix the link and avoid the warning. Unfortunately this is
not possible for auto-generated docs that produce invalid anchors/links, like
javadoc.
bq. But maybe some people are relying on behavior to turn {{{Some Section
Heading}blah}} into blah
Yes, that's the origin of the problem, we would break a lot of existing links
if we changed that now.
> Cannot link to javadoc methods
> --
>
> Key: DOXIA-397
> URL: http://jira.codehaus.org/browse/DOXIA-397
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Apt, Module - Xdoc
>Affects Versions: 1.1.3
>Reporter: Lukas Theussl
>
> Using a link to a javadoc method like
> {noformat}
> {{{../apidocs/groovyx/net/http/ParserRegistry.html#parseText(org.apache.http.HttpResponse)}ParserRegistry}}
> {noformat}
> the apt parser removes the brackets of the anchor. The same thing happens
> with xdocs and probably other formats. Note that non-ascii characters are not
> legal in anchor names, but they should be replaced by their hex values, see
> http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars.
--
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
