[GUMP@vmgump]: Project velocity-texen-test (in module velocity-texen) failed

View: New views
9 Messages — Rating Filter:   Alert me  

[GUMP@vmgump]: Project velocity-texen-test (in module velocity-texen) failed

by Velocity - Dev mailing list-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

To whom it may engage...
       
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at general@....

Project velocity-texen-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 17 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
    - velocity-texen-test :  Texen is a general purpose text generating utility based on ...


Full details are available at:
    http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/gump_work/build_velocity-texen_velocity-texen-test.html
Work Name: build_velocity-texen_velocity-texen-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Ddeprecation=false -Dversion=04052008 -Dskip.jar.loading=true test
[Working Directory: /srv/gump/public/workspace/velocity-texen/build]
CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/velocity-texen/bin/test-classes:/srv/gump/public/workspace/velocity-texen/bin/test:/srv/gump/public/workspace/velocity-texen/bin/test/texen-classpath.jar:/srv/gump/public/workspace/velocity-texen/bin/texen-04052008.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-04052008.jar:/srv/gump/public/workspace/apache-commons/lang/commons-lan
 g-04052008.jar:/srv/gump/public/workspace/logging-log4j-12/dist/lib/log4j-04052008.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/packages/werken-xpath/werken-xpath-0.9.4.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-04052008.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-04052008.jar:/srv/gump/public/workspace/velocity-anakia/bin/anakia-04052008.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar
---------------------------------------------

test-jar:
    [mkdir] Created dir: /srv/gump/public/workspace/velocity-texen/bin/test
      [jar] Building jar: /srv/gump/public/workspace/velocity-texen/bin/test/texen-classpath.jar

test:
    [mkdir] Created dir: /srv/gump/public/workspace/velocity-texen/bin/test-reports
    [junit] Running org.apache.texen.ExtendedTexenTestCase
    [junit] Template results directory does not exist
    [junit] Created template results directory
    [junit] Generating to file bin/test/texen-generator/report
    [junit] Comparing result file 'bin/test/texen-generator/TurbineWeather.java' with compare file 'test/texen/compare/TurbineWeather.java'
    [junit] Comparing result file 'bin/test/texen-generator/TurbineWeatherService.java' with compare file 'test/texen/compare/TurbineWeatherService.java'
    [junit] Comparing result file 'bin/test/texen-generator/WeatherService.java' with compare file 'test/texen/compare/WeatherService.java'
    [junit] Comparing result file 'bin/test/texen-generator/book.txt' with compare file 'test/texen/compare/book.txt'
    [junit] Comparing result file 'bin/test/texen-generator/Text.txt' with compare file 'test/texen/compare/Text.txt'
    [junit] Template results directory does not exist
    [junit] Created template results directory
    [junit] Using classpath
    [junit] Generating to file bin/test/texen-generator-classpath/report
    [junit] org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'Control.vm'
    [junit] at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:452)
    [junit] at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335)
    [junit] at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1342)
    [junit] at org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:419)
    [junit] at org.apache.texen.Generator.getTemplate(Generator.java:321)
    [junit] at org.apache.texen.Generator.parse(Generator.java:451)
    [junit] at org.apache.texen.Texen.execute(Texen.java:342)
    [junit] at org.apache.texen.ExtendedTexenTestCase.testExtendedTexenClasspath(ExtendedTexenTestCase.java:176)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.737 sec
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    [junit] at java.lang.reflect.Method.invoke(Method.java:585)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:154)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:127)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
    [junit] at junit.framework.TestResult.run(TestResult.java:109)
    [junit] at junit.framework.TestCase.run(TestCase.java:118)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:203)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)

BUILD FAILED
/srv/gump/public/workspace/velocity-texen/build/build.xml:520: Test org.apache.texen.ExtendedTexenTestCase failed

Total time: 4 seconds
---------------------------------------------

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/rss.xml
- Atom: http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/atom.xml

