Another problem is that some poms in the repo contain uninterpolated
${mavenVersion} values. If we specify the runtime version of say Maven 3.0,
when the artifact provider compiled with Maven 2.0, then we could get all
sorts of nasty class cast exceptions. Outside of cleaning up the repo
metadata, I don't see how to solve this problem.Shane On Tue, Nov 18, 2008 at 3:39 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > It would cause a circular dependency so we're doing this for the time > being. > > > On 18-Nov-08, at 5:12 PM, Brett Porter wrote: > > There are libraries for getting the current version of Maven from within >> Maven - it used to be called RuntimeInfo. Jason did the same thing for >> settings reading a little while back. I'm not sure since settings was folded >> back in how this might work from outside of the core, but it needs to be >> passed in somehow... >> >> Cheers, >> Brett >> >> On 19/11/2008, at 4:29 AM, [EMAIL PROTECTED] wrote: >> >> Author: sisbell >>> Date: Tue Nov 18 09:29:00 2008 >>> New Revision: 718660 >>> >>> URL: http://svn.apache.org/viewvc?rev=718660&view=rev >>> Log: >>> Add in implicit maven version property. >>> >>> Modified: >>> >>> >>> maven/components/branches/sisbell-maven-3.0-mercury/maven-mercury/src/main/java/org/apache/maven/mercury/MavenDependencyProcessor.java >>> >>> Modified: >>> maven/components/branches/sisbell-maven-3.0-mercury/maven-mercury/src/main/java/org/apache/maven/mercury/MavenDependencyProcessor.java >>> URL: >>> http://svn.apache.org/viewvc/maven/components/branches/sisbell-maven-3.0-mercury/maven-mercury/src/main/java/org/apache/maven/mercury/MavenDependencyProcessor.java?rev=718660&r1=718659&r2=718660&view=diff >>> >>> ============================================================================== >>> --- >>> maven/components/branches/sisbell-maven-3.0-mercury/maven-mercury/src/main/java/org/apache/maven/mercury/MavenDependencyProcessor.java >>> (original) >>> +++ >>> maven/components/branches/sisbell-maven-3.0-mercury/maven-mercury/src/main/java/org/apache/maven/mercury/MavenDependencyProcessor.java >>> Tue Nov 18 09:29:00 2008 >>> @@ -29,6 +29,9 @@ >>> } >>> >>> List<InterpolatorProperty> interpolatorProperties = new >>> ArrayList<InterpolatorProperty>(); >>> + interpolatorProperties.add(new >>> InterpolatorProperty("${mavenVersion}", "3.0-SNAPSHOT", >>> PomInterpolatorTag.SYSTEM_PROPERTIES.name())); >>> + interpolatorProperties.add(new >>> InterpolatorProperty("${maven.version}", "3.0-SNAPSHOT", >>> PomInterpolatorTag.SYSTEM_PROPERTIES.name())); >>> + >>> if(system != null) { >>> interpolatorProperties.addAll( >>> InterpolatorProperty.toInterpolatorProperties( system, >>> PomInterpolatorTag.SYSTEM_PROPERTIES.name())); >>> >>> >>> >> -- >> Brett Porter >> [EMAIL PROTECTED] >> http://blogs.exist.com/bporter/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
