svn commit: r518598 - /jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/DefaultExecutor.java
Author: sgoeschl
Date: Thu Mar 15 04:56:12 2007
New Revision: 518598
URL: http://svn.apache.org/viewvc?view=revrev=518598
Log:
Fixed typo that broke the usage of the watchdog (watchDog vs. watchdog)
Modified:
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/DefaultExecutor.java
Modified:
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/DefaultExecutor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/DefaultExecutor.java?view=diffrev=518598r1=518597r2=518598
==
---
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/DefaultExecutor.java
(original)
+++
jakarta/commons/sandbox/exec/trunk/src/main/java/org/apache/commons/exec/DefaultExecutor.java
Thu Mar 15 04:56:12 2007
@@ -71,7 +71,7 @@
* @see
org.apache.commons.exec.Executor#setWatchdog(org.apache.commons.exec.ExecuteWatchdog)
*/
public void setWatchdog(ExecuteWatchdog watchDog) {
-this.watchdog = watchdog;
+this.watchdog = watchDog;
}
/*
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-71) [cli] A weakness of parser
[
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated CLI-71:
-
Fix Version/s: 1.1
[cli] A weakness of parser
--
Key: CLI-71
URL: https://issues.apache.org/jira/browse/CLI-71
Project: Commons CLI
Issue Type: Bug
Components: CLI-1.x
Environment: Operating System: other
Platform: All
Reporter: Amro Al-Akkad
Fix For: 1.1
Attachments: TestCommonsCLI.java
I found a weakness of Jakarta Commons CLI and want to explain it with a simple
example:
Our program provides 2 options:
1.-a or --algo name: The -a option requires an argument.
2.-k or --key value: The -k option requires an argument too.
a)
If you pass the following command line arguments everything will be ok:
-a Caesar -k A
After evaluation:
• Caesar is the parameter of the -a option and
• A is the parameter of the -k option.
b)
However an org.apache.commons.cli.MissingArgumentException: no argument for:k
is
thrown if you pass the following input:
-a Caesar -k a
The Parser assumes that the argument a after the -k option, is the -a option
missing the hyphen. At the end of this description there is Java code for
executing this problem.
Information:
The handling of this command line
-a Caesar -k a
works in Getopt without any problem:
• Caesar is the parameter of the -a option and
• a of the -k option.
After parsing a valid option Getopt always takes the next (available) command
line argument as the option's parameter if the option requires an argument -
means if you pass to the command line
-k -a Caesar
After evaluation:
• a is the parameter of the -k option
• the Caesar argument is just ignored
If the option's parameter (value) represents an optional argument the next
argument is not required, if it represents a valid option - means if you pass
to
the command line
-k -a Caesar
After evaluation:
• Caesar is the parameter of the -a option
• k option is set without a parameter - in this case a default value
makes sense.
Last but not least here is the code snippet for the CLI Test:
import org.apache.commons.cli.CommandLine;
import org.apache.commons.cli.CommandLineParser;
import org.apache.commons.cli.Option;
import org.apache.commons.cli.Options;
import org.apache.commons.cli.ParseException;
import org.apache.commons.cli.PosixParser;
public class TestCommonsCLI {
/**
* @param args
*/
public static void main(String[] args) {
Options options = new Options();
Option algorithm = new Option(a , algo, true, the
algorithm which it to
perform executing);
algorithm.setArgName(algorithm name);
options.addOption(algorithm);
Option key = new Option(k , key, true, the key the setted
algorithm uses
to process);
algorithm.setArgName(value);
options.addOption(key);
CommandLineParser parser = new PosixParser();
try {
CommandLine line = parser.parse( options, args);
if(line.hasOption('a')){
System.out.println(algo: + line.getOptionValue( a
));
}
if(line.hasOption('k')){
System.out.println(key: + line.getOptionValue('k'));
}
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] fileupload failed.
Failed build logs: /20070317/fileupload.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
On 3/17/07, Torsten Curdt [EMAIL PROTECTED] wrote: I'd like to bring this well before an actual vote. At the moment I am still in the middle of documenting and fixing up JCI for a first 1.0 release. I hope to be able to provide a first RC1 at the end of next week ...latest the week after. There are a few things about JCI that are worth talking about. 1) Community Frankly speaking there still is no big developer community. There are contributors - but so far I am the only one committing. Still the project is integral part and heavily used by well known projects like Cocoon and Drools (plus more of course). Now both communities are eagerly waiting for a release (as this also blocks their release process). IMO community should not be too much of a concern. If there is a bug and I don't - I know they will dig into it. JCI might have well more people behind it than other components we have. Oh ...and testcase coverage is good :) So question is whether it is OK to move JCI out of the sandbox - soon. Sounds good to me. A component being alive and getting close to being release ready is IMO good enough criteria. To the outside world I don't think theres much difference when there hasn't been a release - and with now having a dormant area we also have a place to put things that graduate and then do nothing. 2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. What are the different modules for - can you give a brief description? 3) Site Another thing that comes with the multi-module is that (unfortunately) maven's multi-project reporting facilities still suck! At the moment this still means that some of reports are just empty. The only other option would be to have a sub-site for each individual model - but for JCI that would be just overkill. Please just have a look what needs to be changed for a release. The homepage is just about as minimalist as it gets - at least a couple of paragraphs giving a flavour would be nice and maybe the odd example. http://jakarta.apache.org/commons/sandbox/jci/ 3) groupId I would like to use the proper maven2 groupId naming scheme for JCI. +1 Niall Thoughts? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threading problems in connection pooling - suggested code change
On Fri, 16 Mar 2007 13:18:23 -0700, Elli Albek wrote: I use DBCP, and in our multithreaded performance test of DAOs we found that multiple threads are basically blocking on the connection pool class, either waiting to get a connection or to return a connection. In the test most threads were idle blocking on the DBCP pool, and not doing database work. This behavior becomes more severe as the number of threads grows. The problem identified was over synchronization of the pool. Calls to get and return a connection, were performing database calls, while other threads block during these calls. This includes resetting connection state (auto commit), and validation on borrow/return. ... (snip) The oversynchronization of pool is both a bug and a feature; after all the whole point of a pool is to be a bottleneck...sometimes. ;) I have not yet read the new borrowObject() code but can at least provide some feedback for returnObject(): 1) branching off addObjectToPool() with a constant decrementNumActive argument can be refactored into returnObject() again. :) 2) you have esentially reimplemented my work for GKOP from https://issues.apache.org/jira/browse/POOL-93 That issue also provides some insight as to why really effective changes require much more than just splitting up of synchronization blocks, even though that's a good start. When pooling objects with heavyweight creation/validation/destruction, something even more advanced like a concurrently pipelined factory might be the only way to increase scalability. Search through the commons archives for past discussion on this. Btw: your code has a better chance of being reviewed and adopted if you file a separate JIRA for tracking. regards Holger (just another pool user) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] JCL sans auto-discovery?
Folks, Please correct me if I am wrong, but the auto-discovery mechanism in Commons Logging is believed to be the only major gripe about JCL. What happened to the idea of releasing a version of JCL that retains the full API compatibility with JCL 1.0.x and 1.1.x but with the auto-discovery mechanism removed / disabled per default? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL sans auto-discovery?
On 17.03.2007, at 15:20, Oleg Kalnichevski wrote: Folks, Please correct me if I am wrong, but the auto-discovery mechanism in Commons Logging is believed to be the only major gripe about JCL. What happened to the idea of releasing a version of JCL that retains the full API compatibility with JCL 1.0.x and 1.1.x but with the auto-discovery mechanism removed / disabled per default? Good question I also really liked that idea. But I guess someone just have to do it. ...but you don't have to wait for that - write your own LogFactory implementation. At least that's what we did. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
Seems like a bad idea for a Commons component: * Potential confusion due to version numbers of modules moving independently etc.. * Its unlikely that releasing one module is significantly easier than releasing all. * Its likely that even though after a given quantum of time major changes are in one module (hence the temptation to release separately), there will probably be little changes elsewhere that are good to push out anyway * Data points around us -- even larger multi-project m2 builds like Shale (Struts too, I believe) release all bits together (yes, not all reasons there make sense here, but ... data points). Hm... well I am not religious about this. But re-releasing the core just because a bug in a compiler implementation does not really make much sense to me. But basically that's why I brought this up beforehand ...to check with you guys. How about: * A little guide? Tiny code snippets? Coming! There is already an example sub project featuring a (more or less) javac compatible command line interface to jci and a serverpages servlet. Still more to come. And of course that needs to be linked from the site. * package.html files? Coming! cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
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 [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 94 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 35 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-17032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-17032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
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 [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 94 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 35 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-17032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-17032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
Re: [jci] out of the sandbox
2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. Attributes had 2 jars - and a build that was irritating because of it. ie) you didn't just go 'lah! build' in the standard way. Jelly has a bajillion jars. I assume it's an m1 multiproject. BeanUtils has a couple of jars; but the optional one is more of a thick-child-project. I seem to recall it being a pain to build. So not the first. Well ...but the first one with a maven2 build - no? :) Rahul's point on keeping versions in sync is well made. 3) Site Another thing that comes with the multi-module is that (unfortunately) maven's multi-project reporting facilities still suck! At the moment this still means that some of reports are just empty. The only other option would be to have a sub-site for each individual model - but for JCI that would be just overkill. Please just have a look what needs to be changed for a release. http://jakarta.apache.org/commons/sandbox/jci/ Seems pretty bad - no information about the N different subcomponents, and the dependency page claims there are no deps (really?). I guess you've not written the site itself yet? :) Well, the problem is that the sub project are basically just a few classes. Having a complete site for every sub-project feels more confusing to me than aggregating it on the main site. BUT as you can see aggregation does not work for all reports and e.g. the dependencies are listed for the parent pom - not the core or the sub projects. And therefor are empty. I can put a site online with all the sub projects. And then you guys can let me know if you prefer that. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. What are the different modules for - can you give a brief description? JCI is basically split up into o fam - the filesystem alteration monitor o core - core interfaces and classes o compiler implementations for - eclipse - janinio - groovy - javac - rhino - jsr199 o examples - some examples showing how to use jci cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jexl] PROPOSAL: Extend Jexl to Support comparison operations between used-defined types
Please let me know if you aagree with the following proposal:
I would like to extend Jexl to support comparison operations between
used-defined types.
This will enable Jexl to do comparison operations between user-define data
types that are not a-priori comparable. For example, you will be able to
compare dates to strings representing dates, numbers to strings formatted as
percentages et cetera.
This will be accomplished by implementing custom type converters:
public interface TypeConverter {
public Object convert(JexlContext context, Object object) throws
TypeConversionException ;
}
And registering them with the context:
JexlContext context = JexlHelper.createContext();
context.registerConverter(Date.class, converter);
These are some sample usages in unit-test form:
public void testDateComparison() throws Exception {
SimpleDateTypeConverter converter = new
SimpleDateTypeConverter();
context.registerConverter(Date.class, converter);
Calendar c1 = new GregorianCalendar(2006,
Calendar.MARCH, 4);
context.getVars().put(date, c1.getTime());
assertTrue(date '2007-01-01');
assertTrue('2006-01-01' date);
converter.registerFormat(MM/dd/yy);
assertTrue(date == '3/4/06');
}
public void testUserDefinedType() throws Exception {
context.registerConverter(Temperature.class, new
TypeConverter() {
public Object convert(JexlContext
context, Object object) throws TypeConversionException {
if (object == null) {
return null;
}
if (object instanceof
Temperature) {
return
(Temperature) object;
}
String str = object.toString
();
return Temperature.valueOf
(str);
}
});
context.getVars().put(temp, Temperature.COLD);
assertTrue(temp == 'COLD');
assertTrue(temp 'HOT');
assertTrue('MEDIUM' temp);
}
public void testExtendTypeConverter() throws Exception {
context.registerConverter(Float.class, new PercentConverter());
context.registerConverter(Double.class, new PercentConverter());
context.registerConverter(BigDecimal.class, new PercentConverter());
assertTrue(0.14 == '14%');
context.getVars().put(a, new BigDecimal(0.65));
assertTrue(a '70%');
}
Re: [jci] out of the sandbox
On 3/17/07, Torsten Curdt [EMAIL PROTECTED] wrote: 2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. What are the different modules for - can you give a brief description? JCI is basically split up into o fam - the filesystem alteration monitor o core - core interfaces and classes o compiler implementations for - eclipse - janinio - groovy - javac - rhino - jsr199 o examples - some examples showing how to use jci I had a quick look at the filesystem alteration monitor module - looks like could be useful component for people outside of JCI. If you're planning on releasing modules independantly anyway, maybe it should be a commons component in its own right (or perhaps part of Commons IO?). Niall cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
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 [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 94 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-17032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-17032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-17032007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
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 [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 94 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-17032007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-17032007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-17032007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-17032007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-17032007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
svn commit: r519356 - /jakarta/commons/proper/commons-nightly/trunk/vmbuild.conf
Author: bayard Date: Sat Mar 17 08:57:51 2007 New Revision: 519356 URL: http://svn.apache.org/viewvc?view=revrev=519356 Log: Add log url in so people can find the right logs Modified: jakarta/commons/proper/commons-nightly/trunk/vmbuild.conf Modified: jakarta/commons/proper/commons-nightly/trunk/vmbuild.conf URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-nightly/trunk/vmbuild.conf?view=diffrev=519356r1=519355r2=519356 == --- jakarta/commons/proper/commons-nightly/trunk/vmbuild.conf (original) +++ jakarta/commons/proper/commons-nightly/trunk/vmbuild.conf Sat Mar 17 08:57:51 2007 @@ -18,8 +18,9 @@ javadoc_location=/home/commons/public_html/javadocs nightly_reports=/home/commons/public_html/nightly/nightly_reports +log_url='http://vmbuild.apache.org/~commons/nightly/logs/' + # deprecated -##log_url='http://people.apache.org/~psteitz/commons-nightlies' ##maven_snapshot_host='people.apache.org' # Maven snapshot host ##maven_snapshot_user='psteitz' ##maven_snapshot_directory='/www/people.apache.org/repo/m1-snapshot-repository' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-115) FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available
[ https://issues.apache.org/jira/browse/IO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481869 ] Oliver Heger commented on IO-115: - The problem seems to be fixed in revision 518770 (http://svn.apache.org/viewvc?view=revrevision=518770). Here the os.name system property is checked to avoid that the affected tests get executed under windows. Don't know if this is the most elegant solution, but it works! FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available -- Key: IO-115 URL: https://issues.apache.org/jira/browse/IO-115 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.1 Reporter: Joerg Schaible Fix For: 1.4 Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. If Posix tools are available e.g. from Cygwin, MKS Toolkit, Microsoft's Posix Tools or similar ones the test fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] findings...
Henri Yandell wrote: On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: snip/ 3) Let's remove the commons-configuration-integration and RESEARCH_CLI_2_ROXSPRING branch. There was no activity within the past 20 months unless I am mistaken. So I think we can safely say these tries were dead-ends. Let's check with Oliver on the commons-configuration-integration. I know that was a subject that's come up a few times (last time I needed a cli type thing, I went with configuration and much preferred it; it just needs a cli like option). I had a short glance at this branch (I was not aware that it existed before). There are the two classes ConfigurationCommandLine and CommandLineConfiguration that implement the integration in both directions. They are pretty simple (probably because the APIs of cli and configuration are similar), but seem to be functional. I am not sure how to proceed here. The code of the CommandLineConfiguration class could be added to CONFIGURATION-211 (enhancement request for a command line configuration). But should configuration declare another dependency to cli? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation version check utility code
Oops... try it now. -Matt --- Henri Yandell [EMAIL PROTECTED] wrote: That 403s. Can you fix the perms? Hen On 3/15/07, Matt Benson [EMAIL PROTECTED] wrote: Sorry for the lack of a bracketed subtopic. But that's my point. ;) I have some code--mostly extracted from Ant--to check a library's implementation version, e.g. if you know you need at least version x.x.x of a class because a bug was fixed or some such, but there may be no clear indicator in the library's API to tell you its version. The code basically finds the top-level parent whence the class was loaded (jar file or folder), locates the manifest and returns the value of its Implementation-Version attribute. There is an example archive at http://people.apache.org/~mbenson/sharedfiles/ImplementationVersion.tar.gz . My questions are: what is the overall opinion of the community on whether this code is gp enough to be of wide use, and whether it is a smart fit anywhere in the commons. TIA, Matt Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SANDBOX-188) [jci] javac tests are failing
[jci] javac tests are failing - Key: SANDBOX-188 URL: https://issues.apache.org/jira/browse/SANDBOX-188 Project: Commons Sandbox Issue Type: Bug Components: JCI Environment: Windows XP java version 1.6.0 Java(TM) SE Runtime Environment (build 1.6.0-b105) Maven 2.0.5 Reporter: Grzegorz Kossakowski Tests for javac are failing on Windows platform but on openSUSE 10.2 with Java 6 they run just fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-188) [jci] javac tests are failing
[ https://issues.apache.org/jira/browse/SANDBOX-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated SANDBOX-188: - Attachment: target.zip Attached target directory with reports of failing tests. [jci] javac tests are failing - Key: SANDBOX-188 URL: https://issues.apache.org/jira/browse/SANDBOX-188 Project: Commons Sandbox Issue Type: Bug Components: JCI Environment: Windows XP java version 1.6.0 Java(TM) SE Runtime Environment (build 1.6.0-b105) Maven 2.0.5 Reporter: Grzegorz Kossakowski Attachments: target.zip Tests for javac are failing on Windows platform but on openSUSE 10.2 with Java 6 they run just fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] findings...
Oliver Heger wrote: Henri Yandell wrote: On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: snip/ 3) Let's remove the commons-configuration-integration and RESEARCH_CLI_2_ROXSPRING branch. There was no activity within the past 20 months unless I am mistaken. So I think we can safely say these tries were dead-ends. Let's check with Oliver on the commons-configuration-integration. I know that was a subject that's come up a few times (last time I needed a cli type thing, I went with configuration and much preferred it; it just needs a cli like option). I had a short glance at this branch (I was not aware that it existed before). There are the two classes ConfigurationCommandLine and CommandLineConfiguration that implement the integration in both directions. They are pretty simple (probably because the APIs of cli and configuration are similar), but seem to be functional. I am not sure how to proceed here. The code of the CommandLineConfiguration class could be added to CONFIGURATION-211 (enhancement request for a command line configuration). But should configuration declare another dependency to cli? It's optional ... why not? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-115) FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available
[ https://issues.apache.org/jira/browse/IO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481882 ] Jochen Wiedmann commented on IO-115: Checking this in was unintentional. My plan was to discuss the issue before actually committing it. However, this issue is of course a good platform to discuss the necessary steps. I am ready to revert the change, if this should be desired. Otherwise, someone else should resove the issue. FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available -- Key: IO-115 URL: https://issues.apache.org/jira/browse/IO-115 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.1 Reporter: Joerg Schaible Fix For: 1.4 Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. If Posix tools are available e.g. from Cygwin, MKS Toolkit, Microsoft's Posix Tools or similar ones the test fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] fileupload failed.
On 3/17/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: /20070317/fileupload.log Where can I inspect this log file? Thanks, Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] fileupload failed.
On 3/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 3/17/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: /20070317/fileupload.log Where can I inspect this log file? http://vmbuild.apache.org/~commons/nightly/logs/20070317/fileupload.log I fixed the mail so it should include the full url tomorrow. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] fileupload failed.
On 3/17/07, Henri Yandell [EMAIL PROTECTED] wrote: On 3/17/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 3/17/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: /20070317/fileupload.log Where can I inspect this log file? http://vmbuild.apache.org/~commons/nightly/logs/20070317/fileupload.log I fixed the mail so it should include the full url tomorrow. Probably because the nightly builds aren't deployed to the snapshots yet. Phil had to expire his key for doing that, and as an empty passphrase ssh is a bit of an ssh issue, I've avoided turning that back on. I had a wget script in there to pull down tars of the builds, but it seemed to have trouble and seems a bit clumsy. I think it needs a smarter script that uses the date to grab the files (using the same list as commons-nightly). Been on my todo list for a bit, but hasn't got near the top. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] fileupload failed.
On 3/17/07, Henri Yandell [EMAIL PROTECTED] wrote: Probably because the nightly builds aren't deployed to the snapshots yet. Phil had to expire his key for doing that, and as an empty passphrase ssh is a bit of an ssh issue, I've avoided turning that back on. That seems to be the problem, indeed. I have deployed a snapshot of commons-io, hope that will work tomorrow. Jochen -- Emacs 22 will support MacOS and CygWin. It is not yet decided, whether these will be used to run Emacs or the other way round. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sandbox] releasing parent sandbox pom
can the parent commons-sandbox be released so all sandbox components can be built by themselves? it just needs to have the parent version updated to 2 or even better if commons parent is also released to take advantage of latest changes before releasing sandbox parent. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] releasing parent sandbox pom
On 3/17/07, Carlos Sanchez [EMAIL PROTECTED] wrote: can the parent commons-sandbox be released so all sandbox components can be built by themselves? it just needs to have the parent version updated to 2 or even better if commons parent is also released to take advantage of latest changes before releasing sandbox parent. I was hoping the maven source plugin was going to get a release - so that we could remove the antrun workaround for the source plugin bug - then release a new commons parent. Unfortunately that seems to be stalled on the maven list. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] bug in parser(s)
On 16/03/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 16.03.2007, at 05:28, Henri Yandell wrote: On 3/15/07, Torsten Curdt [EMAIL PROTECTED] wrote: IMO we should do a cli 1.0.1 bug release and get then get 2.0 out of the door ASAP. Someone needs to have the energy (and comprehension) to push them out. I get the CLI 1.x code and can do a 1.1 or 1.0.1 release; no one really seemed to be demanding it. I am :) ...this has been bugging a couple of times already. And I even dug into the code. So I would be happy to help with that too. But my main focus for now is to get jci out of the door ...and I don't want to wait for a cli release for that. When I started looking into CLI 2.x I found myself in the minority position of thinking it was worse than CLI 1.x so I quietly backed away from it. Really? Care to elaborate? What's the story with the branches again? I lost track. cli/ itself is cli2. cli-1.x/ is the active cli1 branch. cli-avalon/ or something like that.. that's what I called it on trunk/ is the avalon code that someone uses and loves (I forget who). We use it in JMeter, but we have our own copy in SVN. I copied the source to JMeter from Avalon, as there were some bugs we needed fixing for JMeter. Having fixed the bugs, it seemed to work fine for JMeter, so I thought it might be useful for others, and so it was provided as a patch for Commons CLI. Since JMeter has its own copy, it does not matter to us whether the CLI copy is ever released, but it seems a shame as it is working well for us. I had a look recently at SVN with a view to making a release of just the Avalon CLI but I got bogged down. There seemed to be a lot of stuff that was not related to Avalon CLI, and I don't know Maven. Note that the Avalon API is rather different from the CLI1/CLI2 APIs. Will have a look into that ...at some stage. All three need stake in the ground releases so N years of bugfixing can be stabilized. Sure - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] PROPOSAL: Extend Jexl to Support comparison operations between used-defined types
Please open an enhancement request in JIRA [1]. Proposals on the
mailing list tend to get lost unless there is immediate interest /
cycles available. Thanks.
-Rahul
[1] http://issues.apache.org/jira/browse/JEXL
On 3/17/07, Dimitri Papaioannou [EMAIL PROTECTED] wrote:
Please let me know if you aagree with the following proposal:
I would like to extend Jexl to support comparison operations between
used-defined types.
This will enable Jexl to do comparison operations between user-define data
types that are not a-priori comparable. For example, you will be able to
compare dates to strings representing dates, numbers to strings formatted as
percentages et cetera.
This will be accomplished by implementing custom type converters:
public interface TypeConverter {
public Object convert(JexlContext context, Object object) throws
TypeConversionException ;
}
And registering them with the context:
JexlContext context = JexlHelper.createContext();
context.registerConverter(Date.class, converter);
These are some sample usages in unit-test form:
public void testDateComparison() throws Exception {
SimpleDateTypeConverter converter = new
SimpleDateTypeConverter();
context.registerConverter(Date.class, converter);
Calendar c1 = new GregorianCalendar(2006,
Calendar.MARCH, 4);
context.getVars().put(date, c1.getTime());
assertTrue(date '2007-01-01');
assertTrue('2006-01-01' date);
converter.registerFormat(MM/dd/yy);
assertTrue(date == '3/4/06');
}
public void testUserDefinedType() throws Exception {
context.registerConverter(Temperature.class, new
TypeConverter() {
public Object convert(JexlContext
context, Object object) throws TypeConversionException {
if (object == null) {
return null;
}
if (object instanceof
Temperature) {
return
(Temperature) object;
}
String str = object.toString
();
return Temperature.valueOf
(str);
}
});
context.getVars().put(temp, Temperature.COLD);
assertTrue(temp == 'COLD');
assertTrue(temp 'HOT');
assertTrue('MEDIUM' temp);
}
public void testExtendTypeConverter() throws Exception {
context.registerConverter(Float.class, new PercentConverter());
context.registerConverter(Double.class, new PercentConverter());
context.registerConverter(BigDecimal.class, new PercentConverter());
assertTrue(0.14 == '14%');
context.getVars().put(a, new BigDecimal(0.65));
assertTrue(a '70%');
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (NET-154) Typo in NNTPClient javadoc comment
Typo in NNTPClient javadoc comment -- Key: NET-154 URL: https://issues.apache.org/jira/browse/NET-154 Project: Commons Net Issue Type: Improvement Reporter: Brian Lewis Priority: Trivial In NNTPClient's NNTPClient() javadoc comment, NNTPConectionClosedException is missing an n. It should be NNTPConnectionClosedException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] JCL sans auto-discovery?
On Sat, 2007-03-17 at 16:23 +0100, Torsten Curdt wrote: On 17.03.2007, at 15:20, Oleg Kalnichevski wrote: Folks, Please correct me if I am wrong, but the auto-discovery mechanism in Commons Logging is believed to be the only major gripe about JCL. What happened to the idea of releasing a version of JCL that retains the full API compatibility with JCL 1.0.x and 1.1.x but with the auto-discovery mechanism removed / disabled per default? Good question I also really liked that idea. But I guess someone just have to do it. ...but you don't have to wait for that - write your own LogFactory implementation. At least that's what we did. To disable auto-discovery, just use an environment variable to specify which system you want, eg org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger This is described in the user guide: http://jakarta.apache.org/commons/logging/guide.html However writing your own LogFactory is also a reasonable solution; it's only a handful of methods, all with trivial implementations. What was being considered for JCL was distributing one JCL version for each supported logging lib, in a way similar to SLF4J. However that requires a fair amount of work and it doesn't appear that anyone is particularly interested in tackling this. Or you could use SLF4J which (I believe) does provide one-jar-per-supported-lib and provides commons-logging compatibility. Possibly it would be a good idea to provide a simple JCL-to-java.util.logging mapping, as most apps should probably be using java.util.logging now. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
Hi! I had a quick look at the filesystem alteration monitor module - looks like could be useful component for people outside of JCI. Yea, in the long term we discussed to replace the VFS's one with this implementation, though, if it is its own component with an abstract FS implementation it would be fine too. commons-io might be a good place then. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