============================== Gump Tracking Only ===
Produced by Gump version 2.3.
Gump Run 11000004052008, vmgump:vmgump-public:11000004052008
Gump E-mail Identifier (unique within run) #28.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Expanding Environmental variables patch

by csanders :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Attached is the patch, adding three new functions,
expandEnvironmentalVariables( ExtendedProperties ),
expandEnvironmentalVariables(Vector ), expandEnvironmentalVariables(String).

The expansion should really take place in ExtendedProperties, but this
might work in the interim .

Is their someone to codereview this ?

Thanks!
Charlei

Index: /home/csanders/workspace/Velocity/src/java/org/apache/velocity/runtime/RuntimeInstance.java
===================================================================
--- /home/csanders/workspace/Velocity/src/java/org/apache/velocity/runtime/RuntimeInstance.java (revision 653790)
+++ /home/csanders/workspace/Velocity/src/java/org/apache/velocity/runtime/RuntimeInstance.java (working copy)
@@ -29,8 +29,10 @@
 import java.util.Enumeration;
 import java.util.HashMap;
 import java.util.Hashtable;
+import java.util.Iterator;
 import java.util.Map;
 import java.util.Properties;
+import java.util.Vector;
 
 import org.apache.commons.collections.ExtendedProperties;
 import org.apache.velocity.Template;
@@ -395,7 +397,12 @@
             overridingProperties = new ExtendedProperties();
         }
 
