|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
|
|
[GUMP@vmgump]: Project velocity-texen-test (in module velocity-texen) failedTo 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 patchAttached 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 patchCharlei,
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>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 patchCharles,
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 |
|
|
RE: Expanding Environmental variables patch> 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 patchHi,
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 patchHi 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 patchOn 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@... |
| Free Forum Powered by Nabble | Forum Help |