[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322888#comment-322888
]
Sergei Ivanov commented on MNG-3092:
@Joniec:
Are you concerned about the way it is going to be handled in IDEs? I personally
don't see that being a problem, although IDE vendors may need to implement the
equivalent of a command line option for embedded Maven engines.
To your example. Let us elaborate on it a bit, so that we can be sure that we
are all on the same page.
Suppose we have project A. Local version of project A is 1.0.1-SNAPSHOT, remote
repo contains versions 1.0.0 and 1.0.1-SNAPSHOT.
Then we have project B, local version 2.1.0-SNAPSHOT, which depends on A with a
defined version range of [1.0.0,1.0.1].
If we build B on command line with {{-DenableSnapshotsInRanges=false}} flag,
then B picks up A:1.0.0, otherwise it picks up A:1.0.1-SNAPSHOT. If we release
project A, then regardless of the flag B will pick up A:1.0.1, because the new
snapshot A:1.0.2-SNAPSHOT will fall out of [1.0.0,1.0.1] range.
Now, suppose we open both A:1.0.1-SNAPSHOT and B:2.1.0-SNAPSHOT in an IDE. The
default resolution behaviour is that snapshots are included in ranges, thus our
projects will be linked together inside the IDE, which is typically the desired
outcome. If we only open project B in the IDE, or the local version of project
A falls outside of the range defined in project B, then IDE resolves B's
dependency from the local/remote repo in a default way (unless the IDE offers
some degree of control over it). If we want to peg B's dependency on A, we edit
the local POM, which is no worse than the alternative proposal of including
snapshot versions in ranges explicitly, and then editing them again before
releasing the project.
> Version ranges with non-snapshot bounds can contain snapshot versions
> -
>
> Key: MNG-3092
> URL: https://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: Mark Hobson
>Assignee: Jason van Zyl
> Fix For: 3.1.1
>
> Attachments: MNG-3092.patch, 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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322893#comment-322893
]
Sergei Ivanov commented on MNG-3092:
@Kunalkumar:
Again, I do not see what the problem is with the parent POM. If I understand it
correctly, Maven always interpolates the project's POM entirely before
attempting to resolve dependencies.
Let's set up the following project structure:
{noformat}
./pom.xml
./child/pom.xml
{noformat}
The POM file contents are below:
{code:lang=xml|title=./pom.xml}
4.0.0
test
parent
1.0
pom
child
junit
junit
[3.8.1,4.0)
test
{code}
{code:lang=xml|title=./child/pom.xml}
4.0.0
test
parent
1.0
child
jar
{code}
Now change to {{child}} directory and run {{mvn help:effective-pom}}. In the
output you will see:
{code:lang=xml}
junit
junit
[3.8.1,4.0)
test
{code}
Note that the range is still there. Now, after the project has been
interpolated (that is, an effective POM has been built), Maven will attempt to
resolve the dependencies. It will apply the same resolution logic to every
dependency range it encounters. If snapshots are disabled in ranges via a
global build-level option/flag, each range will be guaranteedly resolved to the
highest available release version. If snapshots are enabled, we revert to the
current behaviour.
The same principle applies to any transitive dependencies. If project A depends
on project B:2.0, and project B depends on C:[1.0,2.0), then the range is still
resolved using the same build-level resolution strategy. If snapshots in ranges
are allowed for the current build execution, then A ends up depending on e.g.
C:1.1, otherwise it ends up depending on e.g. C:1.2-SNAPSHOT.
The main advantage of the build-level control that I propose is that by
excluding the snapshots from version ranges, the project's direct and
transitive dependencies are guaranteedly resolved to release versions only,
with the two exceptions below.
With snapshots in ranges turned off, there are only two ways that the project's
dependency can resolve to a snapshot:
# project A depends on B:1.0.2-SNAPSHOT explicitly. In this case there is no
range definition, and there is no error.
# for example, B:[1.0,2.0) contains only 1.0.0-SNAPSHOT and 1.0.1-SNAPSHOT, and
the range does not resolve to any release version. This must trigger a build
error (unresolved dependency) if snapshots in ranges are disabled.
> Version ranges with non-snapshot bounds can contain snapshot versions
> -
>
> Key: MNG-3092
> URL: https://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: Mark Hobson
>Assignee: Jason van Zyl
> Fix For: 3.1.1
>
> Attachments: MNG-3092.patch, 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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322900#comment-322900 ] Merlijn commented on MNG-3092: -- I like sergei's proposed solution here. Having to edit the poms to switch between release/development mode would a pain. Another plus is that the behaviour will not change from the current state if you choose not to make use of the build flag. I realise my opinion probably has zero influence but may be others could comment/voice an opinion about the issue so we can reach a consensus. It would be sad to see a decision made that most disagree with. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322902#comment-322902 ] Scott Sosna commented on MNG-3092: -- Have we narrowed it down to just these two approaches? And does it solve all the issues in this thread? I see some discussions about versions 4.0-alpha-1 and should it behave like 4.0-SNAPSHOT, I'm concerned we've addressed the happy-path (not that there's anything happy here) and want to make sure everything is addressed (even the statement is "that's silly"). Also, what are the performance impacts on either of these approaches? For my projects, Maven3 is substantially slower in resolving versions, making things like the Eclipse m2e plugin borderline useless. Dependencies need to be resolved as quickly as in Maven2. If these are the two approaches, who approaches the Maven committers or whomever to get signoff on an approach and get it commited to the branch? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322904#comment-322904 ] Alex Koon commented on MNG-3092: Sergei's proposed solution fits best with a -D command line switch and/or an attribute for the compiler plugin. This would work similar to -DskipTests=true with the junit plugin. I fully agree with the observations Merlijn highlighted, switching poms between release and development will be a pain or having to have two poms in a project. This diverges from the simplicity maven provides in a build. Also pointed out is that this proposal will not break default behaviour else it would be a breaking change for anyone upgrading. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322906#comment-322906 ] Sergei Ivanov commented on MNG-3092: @Scott: I am deliberately trying to *not* consider anything but snapshots in the context of this issue. As Herve noted [above|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=314137&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-314137], resolution of pre-release versions is partially covered by MNG-5353, but it is a much wider and more complex issue. Unless someone from Maven core team volunteers to engineer a complete solution, we may be better off focusing on and solving only the most painful issue, which is this very MNG-3092. I am proposing a solution that will only affect snapshots and will hopefully remove the major pain that we are experiencing on a daily basis. A solution that allows to reuse the same POM file for building against either snapshots or releases. Without the need to edit ranges in the POM file on a regular basis (and the unwillingness to edit POMs every time the dependency is released is the very reason that we use dependency ranges in the first place). > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322907#comment-322907 ] Sergei Ivanov commented on MNG-3092: @Alex: please note that _the switch_ cannot be an attribute of maven-compiler-plugin. Dependency resolution takes place way before the plugins are initialised (at least the ones annotated with @requiresDependencyResolution). > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322908#comment-322908 ] Scott Sosna commented on MNG-3092: -- My questions are: will the Maven core team accept a patch that only addresses a portion of this discussion? And if not addressed, how do we avoid extending discussions on this issue another 6 years?!? I fully agree with wanting to take incremental steps, and hopefully this is acceptable. I also know that the current implementation resolves dependencies magnitudes slower than what was in Maven2. Locking down the behavior is fine, but it doesn't help me if the overall performance doesn't increase as well. I have Eclipse users breathing down my back who want to flat-out ditch Maven because of the Eclipse plug-in problem (the plug-in insists on embedding Maven3 with no way to override it for dependency resolution). So dealing with just a subset may not be enough, for me, for others, for the core team. And if it's not, the previous functionality of Maven2 (and very early Maven3) should be restored. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-455) No XML Entity Encoding (Escaping) is done in FO Footer Generation
[
https://jira.codehaus.org/browse/DOXIA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed DOXIA-455.
Resolution: Fixed
Fix Version/s: 1.4
Assignee: Robert Scholte (was: Lukas Theussl)
Fixed in [r1462625|http://svn.apache.org/r1462625]
Thanks!
> No XML Entity Encoding (Escaping) is done in FO Footer Generation
> -
>
> Key: DOXIA-455
> URL: https://jira.codehaus.org/browse/DOXIA-455
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - FO
>Affects Versions: 1.2, 1.3
>Reporter: Birger Zimmermann
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 1.4
>
> Attachments: doxia-module-fo-test.zip, patch.txt, test case patch.txt
>
>
> When using an ampersand in the pom.xml organization.name e.g. "Some Company &
> Friends" the resulting fo file has xml parse errors.
> Soulution seems to be:
> {noformat}
> ### Eclipse Workspace Patch 1.0
> #P doxia-module-fo
> Index: src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
> ===
> --- src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
> (revision 1205142)
> +++ src/main/java/org/apache/maven/doxia/module/fo/FoAggregateSink.java
> (working copy)
> @@ -733,7 +733,7 @@
> actualYear = Calendar.getInstance().get( Calendar.YEAR );
> }
>
> -return "©" + actualYear + ", " + companyName + add;
> +return "©" + actualYear + ", " + escaped(companyName, false) +
> add;
> }
>
> /**
> @@ -826,11 +826,11 @@
>
> if ( headerText == null )
> {
> -write( docTitle );
> +text( docTitle );
> }
> else
> {
> -write( headerText );
> +text( headerText );
> }
>
> writeEndTag( BLOCK_TAG );
> @@ -927,7 +927,7 @@
> atts.addAttribute( "text-align-last", "justify" );
> writeStartTag( BLOCK_TAG, atts );
> writeStartTag( BASIC_LINK_TAG, "internal-destination", ref );
> -write( tocItem.getName() );
> +text( tocItem.getName() );
> writeEndTag( BASIC_LINK_TAG );
> writeEmptyTag( LEADER_TAG, "toc.leader.style" );
> writeStartTag( INLINE_TAG, "page.number" );
> @@ -985,7 +985,7 @@
>
> writeStartTag( BOOKMARK_TAG, "internal-destination", ref );
> writeStartTag( BOOKMARK_TITLE_TAG );
> -write( tocItem.getName() );
> +text( tocItem.getName() );
> writeEndTag( BOOKMARK_TITLE_TAG );
>
> if ( tocItem.getItems() != null )
> @@ -1134,7 +1134,7 @@
>
> writeStartTag( TABLE_CELL_TAG, "number-columns-spanned", "2",
> "cover.border.left" );
> writeStartTag( BLOCK_TAG, "cover.title" );
> -write( title == null ? "" : title );
> +text( title == null ? "" : title );
> writeEndTag( BLOCK_TAG );
> writeEndTag( TABLE_CELL_TAG );
> writeEndTag( TABLE_ROW_TAG );
> @@ -1146,10 +1146,10 @@
>
> writeStartTag( TABLE_CELL_TAG, "number-columns-spanned", "2",
> "cover.border.left.bottom" );
> writeStartTag( BLOCK_TAG, "cover.subtitle" );
> -write( subtitle == null ? ( version == null ? "" : " v. " + version
> ) : subtitle );
> +text( subtitle == null ? ( version == null ? "" : " v. " + version )
> : subtitle );
> writeEndTag( BLOCK_TAG );
> writeStartTag( BLOCK_TAG, "cover.subtitle" );
> -write( type == null ? "" : type );
> +text( type == null ? "" : type );
> writeEndTag( BLOCK_TAG );
> writeEndTag( TABLE_CELL_TAG );
> writeEndTag( TABLE_ROW_TAG );
> @@ -1214,7 +1214,7 @@
> att.addAttribute( "height", "0.3in" );
> att.addAttribute( "text-align", "left" );
> writeStartTag( BLOCK_TAG, att );
> -write( compName == null ? ( cover.getAuthor() == null ? "" :
> cover.getAuthor() ) : compName );
> +text( compName == null ? ( cover.getAuthor() == null ? "" :
> cover.getAuthor() ) : compName );
> writeEndTag( BLOCK_TAG );
> writeEndTag( TABLE_CELL_TAG );
>
> @@ -1223,7 +1223,7 @@
> att.addAttribute( "height", "0.3in" );
> att.addAttribute( "text-align", "right" );
> writeStartTag( BLOCK_TAG, att );
> -write( date == null ? "" : date );
> +text( date == null ? "" : date );
> writeEndTag( BLOCK_TAG );
> writeEndTag( TABLE_CELL_TAG );
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more informat
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322912#comment-322912 ] Joniec Jacek commented on MNG-3092: --- @Sergei, you believe we need to change the default behavior of IDE, right? According to you we need to change the IDE behaviour first to solve this simple problem. Here is the example suppose I have project A 1.0.0 and 1.0.1-SNAPSHOT from one Team. Project B different team is depending on A. Project B is developing their project and using range [1.0.0,1.1.0] of A, development time you will get 1.0.1-SNAPSHOT but build time you will get 1.0.0 because you are passing parameter. If you think we need to fix IDE first then we should stop commenting here and ask all IDE to fix it first. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322912#comment-322912 ] Joniec Jacek edited comment on MNG-3092 at 3/29/13 3:07 PM: @Sergei, you believe we need to change the default behavior of IDE, right? According to you we need to change the IDE behavior first to solve this simple problem. Here is the example suppose I have project A 1.0.0 and 1.0.1-SNAPSHOT from one Team. Project B different team is depending on A. Project B is developing their project and using range [1.0.0,1.1.0] of A, development time you will get 1.0.1-SNAPSHOT but build time you will get 1.0.0 because you are passing parameter. If you think we need to fix IDE first then we should stop commenting here and ask all IDE to fix it first. Pls don't take it personally. was (Author: joniec): @Sergei, you believe we need to change the default behavior of IDE, right? According to you we need to change the IDE behaviour first to solve this simple problem. Here is the example suppose I have project A 1.0.0 and 1.0.1-SNAPSHOT from one Team. Project B different team is depending on A. Project B is developing their project and using range [1.0.0,1.1.0] of A, development time you will get 1.0.1-SNAPSHOT but build time you will get 1.0.0 because you are passing parameter. If you think we need to fix IDE first then we should stop commenting here and ask all IDE to fix it first. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322913#comment-322913 ] Paul Vonnahme commented on MNG-3092: How many maven command line options exist that affect the build without a corresponding XML element? You can put true in your surefire configuration. Since this cuts across and , it seems to me if this were to be an attribute it would have to be at the top level: http://maven.apache.org/pom.html#Quick_Overview It seems about 50% of the people on this thread believe a range should never contain a SNAPSHOT. If that's the case it would be nice to put false in your topmost corporate pom and not have to worry about it going on the command line of every build. If the solution also needed to cover MNG-5353, it feels like you would need additional options. So maybe noSnapshots or noPreRelease or ...? If you wanted different advice for different stages of development, you could put this attribute in a profile you could activate from the command line. I'm not sure of the technical hurdles to something like , but in my opinion it seems like the most complete solution. I'm not heavily invested in version ranges at the moment, but thought I'd throw in my $0.02. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322914#comment-322914 ] Joniec Jacek commented on MNG-3092: --- Ok so in that case you need to change POM file for release and SNAPSHOT, then what is problem with putting and removing -SNAPSHOT from range and here you don't required more attribute as well and it easy to understand > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322915#comment-322915 ] Scott Sosna commented on MNG-3092: -- I'm in the other 50% who require snapshots to be included in ranges for development, and changing that breaks previous behavior. Sure, I can make the change, that's fine, but 50% of the populations going to be inconvenienced, and if they haven't been following this, they'll have no idea why. Potentially dangerous. Also, I cannot wait n months until all the IDEs support behavior that I'm not convinced could be decently explained to them. We've had almost 6 years to scope this out, and nothing's happened, why does anyone believe it's going to happen now. Let's restore the behavior from Maven2 - regardless of how right or wrong anyone feels it is - and start with a clean slate. At least it was understood and usable, what we have now in Maven3 is neither. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322916#comment-322916 ] Joniec Jacek commented on MNG-3092: --- @Scott, that is what I'm asking to all if you go with http://www.mail-archive.com/dev@maven.apache.org/msg68512.html it simply says "We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary" We need this to be resolve ASAP with simple solution until finalize new design. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322916#comment-322916 ] Joniec Jacek edited comment on MNG-3092 at 3/29/13 3:36 PM: @Scott, that is what I'm asking to all if you go with http://www.mail-archive.com/dev@maven.apache.org/msg68512.html it simply says "We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary" We need this to be resolve ASAP with simple solution until new design finalize was (Author: joniec): @Scott, that is what I'm asking to all if you go with http://www.mail-archive.com/dev@maven.apache.org/msg68512.html it simply says "We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary" We need this to be resolve ASAP with simple solution until finalize new design. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-399) Links with '_' and '-' don't work
[ https://jira.codehaus.org/browse/DOXIA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed DOXIA-399. Resolution: Fixed Fix Version/s: 1.4 Assignee: Robert Scholte Fixed in [r1462638|http://svn.apache.org/r1462638] > Links with '_' and '-' don't work > - > > Key: DOXIA-399 > URL: https://jira.codehaus.org/browse/DOXIA-399 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1.3 > Environment: mvn -version > Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.6.0_20 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" >Reporter: Nathan Sowatskey >Assignee: Robert Scholte > Fix For: 1.4 > > Attachments: toc-test-case.zip, toc-test-case.zip, toc-test-case.zip > > > See links.confluence in the attached project. > Neither the link to PAC or WPAD are rendered properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322918#comment-322918 ] Scott Sosna commented on MNG-3092: -- @Joniec Agreed, it needs to be solved ASAP. But if it isn't resolved - and it's 3 months short of 6 years - the second possibility listed is to "leave range resolution behaving as it is, then use profiles to enable or disable snapshot repositories at build time." The history on this issue does not lend confidence in trying to implement the design docs as defined, and if we can't then the original Maven2 behavior should be restored. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322919#comment-322919 ] Sergei Ivanov commented on MNG-3092: [@Scott|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322908&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322908] Reverting to dependency management from Maven2 is not an option. Firstly, because Maven3 uses an entirely new [dependency management library|http://projects.eclipse.org/projects/technology.aether]. Secondly, because dependency resolution that involves ranges is broken in Maven2, and we went through really hard time when we had to adapt our Maven3 project to be usable by another team, who are still on Maven2. Effectively, we ended up providing them with an alternative POM, where all version ranges were removed and versions locked down. [@Joniec|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322912&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322912] No, the default behaviour of IDEs will not change. Neither will change the default behaviour of Maven. One will need to override it with the new switch to exclude snapshots. If the team of project B does not override the default behaviour, they will be both building and developing against 1.0.1-SNAPSHOT. If project B starts using features from A:1.0.1-SNAPSHOT that are not available in A:1.0.0, then they will not be able to release (or build with _the switch_ turned on) until project A releases 1.0.1. They can set up (like we do) two CI builds, one of which will verify that project B still builds against the latest released version of project A (1.0.0), and the other one will check that project B builds against the latest snapshot of project A(1.0.1-SNAPSHOT). If team B never want to build or develop against snapshots of A, they can control it via repository management. Or they should perhaps not use ranges in the first place (which is probably a good idea if the teams are developing at different paces and want to have better control of their dependencies). All in all, they will not be worse off than they are now. [@Paul|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322913&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322913] In an ideal world, yes we'd be able to extend Maven POM model and carry on. Unfortunately, this has a potential to break projects that are still using previous Maven versions. This is the reason why Maven core team are so reluctant to introduce any changes to the model. I agree, we may want to control it in a finer-grained way. Like specifying the default resolution strategy on the level, and posiibly overriding in on the individual level. In a real world, this MNG-3092 saga has been going on for ages, and the only alternative proposed solution involves modifying the POMs on a regular basis to achieve the desired behaviour. Personally, I do not want to go through tens of related POMs in my project and introduce snapshots in ranges so that I could use them in my IDE, and then revert the changes when I want to release them. This would completely negate any benefits of version ranges. I am proposing a solution that (1) will not break backward compatibility of maven builds by default, (2) will not require changes to POM model, (3) will allow to use the new behaviour without the need to edit POM files (essentially, you can switch between the old and the new behaviour when using the same POM file). I do also desperately want a concrete solution to this six year old problem, and I want a solution that I will be able to start using within my own lifespan. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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 s
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322928#comment-322928 ] Joniec Jacek commented on MNG-3092: --- @Sergei, It's very difficult to explain you... :) Please understand the problem, First of all Team B does not want to use SNAPSHOT and want to use only release version of A. Whenever team A release incremental version it should picked up by team B without changing anything. But this is very common that team A is also adding new feature and creating SNAPSHOT version before release. In between if team B also working on their app and at that time they will get SNAPSHOT... this is very common situation please understand it. You two CI model is going to work as it's more work we need to do so please leave that option. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322929#comment-322929 ] Joniec Jacek commented on MNG-3092: --- @Sergei, what do you mean by "Are you concerned about the way it is going to be handled in IDEs? I personally don't see that being a problem, although IDE vendors may need to implement the equivalent of a command line option for embedded Maven engines." Are you saying IDE vendors need to change their implementation? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322930#comment-322930 ] Sergei Ivanov commented on MNG-3092: @Joniec To your [first comment|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322928]. I know it may be difficult to explain, that is why I am asking for detailed examples or use cases, so that we all can be sure we understand the problem in the same way. If team B *never* wants to pick up snapshots of team A, then this problem can be solved pretty easily without changing Maven a bit. All they need to do is to segregate their repositories (which is generally not a bad idea anyway): 1. Team A sets up separate release and snapshot repositories for their artifacts. 2. Team B sets up a repository group for themselves that only includes the release repo of team A. This way, team B will only ever see the released versions of artifacts from team A. Done. As a matter of fact, both teams can even share the same release repository, it is only the snapshot repositories that need to be segregated. To your [second comment|https://jira.codehaus.org/browse/MNG-3092?focusedCommentId=322929&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322929]. Yes, obviously if we are going to introduce changes into Maven, IDE vendors will have to support the new functionality eventually. Our implementation choice does not really matter here. By default, however, everything should continue to work the way it is now. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322931#comment-322931 ] Joniec Jacek commented on MNG-3092: --- @Sergei, you are making so complicate here when you are working with big company it's very difficult to separate out repo team by team if Same team is working on different project and want SNAPSHOT version of team C thn and more over in same project it self if they want SNAPSHOT version of C and release version of A then this is valid use case We can not separate out repo team base we have common repo in entire organization one for SNAPSHOT and one for RELEASE and many company they have only one repo which contain release and SNAPSHOT... We want to solve this problem for everyone with minimal change. If you are saying "Yes obviously" to IDE vendors to change their implementation thn please ask them first, are they ready to change? If we have problem in Maven feature then first we need to solve the problem in Maven without depending on other tools to support us... Sorry, but I'm not agree with you. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322932#comment-322932 ] Sergei Ivanov commented on MNG-3092: Joniec, Firstly, I do not see any point in asking IDE vendors for permission. It is their job to follow the trends and changes in the software landscape and constantly adapting to the changes. Can you imagine people from Spring or Hibernate projects begging IDE vendors for permission to make changes in their products? This would be plain silly. Secondly, if an organisation has a complicated web of project dependencies and they are not willing to invest in a proper repository set-up and management, then they are not doing themselves any favour. I am myself working in a large organisation, and we have tens of teams, lots of projects, and we do maintain many separate Maven repositories. Suppose our team is responsible for a financial application that handles transactions worth £1bn daily, then we would want a complete control over the artifacts that we integrate from other teams, would not we? I firmly believe that the use case you described can be (and perhaps should be) handled through proper repository set-up. If your project C depends on A:[1.0,1.1) and B:[2.3,2.4), and you do actually need to include snapshots for A, but not for B, then my proposal will not work for you with a vanilla repository set-up. In that case you will need a fine-grained resolution policy on the individual dependency level. And that does not solve the problem with releasing projects when snapshot dependencies are present. If we are forced to edit POM files before release, then what is the point in having version ranges? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-142) Shade plugin does unbuffered output
[
https://jira.codehaus.org/browse/MSHADE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MSHADE-142.
-
Resolution: Fixed
Fix Version/s: 2.0.1
Assignee: Kristian Rosenvold
Fixed in r1462709, thanks for the patch !
> Shade plugin does unbuffered output
> ---
>
> Key: MSHADE-142
> URL: https://jira.codehaus.org/browse/MSHADE-142
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Anders Wallgren
>Assignee: Kristian Rosenvold
> Fix For: 2.0.1
>
>
> maven-shade-plugin does unbuffered output:
> {code}
> JarOutputStream jos = new JarOutputStream( new FileOutputStream(
> shadeRequest.getUberJar() ) );
> {code}
> This results in massive amounts of single-byte writes, which kills
> performance, particularly on network shares.
> Changing the code to
> {code}
> JarOutputStream jos = new JarOutputStream( new BufferedOutputStream(
> new FileOutputStream( shadeRequest.getUberJar() ) ) );
> {code}
> Fixes the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5456) Maven skips modules and reports success if parallel build encounters java.lang.Error
[ https://jira.codehaus.org/browse/MNG-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MNG-5456. --- Resolution: Fixed Fix Version/s: 3.1.0 Assignee: Kristian Rosenvold Fixed in 973673721b138e8dde68997fe198dff1417c2299, thanks for the excellent bug report! > Maven skips modules and reports success if parallel build encounters > java.lang.Error > > > Key: MNG-5456 > URL: https://jira.codehaus.org/browse/MNG-5456 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Reporter: Ivan S. Dubrov >Assignee: Kristian Rosenvold >Priority: Critical > Fix For: 3.1.0 > > > If Mojo throws instance of java.lang.Error during the parallel build (for > example, OutOfMemoryError), Maven marks module as "SKIPPED", skips the rest > of the modules and reports "BUILD SUCCESSFUL". This is very confusing and > dangerous behavior. > The root cause is that exception coming from executor service is swallowed at > line 133 in the org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder. > Note that this only happens if parallel build is enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322938#comment-322938 ] Joniec Jacek commented on MNG-3092: --- Sergei, when you want to release your SNAPSHOT what do you do? And same artifact when you want to release without SNAPSHOT what you do? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322938#comment-322938 ] Joniec Jacek edited comment on MNG-3092 at 3/30/13 1:30 AM: Sergei, To solve this problem you are expecting IDE needs to change their implement and then everyone has to use that IDE to implement this feature..? Give me answer of below question... when you want to release your SNAPSHOT what do you do? And same artifact when you want to release without SNAPSHOT what you do? was (Author: joniec): Sergei, when you want to release your SNAPSHOT what do you do? And same artifact when you want to release without SNAPSHOT what you do? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322938#comment-322938 ] Joniec Jacek edited comment on MNG-3092 at 3/30/13 1:34 AM: Sergei, To solve this problem you are expecting IDE verndors needs to change their implementation and then everyone has to use that IDE to implement this feature..? This is a bug and not a new feature due to which they need to change this. Give me answer of below question... when you want to release your SNAPSHOT what do you do? And same artifact when you want to release without SNAPSHOT what you do? was (Author: joniec): Sergei, To solve this problem you are expecting IDE needs to change their implement and then everyone has to use that IDE to implement this feature..? Give me answer of below question... when you want to release your SNAPSHOT what do you do? And same artifact when you want to release without SNAPSHOT what you do? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322939#comment-322939 ] Joniec Jacek commented on MNG-3092: --- Sergei, Suppose I have two dependency defined with version range in my project and one of them I want to use SNAPSHOT and second release, this is again valid use case because many project has on going work for many library and they need SNAPSHOT version of those. > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: https://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 3.1.1 > > Attachments: MNG-3092.patch, 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, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