-        overridingProperties.setProperty(key, value);
+     Object newValue = value;
+        
+        if ( value instanceof String ) newValue = expandEnvironmentalVariable((String)value);
+        else if ( value instanceof Vector ) newValue = this.expandEnvironmentalVariables((Vector)value);
+        
+        overridingProperties.setProperty(key, newValue);
     }
 
     /**
@@ -410,6 +417,9 @@
      */
     public void setConfiguration( ExtendedProperties configuration)
     {
+
+     expandEnvironmentalVariables(configuration);
+    
         if (overridingProperties == null)
         {
             overridingProperties = configuration;
@@ -450,7 +460,12 @@
             overridingProperties = new ExtendedProperties();
         }
 
-        overridingProperties.addProperty(key, value);
+        Object newValue = value;
+        
+        if ( value instanceof String ) newValue = expandEnvironmentalVariable((String)value);
+        else if ( value instanceof Vector ) newValue = this.expandEnvironmentalVariables((Vector)value);
+        
+        overridingProperties.addProperty(key, newValue);
     }
 
     /**
@@ -521,6 +536,7 @@
         if (configuration.isInitialized() == false)
         {
             setDefaultProperties();
+            expandEnvironmentalVariables(configuration);
         }
 
         if( overridingProperties != null)
@@ -525,6 +541,7 @@
 
         if( overridingProperties != null)
         {
+         expandEnvironmentalVariables(overridingProperties);
             configuration.combine(overridingProperties);
         }
     }
@@ -529,13 +546,85 @@
         }
     }
 
+    
     /**
-     * Initialize the Velocity Runtime with a Properties
-     * object.
-     *
-     * @param p
-     * @throws Exception When an error occurs during initialization.
-     */
+ * Replace all environmental variables in the form of ${VELOCITY_HOME} with their expansions
+ *
+ * @param properties
+ */
+
+    private Vector expandEnvironmentalVariables(Vector stringVector) {
+ Vector newVector = new Vector();
+ Iterator vectorIterator = stringVector.iterator();
+
+ while (vectorIterator.hasNext()) {
+ String newValue = expandEnvironmentalVariable((String) vectorIterator.next());
+ newVector.add(newValue);
+ }
+
+ return newVector;
+ }
+
+ private void expandEnvironmentalVariables(ExtendedProperties properties) {
+
+ Iterator propertiesIterator = properties.getKeys();
+ Map convertedValues = new HashMap();
+
+ while (propertiesIterator.hasNext()) {
+ String key = (String) propertiesIterator.next();
+ Object value = properties.get(key);
+
+ if (value instanceof String) {
+ String newValue = expandEnvironmentalVariable((String) value);
+ convertedValues.put(key, newValue);
+ }
+ else if (value instanceof Vector) {
+ Vector newVector = expandEnvironmentalVariables((Vector) value);
+ convertedValues.put(key, newVector);
+ }
+ }
+ properties.putAll(convertedValues);
+ }
+
+ /**
+ * Replace all occurrences of ${} in a string with its corresponding expanded environmental var's
+ *  enviornment
+ * @param string
+ * @return
+ */
+
+ private String expandEnvironmentalVariable(String string) {
+
+ int start = string.indexOf("${");
+
+ if (start != -1) {
+
+ int end = string.indexOf('}');
+
+ if (end != -1) {
+ String env = string.substring(start + 2, end);
+ String regex = "\\$\\{" + env + "\\}";
+ String replacement = System.getenv(env);
+
+ if (replacement != null) { return string.replaceAll(regex, replacement);
+
+ }
+
+ }
+
+ }
+ return string;
+
+ }
+
+    
+    /**
+ * Initialize the Velocity Runtime with a Properties object.
+ *
+ * @param p
+ * @throws Exception
+ *             When an error occurs during initialization.
+ */
     public void init(Properties p) throws Exception
     {
         overridingProperties = ExtendedProperties.convertProperties(p);


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Expanding Environmental variables patch

by Christopher Schultz-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Charlei,

csanders wrote:
> Attached is the patch, adding three new functions,
> expandEnvironmentalVariables( ExtendedProperties ),
> expandEnvironmentalVariables(Vector ),

Any reason not to accept any Collection rather than limiting this to
just a Vector? Forgive me if there are API implications coming from
ExtendedProperties.

> + Vector newVector = new Vector();

This should really be:

Vectory newVector = new Vector(stringVector.size());
(or an appropriate Collection instance)

Better yet, if you are using Vectors, why not use Vector.set() instead
of creating a completely new Vector every time? I actually dislike
modifying passed-in parameters, but your
expandEnvironmentalVariables(ExtendedProperties) method does that
already, so what does it matter if the methods that it calls do the same?

> The expansion should really take place in ExtendedProperties, but this
> might work in the interim .

Then why not patch ExtendedProperties instead?

I'm a little curious why this capability needs to be added to Velocity
in the first place. Does anybody really use environment variables
anymore, anyway?

If anything, this should be implemented as a subclass of
ExtendedProperties and handled there. There is no need to modify any
Velocity code to get this to work.

-chris



signature.asc (266 bytes) Download Attachment

RE: Expanding Environmental variables patch

by csanders :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>Any reason not to accept any Collection rather than limiting this to
>just a Vector? Forgive me if there are API implications coming from
>ExtendedProperties.

The Vector was only added because the comma delimted list in the properties file gets translated to a vector.

>I actually dislike  modifying passed-in parameters

Why?  

>I'm a little curious why this capability needs to be added to Velocity
>in the first place. Does anybody really use environment variables
>anymore, anyway?

Err, you don't use JAVA_HOME?  I'm guessing you're not a *nix user ?  

The reason I want them in Velocity, is file.resource.loader.path only accepts a full path.  With several developers working on a project its a pain to have explain how to update this for everyone who wants to run the project.


I agree the ExtendedProperties class is what needs patching, I don't know how receptive they will be though.


Thanks,
Charlei




-----Original Message-----
From: Christopher Schultz [mailto:chris@...]
Sent: Tue 5/6/2008 5:04 PM
To: Velocity Developers List
Subject: Re: Expanding Environmental variables patch
 
Charlei,

csanders wrote:
> Attached is the patch, adding three new functions,
> expandEnvironmentalVariables( ExtendedProperties ),
> expandEnvironmentalVariables(Vector ),

Any reason not to accept any Collection rather than limiting this to
just a Vector? Forgive me if there are API implications coming from
ExtendedProperties.

> + Vector newVector = new Vector();

This should really be:

Vectory newVector = new Vector(stringVector.size());
(or an appropriate Collection instance)

Better yet, if you are using Vectors, why not use Vector.set() instead
of creating a completely new Vector every time? I actually dislike
modifying passed-in parameters, but your
expandEnvironmentalVariables(ExtendedProperties) method does that
already, so what does it matter if the methods that it calls do the same?

> The expansion should really take place in ExtendedProperties, but this
> might work in the interim .

Then why not patch ExtendedProperties instead?

I'm a little curious why this capability needs to be added to Velocity
in the first place. Does anybody really use environment variables
anymore, anyway?

If anything, this should be implemented as a subclass of
ExtendedProperties and handled there. There is no need to modify any
Velocity code to get this to work.

-chris



Re: Expanding Environmental variables patch

by Christopher Schultz-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Charles,

Sanders, Charles wrote:
>> I actually dislike  modifying passed-in parameters
>
> Why?  

The documentation for RuntimeInstance.setConfiguration does not state
that the parameter is modified, so it's rude to modify it. Don't forget
that the documentation is part of the API, too, and it's supposed to be
a stable API. If you need to modify the ExtendedProperties, create a new
one instead and modify that one.

>> I'm a little curious why this capability needs to be added to Velocity
>> in the first place. Does anybody really use environment variables
>> anymore, anyway?
>
> Err, you don't use JAVA_HOME?  I'm guessing you're not a *nix user ?  

I've never deployed anything on Microsoft Windows. Nobody uses
environment variables anymore, even on *NIX. It's system properties, baby.

System.getProperty("java.home")

> The reason I want them in Velocity, is file.resource.loader.path only
> accepts a full path. With several developers working on a project its a
> pain to have explain how to update this for everyone who wants to run
> the project.

I understand the utility of properties files that know how to resolve
references. I'm just not sure I understand why Velocity needs to do this
and not the Properties implementation.

By the way, another way to achieve your goal is to use a build script
that replaces variables for you. Check out Apache ant, which comes with
a whole host of utilities geared toward this purpose.

> I agree the ExtendedProperties class is what needs patching, I don't
> know how receptive they will be though.

I'm sure they will be receptive. Instead of a patch, why not submit an
entirely new class called EnvironmentExpandingExtendedProperties which
extends ExtendedProperties. The methods you would have to override would
be addProperty, combine, convertProperties, setProperty, and possibly
the "load" methods.

Even better, if you read the source code for ExtendedProperties you may
find that every method used "interpolate" in order to replace
parameterized keys and values. In that case, simply override
interpolate() and your job is done.

If you configure Velocity programatically, then you are done.

If you use configuration files, you'll need to ask the Velocity folks to
either replace their use of ExtendedProperties in their config file
loader with EnvironmentExpandingExtendedProperties (which I doubt they'd
do) or allow you to specify the ExtendedProperties subclass to use when
loading configuration (which makes more sense anyway, and is more likely
to actually be done).

Actually, if Velocity supports this, then you can use your own
implementation of ExtendedProperties regardless of the response from the
commons collections folks.

-chris



signature.asc (266 bytes) Download Attachment

RE: Expanding Environmental variables patch

by csanders :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> The documentation for RuntimeInstance.setConfiguration does not state
> that the parameter is modified, so it's rude to modify it.

Ah that makes sense.

>Actually, if Velocity supports this, then you can use your own
>implementation of ExtendedProperties regardless of the response from the
>commons collections folks.

I think this is the most flexibile solution, any Velocity developers care to comment ?  



Thanks,
Charlei





-----Original Message-----
From: Christopher Schultz [mailto:chris@...]
Sent: Wed 5/7/2008 8:21 AM
To: Velocity Developers List
Subject: Re: Expanding Environmental variables patch
 
Charles,

Sanders, Charles wrote:
>> I actually dislike  modifying passed-in parameters
>
> Why?  

The documentation for RuntimeInstance.setConfiguration does not state
that the parameter is modified, so it's rude to modify it. Don't forget
that the documentation is part of the API, too, and it's supposed to be
a stable API. If you need to modify the ExtendedProperties, create a new
one instead and modify that one.

>> I'm a little curious why this capability needs to be added to Velocity
>> in the first place. Does anybody really use environment variables
>> anymore, anyway?
>
> Err, you don't use JAVA_HOME?  I'm guessing you're not a *nix user ?  

I've never deployed anything on Microsoft Windows. Nobody uses
environment variables anymore, even on *NIX. It's system properties, baby.

System.getProperty("java.home")

> The reason I want them in Velocity, is file.resource.loader.path only
> accepts a full path. With several developers working on a project its a
> pain to have explain how to update this for everyone who wants to run
> the project.

I understand the utility of properties files that know how to resolve
references. I'm just not sure I understand why Velocity needs to do this
and not the Properties implementation.

By the way, another way to achieve your goal is to use a build script
that replaces variables for you. Check out Apache ant, which comes with
a whole host of utilities geared toward this purpose.

> I agree the ExtendedProperties class is what needs patching, I don't
> know how receptive they will be though.

I'm sure they will be receptive. Instead of a patch, why not submit an
entirely new class called EnvironmentExpandingExtendedProperties which
extends ExtendedProperties. The methods you would have to override would
be addProperty, combine, convertProperties, setProperty, and possibly
the "load" methods.

Even better, if you read the source code for ExtendedProperties you may
find that every method used "interpolate" in order to replace
parameterized keys and values. In that case, simply override
interpolate() and your job is done.

If you configure Velocity programatically, then you are done.

If you use configuration files, you'll need to ask the Velocity folks to
either replace their use of ExtendedProperties in their config file
loader with EnvironmentExpandingExtendedProperties (which I doubt they'd
do) or allow you to specify the ExtendedProperties subclass to use when
loading configuration (which makes more sense anyway, and is more likely
to actually be done).

Actually, if Velocity supports this, then you can use your own
implementation of ExtendedProperties regardless of the response from the
commons collections folks.

-chris




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Expanding Environmental variables patch

by wglass :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Thanks for your enthusiasm and interest.  We're all Velocity developers
here...

I've never played myself with custom implementations of Extended Properties,
but that seems like a reasonable approach.

Will this patch also support system properties?  (or are they already
supported).  That seems the most useful.

Really, I'd like to see this become part of ExtendedProperties.  Makes more
sense to have that kind of substitution occur at the level.  One idea would
be to submit your patch to that project, then use the modified version with
Velocity. If you do this, let us know how it is working out.  You might even
want to post sample code on our Wiki.

If you still feel that belongs part of Velocity core, then do continue to
speak up and advocate for it being included in the Velocity code directly.

Best, WILL



On Wed, May 7, 2008 at 8:10 AM, Sanders, Charles <csanders@...>
wrote:

> > The documentation for RuntimeInstance.setConfiguration does not state
> > that the parameter is modified, so it's rude to modify it.
>
> Ah that makes sense.
>
> >Actually, if Velocity supports this, then you can use your own
> >implementation of ExtendedProperties regardless of the response from the
> >commons collections folks.
>
> I think this is the most flexibile solution, any Velocity developers care
> to comment ?
>
>
>
> Thanks,
> Charlei
>
>
>
>
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@...]
> Sent: Wed 5/7/2008 8:21 AM
> To: Velocity Developers List
> Subject: Re: Expanding Environmental variables patch
>
> Charles,
>
> Sanders, Charles wrote:
> >> I actually dislike  modifying passed-in parameters
> >
> > Why?
>
> The documentation for RuntimeInstance.setConfiguration does not state
> that the parameter is modified, so it's rude to modify it. Don't forget
> that the documentation is part of the API, too, and it's supposed to be
> a stable API. If you need to modify the ExtendedProperties, create a new
> one instead and modify that one.
>
> >> I'm a little curious why this capability needs to be added to Velocity
> >> in the first place. Does anybody really use environment variables
> >> anymore, anyway?
> >
> > Err, you don't use JAVA_HOME?  I'm guessing you're not a *nix user ?
>
> I've never deployed anything on Microsoft Windows. Nobody uses
> environment variables anymore, even on *NIX. It's system properties, baby.
>
> System.getProperty("java.home")
>
> > The reason I want them in Velocity, is file.resource.loader.path only
> > accepts a full path. With several developers working on a project its a
> > pain to have explain how to update this for everyone who wants to run
> > the project.
>
> I understand the utility of properties files that know how to resolve
> references. I'm just not sure I understand why Velocity needs to do this
> and not the Properties implementation.
>
> By the way, another way to achieve your goal is to use a build script
> that replaces variables for you. Check out Apache ant, which comes with
> a whole host of utilities geared toward this purpose.
>
> > I agree the ExtendedProperties class is what needs patching, I don't
> > know how receptive they will be though.
>
> I'm sure they will be receptive. Instead of a patch, why not submit an
> entirely new class called EnvironmentExpandingExtendedProperties which
> extends ExtendedProperties. The methods you would have to override would
> be addProperty, combine, convertProperties, setProperty, and possibly
> the "load" methods.
>
> Even better, if you read the source code for ExtendedProperties you may
> find that every method used "interpolate" in order to replace
> parameterized keys and values. In that case, simply override
> interpolate() and your job is done.
>
> If you configure Velocity programatically, then you are done.
>
> If you use configuration files, you'll need to ask the Velocity folks to
> either replace their use of ExtendedProperties in their config file
> loader with EnvironmentExpandingExtendedProperties (which I doubt they'd
> do) or allow you to specify the ExtendedProperties subclass to use when
> loading configuration (which makes more sense anyway, and is more likely
> to actually be done).
>
> Actually, if Velocity supports this, then you can use your own
> implementation of ExtendedProperties regardless of the response from the
> commons collections folks.
>
> -chris
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>



