DO NOT REPLY [Bug 26966] New: - Connectionpool's connections always returns same
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26966. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26966 Connectionpool's connections always returns same Summary: Connectionpool's connections always returns same Product: Commons Version: 1.1 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Dbcp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When we tried to implement a PreparedStatement cache we discovered that the hashCode method on a connection always returns the same id. It did so even if we got a new connection from the pool. The prepared statements are cached for each connection and therefore we need a unique id for the connection. Usually the method hashCode generates one for us. The problem exists in both version 1.0 and 1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] EmpiricalDistribution improvments
Phil Steitz wrote: 1. Either remove or implement the not implemented yet distribution persistence methods. I am ambivalent on these, maybe just supporting serialization is enough. The question is if it happens very often that we obtain data in the form of the EDF. This might be the case if data are pre-processed using different application (or experimental equipment)... I'm thinking about the best form in which EmpiricalDistribution can be saved, maybe saving pairs observed_value_i = probability_i would do the job? 3. Develop some sort of rationale for the test tolerances. This is an interesting mathstat problem. I would ideally like to use statistical tests (like elsewhere in the random package), but it is not obvious what the right test or test parameters should be. As long as we test means or variances we can use t test or some variance equality test (Levene test). However we need to choose significane level anyway, so still there is a arbitrary number (like tolerance we have now), on the other hand this number have clear interpretation. Piotr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26922] - [lang] public static boolean DateUtils.equals(Date dt1, Date dt2) ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26922.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26922
[lang] public static boolean DateUtils.equals(Date dt1, Date dt2) ?
--- Additional Comments From [EMAIL PROTECTED] 2004-02-16 09:31 ---
Yes, I agree with you. And I propose the code to do this :
/**
* pCompares two Dates, returning codetrue/code if they are equal./p
*
* pcodenull/codes are handled without exceptions. Two
codenull/code
* references are considered to be equal./p
*
* pre
* long now = System.currentTimeMillis();
* java.util.Date date = new java.util.Date(now);
* java.sql.Timestamp timestamp = new java.sql.Timestamp(now);
* DateUtils.equals(null, null) = true
* DateUtils.equals(null, date) = false
* DateUtils.equals(date, null) = false
* DateUtils.equals(date, date) = true
* DateUtils.equals(date, timestamp) = true
* /pre
*
* @see java.util.Date#equals(Object)
* @param dt1 the first Date, may be null
* @param dt2 the second Date, may be null
* @return codetrue/code if the Dates are equal or both
codenull/code
*/
public static boolean equals(Date dt1, Date dt2) {
return (dt1 == null ? dt2 == null : dt1.getTime() == dt2.getTime
());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] Access to the underlying connection
A few questions: I am using the SharedPoolDataSource. The connections returned from the DataSource are facades to the actual connection. I need access to the underlying connection so that I can call a proprietary method on the connection to unlock it. Is there any way to do this or do I need to change the DBCP code? If I need to change the code has anyone got a recommended way of implementing this so that I can submit a patch back to you for inclusion. Also could you tell me when the patch attached to this bug will be implemented: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24136 Is there a release plan for 1.2? Can we expect a release before about July'ish? Cheers. Dave. [EMAIL PROTECTED] This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26694] - BaseConfiguration: containsKey ignores default properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26694. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26694 BaseConfiguration: containsKey ignores default properties --- Additional Comments From [EMAIL PROTECTED] 2004-02-16 13:47 --- I'm answering here because I'm not subscribed to the list. I actually switched from PropertiesConfiguration with default values to CompositeConfiguration after discovering this bug. My initial reason for not using CompositeConfiguration was a documentation bug: CompositeConfiguration.addProperty says CompositeConfigurations can not be added to. Luckily, this isn't true (would have been a blocker for me if it were), but I had to check the source code to find out. Otherwise I'm quite happy with using CompositeConfiguration instead of chained defaults, but there is still one problem: CompositeConfiguration live in memory only, I cannot store them. Currently I could convert a CompositeConfiguration to a PropertiesConfiguration via the PropertiesConfiguration(Configuration defaults) constructor for storing it, but if you remove the defaults that would no longer be possible. Is there another way for converting a CompositeConfiguration to a serializable format, or could you add one? If yes, I think it a good idea to replace chained defaults by CompositeConfiguration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Refactor AbstractConfiguration(Configuration defaults)
Hmm I'm not should we should remove this, even if a CompositeConfiguration looks cleaner, it also hides the specific methods of the underlying configuration. For example if I work with a PropertiesConfiguration, i can no longer call save() if it's embeeded in a CompositeConfiguration. Emmanuel Bourg Eric Pugh wrote: Hi all, Based on the Bugzilla 26694 (BaseConfiguration: containsKey ignores default properties) bug, I think that the constructor for AbstractConfiguration(Configuration defaults) should be removed.. Basically it is providing the equivalent of a CompositeConfiguration built using the ConfigurationFactory's union versus override rules.. The semantics are kinda weird to have these defaults.. If you want defualts that are used when something else is missing, then just do: CompositeConfiguration cc = new CompositeConfiguration(); cc.addConfiguration(myDefaultConfig); return cc; And that does the same thing, but cleaner! Any opinons? Otherwise I am going to delete it (after of course going and writing the testcase to prove 26694 (argh!)). Eric - 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]
DO NOT REPLY [Bug 26694] - BaseConfiguration: containsKey ignores default properties
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26694. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26694 BaseConfiguration: containsKey ignores default properties --- Additional Comments From [EMAIL PROTECTED] 2004-02-16 14:10 --- Maybe we could mark one of the configurations as the main configuration where the added properties go instead of the in memory configuration. Then we might add a save() method on the CompositeConfiguration that would call the save() method on the contained configurations if available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Re: cvs commit math/src/test/org/apache/commons/math/analysis InterpolatorTest.java
Phil,
I noticed that in testInterpolateLinearDegenerateThreeSegment() you didn't
insert a TODO comment when you deleted most of the body of the method (quoted
below)
Al
--- [EMAIL PROTECTED] wrote:
psteitz 2004/02/15 22:30:21
Modified:math/src/test/org/apache/commons/math/analysis
InterpolatorTest.java RealSolverTest.java
math/src/test/org/apache/commons/math/stat
DescriptiveStatisticsTest.java
Log:
Commented out sysouts.
Revision ChangesPath
1.11 +19 -52
jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java
Index: InterpolatorTest.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- InterpolatorTest.java 29 Jan 2004 16:48:49 - 1.10
+++ InterpolatorTest.java 16 Feb 2004 06:30:21 - 1.11
@@ -42,18 +42,19 @@
...
public void testInterpolateLinearDegenerateThreeSegment()
throws MathException {
-System.out.println( deg 3 seg);
+// System.out.println( deg 3 seg);
double xval[] = { 0.0, 0.5, 1.0, 1.5 };
double yval[] = { 0.0, 0.5, 1.0, 1.5 };
UnivariateRealInterpolator i = new SplineInterpolator();
UnivariateRealFunction f = i.interpolate(xval, yval);
-double x;
-x = 0.0;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 0.5 - 1E-6;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 0.5;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 1 - 1E-6;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 1;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 1.5 - 1E-6;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
}
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Re: cvs commit math/src/test/org/apache/commons/math/analysis InterpolatorTest.java
Al Chou wrote:
Phil,
I noticed that in testInterpolateLinearDegenerateThreeSegment() you didn't
insert a TODO comment when you deleted most of the body of the method (quoted
below)
Al
Oops! I should have commented that block out, as I did the others and
insert a todo. I will fix this evening. Sorry.
Phil
--- [EMAIL PROTECTED] wrote:
psteitz 2004/02/15 22:30:21
Modified:math/src/test/org/apache/commons/math/analysis
InterpolatorTest.java RealSolverTest.java
math/src/test/org/apache/commons/math/stat
DescriptiveStatisticsTest.java
Log:
Commented out sysouts.
Revision ChangesPath
1.11 +19 -52
jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java
Index: InterpolatorTest.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- InterpolatorTest.java 29 Jan 2004 16:48:49 - 1.10
+++ InterpolatorTest.java 16 Feb 2004 06:30:21 - 1.11
@@ -42,18 +42,19 @@
...
public void testInterpolateLinearDegenerateThreeSegment()
throws MathException {
-System.out.println( deg 3 seg);
+// System.out.println( deg 3 seg);
double xval[] = { 0.0, 0.5, 1.0, 1.5 };
double yval[] = { 0.0, 0.5, 1.0, 1.5 };
UnivariateRealInterpolator i = new SplineInterpolator();
UnivariateRealFunction f = i.interpolate(xval, yval);
-double x;
-x = 0.0;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 0.5 - 1E-6;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 0.5;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 1 - 1E-6;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 1;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
-
-x = 1.5 - 1E-6;
-System.out.println(
-x=
-+ x
-+ y=
-+ f.value(x));
}
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
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: [math] EmpiricalDistribution improvments
Piotr Kochañski wrote: Phil Steitz wrote: 1. Either remove or implement the not implemented yet distribution persistence methods. I am ambivalent on these, maybe just supporting serialization is enough. The question is if it happens very often that we obtain data in the form of the EDF. This might be the case if data are pre-processed using different application (or experimental equipment)... The use case that I had in mind was repeated simulation runs using the same source dataset -- for this it would be handy to be able to digest a large dataset once and then reload just the digest (EDF) for subsequent runs. I'm thinking about the best form in which EmpiricalDistribution can be saved, maybe saving pairs observed_value_i = probability_i would do the job? There is more data than that -- remember the bin stats, etc. If we want to do it in a platform-independent way, that will be interesting; otherwise we could just serialize the whole mess using Java serialization (hence the comment that maybe just implementing Serializable is enough). 3. Develop some sort of rationale for the test tolerances. This is an interesting mathstat problem. I would ideally like to use statistical tests (like elsewhere in the random package), but it is not obvious what the right test or test parameters should be. As long as we test means or variances we can use t test or some variance equality test (Levene test). However we need to choose significane level anyway, so still there is a arbitrary number (like tolerance we have now), on the other hand this number have clear interpretation. Yes, that is the problem. I don't see how exactly we can correctly set df for the t-test, for example, since the sampling distribution of the mean of EDF-generated values is sort of an ugly beast that depends on the the number and dispersion of the origial values as well as the number of bins and the number of generated values. Phil Piotr - 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: [configuration] Refactor AbstractConfiguration(Configuration defaults)
True.. But, you could grab the propertiesConfiguration out of the composite and save it.. I think the composite should be looked at as a read only thing because saving has too many odd ramifications.. And, at least, the one user who mentioned the AbstractConfiguration(Configuration conf) is actually using a CompositeConfig anyway, and needs that exact same problem solved.. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 12:08 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Refactor AbstractConfiguration(Configuration defaults) Hmm I'm not should we should remove this, even if a CompositeConfiguration looks cleaner, it also hides the specific methods of the underlying configuration. For example if I work with a PropertiesConfiguration, i can no longer call save() if it's embeeded in a CompositeConfiguration. Emmanuel Bourg Eric Pugh wrote: Hi all, Based on the Bugzilla 26694 (BaseConfiguration: containsKey ignores default properties) bug, I think that the constructor for AbstractConfiguration(Configuration defaults) should be removed.. Basically it is providing the equivalent of a CompositeConfiguration built using the ConfigurationFactory's union versus override rules.. The semantics are kinda weird to have these defaults.. If you want defualts that are used when something else is missing, then just do: CompositeConfiguration cc = new CompositeConfiguration(); cc.addConfiguration(myDefaultConfig); return cc; And that does the same thing, but cleaner! Any opinons? Otherwise I am going to delete it (after of course going and writing the testcase to prove 26694 (argh!)). Eric - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Refactor AbstractConfiguration(Configuration defaults)
Eric Pugh wrote: True.. But, you could grab the propertiesConfiguration out of the composite and save it.. I think the composite should be looked at as a read only thing because saving has too many odd ramifications.. What kind of ramifications? I was planning to experiment the addition of a save() method on the CompositeConfiguration class. And, at least, the one user who mentioned the AbstractConfiguration(Configuration conf) is actually using a CompositeConfig anyway, and needs that exact same problem solved.. Let's deprecate it and wait for user feedback after the 1.0 release maybe? This constructor is inherited from the java.util.Properties constructor using a default properties, people migrating their code might expect this similarity. It's already there, well tested, not causing much troubles and easy to use, for these reasons I would keep it. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Refactor AbstractConfiguration(Configuration defaults)
Are we sure we want to do the deprecated? Seems odd to have 1.0 have a deprecated method.. It may make more sense to just add another howto: How to save your properties set in CompositeConfiguration? Basically should be able to just grab out the inmemory and save it by hand... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 4:33 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Refactor AbstractConfiguration(Configuration defaults) Eric Pugh wrote: True.. But, you could grab the propertiesConfiguration out of the composite and save it.. I think the composite should be looked at as a read only thing because saving has too many odd ramifications.. What kind of ramifications? I was planning to experiment the addition of a save() method on the CompositeConfiguration class. And, at least, the one user who mentioned the AbstractConfiguration(Configuration conf) is actually using a CompositeConfig anyway, and needs that exact same problem solved.. Let's deprecate it and wait for user feedback after the 1.0 release maybe? This constructor is inherited from the java.util.Properties constructor using a default properties, people migrating their code might expect this similarity. It's already there, well tested, not causing much troubles and easy to use, for these reasons I would keep it. Emmanuel - 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: [configuration] Refactor AbstractConfiguration(Configuration defaults)
Eric Pugh wrote:
Are we sure we want to do the deprecated? Seems odd to have 1.0 have a
deprecated method.. It may make more sense to just add another howto: How
to save your properties set in CompositeConfiguration? Basically should be
able to just grab out the inmemory and save it by hand...
That seems quite complicated, using a CompositeConfiguration we would
have (I'm not familiar with this class so let me know if my use case is
wrong) :
// loading
Configuration default = new PropertiesConfiguration(default.properties);
Configuration config = new PropertiesConfiguration(myapp.properties);
CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration(default);
cc.addConfiguration(config);
// using/modifying
cc.addProperty(foo, bar);
// saving (assuming the previous reference is not available here)
PropertiesConfiguration pc = (PropertiesConfiguration)
cc.getConfiguration(1);
Configuration inmemory = cc.getConfiguration(0);
Iterator it = inmemory.getKeys();
while (it.hasNext()) {
String key = (String) it.next();
pc.addProperty(key, inmemory.getProperty(key));
}
pc.save();
using an unmodified PropertiesConfiguration this would be reduced to :
// loading
Configuration default = new PropertiesConfiguration(default.properties);
PropertiesConfiguration config = new
PropertiesConfiguration(myapp.properties, default);
// using
config.addProperty(foo, bar);
// saving
config.save();
Emmanuel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] interested in a JaxMe tag library...?
On 14-Feb-04, at 20:44 Uhr, robert burrell donkin wrote: jaxme is a JAXB implementation (with a pure ASF license) being incubated over at web services. i'm writing a maven plugin that exposes some of the functionality in particular generating source from schema. it seems like a good idea to implement the functionality i want by creating a jelly tag library exposing the features i need. are the jelly team interested in hosting this tag library here? Yes, I think it would be very appropriate. Jelly taglibs seem to me one good place to contain all sorts of xml-events-producing serializers/deserializers. And JAXB is such (namely, serializes to object... kind of the opposite of serialization but who cares). I presume there are on the list people that use JAXB implementations and Jelly at the same time... they would probably be interested. paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Refactor AbstractConfiguration(Configuration defaults)
You are right about that.. It is simpler.. The problem is that it ONLY
works when pass in a default that works like that.. I think maybe a better
approach would be to change CompositeConfiguratoin. Right now the issue is
that this returns a memory only config object:
Configuration inmemory = cc.getConfiguration(0);
And saving it is a pain! I think we should a method:
CompositeConfiguration(Configuration changesConfig)
setChangesConfiguration()
getChangesConfgiuration().
By default you get back a inmemory config like we have today. But, in your
usecase we woudl do this
// loading
Configuration changes = new PropertiesConfiguration(default.properties)
Configuration cc = new CompositeConfiguration(changes);
PropertiesConfiguration config = new
PropertiesConfiguration(myapp.properties, default);
cc.addConfiguration(config)
// using
cc.addProperty(foo, bar);
// saving
changes.save();
//
PropertiesConfiguration needToSave =
(PropertiesConfiguration)cc.getChangesConfiguration()
although I don't like the name get/setChangesConfiguration, maybe
get/setDeltaConfiguration?
ERic
-Original Message-
From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
Sent: Monday, February 16, 2004 5:23 PM
To: Jakarta Commons Developers List
Subject: Re: [configuration] Refactor
AbstractConfiguration(Configuration defaults)
Eric Pugh wrote:
Are we sure we want to do the deprecated? Seems odd to
have 1.0 have a
deprecated method.. It may make more sense to just add
another howto: How
to save your properties set in CompositeConfiguration?
Basically should be
able to just grab out the inmemory and save it by hand...
That seems quite complicated, using a CompositeConfiguration we would
have (I'm not familiar with this class so let me know if my
use case is
wrong) :
// loading
Configuration default = new
PropertiesConfiguration(default.properties);
Configuration config = new
PropertiesConfiguration(myapp.properties);
CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration(default);
cc.addConfiguration(config);
// using/modifying
cc.addProperty(foo, bar);
// saving (assuming the previous reference is not available here)
PropertiesConfiguration pc = (PropertiesConfiguration)
cc.getConfiguration(1);
Configuration inmemory = cc.getConfiguration(0);
Iterator it = inmemory.getKeys();
while (it.hasNext()) {
String key = (String) it.next();
pc.addProperty(key, inmemory.getProperty(key));
}
pc.save();
using an unmodified PropertiesConfiguration this would be reduced to :
// loading
Configuration default = new
PropertiesConfiguration(default.properties);
PropertiesConfiguration config = new
PropertiesConfiguration(myapp.properties, default);
// using
config.addProperty(foo, bar);
// saving
config.save();
Emmanuel
-
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]
cvs commit: jakarta-commons/commons-build/xdocs/maven project-base.xml
mdiggory2004/02/16 10:43:59 Removed: commons-build/xdocs/maven project-base.xml Log: We only need one project.xml file to extend for commons subprojects. Use jakarta-commons/commons-build/project.xml in this case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] interested in a JaxMe tag library...?
On 16 Feb 2004, at 16:33, Paul Libbrecht wrote: On 14-Feb-04, at 20:44 Uhr, robert burrell donkin wrote: jaxme is a JAXB implementation (with a pure ASF license) being incubated over at web services. i'm writing a maven plugin that exposes some of the functionality in particular generating source from schema. it seems like a good idea to implement the functionality i want by creating a jelly tag library exposing the features i need. are the jelly team interested in hosting this tag library here? Yes, I think it would be very appropriate. Jelly taglibs seem to me one good place to contain all sorts of xml-events-producing serializers/deserializers. And JAXB is such (namely, serializes to object... kind of the opposite of serialization but who cares). I presume there are on the list people that use JAXB implementations and Jelly at the same time... they would probably be interested. cool. i'm helping to develop the start-from-java side of JaxMe (which will be based on betwixt). at this time, i'm just trying to put something basic together to help me learn jaxme and to help create a maven plugin. i'll post a patch (or - if that's cool with you) just go ahead and commit once i've got something a bit more substantial. BTW i think that i understand a little more about the issues with registering convertors in beanutils and i'm pretty sure that a pluggable registry coupled with use of a bean instance in the context would provide a solid solution. i don't have time to develop this now but i'll try to get back to this a little later. unless anyone else fancies taking this one on, of course :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp][launcher][pool] Extending project.xml
With the migration of the common build resources into commons-build. We need to adjust the extend location of you project.xml file from extend../../jakarta-commons/xdocs/maven/project-base.xml/extend to extend../commons-build/project.xml/extend this is the exact same file, only in the new location. It appears your projects were extending an alternate project.xml file that was exactly the same from the xdoc directory. This file has been removed as it was a duplicate of commons-build/project.xml. I will be commiting this shortly. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/pool project.xml
mdiggory2004/02/16 10:53:08 Modified:dbcp project.xml launcher project.xml pool project.xml Log: We should have only one project.xml file to extend for commons subprojects. Use jakarta-commons/commons-build/project.xml in this case. Revision ChangesPath 1.22 +1 -1 jakarta-commons/dbcp/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/dbcp/project.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- project.xml 7 Feb 2004 15:10:08 - 1.21 +++ project.xml 16 Feb 2004 18:53:08 - 1.22 @@ -1,6 +1,6 @@ ?xml version=1.0? project - extend../xdocs/maven/project-base.xml/extend + extend../commons-build/project.xml/extend nameCommons DBCP/name idcommons-dbcp/id logo/images/dbcp-logo-blue.jpg/logo 1.3 +1 -1 jakarta-commons/launcher/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/launcher/project.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- project.xml 30 Nov 2003 15:17:02 - 1.2 +++ project.xml 16 Feb 2004 18:53:08 - 1.3 @@ -1,6 +1,6 @@ ?xml version=1.0 encoding=UTF-8? project - extend../../jakarta-commons/xdocs/maven/project-base.xml/extend + extend../commons-build/project.xml/extend nameCommons Launcher/name idcommons-launcher/id logo/images/launcher-logo-blue.jpg/logo 1.20 +1 -1 jakarta-commons/pool/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/pool/project.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- project.xml 31 Dec 2003 13:51:32 - 1.19 +++ project.xml 16 Feb 2004 18:53:08 - 1.20 @@ -1,6 +1,6 @@ ?xml version=1.0? project - extend../xdocs/maven/project-base.xml/extend + extend../commons-build/project.xml/extend nameCommons Pool/name idcommons-pool/id logo/images/pool-logo-blue.jpg/logo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26922] - [lang] public static boolean DateUtils.equals(Date dt1, Date dt2) ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26922.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26922
[lang] public static boolean DateUtils.equals(Date dt1, Date dt2) ?
--- Additional Comments From [EMAIL PROTECTED] 2004-02-16 18:57 ---
The assumption that time values are equal for Date and Timestamp is incorrect as
the basic test below shows. Writting unit tests first avoids this kind of
misunderstandings ;-) Also, supplying unit tests with your code greatly
increases the patching process and confidence in submissions compared to blind
submissions. :-)
Index: ObjectUtilsTest.java
===
retrieving revision 1.9
diff -u -r1.9 ObjectUtilsTest.java
--- ObjectUtilsTest.java18 Aug 2003 02:22:25 - 1.9
+++ ObjectUtilsTest.java16 Feb 2004 18:50:39 -
@@ -1,7 +1,6 @@
-/*
- * The Apache Software License, Version 1.1
- *
- * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
+/*
+ *
+ * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -122,6 +121,15 @@
assertTrue(ObjectUtils.equals(\foo\, \foo\) returned false,
ObjectUtils.equals(FOO, FOO));
}
+public void testDateEquals() {
+long now = 1076957313284L; // Feb 16, 2004 10:49 PST
+java.util.Date date = new java.util.Date(now);
+java.util.Date timestamp = new java.sql.Timestamp(now);
+assertEquals(date.getTime(), timestamp.getTime());
+assertEquals(timestamp, date);
+assertTrue(ObjectUtils.equals(date, timestamp));
+}
+
public void testIdentityToString() {
assertEquals(null, ObjectUtils.identityToString(null));
assertEquals(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build commonDependencies.ent project.properties project.xml maven.xml LICENSE.txt
mdiggory2004/02/16 11:00:43
Modified:commons-build project.properties project.xml maven.xml
LICENSE.txt
Added: commons-build commonDependencies.ent
Log:
fixes to maven.xml and other supporting files to enable commons project build
Revision ChangesPath
1.2 +2 -2 jakarta-commons/commons-build/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/commons-build/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties10 Feb 2004 18:30:03 - 1.1
+++ project.properties16 Feb 2004 19:00:43 - 1.2
@@ -15,4 +15,4 @@
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
-maven.xdoc.poweredby.image=maven-feather.png
\ No newline at end of file
+maven.xdoc.poweredby.image=maven-feather.png
1.14 +12 -4 jakarta-commons/commons-build/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/commons-build/project.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- project.xml 1 Oct 2003 20:30:55 - 1.13
+++ project.xml 16 Feb 2004 19:00:43 - 1.14
@@ -1,10 +1,11 @@
?xml version=1.0 encoding=UTF-8?
-
project
pomVersion3/pomVersion
idcommons-master/id
nameCommons Master Maven POM/name
currentVersion1.0/currentVersion
+ packageorg.apache.commons.${pom.artifactId.substring(8)}.*/package
+
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/index.html/url
organization
nameApache Software Foundation/name
@@ -12,11 +13,18 @@
logohttp://jakarta.apache.org/images/jakarta-logo-blue.gif/logo
/organization
logo/images/logo.jpg/logo
- packageorg.apache.commons.*/package
+
+ licenses
+ license
+ nameThe Apache Software License, Version 2.0/name
+ url/LICENSE.txt/url
+ distributionrepo/distribution
+ /license
+ /licenses
gumpRepositoryIdjakarta/gumpRepositoryId
-
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/index.html/url
- issueTrackingUrlhttp://nagoya.apache.org//issueTrackingUrl
+
+ issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
1.7 +18 -26jakarta-commons/commons-build/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/jakarta-commons/commons-build/maven.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- maven.xml 10 Feb 2004 19:20:09 - 1.6
+++ maven.xml 16 Feb 2004 19:00:43 - 1.7
@@ -40,24 +40,21 @@
!-- number and combination of conditions.--
!-- --
-project default=build
- xmlns:reactor=reactor
- xmlns:m=maven
- xmlns:texen=texen
+project default=build-all xmlns:maven=jelly:maven
!-- == --
!-- B U I L D --
!-- == --
- goal name=build
+ goal name=build-all
-reactor:execute
- basedir=${basedir}
- glob=../*/project.xml
- excludes=commons-build/project.xml
+maven:reactor
+ basedir=${basedir}/..
+ includes=*/project.xml
+ excludes=commons-build/project.xml
goals=clean,jar:install
banner=Building
- ignoreFailures=true
+ ignoreFailures=false
/
/goal
@@ -68,16 +65,10 @@
goal name=site
-!--
- ||
- || Generate the documentation for each of the commons projects.
- ||
---
-
-reactor:execute
- basedir=${basedir}
- glob=../*/project.xml
- excludes=commons-build/project.xml
+maven:reactor
+ basedir=${basedir}/..
+ includes=*/project.xml
+ excludes=commons-build/project.xml
goals=site:deploy
banner=Generating site for
ignoreFailures=true
@@ -93,10 +84,10 @@
goal name=site-front-end
-reactor:execute
- basedir=${basedir}
- glob=../*/project.xml
- excludes=commons-build/project.xml
+maven:reactor
+ basedir=${basedir}/..
+ includes=*/project.xml
+
DO NOT REPLY [Bug 26922] - [lang] public static boolean DateUtils.equals(Date dt1, Date dt2) ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26922. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26922 [lang] public static boolean DateUtils.equals(Date dt1, Date dt2) ? --- Additional Comments From [EMAIL PROTECTED] 2004-02-16 19:17 --- BTW, the 1st assert blows up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
Once again, this misses the point for me. The newer maven style is much worse not better. We need a L+F that is controlled by commons, not by whatever maven decides to do today. I'll try and play tonight. Stephen - Original Message - From: [EMAIL PROTECTED] And the 'new look and feel' can be done by using RC1 and the included xdocs/project.css (from memory). -- dIon Gillard, Multitask Consulting Martin Cooper [EMAIL PROTECTED] wrote on 16/02/2004 03:17:00 PM: -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Sunday, February 15, 2004 7:57 PM To: [EMAIL PROTECTED] Subject: [all] maven sites Hey, someone is publishing Commons Maven sites with an unreleased version of Maven. Probably either from Maven's CVS HEAD, or a beta version. BeanUtils, Betwixt, and Digester all have the newish Maven L+F. A decision was reached a while back to standardize on the released version of Maven. Could whoever did that please get the released version of Maven and republish those sites? There is no released version of Maven yet, according to the Maven web site. There's just RC1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.xml
mdiggory2004/02/16 11:37:25
Modified:commons-build project.xml
Log:
reports possibly can be default to commons build.
Revision ChangesPath
1.15 +18 -1 jakarta-commons/commons-build/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/commons-build/project.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- project.xml 16 Feb 2004 19:00:43 - 1.14
+++ project.xml 16 Feb 2004 19:37:25 - 1.15
@@ -27,7 +27,7 @@
issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
-
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
+
siteDirectory/www/jakarta.apache.org/commons-mavenized/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
repository
@@ -76,4 +76,21 @@
jars/jars
/build
+ reports
+ !--
+ reportmaven-changelog-plugin/report
+ reportmaven-changes-plugin/report
+reportmaven-checkstyle-plugin/report
+reportmaven-clover-plugin/report
+reportmaven-developer-activity-plugin/report
+reportmaven-file-activity-plugin/report
+reportmaven-javadoc-plugin/report
+reportmaven-jdepend-plugin/report
+reportmaven-junit-report-plugin/report
+reportmaven-jxr-plugin/report
+reportmaven-license-plugin/report
+reportmaven-statcvs-plugin/report
+reportmaven-tasklist-plugin/report
+--
+ /reports
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
On 16 Feb 2004, at 03:56, Tim O'Brien wrote: Hey, someone is publishing Commons Maven sites with an unreleased version of Maven. Probably either from Maven's CVS HEAD, or a beta version. BeanUtils, Betwixt, and Digester all have the newish Maven L+F. A decision was reached a while back to standardize on the released version of Maven. Could whoever did that please get the released version of Maven and republish those sites? i'm using a version nearer cvs head. i'm not very keen on downgrading since it always seems to take a couple of hours for me to get a version of maven that i'm happy with. we're nearing a situation where we'll be able to build the entire commons site from a single command. there are only a handful of site remaining to be converted. anyone feel like volunteering to take care of them?. i'd be happy to avoid deploying the website (with my development version of maven) so long as we start deploying every component website rather than each atomically. how close are we to having a usable reactor documentation build? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Refactor AbstractConfiguration(Configuration defaults)
Hi, On Mon, 16 Feb 2004, Eric Pugh wrote: True.. But, you could grab the propertiesConfiguration out of the composite and save it.. I think the composite should be looked at as a read only thing because saving has too many odd ramifications.. And, at least, the one user who mentioned the AbstractConfiguration(Configuration conf) is actually using a CompositeConfig anyway, and needs that exact same problem solved.. Well, as long as CompositeConfigs are read-only/in-memory-only, I don't think they can fully substitute chainable defaults. But of course, adding a save() method to CompositeConfig doesn't make sense, because they don't have a native format. Maybe a CompositeConfiguration.flatten(Configuration out) method that adds all key/value pairs to the out configuration? This would allow flattening a Composite to BaseProperties or XML/DOM4J or any other format and storing the flattened configuration... Bye Christian PS. Please cc me as I'm not on the list. Christian Siefkes - | Email: [EMAIL PROTECTED]| Web: http://www.siefkes.net/ | Graduate School in Distributed IS: http://www.wiwi.hu-berlin.de/gkvi/ Offline P2P: http://www.leihnetzwerk.de/ -- More than any time in history, mankind now faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly. -- Woody Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
Henri Yandell wrote: I'd just started in commons-build/template, but sandbox sounds fine too. If you want to just point me to the ideal maven config [I started using IO], then I can go ahead and get most of it done for you and let you fix any minor issues left. Hen I was thinking sandbox, because thats where all projects start out and its logical that they won't know where commons-build really is. I've added some files to the cvs and you can go from there. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/project-template there may be thing we want to remove/add to this. But I think this is the basic requirement for a project.xml. -M. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/project-template project.xml
bayard 2004/02/16 12:37:15 Modified:project-template project.xml Log: removed the compile/runtime comment that comes from maven b1 or so poms Revision ChangesPath 1.3 +0 -1 jakarta-commons-sandbox/project-template/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/project-template/project.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- project.xml 16 Feb 2004 20:32:20 - 1.2 +++ project.xml 16 Feb 2004 20:37:15 - 1.3 @@ -38,7 +38,6 @@ /contributor /contributors -!-- Need to mark these as compile-time/run-time -- dependencies dependency idjunit/id - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
Henri Yandell wrote: On Mon, 16 Feb 2004, Mark R. Diggory wrote: I think we should setup a project-template directory somewhere, maybe in the sandbox. It will contian something like: project-template/ project-template/LICENSE.txt Currently the LICENSE.txt in commons-build is the new 2.0 one, except I didn't think we were meant to put the actual 2.0 one there but instead a shorter version that linked to that one and a NOTICE file. We should put a dummy NOTICE file in the template too. I'm open to this. project-template/project.xml project-template/maven.xml Do we have any standard things to go in here? I've had various things in my work maven.xml's, but am slowly refactoring them all into a maven plugin as I'm thinking maven.xml's should only be for custom changes. yes, no requirement for the maven.xml to exist, just an example as an exercise in usage. project-template/project.properties project-template/xdocs Any standard navigation.xml that could be involved? images/ ? Need to work out the details further here. I'm sure some projects have thier own customizations to navigation, I think eventually navigation.xml will always have an include in it as well from commons-build/incl_nav.xml project-template/src/main project-template/src/test src/java ? :) yes, and no, I think the maven standard is moving towards the elimination of java as a src directory to be replaced by main. Once its all together, with nice variables, I can write a nice ant or maven wizard. Been meaning to do that for work as a part of the internal plugin. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/project-template project.xml
bayard 2004/02/16 12:40:29 Modified:project-template project.xml Log: removed testtools exclusion and data resources. If we can decide on a global standard, this can surely go in the super-pom Revision ChangesPath 1.5 +0 -10 jakarta-commons-sandbox/project-template/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/project-template/project.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- project.xml 16 Feb 2004 20:38:07 - 1.4 +++ project.xml 16 Feb 2004 20:40:29 - 1.5 @@ -51,20 +51,10 @@ unitTestSourceDirectorysrc/test/unitTestSourceDirectory !-- Unit test classes -- -!-- TODO Organize test inclusions and exclusions -- unitTest includes include**/*Test*/include /includes -excludes -exclude**/testtools/**/exclude -/excludes - -resources -resource -directorydata/test/directory -/resource -/resources /unitTest !-- J A R R E S O U R C E S -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/project-template project.xml
bayard 2004/02/16 12:41:18 Modified:project-template project.xml Log: switched to be sandbox based. will still work for a proper if unchanged Revision ChangesPath 1.6 +1 -1 jakarta-commons-sandbox/project-template/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/project-template/project.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- project.xml 16 Feb 2004 20:40:29 - 1.5 +++ project.xml 16 Feb 2004 20:41:18 - 1.6 @@ -1,7 +1,7 @@ ?xml version=1.0? project - extend../commons-build/project.xml/extend + extend../../jakarta-commons/commons-build/project.xml/extend nameyour-project/name idcommons-your-project/id - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
yes they do, there are a few things there that don't need to be though:
these can be left out of the project.xml
urlhttp://jakarta.apache.org/commons/io//url
siteAddressjakarta.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/io//siteDirectory
repository
connection
scm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons/io
/connection
urlhttp://cvs.apache.org/viewcvs/jakarta-commons/io//url
/repository
they are resolved in the extended commons-build/project.xml
siteAddressjakarta.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
repository
connectionscm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons/${pom.artifactId.substring(8)}/connection
urlhttp://cvs.apache.org/viewcvs/jakarta-commons/${pom.artifactId.substring(8)}//url
/repository
Stephen Colebourne wrote:
[lang] and [io] have good setups.
Stephen
From: Henri Yandell [EMAIL PROTECTED]
I think we should setup a project-template directory somewhere, maybe in
the sandbox. It will contian something like:
project-template/
project-template/LICENSE.txt
project-template/project.xml
project-template/maven.xml
project-template/project.properties
project-template/xdocs
project-template/src/main
project-template/src/test
I can put this together and place it into the sandbox
I'd just started in commons-build/template, but sandbox sounds fine too.
If you want to just point me to the ideal maven config [I started using
IO], then I can go ahead and get most of it done for you and let you fix
any minor issues left.
Hen
-
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]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
From: Mark R. Diggory [EMAIL PROTECTED]
${maven.xdoc.theme.url}
the contents of this css will override any project.css or print.css
properties.
Are you proposing that 'theme' is the best override point for a commons css?
It sounds as though its placed about right. It appears to not be in the 1.4
xdoc plugin, so its another reason to upgrade I suppose.
The one thing we don't really want to do is copy the file to each commons
project, but I can't see how to do this otherwise.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
project templates Was: [all] maven sites
On Mon, 16 Feb 2004, Mark R. Diggory wrote: I was thinking sandbox, because thats where all projects start out and its logical that they won't know where commons-build really is. Sounds good. Should be based on a sandbox project then, ie) ../../jakarta-commons/commons-build/project.xml as the extend. I've added some files to the cvs and you can go from there. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/project-template there may be thing we want to remove/add to this. But I think this is the basic requirement for a project.xml. I've removed a few things :) Hope that's okay. Couple of questions: Developers: Should emails be in some form of lightly obscured format? Should url and timezone be included? Resources: Should we include .properties by default? In fact, can't most of the build go in the super-pom? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/project-template project.xml
bayard 2004/02/16 12:44:22 Modified:project-template project.xml Log: cute typo change so a search and replace changes the desc Revision ChangesPath 1.7 +1 -1 jakarta-commons-sandbox/project-template/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/project-template/project.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- project.xml 16 Feb 2004 20:41:18 - 1.6 +++ project.xml 16 Feb 2004 20:44:22 - 1.7 @@ -16,7 +16,7 @@ inceptionYear2004/inceptionYear shortDescriptionCommons your-project/shortDescription description -Flesh out a description of your project here. +Flesh out a description of your-project here. /description developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project templates Was: [all] maven sites
On Mon, 16 Feb 2004, Henri Yandell wrote: Resources: Should we include .properties by default? In fact, can't most of the build go in the super-pom? Me idiot. This stuff is all in there by default. So the entire build can be removed in the child project I'm guessing. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
Stephen, most of the maven site already have stylesheets to address your concern. Tim On Mon, 16 Feb 2004, Stephen Colebourne wrote: Once again, this misses the point for me. The newer maven style is much worse not better. We need a L+F that is controlled by commons, not by whatever maven decides to do today. I'll try and play tonight. Stephen - Original Message - From: [EMAIL PROTECTED] And the 'new look and feel' can be done by using RC1 and the included xdocs/project.css (from memory). -- dIon Gillard, Multitask Consulting Martin Cooper [EMAIL PROTECTED] wrote on 16/02/2004 03:17:00 PM: -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Sunday, February 15, 2004 7:57 PM To: [EMAIL PROTECTED] Subject: [all] maven sites Hey, someone is publishing Commons Maven sites with an unreleased version of Maven. Probably either from Maven's CVS HEAD, or a beta version. BeanUtils, Betwixt, and Digester all have the newish Maven L+F. A decision was reached a while back to standardize on the released version of Maven. Could whoever did that please get the released version of Maven and republish those sites? There is no released version of Maven yet, according to the Maven web site. There's just RC1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.xml
bayard 2004/02/16 12:47:15 Modified:commons-build project.xml Log: removed aspect/integration as they are empty here Revision ChangesPath 1.16 +0 -5 jakarta-commons/commons-build/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/commons-build/project.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- project.xml 16 Feb 2004 19:37:25 - 1.15 +++ project.xml 16 Feb 2004 20:47:15 - 1.16 @@ -54,8 +54,6 @@ nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress sourceDirectorysrc/java/sourceDirectory unitTestSourceDirectorysrc/test/unitTestSourceDirectory -integrationUnitTestSourceDirectory/ -aspectSourceDirectory/ !-- Unit test classes -- unitTest @@ -64,9 +62,6 @@ /includes /unitTest -!-- Integration unit test classes -- -integrationUnitTestPatterns/integrationUnitTestPatterns - resources includes include**/*.properties/include - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.xml
bayard 2004/02/16 12:47:53 Modified:commons-build project.xml Log: removed empty jars tag Revision ChangesPath 1.17 +0 -1 jakarta-commons/commons-build/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/commons-build/project.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- project.xml 16 Feb 2004 20:47:15 - 1.16 +++ project.xml 16 Feb 2004 20:47:53 - 1.17 @@ -68,7 +68,6 @@ /includes /resources -jars/jars /build reports - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
There was actually already a 'template' project in the sandbox, but I can never remember the name. Ahh. [proposal]. Stephen From: Mark R. Diggory [EMAIL PROTECTED] I was thinking sandbox, because thats where all projects start out and its logical that they won't know where commons-build really is. I've added some files to the cvs and you can go from there. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/project-template there may be thing we want to remove/add to this. But I think this is the basic requirement for a project.xml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project templates Was: [all] maven sites
Oops. jakarta-commons-sandbox/proposal is effectively the same thing for the old style, so we should integrate it in. Additionally, it's high time we decided what parts of PROPOSAL, RELEASE-NOTES and STATUS are needed for a mavenised commons project. RELEASE-NOTES could be replaced by changes.xml and the changes plugin. STATUS? PROPOSAL still seems necessary, and we should move it into xdocs/proposal.xml with a few parts removed/linked. I'll think further on this. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
yeah. just noticed that again myself. let's build a maven/new version in project-template and deprecated proposal when we've subsumed all its features. Hen On Mon, 16 Feb 2004, Stephen Colebourne wrote: There was actually already a 'template' project in the sandbox, but I can never remember the name. Ahh. [proposal]. Stephen From: Mark R. Diggory [EMAIL PROTECTED] I was thinking sandbox, because thats where all projects start out and its logical that they won't know where commons-build really is. I've added some files to the cvs and you can go from there. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/project-template there may be thing we want to remove/add to this. But I think this is the basic requirement for a project.xml. - 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]
cvs commit: jakarta-commons-sandbox/project-template project.xml
bayard 2004/02/16 12:52:48 Modified:project-template project.xml Log: obfuscated the email address poorly Revision ChangesPath 1.8 +2 -2 jakarta-commons-sandbox/project-template/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/project-template/project.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- project.xml 16 Feb 2004 20:44:22 - 1.7 +++ project.xml 16 Feb 2004 20:52:48 - 1.8 @@ -23,7 +23,7 @@ developer nameYour Name Here/name idyhere/id -email[EMAIL PROTECTED]/email +emailyhere at apache dot org/email organization/organization roles roleJava Developer/role @@ -34,7 +34,7 @@ contributors contributor nameYour Name Here/name -email[EMAIL PROTECTED]/email +emailyhere at somewhere dot org/email /contributor /contributors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project templates Was: [all] maven sites
Some more questions: roles Is this pointless? It's always 'Java Developer', unless we switch to ASF positions [PMC, Committer, Member], which should really be in a different file. Really we need a members.xml file that sits outside of the pom and is linked in. ie) something like: http://jakarta.apache.org/~bayard/pergamum/j-c/member-roles.xml Obviously something I need to take over to Maven. organization Also pointless? ie) this should really always be ASF and not insert-your-job-here ? Hen On Mon, 16 Feb 2004, Henri Yandell wrote: Oops. jakarta-commons-sandbox/proposal is effectively the same thing for the old style, so we should integrate it in. Additionally, it's high time we decided what parts of PROPOSAL, RELEASE-NOTES and STATUS are needed for a mavenised commons project. RELEASE-NOTES could be replaced by changes.xml and the changes plugin. STATUS? PROPOSAL still seems necessary, and we should move it into xdocs/proposal.xml with a few parts removed/linked. I'll think further on this. Hen - 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]
cvs commit: jakarta-commons-sandbox/project-template project.xml
bayard 2004/02/16 12:58:53 Modified:project-template project.xml Log: removed the build section, as it should inherit it all from the super-pom Revision ChangesPath 1.9 +0 -23 jakarta-commons-sandbox/project-template/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/project-template/project.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- project.xml 16 Feb 2004 20:52:48 - 1.8 +++ project.xml 16 Feb 2004 20:58:53 - 1.9 @@ -45,29 +45,6 @@ /dependency /dependencies -build -nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress -sourceDirectorysrc/java/sourceDirectory -unitTestSourceDirectorysrc/test/unitTestSourceDirectory - -!-- Unit test classes -- -unitTest -includes -include**/*Test*/include -/includes -/unitTest - -!-- J A R R E S O U R C E S -- -!-- Resources that are packaged up inside the JAR file -- -resources -resource -includes -include**/*.properties/include -/includes -/resource -/resources -/build - reports reportmaven-changelog-plugin/report reportmaven-changes-plugin/report - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project templates Was: [all] maven sites
Discovery project.properties has: maven.repo.central=www.apache.org maven.repo.central.directory=/www/www.apache.org/dist/java-repository maven.remote.group=apcvs Should this be in the template pom.prop? Hen On Mon, 16 Feb 2004, Mark R. Diggory wrote: Henri Yandell wrote: On Mon, 16 Feb 2004, Mark R. Diggory wrote: I was thinking sandbox, because thats where all projects start out and its logical that they won't know where commons-build really is. Sounds good. Should be based on a sandbox project then, ie) ../../jakarta-commons/commons-build/project.xml as the extend. Yes, I was thinking that to. I've added some files to the cvs and you can go from there. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/project-template there may be thing we want to remove/add to this. But I think this is the basic requirement for a project.xml. I've removed a few things :) Hope that's okay. Cool Couple of questions: Developers: Should emails be in some form of lightly obscured format? Should url and timezone be included? Resources: Should we include .properties by default? In fact, can't most of the build go in the super-pom? Cool, sounds very good (considering all the spam my apache account seems to get) -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - 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: [all] maven sites
The point is that maven keep changing their mind. First came classic blue top Second came white top, big font, red section titles Third (current) is white top, good left, but ridiculous section titles see http://maven.apache.org We need to divorce ourselves from this. The current project.css only works against the xdoc 1.4 plugin. Stephen - Original Message - From: Tim O'Brien [EMAIL PROTECTED] Stephen, most of the maven site already have stylesheets to address your concern. Tim On Mon, 16 Feb 2004, Stephen Colebourne wrote: Once again, this misses the point for me. The newer maven style is much worse not better. We need a L+F that is controlled by commons, not by whatever maven decides to do today. I'll try and play tonight. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Re: cvs commit math/src/test/org/apache/commons/math/analysis InterpolatorTest.java
--- Phil Steitz [EMAIL PROTECTED] wrote: Al Chou wrote: Phil, I noticed that in testInterpolateLinearDegenerateThreeSegment() you didn't insert a TODO comment when you deleted most of the body of the method (quoted below) Al Oops! I should have commented that block out, as I did the others and insert a todo. I will fix this evening. Sorry. Phil Cool, thanks. Al __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build .cvsignore
scolebourne2004/02/16 13:10:50 Added: commons-build .cvsignore Log: Ignores Revision ChangesPath 1.1 jakarta-commons/commons-build/.cvsignore Index: .cvsignore === .classpath .project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build navigation.vm
scolebourne2004/02/16 13:11:08 Modified:commons-build navigation.vm Log: Add convert Revision ChangesPath 1.7 +1 -0 jakarta-commons/commons-build/navigation.vm Index: navigation.vm === RCS file: /home/cvs/jakarta-commons/commons-build/navigation.vm,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- navigation.vm 15 Feb 2004 16:11:31 - 1.6 +++ navigation.vm 16 Feb 2004 21:11:08 - 1.7 @@ -46,6 +46,7 @@ item name=Clazz href=http://jakarta.apache.org/commons/sandbox/clazz// item name=Compress href=http://jakarta.apache.org/commons/sandbox/compress// item name=Configuration href=http://jakarta.apache.org/commons/sandbox/configuration// +item name=Convert href=http://jakarta.apache.org/commons/sandbox/convert// item name=Events href=http://jakarta.apache.org/commons/sandbox/events// item name=Functor href=http://jakarta.apache.org/commons/sandbox/functor// item name=HiveMind href=http://jakarta.apache.org/commons/sandbox/hivemind// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DateUtils.equals(d1, d2)
Serge, I'm not sure that your proposed method will do what you want. You can't compare the results of java.util.Date.getTime() and java.sql.Timestamp.getTime() because the latter is only precise to the second, not the millisecond. Likewise, java.sql.Date.getTime() is only precise to the second. Unless you do rather snarly logic, it may not be meaningful to compare any util.Date with any of the sql types. Quoting from the Timestamp API: Due to the differences between the Timestamp class and the java.util.Date class mentioned above, it is recommended that code not view Timestamp values generically as an instance of java.util.Date. The inheritance relationship between Timestamp and java.util.Date really denotes implementation inheritance, and not type inheritance. To compare a until.Date with a sql.Timestamp you'll have to rebuild the latter's time to millisecond precision by call getNanos(), rounding the result to the millisecond, and adding it to getTime(). And if you want true equality you'll have to fail if the submillisecond nanos aren't zero. Doing all of that is of debatable usefulness, because the use of such a somewhat-generic equality method probably indicates that the programmer doesn't understand the subtleties here and he's probably writing a bug. :-) Just my two cents from painful experience... .T. On Fri, 13 Feb 2004 18:12:37 -0500, Serge Knystautas [EMAIL PROTECTED] said: There was a bugzilla issue opened about this, and a brief discussion about such, but I wanted to move it to the list for better visibility. Basically if you have 2 date objects (e.g., java.util.Date and java.sql.Timestamp), ObjectUtils.equals() will return that they are not equal even if they represent the same point in time. Unless someone objects, I was going to add DateUtils.equals(Date d1, Date d2) and the equality check will be what's returned from each date's getTime(). Just as an example: long now = System.currentTimeMillis(); Date date = new java.util.Date(now); Date ts = new java.sql.Timestamp(now); ObjectUtils.equals(date, ts) = false; (as of 2.1) DateUtils.equals(date, ts) = true; Anyone have a different idea or think this is a bad idea? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] -- Todd V. Jonker Conscious Code Ltd The Practice of Programming www.consciouscode.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] canPreProcess and preProcess
John Keyes wrote: Looking at the Argument API I was looking at the canPreProcess and preProcess methods. I dislike the names as they don't describe what the methods do. Yeah - I wasn't so bothered when it was just preProcess but it is a bit daft with canPreProcess too. +1 on moving the logic from Argument to Parent (where it's used anyway) and giving it a meaningful name. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/xdocs guide.xml index.xml navigation.xml
rdonkin 2004/02/16 13:28:09 Modified:logging project.xml logging/xdocs guide.xml index.xml navigation.xml Log: Corrections to documentation. Submitted by Dennis Lundberg. Revision ChangesPath 1.12 +2 -3 jakarta-commons/logging/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/logging/project.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- project.xml 15 Feb 2004 09:38:22 - 1.11 +++ project.xml 16 Feb 2004 21:28:08 - 1.12 @@ -4,7 +4,6 @@ extend../commons-build/project.xml/extend nameLogging/name idcommons-logging/id - logo/logo currentVersion1.0-dev/currentVersion organization @@ -16,7 +15,7 @@ inceptionYear2001/inceptionYear shortDescriptionCommons Logging/shortDescription description -Commons Logging is a thin adapter allowing configurable bridging to other, +Commons Logging is a thin adapter allowing configurable bridging to other, well known logging systems. /description @@ -51,7 +50,7 @@ /developer developer nameScott Sanders/name - idsanders/id + idsanders/id emailsanders at apache dot org/email organizationApache Software Foundation/organization /developer 1.2 +21 -21jakarta-commons/logging/xdocs/guide.xml Index: guide.xml === RCS file: /home/cvs/jakarta-commons/logging/xdocs/guide.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- guide.xml 15 Feb 2004 10:28:56 - 1.1 +++ guide.xml 16 Feb 2004 21:28:09 - 1.2 @@ -13,7 +13,7 @@ p The Jakarta Commons Logging (JCL) provides a Log interface that is intended to be both light-weight and independent of numerous logging toolkits. -It provides the middleware/tooling developer a simple +It provides the middleware/tooling developer with a simple logging abstraction, that allows the user (application developer) to plug in a specific logging implementation. /p @@ -25,8 +25,8 @@ p The Jakarta Commons Logging provides a Log interface with thin-wrapper implementations for other logging tools, including -a href=http://jakarta.apache.org/log4j/docs/index.html;Log4J/a, -a href=http://jakarta.apache.org/avalon/logkit/index.html;Avalon LogKit/a, +a href=http://logging.apache.org/log4j/docs/index.html;Log4J/a, +a href=http://avalon.apache.org/logkit/index.html;Avalon LogKit/a, and aJDK 1.4/a. The interface maps closely to Log4J and LogKit. @@ -35,7 +35,7 @@ /section section name=Users Quick Start p -As far as possible, emCommons-Logging/em tries to be as unobtrusive as possible. +As far as possible, emCommons-Logging/em tries to be as unobtrusive as possible. In most cases, including the (full) codecommons-logging.jar/code in the classpath should result in emCommons-Logging/em configuring itself in a reasonable manner. There's a good chance that it'll guess your preferred logging system and you won't @@ -43,10 +43,10 @@ /p subsection name='Configuration' p -There are two base abstractions used by emCommons-Logging/em: codeLog/code +There are two base abstractions used by emCommons-Logging/em: codeLog/code (the basic logger) and codeLogFactory/code (which knows how to create codeLog/code -instances). Using codeLogFactory/code implementations other than the default is a -subject for advanced users only, so let's concentrate on configuring the default +instances). Using codeLogFactory/code implementations other than the default is a +subject for advanced users only, so let's concentrate on configuring the default implementation. /p p @@ -104,7 +104,7 @@ /code /ul p -Note that some components using commons-logging may +Note that some components using commons-logging may either extend Log, or provide a component-specific LogFactory implementation. Review the component documentation for guidelines @@ -165,7 +165,7 @@ /ul subsection name='Best Practices' p -Best practices for programming/planning are presented in two categories: +Best practices for programming/planning are presented in two categories: General and Enterprise. The general principles are fairly clear. Enterprise practices are a bit more involved and it is not always as clear as to why they are important. @@ -187,7 +187,7 @@ that otherwise introduces undesirable runtime overhead in the general case (logging disabled). Examples are multiple parameters, or expressions (i.e. string + more) for parameters. -Use the guard
Re: [all] maven sites
On Mon, 16 Feb 2004, Stephen Colebourne wrote: The point is that maven keep changing their mind. First came classic blue top Second came white top, big font, red section titles Third (current) is white top, good left, but ridiculous section titles see http://maven.apache.org We need to divorce ourselves from this. The current project.css only works against the xdoc 1.4 plugin. snip This may be a bit drastic, but commons could define its own site.jsl file (originally copied from the appropriate version of the xdoc plugin) and use the property maven.xdoc.jsl=.../commons-site.jsl michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Enhancing CallMethodRule to take target offset
On Mon, 2004-02-16 at 11:32, robert burrell donkin wrote: (a few possible disconnected observations.) betwixt is more focussed on automated mapping than digester. betwixt bean reading rulesets can be freely mixed with digester rules but it's designed (at the moment) around producing a single output bean. one concept i'd like to add (one day) is partial mapping - this means that xml sub-graph's would be mapped and push the resultant bean onto a pipe for processing. i believe that this would be useful in processing large, regular xml documents. i've never really considered about using a hashmap to store betwixt results. for a while i've been thinking about adding named stacks to digester. the problem with a hashmap is that it supports well only flat xml. named stacks would be a map of stacks which would function equally well whether the xml was flat or deep. in the deep case, rules would push objects onto stacks with particular names and then pop them. in the flat case, they could be used in the way joe's describing. again, this is something that i think would be very useful but is probably looking for a volunteer to code. - robert On 12 Feb 2004, at 00:56, Joe Germuska wrote: I don't really understand how XMLBeanFactory can get away without the equivalent of Digester's rules, unless the java class names, attribute names, etc *must* map 1:1 with the xml element/attribute names. Well, XMLBeanFactory isn't promising to be as universally useful at processing XML as Digester, which is how it can get away without requiring rules to be defined. The XMLBeanFactory encounters any number of bean elements, which implicitly mean object-create, but instead of pushing them on a stack, it puts them in a map (effectively, at least). Then it has a standard set-property element, which does what you would expect. However, the contents of set-property can be literal values or references to beans which have already been instantiated. My most common use case for Digester is to instantiate some object and populate it with values. I think it's great that Digester can do a lot more than that, but I feel like I write the same rules over and over, just hooking them to different element names. Of course, if you don't get to define the structure of the XML you are processing, Digester has all the necessary flexibility and such, but since my XML files are usually my own invention, it's no big deal to adapt the XML to whatever tool I'm using. I just found it convenient in this case to be able to use a name rather than a known position on the stack to make an introduction between two objects that were instantiated from the XML. That sounded a little like your goal to have rules that reach objects in arbitrary locations on the digester stack, so I piped up. I think that Joe's suggestion was essentially so that references can be built between objects other than parent/child. doc bean1 id=123 ... /bean1 bean2 sibling id=123/ /bean2 /doc The sibling tag results in a bean2 method being invoked with a *reference* to bean1 as a parameter. I think this can be fairly easily done with 2 new rules: StoreNamedReferenceRule(String attrname) and NamedReferenceParamRule(String attrname) The StoreNamedReferenceRule just puts the entry in a HashMap, as Joe describes. The NamedReferenceParamRule retrieves the referenced object from the map and puts it into the params array of a CallMethodRule. One issue is that the HashMap used to store the named objects needs to be accessable to both rules, so really needs to be stored at the Digester level. I've been thinking of having a HashMap member on the Digester class, which can be used by cooperative rules like this pair to communicate. A rule can store into this hashmap a single object keyed by its own package name; this provides a namespacing mechanism that prevents conflicts over use of this map. I'm not sure how your named stacks idea differs from this. Can you describe how it would be used? And sorry, but I didn't understand your suggestion about partial mapping at all! NB: I still think that a Digester 1.6 release should come before new work like this. There's no reason a Digester 1.7 couldn't be done on a much shorter cycle than the last one. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] release (was attribute substitution/variable expansion)
Any chance the commons-collections usage can be removed for this release? This was brought up earlier and seemed to be supported. The last I checked digester made a very minimal use of commons-collections anyways. Other packages using digester don't need collections and it's a rather big dependency to carry around in addition to the recent 3.0 incompatible changes. David Simon Kitching [EMAIL PROTECTED] wrote: On Tue, 2004-02-17 at 04:52, Simon Kitching wrote: I only see *one* item as needing to be done prior to a release Oh - and change the licence to version 2.0. The email discussion about permission to relicense has died away. I saw Craig's email saying it was ok, but nothing from the ASF officially. If necessary, I could grep out all the @author tags and check against the ASF contributors list I saw a few links to apps for auto-changing the license text. I'm happy to do chase these down, run them commit the updates unless there are objections, or someone else prefers to do this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online
Re: [lang] split join
Stick with split, otherwise users will have to remember the difference between split and divide or chop or hack or cut or slice or some other arbitrary word. The slight semantic difference is far from obvious in the name. This is why I am constantly digging through the [lang] API docs to remember the difference between (for example) clean() and trim() and strip(). There are subtle semantic differences hidden, none of which are indicated by the method names, which are all equally arbitrary and generic. I find it continually frustrating. Let's not make that mistake again. .T. On Thu, 12 Feb 2004 19:08:29 +0100, Emmanuel Bourg [EMAIL PROTECTED] said: Joe Germuska wrote: Maybe the best would just be an alternate method signature to split(...) ? This solution is a bit ugly i think, but it's the only one if we can't find a better name. What about divide(), break() or cut() ? Emmanuel Bourg -- Todd V. Jonker Conscious Code Ltd The Practice of Programming www.consciouscode.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang][proposal] SystemUtils property out of sync problem; add set methods.
Gary, Would it meet testing needs to add a reloadSystemProperties() method that test-code can call after tweaking things? It seems like that would make testing easy without cluttering SystemUtils with setters (that perhaps shouldn't be used otherwise). .T. On Fri, 13 Feb 2004 23:11:43 -, Stephen Colebourne [EMAIL PROTECTED] said: From: Gary Gregory [EMAIL PROTECTED] Do people really change these values? (other than in tests, which kinda don't count...) My feeling is that is does not matter what /kind/ of call site uses (for example) SystemUtils, whether it is application code or unit test code. My application, in general terms, is the client/customer. What matters is that [lang] provides the services that make my job of writing code easier/better/faster. The point I'm really driving at is where the limits of [lang] lie. There is no technical difficulty (other than its a bit boring) of adding get and set methods for each system property in addition to the constants. The question is whether it serves a big enough need. Maybe there is a large need to change environment variables, but I just feel a little unconvinced. Consider me -0 I guess. Stephen - 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: [digester] release (was attribute substitution/variable expansion)
On Tue, 2004-02-17 at 10:38, David Graham wrote: Any chance the commons-collections usage can be removed for this release? This was brought up earlier and seemed to be supported. The last I checked digester made a very minimal use of commons-collections anyways. Other packages using digester don't need collections and it's a rather big dependency to carry around in addition to the recent 3.0 incompatible changes. Craig Mcc. committed changes to implement this just a few days ago for the Digester code itself. We still depend on BeanUtils, and BeanUtils currently depends on collections. Unless we wait for BeanUtils to make a new collections-independent release, we can't completely rid digester of the collections jar. Robert, what are the plans for the next BeanUtils release? Should we delay the next Digester release until then? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang][proposal] SystemUtils property out of sync problem; ad d set methods.
The method is a fine idea but it would not meet my needs since my code looks
like this:
public void testJavaExtDirDoesNotExist() {
String saveJavaExtDirs = SystemUtils.JAVA_EXT_DIRS;
try {
String testJavaExtDirs = ...;
System.setProperty(java.ext.dirs, testJavaExtDirs);
// The real test starts here...
} finally {
System.setProperty(java.ext.dirs, saveJavaExtDirs);
}
}
And would perhaps be prettier if I could do:
SystemUtils.setJavaExtDirs(saveJavaExtDirs);
Instead of:
System.setProperty(java.ext.dirs, saveJavaExtDirs);
Gary
-Original Message-
From: Todd V. Jonker [mailto:[EMAIL PROTECTED]
Sent: Monday, February 16, 2004 13:52
To: Jakarta Commons Developers List
Subject: Re: [lang][proposal] SystemUtils property out of sync problem;
add set methods.
Gary,
Would it meet testing needs to add a reloadSystemProperties() method that
test-code can call after tweaking things? It seems like that would make
testing easy without cluttering SystemUtils with setters (that perhaps
shouldn't be used otherwise).
.T.
On Fri, 13 Feb 2004 23:11:43 -, Stephen Colebourne
[EMAIL PROTECTED] said:
From: Gary Gregory [EMAIL PROTECTED]
Do people really change these values? (other than in tests, which
kinda
don't count...)
My feeling is that is does not matter what /kind/ of call site uses
(for
example) SystemUtils, whether it is application code or unit test
code. My
application, in general terms, is the client/customer. What matters is
that
[lang] provides the services that make my job of writing code
easier/better/faster.
The point I'm really driving at is where the limits of [lang] lie. There
is
no technical difficulty (other than its a bit boring) of adding get and
set
methods for each system property in addition to the constants. The
question
is whether it serves a big enough need.
Maybe there is a large need to change environment variables, but I just
feel
a little unconvinced. Consider me -0 I guess.
Stephen
-
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: [lang][proposal] SystemUtils property out of sync problem; add set methods.
What's wrong with the changes inlined below?
public void testJavaExtDirDoesNotExist() {
String saveJavaExtDirs = SystemUtils.JAVA_EXT_DIRS;
try {
String testJavaExtDirs = ...;
System.setProperty(java.ext.dirs, testJavaExtDirs);
SystemUtils.reloadProperties();
// The real test starts here...
} finally {
System.setProperty(java.ext.dirs, saveJavaExtDirs);
SystemUtils.reloadProperties();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang][proposal] SystemUtils property out of sync problem; ad d set methods.
Nothing wrong ;-) but I'd would prefer to also refactor:
System.setProperty(java.ext.dirs, testJavaExtDirs);
Not in my code like this:
this.setJavaExtDirs(saveJavaExtDirs);
But in SystemUtils like this:
SystemUtils.setJavaExtDirs(saveJavaExtDirs);
Which would also avoid having to call SystemUtils.reloadProperties() in the
first place. So, from my one example's POV, the ugliness gets x2. The
reloadProperties is still useful of course to workaround other setProperty
call sites not in the control of the developer.
Gary
-Original Message-
From: Todd V. Jonker [mailto:[EMAIL PROTECTED]
Sent: Monday, February 16, 2004 13:59
To: Jakarta Commons Developers List
Subject: RE: [lang][proposal] SystemUtils property out of sync problem;
add set methods.
What's wrong with the changes inlined below?
public void testJavaExtDirDoesNotExist() {
String saveJavaExtDirs = SystemUtils.JAVA_EXT_DIRS;
try {
String testJavaExtDirs = ...;
System.setProperty(java.ext.dirs, testJavaExtDirs);
SystemUtils.reloadProperties();
// The real test starts here...
} finally {
System.setProperty(java.ext.dirs, saveJavaExtDirs);
SystemUtils.reloadProperties();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: DateUtils.equals(d1, d2)
See alse the bug report for an example of this not working... gg -Original Message- From: Todd V. Jonker [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 13:21 To: Jakarta Commons Developers List Subject: Re: DateUtils.equals(d1, d2) Serge, I'm not sure that your proposed method will do what you want. You can't compare the results of java.util.Date.getTime() and java.sql.Timestamp.getTime() because the latter is only precise to the second, not the millisecond. Likewise, java.sql.Date.getTime() is only precise to the second. Unless you do rather snarly logic, it may not be meaningful to compare any util.Date with any of the sql types. Quoting from the Timestamp API: Due to the differences between the Timestamp class and the java.util.Date class mentioned above, it is recommended that code not view Timestamp values generically as an instance of java.util.Date. The inheritance relationship between Timestamp and java.util.Date really denotes implementation inheritance, and not type inheritance. To compare a until.Date with a sql.Timestamp you'll have to rebuild the latter's time to millisecond precision by call getNanos(), rounding the result to the millisecond, and adding it to getTime(). And if you want true equality you'll have to fail if the submillisecond nanos aren't zero. Doing all of that is of debatable usefulness, because the use of such a somewhat-generic equality method probably indicates that the programmer doesn't understand the subtleties here and he's probably writing a bug. :-) Just my two cents from painful experience... .T. On Fri, 13 Feb 2004 18:12:37 -0500, Serge Knystautas [EMAIL PROTECTED] said: There was a bugzilla issue opened about this, and a brief discussion about such, but I wanted to move it to the list for better visibility. Basically if you have 2 date objects (e.g., java.util.Date and java.sql.Timestamp), ObjectUtils.equals() will return that they are not equal even if they represent the same point in time. Unless someone objects, I was going to add DateUtils.equals(Date d1, Date d2) and the equality check will be what's returned from each date's getTime(). Just as an example: long now = System.currentTimeMillis(); Date date = new java.util.Date(now); Date ts = new java.sql.Timestamp(now); ObjectUtils.equals(date, ts) = false; (as of 2.1) DateUtils.equals(date, ts) = true; Anyone have a different idea or think this is a bad idea? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] -- Todd V. Jonker Conscious Code Ltd The Practice of Programming www.consciouscode.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
Michael Heuer wrote: On Mon, 16 Feb 2004, Stephen Colebourne wrote: The point is that maven keep changing their mind. First came classic blue top Second came white top, big font, red section titles Third (current) is white top, good left, but ridiculous section titles see http://maven.apache.org We need to divorce ourselves from this. The current project.css only works against the xdoc 1.4 plugin. snip This may be a bit drastic, but commons could define its own site.jsl file (originally copied from the appropriate version of the xdoc plugin) and use the property maven.xdoc.jsl=.../commons-site.jsl I don't think it's drastic but it will require consensus on the LF. I think if we do go this way we will need to have multiple LF's and have a vote to decide on the best one. BTW, great work by you guys on this already. My maven skills are limited but if someone needs some help on some of this, give me a shout. -John K michael - 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: [PATCH][logging] Patches for the mavenized website
committed. many thanks. you won't see any differences on the main website yet because i'm trying to refrain from regenerating right now (i'm using a very of maven that produces a different LF from the rest). - robert On 15 Feb 2004, at 19:15, Dennis Lundberg wrote: Here are some patches for the mavenized website. Here's what has been done: * Corrected spelling and made some clarifications * Updated the links to Log4J and Avalon LogKit, to their new location * Includes the navigation-file from the new commons-build directory * Removed duplicate logo-tag from project.xml -- Dennis Lundberg Index: project.xml === RCS file: /home/cvspublic/jakarta-commons/logging/project.xml,v retrieving revision 1.11 diff -u -r1.11 project.xml --- project.xml 15 Feb 2004 09:38:22 - 1.11 +++ project.xml 15 Feb 2004 19:01:31 - @@ -4,7 +4,6 @@ extend../commons-build/project.xml/extend nameLogging/name idcommons-logging/id - logo/logo currentVersion1.0-dev/currentVersion organization @@ -16,7 +15,7 @@ inceptionYear2001/inceptionYear shortDescriptionCommons Logging/shortDescription description -Commons Logging is a thin adapter allowing configurable bridging to other, +Commons Logging is a thin adapter allowing configurable bridging to other, well known logging systems. /description @@ -51,7 +50,7 @@ /developer developer nameScott Sanders/name - idsanders/id + idsanders/id emailsanders at apache dot org/email organizationApache Software Foundation/organization /developer Index: xdocs/guide.xml === RCS file: /home/cvspublic/jakarta-commons/logging/xdocs/guide.xml,v retrieving revision 1.1 diff -u -r1.1 guide.xml --- xdocs/guide.xml 15 Feb 2004 10:28:56 - 1.1 +++ xdocs/guide.xml 15 Feb 2004 19:03:21 - @@ -13,7 +13,7 @@ p The Jakarta Commons Logging (JCL) provides a Log interface that is intended to be both light-weight and independent of numerous logging toolkits. -It provides the middleware/tooling developer a simple +It provides the middleware/tooling developer with a simple logging abstraction, that allows the user (application developer) to plug in a specific logging implementation. /p @@ -25,8 +25,8 @@ p The Jakarta Commons Logging provides a Log interface with thin-wrapper implementations for other logging tools, including -a href=http://jakarta.apache.org/log4j/docs/index.html;Log4J/a, -a href=http://jakarta.apache.org/avalon/logkit/index.html;Avalon LogKit/a, +a href=http://logging.apache.org/log4j/docs/index.html;Log4J/a, +a href=http://avalon.apache.org/logkit/index.html;Avalon LogKit/a, and aJDK 1.4/a. The interface maps closely to Log4J and LogKit. @@ -35,7 +35,7 @@ /section section name=Users Quick Start p -As far as possible, emCommons-Logging/em tries to be as unobtrusive as possible. +As far as possible, emCommons-Logging/em tries to be as unobtrusive as possible. In most cases, including the (full) codecommons-logging.jar/code in the classpath should result in emCommons-Logging/em configuring itself in a reasonable manner. There's a good chance that it'll guess your preferred logging system and you won't @@ -43,10 +43,10 @@ /p subsection name='Configuration' p -There are two base abstractions used by emCommons-Logging/em: codeLog/code +There are two base abstractions used by emCommons-Logging/em: codeLog/code (the basic logger) and codeLogFactory/code (which knows how to create codeLog/code -instances). Using codeLogFactory/code implementations other than the default is a -subject for advanced users only, so let's concentrate on configuring the default +instances). Using codeLogFactory/code implementations other than the default is a +subject for advanced users only, so let's concentrate on configuring the default implementation. /p p @@ -104,7 +104,7 @@ /code /ul p -Note that some components using commons-logging may +Note that some components using commons-logging may either extend Log, or provide a component-specific LogFactory implementation. Review the component documentation for guidelines @@ -165,7 +165,7 @@ /ul subsection name='Best Practices' p -Best practices for programming/planning are presented in two categories: +Best practices for programming/planning are presented in two categories: General and Enterprise. The general principles are fairly clear. Enterprise practices are a bit more involved and it is not always as clear as to why they are important. @@ -187,7 +187,7 @@ that otherwise introduces undesirable runtime overhead in the general case (logging disabled). Examples are multiple parameters, or expressions (i.e. string + more) for parameters. -Use the guard methods of the form
Re: [all] maven sites
Michael Heuer wrote: On Mon, 16 Feb 2004, Stephen Colebourne wrote: The point is that maven keep changing their mind. First came classic blue top Second came white top, big font, red section titles Third (current) is white top, good left, but ridiculous section titles see http://maven.apache.org We need to divorce ourselves from this. The current project.css only works against the xdoc 1.4 plugin. snip This may be a bit drastic, but commons could define its own site.jsl file (originally copied from the appropriate version of the xdoc plugin) and use the property maven.xdoc.jsl=.../commons-site.jsl I would recommend we do this, but with the intention of switching over to the theme property once the next release of Maven roles out. Basically this means copying the site.jsl off the maven xdoc cvs head and using our own css to define our theme, once the next maven release roles out. We can just drop our copy of the site.jsl and work specifically with our themed css. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon KEYS
jfclere 2004/02/16 14:35:31 Modified:daemon KEYS Log: upgrade my key. Revision ChangesPath 1.2 +22 -14jakarta-commons/daemon/KEYS Index: KEYS === RCS file: /home/cvs/jakarta-commons/daemon/KEYS,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- KEYS 9 Oct 2003 15:05:41 - 1.1 +++ KEYS 16 Feb 2004 22:35:31 - 1.2 @@ -14,11 +14,11 @@ Type Bits/KeyIDDate User ID pub 1024D/86867BA6 2001-11-22 Jean-Frederic Clere (jfclere) [EMAIL PROTECTED] + -BEGIN PGP PUBLIC KEY BLOCK- -Version: GnuPG v1.0.5 (GNU/Linux) -Comment: For info see http://www.gnupg.org - +Version: GnuPG v1.3.3 (GNU/Linux) + mQGiBDv9Gx8RBADclmKwDLcibNVipQnhYW+bFIpuQjQnRrqRwn3gXM+/luzzJYJ4 bbWpw13zjX0EkrAJ8qH2A/d0EIU1eZ0zHrLgRvMUfLGFUX7FFFw18JKFLTVGhG4/ 8sSl3ydHSA2Kd1PF6xjBP7iM7sg5dJfEkyMzvK5H4F0ZpTqy3087wsg1wwCgitRy @@ -29,15 +29,23 @@ LCxTbfgA5htpI8U7vPR9/5gH7U8Wy3HR6xQUZxcbttMeYit2VbDEJzF5r5S0pJvD vyk3n1kiKU7r49sjhxGgE8J/VvDpO6YcIsDs8LoULwuJTg0DTrRDSmVhbi1GcmVk ZXJpYyBDbGVyZSAoamZjbGVyZSkgPEpGcmVkZXJpYy5DbGVyZUBmdWppdHN1LXNp -ZW1lbnMuY29tPohXBBMRAgAXBQI7/RsfBQsHCgMEAxUDAgMWAgECF4AACgkQ0+/m -toaGe6amGQCeJU5VZ8QCi8+PY0QJHPA63e5uPyoAmgOWIwFm8A/xmW8qjEvVAWtb -TjZxuQENBDv9GyMQBACCbFlSF+udW/Qz2oknDen8Hoql4Q1Q7CUQTbPjoQAcYgZg -LrsR6hc9aCIf3Kt4qZBgQ1Oe9M/AemOFhU04UNp3dgHk91EYRvx80Rua992p/8V7 -QOhwIBVb2XE8as5nL2j8w6Jz7eSs/bivxm9yD0AH/I5H01RAJivRbOTsUgSkDwAD -BQP5ARlW2Nqc0U17asQsmMYvT1UMiOiyBwUD/DIEG2Xy1hlEvdljg8WU26jcjpGq -MrT69T4Z+eZ2oVyiRQTW4qMUBKc0Nbz89hL0qv9K41ExxxH+JgE1csRVvmwAT8Iy -lnhof7TJLRBtvan3+p21Kxl1uQ7MbmLT875u+vc+J098fIiIRgQYEQIABgUCO/0b -IwAKCRDT7+a2hoZ7pn9UAJ9f0TK0QQOtjQBvxAissopYhDKHGACePZg0k9sj69yw -nVWrBS9fvFC9jcA= -=BTiM +ZW1lbnMuY29tPohGBBARAgAGBQJAEVHcAAoJEFd7hHVGA0DQsUsAoK2SuAnTybek +AJkFmei/kbv59fA+AJ4/smxUz6EGuNmWOYwnHTxPz09c4IhXBBMRAgAXBQI7/Rsf +BQsHCgMEAxUDAgMWAgECF4AACgkQ0+/mtoaGe6amGQCeJU5VZ8QCi8+PY0QJHPA6 +3e5uPyoAmgOWIwFm8A/xmW8qjEvVAWtbTjZxiJwEEwECAAYFAj/F+7gACgkQN+P0 +X+5l4yHDEwQAwp2yr9mwHIti5D2tvgNDQjOw9K/qbGbQ1IH3f/BLF0J5EHxYxUSt +E0glh8GPJOi1U+0Jv999W/8xnOs5Tf16d0DmhscXvylxWYGis1PcoqA2zemaWuVM +nBoJaA89gPiwconEEvdxym7vBGK1Lodz+ote2doiuCsWSjcfl74LFxeInAQTAQIA +BgUCP8dbpwAKCRArAsNF4kSQGcqYA/9ZkL7Uwy1xZ8EPAQT6eXVCmS743C3Mc2kr +Cv8CEnsVNQrsQMYzkU2OjsJ09semmIHnvpx14i8cGlLRoKpfNn7V+O6wmMEHr2zn +HlMtDsgvk8FK12cDGGxUlHr9sz6wOTQyZG3bNLA9iQPUlHAjTTZlISx55i3/opKQ +yI5LzOMaSrkBDQQ7/RsjEAQAgmxZUhfrnVv0M9qJJw3p/B6KpeENUOwlEE2z46EA +HGIGYC67EeoXPWgiH9yreKmQYENTnvTPwHpjhYVNOFDad3YB5PdRGEb8fNEbmvfd +qf/Fe0DocCAVW9lxPGrOZy9o/MOic+3krP24r8Zvcg9AB/yOR9NUQCYr0Wzk7FIE +pA8AAwUD+QEZVtjanNFNe2rELJjGL09VDIjosgcFA/wyBBtl8tYZRL3ZY4PFlNuo +3I6RqjK0+vU+GfnmdqFcokUE1uKjFASnNDW8/PYS9Kr/SuNRMccR/iYBNXLEVb5s +AE/CMpZ4aH+0yS0Qbb2p9/qdtSsZdbkOzG5i0/O+bvr3PidPfHyIiEYEGBECAAYF +Ajv9GyMACgkQ0+/mtoaGe6Z/VACfX9EytEEDrY0Ab8QIrLKKWIQyhxgAnj2YNJPb +I+vcsJ1VqwUvX7xQvY3A +=6E4I -END PGP PUBLIC KEY BLOCK- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Enhancing CallMethodRule to take target offset
On 16 Feb 2004, at 21:33, Simon Kitching wrote: snip I'm not sure how your named stacks idea differs from this. Can you describe how it would be used? the idea is that rather than having just a single object stored for each name, stacks (identified by name) are used instead. this allows nested rules to push and pop in additional to allowing flat rules to communicate by using a single object on the stack. you'd have signatures something like: void push(String stackName, Object value) Object peek(String stackName) Object pop(String stackName) this is a more general form which includes the functionality of the hash map (rules just use a one-deep stack) but also allows more complex communication. And sorry, but I didn't understand your suggestion about partial mapping at all! maybe i'll explain it better some other time. (it's a little involved.) NB: I still think that a Digester 1.6 release should come before new work like this. There's no reason a Digester 1.7 couldn't be done on a much shorter cycle than the last one. i agree - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] release (was attribute substitution/variable expansion)
i think that craig has already handled this. - robert On 16 Feb 2004, at 21:38, David Graham wrote: Any chance the commons-collections usage can be removed for this release? This was brought up earlier and seemed to be supported. The last I checked digester made a very minimal use of commons-collections anyways. Other packages using digester don't need collections and it's a rather big dependency to carry around in addition to the recent 3.0 incompatible changes. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] release (was attribute substitution/variable expansion)
On 16 Feb 2004, at 21:53, Simon Kitching wrote: snip Robert, what are the plans for the next BeanUtils release? Should we delay the next Digester release until then? beanutils is pretty much in the same boat as digester. (i've cut the last few releases but i'm not willing to cut any more.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] release (was attribute substitution/variable expansion)
On 16 Feb 2004, at 21:53, Simon Kitching wrote: snip We still depend on BeanUtils, and BeanUtils currently depends on collections. Unless we wait for BeanUtils to make a new collections-independent release, we can't completely rid digester of the collections jar. when craig or get some time, i expect that the dependency from beanutils will also be removed (or at least factored into an optional package). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/project-template project.properties
bayard 2004/02/16 14:45:57 Modified:project-template project.properties Log: added the properties from discovery for the asf repo Revision ChangesPath 1.2 +5 -0 jakarta-commons-sandbox/project-template/project.properties Index: project.properties === RCS file: /home/cvs/jakarta-commons-sandbox/project-template/project.properties,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.properties16 Feb 2004 20:30:02 - 1.1 +++ project.properties16 Feb 2004 22:45:57 - 1.2 @@ -6,6 +6,11 @@ maven.test.failure = false maven.xdoc.poweredby.image=maven-feather.png +# apache maven repository information +maven.repo.central=www.apache.org +maven.repo.central.directory=/www/www.apache.org/dist/java-repository +maven.remote.group=apcvs + #If you wish to skip tests when doing builds, uncomment #maven.test.skip = true maven.junit.fork=true - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
Stephen Colebourne [EMAIL PROTECTED] wrote on 17/02/2004 08:14:21 AM: The point is that maven keep changing their mind. First came classic blue top Second came white top, big font, red section titles Third (current) is white top, good left, but ridiculous section titles see http://maven.apache.org We need to divorce ourselves from this. The current project.css only works against the xdoc 1.4 plugin. I agree we need to use our own stylesheet, and not rely on Maven's. FWIW, the 'Third' above is simply a buggy version of the second. -- dIon Gillard, Multitask Consulting
[commons-build] Menus (was Re: [all] maven sites)
I'm somewhat baffled why there are all these menu xdocs inside thestylesheet directory http://cvs.apache.org/viewcvs.cgi/jakarta-commons/commons-build/xdocs/stylesheets/menus/ plus stylesheets needs to be changed to style to be recognized in rc1. -Mark I agree we need to use our own stylesheet, and not rely on Maven's. FWIW, the 'Third' above is simply a buggy version of the second. -- dIon Gillard, Multitask Consulting -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] default values
John Keyes wrote:
One of the failing unit tests on the ROXSPRING branch was the
testWithOption method on CommandLineDefaultsTests. The reason
it failed was the default value set during Option construction
was not accessible to CommandLine.getValue. So to make this
information accessible I propose we add a getArgument method to
Parent and getDefaults to Argument. To see if any default
during construction we simply do:
if (option instanceof Parent) {
Argument arg = ((Parent) option).getArgument();
List defaults = arg.getDefaults();
}
Did you have a different idea about how to resolve this Rob?
Yeah - I had half a plan last week but didn't get around to sending the
email...
My main reason for writing the CommandLineDefaultsTest was that I felt
the combination of 4 different ways to specify defaults was confusing.
Last week I thought we could reduce this to 3 but tonight I'm thinking
that 2 might be a possibility. Here are the 4 sources as they stand (or
as I understand them):
A. Specified at interrogation time (using the overloaded accessor
methods in CommandLine)
B. CommandLine chains using push/set/addDefaultCommandLine(..)
C. Defaults instances from properties and preferences
D. Specified at option construction time:
argumentBuilder.withDefault(Object)
A is a very simple and intuitive way for people to get the values they
expect without involving themselves with the alternative systems. I'd
like to keep this mechanism as it is.
I think B C should be combined into a single mechanism. They both
appear to be tackling the same basic problem - applying defaults
independantly of interrogation and option construction. B has two main
advantages that I can see; the first is that by using CommandLine as the
vehicle it opens the door to supplying defaults for non-arguments
(on/off for switches and potentially presence for simple Command /
DefaultOpitions). B's second advantage is that the chain of objects
allows a customisable precedence order to be set for defaults (think
user vs project vs system vs site defaults). Of course the huige
advantage of C is that implementations exist for Properties and
Preferences. I propose we build a new DefaultingCommandLine
implementation of CommandLine that simply manages and delegates to a
List of CommandLine instances; this would mean that we can simplify the
CommandLine interface to not have the add/set/pushDefaultCommandLine
methods. Then we convert the Defaults implementations into simple
CommandLine implementations, supply defaults for non-arguments in 2.1 or
later. This would allow a more flexible system with at least the
current functionality and less overall complexity (IMO).
If we go the route mentioned above then fitting in the construction-time
defaults might be a little difficult. An approach that occured to me
tonight is that we could add a new method to Option along the lines of
defaults(WriteableCommandLine) that would implement the same structure
walking as process(..) but us used simply to build a
WriteableCommandLine of the construction time defaults.
These in combination allow the user's experience of defaults to be
reduced to three mechanisms A, B/C, D while the code would be pretty
much simplified to two A, B/C/D.
Make sense? over ambitious? or plain missing the point? - thoughts welcome!
Rob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build commons-site.jsl project.properties
mdiggory2004/02/16 15:26:32
Modified:commons-build project.properties
Added: commons-build commons-site.jsl
Log:
Theme'd Maven style without needing to upgrade xdoc plugin.
Revision ChangesPath
1.3 +5 -1 jakarta-commons/commons-build/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/commons-build/project.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- project.properties16 Feb 2004 19:00:43 - 1.2
+++ project.properties16 Feb 2004 23:26:32 - 1.3
@@ -16,3 +16,7 @@
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
maven.xdoc.poweredby.image=maven-feather.png
+
+# this jsl provides the basic theme capabilities of the xdoc plugin version 1.5
+# once maven rc2 is out we can throw this away.
+maven.xdoc.jsl=${basedir}/commons-site.jsl
\ No newline at end of file
1.1 jakarta-commons/commons-build/commons-site.jsl
Index: commons-site.jsl
===
?xml version=1.0?
!-- stylesheet to be used --
jsl:stylesheet select=$doc
xmlns:define=jelly:define
xmlns:j=jelly:core
xmlns:jsl=jelly:jsl
xmlns:log=jelly:log
xmlns:util=jelly:util
xmlns:x=jelly:xml
xmlns:doc=doc
xmlns:maven=jelly:maven
xmlns=dummy
trim=true
jsl:template match=document trim=true
j:useBean var=navbean class=org.apache.maven.NavBean/
j:set var=location value=${outFile.substring(destdir.length())}/
util:replace var=location oldChar=\ newChar=/ value=${location}/
!-- Stores location for publish date / version --
j:set var=date${maven.xdoc.date}/j:set
j:setProperties object=${navbean} document=${doc} location=${location}/
x:doctype name=html publicId=-//W3C//DTD XHTML 1.0 Transitional//EN
systemId=http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd/
html
head
j:set var=docTitlex:expr select=./properties/title//j:set
x:if select=$nav/title
titlex:expr select=$nav/title/ - ${docTitle}/title
/x:if
x:if select=not($nav/title)
title${pom.name} - ${docTitle}/title
/x:if
j:set var=themeUrl value=${maven.xdoc.theme.url}/
util:file var=projectCssFile name=${maven.docs.src}/style/project.css/
style type=text/css media=all![CDATA[
@import url(${relativePath}/style/maven-base.css);
]]
j:if test=${!empty(themeUrl)}![CDATA[
@import url(${maven.xdoc.theme.url});
]]/j:if
j:if test=${empty(themeUrl)}![CDATA[
@import
url(${relativePath}/style/maven-theme.css);
]]/j:if
j:if test=${projectCssFile.exists()}![CDATA[
@import url(${relativePath}/style/project.css);
]]/j:if
/style
link rel=stylesheet type=text/css
href=${relativePath}/style/print.css media=print/
meta http-equiv=Content-Type content=text/html;
charset=${outputencoding}/
x:forEach var=author select=./properties/author
meta name=author content=${author.text}/
meta name=email content=${author.attribute('email').value}/
/x:forEach
jsl:applyTemplates select=$doc/document/head/*/
/head
x:element name=bodyj:whitespace trim=true
x:attribute name=classcomposite/x:attribute
x:forEach var=attr select=$doc/document/body/@*
x:attribute name=${attr.name}${attr.value}/x:attribute
/x:forEach
/j:whitespace
div id=banner
!-- organization logo --
j:set var=logo value=${pom.organization.logo}/
j:if test=${!empty(logo)}
!-- set url to org or project url --
j:set var=url value=${pom.organization.url}/
j:if test=${!empty(url)}
j:set var=home value=${pom.organization.url}/
/j:if
j:if test=${empty(url)}
j:set var=home value=${pom.url}/
/j:if
!-- set image to relative or complete --
j:set var=image value=${pom.organization.logo}/
j:if test=${!image.startsWith('http://') and
!image.startsWith('https://')}
j:set
Re: [CLI] default values
Rob Oxspring wrote:
John Keyes wrote:
One of the failing unit tests on the ROXSPRING branch was the
testWithOption method on CommandLineDefaultsTests. The reason
it failed was the default value set during Option construction
was not accessible to CommandLine.getValue. So to make this
information accessible I propose we add a getArgument method to
Parent and getDefaults to Argument. To see if any default
during construction we simply do:
if (option instanceof Parent) {
Argument arg = ((Parent) option).getArgument();
List defaults = arg.getDefaults();
}
Did you have a different idea about how to resolve this Rob?
Yeah - I had half a plan last week but didn't get around to sending the
email...
My main reason for writing the CommandLineDefaultsTest was that I felt
the combination of 4 different ways to specify defaults was confusing.
Last week I thought we could reduce this to 3 but tonight I'm thinking
that 2 might be a possibility. Here are the 4 sources as they stand (or
as I understand them):
A. Specified at interrogation time (using the overloaded accessor
methods in CommandLine)
B. CommandLine chains using push/set/addDefaultCommandLine(..)
C. Defaults instances from properties and preferences
D. Specified at option construction time:
argumentBuilder.withDefault(Object)
I forgot about 'B' :-)
A is a very simple and intuitive way for people to get the values they
expect without involving themselves with the alternative systems. I'd
like to keep this mechanism as it is.
+1
I think B C should be combined into a single mechanism. They both
appear to be tackling the same basic problem - applying defaults
independantly of interrogation and option construction. B has two main
advantages that I can see; the first is that by using CommandLine as the
vehicle it opens the door to supplying defaults for non-arguments
(on/off for switches and potentially presence for simple Command /
DefaultOpitions). B's second advantage is that the chain of objects
allows a customisable precedence order to be set for defaults (think
user vs project vs system vs site defaults). Of course the huige
advantage of C is that implementations exist for Properties and
Preferences. I propose we build a new DefaultingCommandLine
implementation of CommandLine that simply manages and delegates to a
List of CommandLine instances; this would mean that we can simplify the
CommandLine interface to not have the add/set/pushDefaultCommandLine
methods. Then we convert the Defaults implementations into simple
CommandLine implementations, supply defaults for non-arguments in 2.1 or
later. This would allow a more flexible system with at least the
current functionality and less overall complexity (IMO).
Sounds good. That would tidy it up very nicely.
If we go the route mentioned above then fitting in the construction-time
defaults might be a little difficult. An approach that occured to me
tonight is that we could add a new method to Option along the lines of
defaults(WriteableCommandLine) that would implement the same structure
walking as process(..) but us used simply to build a
WriteableCommandLine of the construction time defaults.
That's a neat idea.
These in combination allow the user's experience of defaults to be
reduced to three mechanisms A, B/C, D while the code would be pretty
much simplified to two A, B/C/D.
Make sense? over ambitious? or plain missing the point? - thoughts welcome!
Haha, if I got to this stage and said 'plain missing the point'
you'd be slightly peeved.
-John K
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24880] - Feature request : create Options from XML file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24880. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24880 Feature request : create Options from XML file [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-02-17 00:33 --- *** This bug has been marked as a duplicate of 24048 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24048] - XML 2 CLI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24048. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24048 XML 2 CLI [EMAIL PROTECTED] changed: What|Removed |Added CC||jakarta- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-17 00:33 --- *** Bug 24880 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10543] - generate ant task automatically from CLI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10543. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10543 generate ant task automatically from CLI [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||24048 Target Milestone|--- |2.1 Final --- Additional Comments From [EMAIL PROTECTED] 2004-02-17 00:35 --- Should be pretty easy if we have an xml representation to go from - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24048] - XML 2 CLI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24048. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24048 XML 2 CLI [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||10543 nThis|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24036] - Interrogation using switch statement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24036. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24036 Interrogation using switch statement [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |2.1 Beta 1 --- Additional Comments From [EMAIL PROTECTED] 2004-02-17 00:45 --- The code is there in CLI2 just waiting for release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang ObjectUtilsTest.java
ggregory2004/02/16 16:55:57
Modified:lang/src/test/org/apache/commons/lang ObjectUtilsTest.java
Log:
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26922
[lang] public static boolean DateUtils.equals(Date dt1, Date dt2) ?
Updated testDateEqualsJava(): The behavior is different b/w Sun Java 1.3.1_10 and
1.4.2_03.
Revision ChangesPath
1.11 +34 -9
jakarta-commons/lang/src/test/org/apache/commons/lang/ObjectUtilsTest.java
Index: ObjectUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/ObjectUtilsTest.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ObjectUtilsTest.java 16 Feb 2004 23:39:03 - 1.10
+++ ObjectUtilsTest.java 17 Feb 2004 00:55:57 - 1.11
@@ -60,7 +60,6 @@
import junit.framework.TestCase;
import junit.framework.TestSuite;
import junit.textui.TestRunner;
-import org.apache.commons.lang.time.DateUtils;
/**
* Unit tests [EMAIL PROTECTED] org.apache.commons.lang.ObjectUtils}.
@@ -125,17 +124,43 @@
/**
* Show that java.util.Date and java.sql.Timestamp are apples and oranges.
- * Prompted by an email discussion.
+ * Prompted by an email discussion.
+ *
+ * The behavior is different b/w Sun Java 1.3.1_10 and 1.4.2_03.
*/
-public void testDateEquals() {
+public void testDateEqualsJava() {
long now = 1076957313284L; // Feb 16, 2004 10:49... PST
java.util.Date date = new java.util.Date(now);
-java.util.Date timestamp = new java.sql.Timestamp(now);
-// sanity check:
-assertFalse(date.getTime() == timestamp.getTime());
-assertFalse(timestamp.equals(date));
+java.sql.Timestamp realTimestamp = new java.sql.Timestamp(now);
+java.util.Date timestamp = realTimestamp;
+// sanity check 1:
+assertEquals(28400, realTimestamp.getNanos());
+assertEquals(1076957313284L, date.getTime());
+//
+// On Sun 1.3.1_10:
+//junit.framework.AssertionFailedError: expected:1076957313284 but
was:1076957313000
+//
+//assertEquals(1076957313284L, timestamp.getTime());
+//
+//junit.framework.AssertionFailedError: expected:1076957313284 but
was:1076957313000
+//
+//assertEquals(1076957313284L, realTimestamp.getTime());
+// sanity check 2:
+assertEquals(date.getDay(), realTimestamp.getDay());
+assertEquals(date.getHours(), realTimestamp.getHours());
+assertEquals(date.getMinutes(), realTimestamp.getMinutes());
+assertEquals(date.getMonth(), realTimestamp.getMonth());
+assertEquals(date.getSeconds(), realTimestamp.getSeconds());
+assertEquals(date.getTimezoneOffset(), realTimestamp.getTimezoneOffset());
+assertEquals(date.getYear(), realTimestamp.getYear());
+//
+// Time values are == and equals() on Sun 1.4.2_03 but NOT on Sun 1.3.1_10:
+//
+//assertFalse(Sanity check failed: date.getTime() == timestamp.getTime(),
date.getTime() == timestamp.getTime());
+//assertFalse(Sanity check failed: timestamp.equals(date),
timestamp.equals(date));
+//assertFalse(Sanity check failed: date.equals(timestamp),
date.equals(timestamp));
// real test:
-assertFalse(ObjectUtils.equals(date, timestamp));
+//assertFalse(java.util.Date and java.sql.Timestamp should be equal,
ObjectUtils.equals(date, timestamp));
}
public void testIdentityToString() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Using FindBugs Maven plugin?
For some reason, I cannot the Maven plugin cannot find its jars: (1) Create a build.properties in my local [lang] root with: maven.repo.remote = http://maven-plugins.sf.net (2) From my local [lang] root, run: maven -DartifactId=maven-findbugs-plugin -Dversion=1.0-SNAPSHOT -DgroupId=maven plugin:download Which gives me on the console: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT plugin:download: [echo] repo is 'http://maven-plugins.sf.net' [echo] Plugin downloaded, removing other versions [delete] Deleting 11 files from C:\Documents and Settings\ggregory\.maven\plugins [delete] Deleted 5 directories from C:\Documents and Settings\ggregory\.maven\plugins BUILD SUCCESSFUL Total time: 3 seconds Finished at: Mon Feb 16 16:58:01 PST 2004 (3) Add a reports entry to project.xml: Index: project.xml === retrieving revision 1.28 diff -u -r1.28 project.xml --- project.xml 14 Feb 2004 01:16:24 - 1.28 +++ project.xml 17 Feb 2004 00:59:38 - @@ -297,7 +297,8 @@ !-- reportmaven-changelog-plugin/report -- !-- reportmaven-changes-plugin/report -- reportmaven-checkstyle-plugin/report - !-- reportmaven-clover-plugin/report -- + reportmaven-findbugs-plugin/report + reportmaven-clover-plugin/report !-- reportmaven-developer-activity-plugin/report -- !-- reportmaven-file-activity-plugin/report -- reportmaven-javadoc-plugin/report (4) Run maven: maven site:generate __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT Attempting to download findbugs-0.6.5.jar. WARNING: Failed to download findbugs-0.6.5.jar. Attempting to download findbugs-ant-0.6.5.jar. WARNING: Failed to download findbugs-ant-0.6.5.jar. Attempting to download findbugs-coreplugin-0.6.5.jar. WARNING: Failed to download findbugs-coreplugin-0.6.5.jar. Attempting to download findbugs-bcel-0.6.5.jar. WARNING: Failed to download findbugs-bcel-0.6.5.jar. Attempting to download dom4j-1.4.jar. WARNING: Failed to download dom4j-1.4.jar. BUILD FAILED File.. file:/C:/Documents and Settings/ggregory/.maven/plugins/maven-xdoc-plugin-1.4/ Element... attainGoal Line.. 575 Column 48 The build cannot continue because of the following unsatisfied dependencies: findbugs-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-ant-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-coreplugin-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-bcel-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) dom4j-1.4.jar (no download url specified) Total time: 6 seconds Finished at: Mon Feb 16 17:00:01 PST 2004 :-( Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 16:17 To: Jakarta Commons Developers List Subject: Re: [lang] Using FindBugs Maven plugin? Its can be a useful part of the process in [lang]. We used it last time. Stephen - Original Message - From: Gary Gregory [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, February 16, 2004 11:57 PM Subject: [lang] Using FindBugs Maven plugin? Any thoughts on using the FindBugs Maven plugin? A good patch was submitted base on FindBugs (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26961) From FindBugs: http://www.cs.umd.edu/~pugh/java/bugs/ It is free software, distributed under the terms of the Lesser GNU Public License. FindBugs requires JRE (or JDK) 1.4.0 or later to run. However, it can analyze programs compiled for any version of Java. Maven plugin: http://maven-plugins.sourceforge.net/maven-findbugs-plugin/index.html Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build project.css
scolebourne2004/02/16 17:13:41
Added: commons-build project.css
Log:
Initial CVS checkin
Revision ChangesPath
1.1 jakarta-commons/commons-build/project.css
Index: project.css
===
/* == */
/* XDOC 1.4 */
#banner, #banner td {
background: #fff;
color: #000;
border: 0px;
}
#banner td {
height: 100%;
vertical-align: middle;
}
div#banner {
border: 0px;
}
#bodycol h3 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #aaf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: bold;
}
#bodycol h4 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #ccf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: normal;
}
.app h3, .app h4, .tabs td, .tabs th, .functnbar {
background-image: none;
}
/* == */
/* XDOC 1.5 */
/* Controls font size on left */
body, td, th, select, input, li{
font-family: Verdana, Helvetica, Arial, sans-serif;
font-size: 13px;
}
/* Logo position */
#organizationLogo img, #projectLogo img {
position: static;
clear: both;
}
#organizationLogo img {
margin-top: 20px;
}
#projectLogo img {
margin-top: 5px;
}
/* Hyperlinks */
a {
text-decoration: none;
}
a:link {
color:#44f;
}
a:visited {
color:#47a;
}
#navcolumn a:visited, #breadcrumbs a:visited {
color:#44f;
}
a:active, a:hover {
color:#69c;
}
/* Titles */
h2 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #aaf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: bold;
}
h3 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #ccf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: normal;
}
#bodycolumn p, #bodycolumn ul, #bodycolumn ol, #bodycolumn dl, #bodycolumn table {
margin-top: .67em;
margin-bottom: .67em;
font-size: 13px;
}
#breadcrumbs {
border-top: 1px solid #aaa;
border-bottom: 1px solid #aaa;
background-color: #ccc;
}
#leftColumn {
margin: 0 0 0 0;
width: 19%;
border-right: 1px solid #999;
border-bottom: 1px solid #999;
background-color: #eee;
}
#navcolumn h5 {
font-size: smaller;
border-bottom: 1px solid #aa;
padding-top: 2px;
}
table.bodyTable {
border: 1px solid #000;
}
table.bodyTable th {
color: white;
background-color: #bbb;
text-align: left;
font-weight: bold;
}
table.bodyTable tr.a {
background-color: #ddd;
}
table.bodyTable tr.b {
background-color: #eee;
}
.source {
border: 1px solid #999;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
I have added a project.css file to the common-build area. It can be used as a theme file or whatever, and should produce reasonably similar results using both the 1.4 and 1.5 xdoc plugin. (Getting a similar result is difficult as everything has changed and the combination of technologies just ain't fun) However, I should point out that the 1.5 plugin is buggy wrt tables on IE5.5. Stephen This may be a bit drastic, but commons could define its own site.jsl file (originally copied from the appropriate version of the xdoc plugin) and use the property maven.xdoc.jsl=.../commons-site.jsl I would recommend we do this, but with the intention of switching over to the theme property once the next release of Maven roles out. Basically this means copying the site.jsl off the maven xdoc cvs head and using our own css to define our theme, once the next maven release roles out. We can just drop our copy of the site.jsl and work specifically with our themed css. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Using FindBugs Maven plugin?
Gary Gregory [EMAIL PROTECTED] wrote on 17/02/2004 12:02:42 PM: For some reason, I cannot the Maven plugin cannot find its jars: (1) Create a build.properties in my local [lang] root with: maven.repo.remote = http://maven-plugins.sf.net Don't use maven-plugins.sf.net as the remote repo. It's not a repository. (2) From my local [lang] root, run: [snip] BUILD SUCCESSFUL (3) Add a reports entry to project.xml: [snip] (4) Run maven: [snip] The build cannot continue because of the following unsatisfied dependencies: findbugs-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-ant-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-coreplugin-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-bcel-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) dom4j-1.4.jar (no download url specified) These are because you have changed your remote repo to a URL that isn't a repo. -- dIon Gillard, Multitask Consulting
RE: [lang] Using FindBugs Maven plugin?
Don't use maven-plugins.sf.net as the remote repo. It's not a repository. Ah, I see, so the directions on their site is not right since this where I got the info: http://maven-plugins.sourceforge.net/installing.html Thanks, Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 17:27 To: Jakarta Commons Developers List Subject: RE: [lang] Using FindBugs Maven plugin? Gary Gregory [EMAIL PROTECTED] wrote on 17/02/2004 12:02:42 PM: For some reason, I cannot the Maven plugin cannot find its jars: (1) Create a build.properties in my local [lang] root with: maven.repo.remote = http://maven-plugins.sf.net Don't use maven-plugins.sf.net as the remote repo. It's not a repository. (2) From my local [lang] root, run: [snip] BUILD SUCCESSFUL (3) Add a reports entry to project.xml: [snip] (4) Run maven: [snip] The build cannot continue because of the following unsatisfied dependencies: findbugs-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-ant-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-coreplugin-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) findbugs-bcel-0.6.5.jar (try downloading from http://www.cs.umd.edu/~pugh/java/bugs/) dom4j-1.4.jar (no download url specified) These are because you have changed your remote repo to a URL that isn't a repo. -- dIon Gillard, Multitask Consulting
Re: [all] maven sites
This should be placed into commons-build/xdocs/style/project.css which
will make it automatically included into the maven site generation.
As well, I've also added the following to commons-build
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/commons-build/commons-site.jsl
and the follwoing line to project.properties
maven.xdoc.jsl=${basedir}/commons-site.jsl
this should default the site generation to use our jsl and theme.
We can also add any theme customization (both tot he global site and
to any subprojects that want to create thier own customization)
maven.xdoc.theme.url=...
This will point to the actuall url of teh css on the web server.
-Mark
Stephen Colebourne wrote:
I have added a project.css file to the common-build area. It can be used as
a theme file or whatever, and should produce reasonably similar results
using both the 1.4 and 1.5 xdoc plugin. (Getting a similar result is
difficult as everything has changed and the combination of technologies just
ain't fun)
However, I should point out that the 1.5 plugin is buggy wrt tables on
IE5.5.
Stephen
This may be a bit drastic, but commons could define its own site.jsl
file
(originally copied from the appropriate version of the xdoc plugin) and
use the property
maven.xdoc.jsl=.../commons-site.jsl
I would recommend we do this, but with the intention of switching over
to the theme property once the next release of Maven roles out.
Basically this means copying the site.jsl off the maven xdoc cvs head
and using our own css to define our theme, once the next maven release
roles out. We can just drop our copy of the site.jsl and work
specifically with our themed css.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/style - New directory
mdiggory2004/02/16 18:26:19 jakarta-commons/xdocs/style - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/style project.css
mdiggory2004/02/16 18:26:21
Added: xdocs/style project.css
Log:
Moving project.css to style directory.
Revision ChangesPath
1.1 jakarta-commons/xdocs/style/project.css
Index: project.css
===
/* == */
/* XDOC 1.4 */
#banner, #banner td {
background: #fff;
color: #000;
border: 0px;
}
#banner td {
height: 100%;
vertical-align: middle;
}
div#banner {
border: 0px;
}
#bodycol h3 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #aaf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: bold;
}
#bodycol h4 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #ccf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: normal;
}
.app h3, .app h4, .tabs td, .tabs th, .functnbar {
background-image: none;
}
/* == */
/* XDOC 1.5 */
/* Controls font size on left */
body, td, th, select, input, li{
font-family: Verdana, Helvetica, Arial, sans-serif;
font-size: 13px;
}
/* Logo position */
#organizationLogo img, #projectLogo img {
position: static;
clear: both;
}
#organizationLogo img {
margin-top: 20px;
}
#projectLogo img {
margin-top: 5px;
}
/* Hyperlinks */
a {
text-decoration: none;
}
a:link {
color:#44f;
}
a:visited {
color:#47a;
}
#navcolumn a:visited, #breadcrumbs a:visited {
color:#44f;
}
a:active, a:hover {
color:#69c;
}
/* Titles */
h2 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #aaf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: bold;
}
h3 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #ccf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: normal;
}
#bodycolumn p, #bodycolumn ul, #bodycolumn ol, #bodycolumn dl, #bodycolumn table {
margin-top: .67em;
margin-bottom: .67em;
font-size: 13px;
}
#breadcrumbs {
border-top: 1px solid #aaa;
border-bottom: 1px solid #aaa;
background-color: #ccc;
}
#leftColumn {
margin: 0 0 0 0;
width: 19%;
border-right: 1px solid #999;
border-bottom: 1px solid #999;
background-color: #eee;
}
#navcolumn h5 {
font-size: smaller;
border-bottom: 1px solid #aa;
padding-top: 2px;
}
table.bodyTable {
border: 1px solid #000;
}
table.bodyTable th {
color: white;
background-color: #bbb;
text-align: left;
font-weight: bold;
}
table.bodyTable tr.a {
background-color: #ddd;
}
table.bodyTable tr.b {
background-color: #eee;
}
.source {
border: 1px solid #999;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs/style project.css
mdiggory2004/02/16 18:41:02 Removed: xdocs/style project.css Log: Unsure how this got back outside the commons-build directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs/style - New directory
mdiggory2004/02/16 18:48:59 jakarta-commons/commons-build/xdocs/style - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs/style project.css
mdiggory2004/02/16 18:49:02
Added: commons-build/xdocs/style project.css
Log:
moving project.css into style directory
Revision ChangesPath
1.1 jakarta-commons/commons-build/xdocs/style/project.css
Index: project.css
===
/* == */
/* XDOC 1.4 */
#banner, #banner td {
background: #fff;
color: #000;
border: 0px;
}
#banner td {
height: 100%;
vertical-align: middle;
}
div#banner {
border: 0px;
}
#bodycol h3 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #aaf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: bold;
}
#bodycol h4 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #ccf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: normal;
}
.app h3, .app h4, .tabs td, .tabs th, .functnbar {
background-image: none;
}
/* == */
/* XDOC 1.5 */
/* Controls font size on left */
body, td, th, select, input, li{
font-family: Verdana, Helvetica, Arial, sans-serif;
font-size: 13px;
}
/* Logo position */
#organizationLogo img, #projectLogo img {
position: static;
clear: both;
}
#organizationLogo img {
margin-top: 20px;
}
#projectLogo img {
margin-top: 5px;
}
/* Hyperlinks */
a {
text-decoration: none;
}
a:link {
color:#44f;
}
a:visited {
color:#47a;
}
#navcolumn a:visited, #breadcrumbs a:visited {
color:#44f;
}
a:active, a:hover {
color:#69c;
}
/* Titles */
h2 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #aaf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: bold;
}
h3 {
padding: 4px 4px 4px 6px;
border: 1px solid #999;
color: #000;
background-color: #ccf;
margin-top: 2px;
margin-bottom: 4px;
font-size: 14px;
font-weight: normal;
}
#bodycolumn p, #bodycolumn ul, #bodycolumn ol, #bodycolumn dl, #bodycolumn table {
margin-top: .67em;
margin-bottom: .67em;
font-size: 13px;
}
#breadcrumbs {
border-top: 1px solid #aaa;
border-bottom: 1px solid #aaa;
background-color: #ccc;
}
#leftColumn {
margin: 0 0 0 0;
width: 19%;
border-right: 1px solid #999;
border-bottom: 1px solid #999;
background-color: #eee;
}
#navcolumn h5 {
font-size: smaller;
border-bottom: 1px solid #aa;
padding-top: 2px;
}
table.bodyTable {
border: 1px solid #000;
}
table.bodyTable th {
color: white;
background-color: #bbb;
text-align: left;
font-weight: bold;
}
table.bodyTable tr.a {
background-color: #ddd;
}
table.bodyTable tr.b {
background-color: #eee;
}
.source {
border: 1px solid #999;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Using FindBugs Maven plugin?
Gary Gregory [EMAIL PROTECTED] wrote on 17/02/2004 12:38:29 PM: Don't use maven-plugins.sf.net as the remote repo. It's not a repository. Ah, I see, so the directions on their site is not right since this where I got the info: http://maven-plugins.sourceforge.net/installing.html Yes, those directions are wrong. I'll fix them later... -- dIon Gillard, Multitask Consulting
RE: [lang] Using FindBugs Maven plugin?
Dion, Could you please post to this list when you do fix this? We'd like to use the Maven plug-in with [lang] at least. Thanks, Gary. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 18:57 To: Jakarta Commons Developers List Subject: RE: [lang] Using FindBugs Maven plugin? Gary Gregory [EMAIL PROTECTED] wrote on 17/02/2004 12:38:29 PM: Don't use maven-plugins.sf.net as the remote repo. It's not a repository. Ah, I see, so the directions on their site is not right since this where I got the info: http://maven-plugins.sourceforge.net/installing.html Yes, those directions are wrong. I'll fix them later... -- dIon Gillard, Multitask Consulting
cvs commit: jakarta-commons/commons-build project.css
mdiggory2004/02/16 18:59:15 Removed: commons-build project.css Log: This file is being moved into commons-build/xdocs/style/project.css so that it can be picked up properly by maven as the css to be used. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs/stylesheets/menus apache.xml
mdiggory2004/02/16 19:53:29 Modified:commons-build/xdocs/stylesheets/menus apache.xml Log: An include has to have xml content available or the parsing fails, this can't be commented out here. Revision ChangesPath 1.3 +1 -2 jakarta-commons/commons-build/xdocs/stylesheets/menus/apache.xml Index: apache.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/stylesheets/menus/apache.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- apache.xml22 Nov 2003 16:43:03 - 1.2 +++ apache.xml17 Feb 2004 03:53:29 - 1.3 @@ -2,9 +2,8 @@ This menu is for general Apache information, special events, ... -- -!-- menu name=Apache item name=ApacheCon href=http://apachecon.com/2003/US/index.html; img=http://jakarta.apache.org/images/logos/ac2003-150.gif/ /menu --- + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/analysis InterpolatorTest.java
psteitz 2004/02/16 20:33:16
Modified:math/src/test/org/apache/commons/math/analysis
InterpolatorTest.java
Log:
Restored test code inadvertently deleted with last commit.
Revision ChangesPath
1.12 +26 -1
jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java
Index: InterpolatorTest.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/analysis/InterpolatorTest.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- InterpolatorTest.java 16 Feb 2004 06:30:21 - 1.11
+++ InterpolatorTest.java 17 Feb 2004 04:33:16 - 1.12
@@ -47,7 +47,9 @@
double yval[] = { 0.0, 0.5, 1.0 };
UnivariateRealInterpolator i = new SplineInterpolator();
UnivariateRealFunction f = i.interpolate(xval, yval);
+
/* todo: rewrite using assertions
+
double x;
x = 0.0;
System.out.println(
@@ -79,6 +81,29 @@
double yval[] = { 0.0, 0.5, 1.0, 1.5 };
UnivariateRealInterpolator i = new SplineInterpolator();
UnivariateRealFunction f = i.interpolate(xval, yval);
+/* todo: rewrite with assertions
+double x;
+x = 0.0;
+System.out.println(
+x=
++ x
++ y=
++ f.value(x));
+
+x = 0.5;
+System.out.println(
+x=
++ x
++ y=
++ f.value(x));
+
+x = 1 - 1E-6;
+System.out.println(
+x=
++ x
++ y=
++ f.value(x));
+*/
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
