I think it already makes sense to put the default generation of the
resource into the lifecycles for 2.1 - 3.0... it should have no
adverse affect even though the JAR plugin bundles a different once
since the content is the same. A future release of the JAR plugin can
check for it's existence and only generate it (for 2.0.x
compatibility) if it doesn't exist.
Does that sound like the right approach?
Cheers,
Brett
On 05/10/2008, at 3:33 AM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sat Oct 4 09:33:36 2008
New Revision: 701665
URL: http://svn.apache.org/viewvc?rev=701665&view=rev
Log:
o placing a hard coded version in the event the pom.properties can't
be found. for debugging inside m2e i can live with this.
Modified:
maven/components/trunk/maven-core/src/main/java/org/apache/maven/
execution/DefaultRuntimeInformation.java
Modified: maven/components/trunk/maven-core/src/main/java/org/apache/
maven/execution/DefaultRuntimeInformation.java
URL:
http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java?rev=701665&r1=701664&r2=701665&view=diff
=
=
=
=
=
=
=
=
======================================================================
--- maven/components/trunk/maven-core/src/main/java/org/apache/maven/
execution/DefaultRuntimeInformation.java (original)
+++ maven/components/trunk/maven-core/src/main/java/org/apache/maven/
execution/DefaultRuntimeInformation.java Sat Oct 4 09:33:36 2008
@@ -66,7 +66,7 @@
if ( resourceAsStream == null )
{
- return new ApplicationInformation( new
DefaultArtifactVersion( version ), builtOn );
+ return new ApplicationInformation( new
DefaultArtifactVersion( "3.0" ), builtOn );
}
properties.load( resourceAsStream );
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