--
Forio Business Simulations

Will Glass-Husain
wglass@...
www.forio.com

Re: Expanding Environmental variables patch

by Emmanuel Bourg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi there,

I'm a developer at Apache Commons and Charles contacted us about its
issue with ExtendedProperties. ExtendedProperties is no longer evolving
in Commons Collections since it forked to spawn the Commons
Configuration project some years ago. Many features have been
implemented in Commons Configuration like automatic reloading, changes
notifications, custom interpolation, and more.

Do you think it would be possible to support Commons Configuration in
Velocity and deprecate the use of ExtendedProperties ? I may dedicate
some time to provide a patch if this change seems acceptable. The added
flexibility of Commons Configuration has a cost though, it would add 2
dependencies to Velocity (Commons Configuration and Commons Logging).

What do you think ?

Emmanuel Bourg



Will Glass-Husain a écrit :

> Hi,
>
> Thanks for your enthusiasm and interest.  We're all Velocity developers
> here...
>
> I've never played myself with custom implementations of Extended Properties,
> but that seems like a reasonable approach.
>
> Will this patch also support system properties?  (or are they already
> supported).  That seems the most useful.
>
> Really, I'd like to see this become part of ExtendedProperties.  Makes more
> sense to have that kind of substitution occur at the level.  One idea would
> be to submit your patch to that project, then use the modified version with
> Velocity. If you do this, let us know how it is working out.  You might even
> want to post sample code on our Wiki.
>
> If you still feel that belongs part of Velocity core, then do continue to
> speak up and advocate for it being included in the Velocity code directly.
>
> Best, WILL


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: Expanding Environmental variables patch

