NPanday - Visual Studio Integration for Maven
Hi, For those not on nmaven-dev that might be interested... After the termination of the NMaven podling in the incubator, a continuation of the 0.14 branch has been started at Codeplex called NPanday: http://www.codeplex.com/npanday The project is composed of Visual Studio integration for Maven (and Maven repositories), and a set of Maven plugins for .NET languages. Discussion list: http://www.codeplex.com/npanday/Thread/List.aspx SVN: https://npanday.svn.codeplex.com/svn Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Proposed change to handling of dependency version ranges
I would like to propose a change to how maven handles version ranges such as [1.0,), as described in http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflicthttp://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+ConflictResolution#DependencyMediationandConflictResolution-DependencyVersionRanges+http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRangesResolution#DependencyMediationandConflictResolution-DependencyVersionRangeshttp://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+ConflictResolution#DependencyMediationandConflictResolution-DependencyVersionRanges The current strategy is defined as Of the overlapping ranges, the *highest* soft requirement is the version to be used (emphasis added). Unfortunately, this leads to temporally unstable builds - a build of the exact same code base can change from one day to the next if a new version of one of the dependencies specified with ranges in its pom is released. I would propose that the semantics change to Of the overlapping ranges, the *lowest* soft requirement is the version to be used. Consequently, new releases of a project would not change builds of other projects depending on it (assuming that version numbers increase instead of decrease with each release). This would negatively impact those projects wanting to live on the bleeding edge, but benefit projects wanting repeatable builds. In practice, range syntax does not appear to have gained much traction to date, so this change would hopefully not have substantial impact in terms of backwards incompatibility. Moreover, providing semantics which do not introduce instability might increase adoption of the syntax. If there are objections to this, I would be interested in knowing what they are. If there are not objections, I would be quite willing to provide a patch of the code and unit tests. - Ian Robertson CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you.
What will replace the @aggregator MOJO configuration?
Hi, I noticed that the 'aggregator' parameter for a MOJO is slated for deprecation in a future release of Maven. http://books.sonatype.com/maven-book/reference/writing-plugins.html#d0e22494 What should be used instead, to fulfill the following use-case: - a multi-module project, which would like to assert something about the entire project at the very end of the build. A concrete example is mentioned on our Clover Forums at http://forums.atlassian.com/post!reply.jspa?messageID=257294857 . The user would like to only run clover2:check on the entire project, not on each sub-module. Cheers, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed change to handling of dependency version ranges
Ian Robertson schrieb: I would propose that the semantics change to Of the overlapping ranges, the *lowest* soft requirement is the version to be used. Consequently, new releases of a project would not change builds of other projects depending on it (assuming that version numbers increase instead of decrease with each release). This would negatively impact those projects wanting to live on the bleeding edge, but benefit projects wanting repeatable builds. Could you please give an example showing exactly the proposed change. Choosing a lower version over a higher version breaks compatibility since higher versions tend to have evolved and may have features a lower version does not provide, assuming that higher versions are backwards compatible to lower versions. -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed change to handling of dependency version ranges
We cannot change the behavior, or really even attempt to fiddle with the code in 2.0.x. We are also planning on entirely replacing this code with Mercury in the 3.x line. Apache SVN is down so I'll point you to Mercury when it comes back. Oleg is the one who has implemented Mercury so he can also point you in the right direction. On 3-Dec-08, at 4:36 PM, Ian Robertson wrote: I would like to propose a change to how maven handles version ranges such as [1.0,), as described in http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+ConflictResolution#DependencyMediationandConflictResolution-DependencyVersionRanges +http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges Resolution#DependencyMediationandConflictResolution- DependencyVersionRangeshttp://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+ConflictResolution#DependencyMediationandConflictResolution-DependencyVersionRanges The current strategy is defined as Of the overlapping ranges, the *highest* soft requirement is the version to be used (emphasis added). Unfortunately, this leads to temporally unstable builds - a build of the exact same code base can change from one day to the next if a new version of one of the dependencies specified with ranges in its pom is released. I would propose that the semantics change to Of the overlapping ranges, the *lowest* soft requirement is the version to be used. Consequently, new releases of a project would not change builds of other projects depending on it (assuming that version numbers increase instead of decrease with each release). This would negatively impact those projects wanting to live on the bleeding edge, but benefit projects wanting repeatable builds. In practice, range syntax does not appear to have gained much traction to date, so this change would hopefully not have substantial impact in terms of backwards incompatibility. Moreover, providing semantics which do not introduce instability might increase adoption of the syntax. If there are objections to this, I would be interested in knowing what they are. If there are not objections, I would be quite willing to provide a patch of the code and unit tests. - Ian Robertson CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed change to handling of dependency version ranges
Dear All, Jason van Zyl wrote: We cannot change the behavior, or really even attempt to fiddle with the code in 2.0.x. We are also planning on entirely replacing this code with Mercury in the 3.x line. Apache SVN is down so I'll point you to Mercury when it comes back. Oleg is the one who has implemented Mercury so he can also point you in the right direction. I tried to comply with OSGi versions spec, Mercury approach is documented here: http://docs.codehaus.org/display/MAVEN/Mercury+Version+Ranges Implementation is here: http://svn.apache.org/repos/asf/maven/mercury/trunk/mercury-artifact/src/main/java/org/apache/maven/mercury/artifact/version/MavenVersionRange.java Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed change to handling of dependency version ranges
On Thu, Dec 4, 2008 at 11:06 AM, Ian Robertson [EMAIL PROTECTED] wrote: I would propose that the semantics change to Of the overlapping ranges, the *lowest* soft requirement is the version to be used. Consequently, new releases of a project would not change builds of other projects depending on it (assuming that version numbers increase instead of decrease with each release). This would negatively impact those projects wanting to live on the bleeding edge, but benefit projects wanting repeatable builds. In practice, range syntax does not appear to have gained much traction to date, so this change would hopefully not have substantial impact in terms of backwards incompatibility. Moreover, providing semantics which do not introduce instability might increase adoption of the syntax. I think the short answer is, if you want repeatable builds then don't use range syntax. By defining a range you are saying that everything that fits in this range is a valid choice. Even those in the future that have yet to be release, as long as they fit in the range. Given that these future versions dont exist they haven't been tested so using a range can be dangerous. There is talk about a plugin (can't recall which) that can lock down the version of plugins and also tell you if newer versions are available, so you can selectively decide to upgrade. But I am not sure if such a plugin exists yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed change to handling of dependency version ranges
2008/12/4 Barrie Treloar [EMAIL PROTECTED] There is talk about a plugin (can't recall which) that can lock down the version of plugins and also tell you if newer versions are available, so you can selectively decide to upgrade. But I am not sure if such a plugin exists yet. That would be the versions-maven-plugin which is 24 hours away from 1.0-alpha-2 (I hope) over on mojo. You define the versions of dependencies using properties. If you put the properties inside a hard range then you have effectively locked the version down. Then the versions-maven-plugin can update the properties for you. In addition, you can define the range within which each property can be updated... The goal you're after is versions:update-properties