by Nathan Bubna :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, May 7, 2008 at 8:10 AM, Sanders, Charles <csanders@...> wrote:

>> The documentation for RuntimeInstance.setConfiguration does not state
>> that the parameter is modified, so it's rude to modify it.
>
> Ah that makes sense.
>
>>Actually, if Velocity supports this, then you can use your own
>>implementation of ExtendedProperties regardless of the response from the
>>commons collections folks.
>
> I think this is the most flexibile solution, any Velocity developers care to comment ?

Charlei, sorry i lost track of this thread, but i'm now playing catch
up with my Velocity TODO list today. I don't think we'll be moving to
commons-configuration anytime soon, and it sounds like the Collections
folks aren't working on ExtendedProperties anymore.  If all this
discussion left something still to be done or some unimplemented ideas
in your head, then could you open a JIRA issue for this, so we can
keep patches/ideas straight here?  Whether it's system properties or
environmental variables, it seems like a useful thing to have some
support.  I'm at least still open to the idea and think it's at least
work tracking in JIRA, if not acting on soon.

>
> Thanks,
> Charlei
>
>
>
>
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@...]
> Sent: Wed 5/7/2008 8:21 AM
> To: Velocity Developers List
> Subject: Re: Expanding Environmental variables patch
>
> Charles,
>
> Sanders, Charles wrote:
>>> I actually dislike  modifying passed-in parameters
>>
>> Why?
>
> The documentation for RuntimeInstance.setConfiguration does not state
> that the parameter is modified, so it's rude to modify it. Don't forget
> that the documentation is part of the API, too, and it's supposed to be
> a stable API. If you need to modify the ExtendedProperties, create a new
> one instead and modify that one.
>
>>> I'm a little curious why this capability needs to be added to Velocity
>>> in the first place. Does anybody really use environment variables
>>> anymore, anyway?
>>
>> Err, you don't use JAVA_HOME?  I'm guessing you're not a *nix user ?
>
> I've never deployed anything on Microsoft Windows. Nobody uses
> environment variables anymore, even on *NIX. It's system properties, baby.
>
> System.getProperty("java.home")
>
>> The reason I want them in Velocity, is file.resource.loader.path only
>> accepts a full path. With several developers working on a project its a
>> pain to have explain how to update this for everyone who wants to run
>> the project.
>
> I understand the utility of properties files that know how to resolve
> references. I'm just not sure I understand why Velocity needs to do this
> and not the Properties implementation.
>
> By the way, another way to achieve your goal is to use a build script
> that replaces variables for you. Check out Apache ant, which comes with
> a whole host of utilities geared toward this purpose.
>
>> I agree the ExtendedProperties class is what needs patching, I don't
>> know how receptive they will be though.
>
> I'm sure they will be receptive. Instead of a patch, why not submit an
> entirely new class called EnvironmentExpandingExtendedProperties which
> extends ExtendedProperties. The methods you would have to override would
> be addProperty, combine, convertProperties, setProperty, and possibly
> the "load" methods.
>
> Even better, if you read the source code for ExtendedProperties you may
> find that every method used "interpolate" in order to replace
> parameterized keys and values. In that case, simply override
> interpolate() and your job is done.
>
> If you configure Velocity programatically, then you are done.
>
> If you use configuration files, you'll need to ask the Velocity folks to
> either replace their use of ExtendedProperties in their config file
> loader with EnvironmentExpandingExtendedProperties (which I doubt they'd
> do) or allow you to specify the ExtendedProperties subclass to use when
> loading configuration (which makes more sense anyway, and is more likely
> to actually be done).
>
> Actually, if Velocity supports this, then you can use your own
> implementation of ExtendedProperties regardless of the response from the
> commons collections folks.
>
> -chris
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...