Re: [all] Nightlies are back...mostly
I also prefer the dated jars approach. On 7/7/06, Phil Steitz <[EMAIL PROTECTED]> wrote: On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 7/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 7/07/2006 2:27 AM, Phil Steitz wrote: > > > 2) Need to decide whether we want dated snaps or just overwriting. If > > > the latter, we would need a way to purge old stuff (like the crontab > > > that runs on Minotaur that purges out the old nightly distros). > > > > I generally prefer dated (just in case something is broken with today's, > > you can try yesterdays). However, it does give you the obligation to > > clean up afterwards (not necessarily a bad thing). > > > > Neither work in Maven 2 if you are downloading from a Maven 1 repo at > > the moment (dated because there was never any facility for that, > > SNAPSHOT because of the bug Jorg mentioned). > > > > > > > > 3) Ensure that the deploy target hosts are set correctly in all of the > > > POMs - maybe modify the script to check to avoid accidental > > > deployments to java-repository. > > > > +1, and also check that currentVersion endsWith -SNAPSHOT. > > > > > > > > 4) Someone needs to remind me (or just patch the script) of the > > > correct maven 1 target to execute. (jar:snapshot-deploy or somesuch). > > > > With the current plugins installed, jar:deploy will do a dated snapshot > > by default I think, based on the end of the version. > > > > > > > > 5) I either need to get over reservations about signing myself, or be > > > OK with no sigs. Is it OK to deploy unsigned stuff to the snapshot > > > repo? The same actually applies to the zips, tars being generated by > > > the script now. > > > > As Craig said, no need to sign them. > > > > It's a false sense of security when they aren't any more secure (anyone > > that can compromise the machine can compromise the key being used to > > sign them if it is automated). > > So hashing (which maven does) is as much as we can really practically > do automated. > > Looks also like we have consensus on the "snapshot" semantics - i.e., > just overwrite with a new snap each night. If there are no objections > in the next couple of days, I will go ahead and make the change to > support this, or someone else can. Sorry, I missed Brett's stated preference for dated jars, which I actually share. Is this possible using maven 1 somehow? I vaguely remember doing this long ago and m1 being smart enough to grab the latest jar when dated snaps were deployed. We could set up a cron to clean up the repo, like we do the nightlies. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ "If you even dream of beating me you'd better wake up and apologize" - Muhammad Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/07/2006 4:09 PM, Phil Steitz wrote: Sorry, I missed Brett's stated preference for dated jars, which I actually share. Is this possible using maven 1 somehow? I vaguely remember doing this long ago and m1 being smart enough to grab the latest jar when dated snaps were deployed. We could set up a cron to clean up the repo, like we do the nightlies. It certainly could deploy it through jar:deploy (previously jar:deploy-snapshot was required). I don't think Maven 1.x ever got smart enough to grab this automatically (but I may be misremembering). This isn't necessarily such a bad thing, allowing folks to always pick the version they want. - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: On 7/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: > On 7/07/2006 2:27 AM, Phil Steitz wrote: > > 2) Need to decide whether we want dated snaps or just overwriting. If > > the latter, we would need a way to purge old stuff (like the crontab > > that runs on Minotaur that purges out the old nightly distros). > > I generally prefer dated (just in case something is broken with today's, > you can try yesterdays). However, it does give you the obligation to > clean up afterwards (not necessarily a bad thing). > > Neither work in Maven 2 if you are downloading from a Maven 1 repo at > the moment (dated because there was never any facility for that, > SNAPSHOT because of the bug Jorg mentioned). > > > > > 3) Ensure that the deploy target hosts are set correctly in all of the > > POMs - maybe modify the script to check to avoid accidental > > deployments to java-repository. > > +1, and also check that currentVersion endsWith -SNAPSHOT. > > > > > 4) Someone needs to remind me (or just patch the script) of the > > correct maven 1 target to execute. (jar:snapshot-deploy or somesuch). > > With the current plugins installed, jar:deploy will do a dated snapshot > by default I think, based on the end of the version. > > > > > 5) I either need to get over reservations about signing myself, or be > > OK with no sigs. Is it OK to deploy unsigned stuff to the snapshot > > repo? The same actually applies to the zips, tars being generated by > > the script now. > > As Craig said, no need to sign them. > > It's a false sense of security when they aren't any more secure (anyone > that can compromise the machine can compromise the key being used to > sign them if it is automated). So hashing (which maven does) is as much as we can really practically do automated. Looks also like we have consensus on the "snapshot" semantics - i.e., just overwrite with a new snap each night. If there are no objections in the next couple of days, I will go ahead and make the change to support this, or someone else can. Sorry, I missed Brett's stated preference for dated jars, which I actually share. Is this possible using maven 1 somehow? I vaguely remember doing this long ago and m1 being smart enough to grab the latest jar when dated snaps were deployed. We could set up a cron to clean up the repo, like we do the nightlies. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: On 7/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: > On 7/07/2006 2:11 PM, Phil Steitz wrote: > > So hashing (which maven does) is as much as we can really practically > > do automated. > > Yep (and this is only for transport integrity, not the authenticity of > the source). > > > # Repository to deploy snapshots > > maven.repo.apache.snapshots=scp://cvs.apache.org Just noticed I forgot to change this. This should be people, right? Yes, and it should be changed in any POMs that reference it directly, too. Otherwise, people who try to look up dependencies at cvs.apache.org are going to have problems. Phil Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: On 7/07/2006 2:11 PM, Phil Steitz wrote: > So hashing (which maven does) is as much as we can really practically > do automated. Yep (and this is only for transport integrity, not the authenticity of the source). > # Repository to deploy snapshots > maven.repo.apache.snapshots=scp://cvs.apache.org Just noticed I forgot to change this. This should be people, right? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira usage
On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
One more thing along these lines. I can't remember where I saw an
intelligent explanation of how we should use "closed" vs. "resolved"
in Jira. I guess a reasonable approach given the above strategy would
be to wait to close until the fix version is actually released, unless
the closing is "won't fix" or "invalid" (in which case, there is no
fix version). Is that right?
FWIW, I can describe how we differentiate these two in my day job ...
developers change the state to "Resolved/Fixed" if they claim to have fixed
it, or something similar ("Resolved/Will Not Fix" or "Resolved/Not A Bug")
for other scenarios, but QA is the one that switches it to "Closed" after
they have verified that the fix works. In open source, theoretically we
would want the original bug reporter to do that, but it seems unlikely to
happen in the general case. For Apache stuff, I tend to focus only on
"unresolved" issues, and not worry about the difference between "resolved"
and "closed".
Phil
Craig
Re: Jira usage
On 7/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: Just wanted to mention how I've been doing things in Jira for LANG. My aim is to make it so every issue in a project has a version set for it. For Sandbox, read component instead of version - less need to manage things there. Wow. Much more organized than the tradition j-c process: code a bit, suggest release, decide which bugs to "fix later", crank release, start again... Given that Jira supports this pretty easily (modulo email spam annoyance), I think what you are suggesting is a good idea. I will try to get this going for [math] and [dbcp]. I will no doubt screw some things up in the process. Please be kind but clear letting me know what I am doing wrong. One more thing along these lines. I can't remember where I saw an intelligent explanation of how we should use "closed" vs. "resolved" in Jira. I guess a reasonable approach given the above strategy would be to wait to close until the fix version is actually released, unless the closing is "won't fix" or "invalid" (in which case, there is no fix version). Is that right? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/07/2006 2:11 PM, Phil Steitz wrote: So hashing (which maven does) is as much as we can really practically do automated. Yep (and this is only for transport integrity, not the authenticity of the source). # Repository to deploy snapshots maven.repo.apache.snapshots=scp://cvs.apache.org maven.repo.apache.snapshots.directory=/www/people.apache.org/repository I assume I can also specify these with -D on the m1 command line? Looks right, might also need a private key and username if the defaults aren't what you wanted. Also, the target is "jar:deploy" right (assuming all have -SNAPSHOT in trunk version)? Yes. This last bit raises an issue that I had to hack around for [scxml] and that we might want to consider standardizing - all trunk POMs have -SNAPSHOT version names. This means that RCs *must* be built from branches. Personally, I think that is a good idea. Pretty much. The release plugin actually puts the release rev# on trunk, but immediately bumps it up to the next snapshot and commits again. Both are good alternatives as long as trunk stays as a snapshot when it has the possibility to change. - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: On 7/07/2006 2:27 AM, Phil Steitz wrote: > 2) Need to decide whether we want dated snaps or just overwriting. If > the latter, we would need a way to purge old stuff (like the crontab > that runs on Minotaur that purges out the old nightly distros). I generally prefer dated (just in case something is broken with today's, you can try yesterdays). However, it does give you the obligation to clean up afterwards (not necessarily a bad thing). Neither work in Maven 2 if you are downloading from a Maven 1 repo at the moment (dated because there was never any facility for that, SNAPSHOT because of the bug Jorg mentioned). > > 3) Ensure that the deploy target hosts are set correctly in all of the > POMs - maybe modify the script to check to avoid accidental > deployments to java-repository. +1, and also check that currentVersion endsWith -SNAPSHOT. > > 4) Someone needs to remind me (or just patch the script) of the > correct maven 1 target to execute. (jar:snapshot-deploy or somesuch). With the current plugins installed, jar:deploy will do a dated snapshot by default I think, based on the end of the version. > > 5) I either need to get over reservations about signing myself, or be > OK with no sigs. Is it OK to deploy unsigned stuff to the snapshot > repo? The same actually applies to the zips, tars being generated by > the script now. As Craig said, no need to sign them. It's a false sense of security when they aren't any more secure (anyone that can compromise the machine can compromise the key being used to sign them if it is automated). So hashing (which maven does) is as much as we can really practically do automated. Looks also like we have consensus on the "snapshot" semantics - i.e., just overwrite with a new snap each night. If there are no objections in the next couple of days, I will go ahead and make the change to support this, or someone else can. I assume the following is correct for maven 1: maven.repo.list=apache.snapshots # Repository to deploy snapshots maven.repo.apache.snapshots=scp://cvs.apache.org maven.repo.apache.snapshots.directory=/www/people.apache.org/repository I assume I can also specify these with -D on the m1 command line? Also, the target is "jar:deploy" right (assuming all have -SNAPSHOT in trunk version)? This last bit raises an issue that I had to hack around for [scxml] and that we might want to consider standardizing - all trunk POMs have -SNAPSHOT version names. This means that RCs *must* be built from branches. Personally, I think that is a good idea. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/07/2006 2:27 AM, Phil Steitz wrote: 2) Need to decide whether we want dated snaps or just overwriting. If the latter, we would need a way to purge old stuff (like the crontab that runs on Minotaur that purges out the old nightly distros). I generally prefer dated (just in case something is broken with today's, you can try yesterdays). However, it does give you the obligation to clean up afterwards (not necessarily a bad thing). Neither work in Maven 2 if you are downloading from a Maven 1 repo at the moment (dated because there was never any facility for that, SNAPSHOT because of the bug Jorg mentioned). 3) Ensure that the deploy target hosts are set correctly in all of the POMs - maybe modify the script to check to avoid accidental deployments to java-repository. +1, and also check that currentVersion endsWith -SNAPSHOT. 4) Someone needs to remind me (or just patch the script) of the correct maven 1 target to execute. (jar:snapshot-deploy or somesuch). With the current plugins installed, jar:deploy will do a dated snapshot by default I think, based on the end of the version. 5) I either need to get over reservations about signing myself, or be OK with no sigs. Is it OK to deploy unsigned stuff to the snapshot repo? The same actually applies to the zips, tars being generated by the script now. As Craig said, no need to sign them. It's a false sense of security when they aren't any more secure (anyone that can compromise the machine can compromise the key being used to sign them if it is automated). - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
If the fix you put in doesn't work, the -Djava.awt.headless=true property might work. - Brett On 7/07/2006 6:18 AM, Phil Steitz wrote: On 7/6/06, Oliver Heger <[EMAIL PROTECTED]> wrote: Phil, thank you very much for your work! Finally I can see, which test fails for [configuration]. Hm, it's a test dealing with Applets. I guess, you run the tests in a non GUI environment, where creating an Applet is not allowed? I modified the test and hope that the problem is now solved. Yes, the script just runs maven from the command line under Ubuntu Linux, JDK 1.5. Thanks for looking into this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/07/2006 5:05 AM, Jörg Schaible wrote: Does currently not work. A SNAPSHOT is *never* downloaded, if there is already sitting one in the local repo - which is true after the first fetch ... MNG-1908 ... vote for it ! They're talking about Maven 1, where it does work. - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 4/07/2006 2:50 PM, Phil Steitz wrote: 2) Ubuntu on vmbuild seems to have no zip command, so the ant builds are not getting zips generated. I guess I could break down and fork Ant again to do the zips, but maybe there is an easier way? sudo apt-get install zip Done :) - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter - pre 2.2
Gary Gregory wrote: At a minimum, I'd like to see MapVariableResolver packge scoped. Looking at the message thread: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg78697.html It seems that another proposal being discussed back in April was to make some classes /easier/ to reuse and extend for the more advanced users by making them come out of inner, which would also mean keeping them public. The problem here is that once we publish the API thats it, we can't unpublish it. MapVariableResolver seems like an internal class that we create for our own needs. All the constructors allow for a Map to be passed in, so the users of MapVariableResolver will be very much edge case users. However, I thnk I'd rather see VariableResolver changed to be a more general StrLookup class rather like StrMatcher. That way it could be used equally as well independent of VariableFormatter. Gary Gregory wrote: The challenge to me here is that I've heard some folks says they do not want [lang] to become too framework-like. I am wondering if making VariableResolver more generic would go in that direction. The nice thing I see about the way it is now is that the solution is on making the variable resolver pluggable and nothing more. Which is a draw back if that interface is really /that great/. The question is whether we can see a [lang] use case for using StrLookup other than in VariableFormatter. Oliver Heger wrote: > Fine with me, but could the return value of lookup be Object instead > of String? Especially if you want to use this interface in other areas, you might need more freedom. If only String processing needs > to be performed, the returned Object can be transformed to a String by > calling toString(). But what kind of object are you expectng to be returned here (other than a String)? A similar question applies to the replaceObject() method which appears to have very odd semantics as you can't rely on the return value being of any specific type. What Objects are you expecting to work with? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r419740 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/CompositeFormat.java
Author: scolebourne
Date: Thu Jul 6 16:34:47 2006
New Revision: 419740
URL: http://svn.apache.org/viewvc?rev=419740&view=rev
Log:
Add serialization version id and javadoc
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/CompositeFormat.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/CompositeFormat.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/CompositeFormat.java?rev=419740&r1=419739&r2=419740&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/CompositeFormat.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/CompositeFormat.java
Thu Jul 6 16:34:47 2006
@@ -15,10 +15,10 @@
*/
package org.apache.commons.lang.text;
-import java.text.Format;
import java.text.FieldPosition;
-import java.text.ParsePosition;
+import java.text.Format;
import java.text.ParseException;
+import java.text.ParsePosition;
/**
* Formats using one formatter and parses using a different formatter.
@@ -26,10 +26,16 @@
* and stored in a database another way.
*
* @author Archimedes Trajano
+ * @version $Id: $
*/
public class CompositeFormat extends Format {
+/** Serialization lock. */
+private static final long serialVersionUID = -4329119827877627683L;
+
+/** The parser to use. */
private final Format parser;
+/** The formatter to use. */
private final Format formatter;
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r419739 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Author: scolebourne
Date: Thu Jul 6 16:31:00 2006
New Revision: 419739
URL: http://svn.apache.org/viewvc?rev=419739&view=rev
Log:
Layout action methods to match general lang formatting
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java?rev=419739&r1=419738&r2=419739&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Thu Jul 6 16:31:00 2006
@@ -605,27 +605,91 @@
this.setEscapeCharacter(escape);
}
+//---
/**
- * Creates a parser object for tokenizing the input data.
+ * Replaces the occurrences of all variables in the given source array by
+ * their current values.
*
* @param data
- *the input data
+ *a character array with the source data
+ * @return the result of the replace operation
+ */
+public String replace(char[] data) {
+return replace(data, 0, data == null ? 0 : data.length);
+}
+
+/**
+ * Replaces the occurrences of all variables in the given source array by
their
+ * current values. Only the specified portion of the array will be
processed.
+ *
+ * @param data
+ *a character array with the source data
* @param offset
- *the offset in the source array
+ *the start offset; processing will start at this position
* @param length
- *the length of the data to be processed
- * @return the parser
+ *the length of the portion to be processed
+ * @return the result of the replace operation
*/
-protected VariableParser createParser(char[] data, int offset, int length)
{
-return new VariableParser(
-StrMatcher.stringMatcher(getVariablePrefix()),
-StrMatcher.stringMatcher(getVariableSuffix()),
-StrMatcher.stringMatcher(String.valueOf(getEscapeCharacter())
+ getVariablePrefix()), offset, length);
+public String replace(char[] data, int offset, int length) {
+Object result = doReplace(data, offset, length, null, null);
+return result == null ? null : result.toString();
}
/**
- * Recursive handler for multiple levels of interpolation. This is the
main interpolation method, which resolves the
- * values of all variable references contained in the passed in text.
+ * Replaces the occurrences of all variables in the given source data by
+ * their current values.
+ *
+ * @param source
+ *the text to be interpolated; this can be an arbitrary object
+ *whose toString() method will be called
+ * @return the result of the replace operation
+ */
+public String replace(Object source) {
+Object result = replaceObject(source);
+return result == null ? null : result.toString();
+}
+
+/**
+ * Replaces the occurrences of all variables in the given source data by
+ * their current values. If the source consists only of a single variable
+ * reference, this method directly returns the value of this variable
+ * (which can be an arbitrary object). If the source contains multiple
+ * variable references or static text, the return value will always be a
+ * String with the concatenation of all these elements.
+ *
+ * @param source
+ *the text to be interpolated; this can be an arbitrary object
+ *whose toString() method will be called
+ * @return the result of the replace operation
+ */
+public Object replaceObject(Object source) {
+return doReplace(source, null);
+}
+
+//---
+/**
+ * Recursive handler for multiple levels of interpolation. This is the main
+ * interpolation method for interpolating objects. It is called for
recursively
+ * processing the values of resolved variables.
+ *
+ * @param obj
+ *the data to be interpolated (as object)
+ * @param priorVariables
+ *keeps track of the replaced variables
+ * @return the result of the interpolation process
+ */
+private Object doReplace(Object obj, List priorVariables) {
+if (obj == null) {
+return null;
+}
+char[] data = obj.toString().toCharArray();
+return doReplace(data, 0, dat
svn commit: r419738 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Author: scolebourne
Date: Thu Jul 6 16:27:57 2006
New Revision: 419738
URL: http://svn.apache.org/viewvc?rev=419738&view=rev
Log:
Layout getters and setters in pairs to match general lang formatting
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java?rev=419738&r1=419737&r2=419738&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Thu Jul 6 16:27:57 2006
@@ -737,47 +737,11 @@
return doReplace(data, 0, data.length, obj, priorVariables);
}
-/**
- * Returns the escape character.
- *
- * @return the character used for escaping variable references
- */
-public char getEscapeCharacter() {
-return this.escapeCharacter;
-}
-
private int getLength(FieldPosition tok) {
return tok.getEndIndex() - tok.getBeginIndex();
}
/**
- * Returns the prefix for variables.
- *
- * @return the prefix for variables
- */
-public String getVariablePrefix() {
-return this.variablePrefix;
-}
-
-/**
- * Gets the VariableResolver
- *
- * @return the VariableResolver
- */
-public VariableResolver getVariableResolver() {
-return this.variableResolver;
-}
-
-/**
- * Returns the suffix for variables.
- *
- * @return the suffix for variables
- */
-public String getVariableSuffix() {
-return this.variableSuffix;
-}
-
-/**
* Replaces the occurrences of all variables in the given source array by
their current values.
*
* @param data
@@ -850,9 +814,20 @@
return this.getVariableResolver().resolveVariable(name);
}
+//---
/**
- * Sets the escape character. If this character is placed before a
variable reference in the source text, this
- * variable will be ignored.
+ * Returns the escape character.
+ *
+ * @return the character used for escaping variable references
+ */
+public char getEscapeCharacter() {
+return this.escapeCharacter;
+}
+
+/**
+ * Sets the escape character.
+ * If this character is placed before a variable reference in the source
+ * text, this variable will be ignored.
*
* @param escapeCharacter
*the escape character (0 for disabling escaping)
@@ -862,14 +837,23 @@
}
/**
+ * Returns the prefix for variables.
+ *
+ * @return the prefix for variables
+ */
+public String getVariablePrefix() {
+return this.variablePrefix;
+}
+
+/**
* Sets the prefix for variables.
*
* @param variablePrefix
- *the prefix for variables
+ *the prefix for variables, not null
* @throws IllegalArgumentException
* if the prefix is null
*/
-public void setVariablePrefix(String variablePrefix) throws
IllegalArgumentException {
+public void setVariablePrefix(String variablePrefix) {
if (variablePrefix == null) {
throw new IllegalArgumentException("Variable prefix must not be
null!");
}
@@ -877,27 +861,46 @@
}
/**
- * Sets the VariableResolver
+ * Returns the suffix for variables.
*
- * @param variableResolver
- *the VariableResolver
+ * @return the suffix for variables
*/
-public void setVariableResolver(VariableResolver variableResolver) {
-this.variableResolver = variableResolver;
+public String getVariableSuffix() {
+return this.variableSuffix;
}
/**
* Sets the suffix for variables
*
* @param variableSuffix
- *the suffix for variables
+ *the suffix for variables, not null
* @throws IllegalArgumentException
* if the prefix is null
*/
-public void setVariableSuffix(String variableSuffix) throws
IllegalArgumentException {
+public void setVariableSuffix(String variableSuffix) {
if (variableSuffix == null) {
throw new IllegalArgumentException("Variable suffix must not be
null!");
}
this.variableSuffix = variableSuffix;
}
+
+/**
+ * Gets the VariableResolver
+ *
+ * @return the VariableResolver
+ */
+public VariableResolver getVariableResolver() {
+return this.variableResolver;
+}
+
+/**
+ * Sets the Var
svn commit: r419737 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Author: scolebourne
Date: Thu Jul 6 16:24:06 2006
New Revision: 419737
URL: http://svn.apache.org/viewvc?rev=419737&view=rev
Log:
Javadoc
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java?rev=419737&r1=419736&r2=419737&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Thu Jul 6 16:24:06 2006
@@ -56,7 +56,7 @@
* valuesMap.put("animal", "quick brown fox");
* valuesMap.put("target", "lazy dog");
* String templateString = "The ${animal} jumped over the
${target}.";
- * VariableFormat vf = new VariableVormat(valuesMap);
+ * VariableFormatter vf = new VariableFormatter(valuesMap);
* String resolvedString = cf.replace(templateString);
*
*
@@ -165,8 +165,9 @@
}
/**
- * A helper class for detecting variables in the source text. This class
provides simple tokenizer functionality. It
- * splits input text into tokens for text, variables, and escaped variable
start tokens.
+ * A helper class for detecting variables in the source text.
+ * This class provides simple tokenizer functionality. It splits input
+ * text into tokens for text, variables, and escaped variable start tokens.
*/
protected static class VariableParser {
/** Constant for the token type ESCAPED_VAR. */
@@ -450,15 +451,16 @@
* Definition of an interface for obtaining values for variables.
*
*
- * Objects implementing this interface can be passed to
VariableFormatter as source for variables'
- * values. The interface is quite simple and defines only a single method
for retrieving the value of a specified
- * value.
+ * Objects implementing this interface can be passed to
VariableFormatter
+ * as source for the values of the variables. The interface is quite
simple and defines
+ * only a single method for retrieving the value of a specified value.
*
*/
public static interface VariableResolver {
/**
- * Returns the value of the specified variable. The variable's value
can be an arbitrary object. If no variable
- * with the given name is known, an implementation should return
null.
+ * Returns the value of the specified variable. The variable's value
+ * can be an arbitrary object. If no variable with the given name is
known,
+ * an implementation should return null.
*
* @param varName
*the name of the searched variable
@@ -477,8 +479,8 @@
public static final String DEFAULT_SUFFIX = "}";
/**
- * Replaces the occurrences of all variables in the given source data by
their current values obtained from the
- * passed in map.
+ * Replaces the occurrences of all variables in the given source data by
+ * their current values obtained from the passed in map.
*
* @param valueMap
*the map with the values
@@ -491,8 +493,9 @@
}
/**
- * Replaces the occurrences of all variables in the given source data by
their current values obtained from the
- * passed in map. This method allows to specifiy a custom variable prefix
and suffix
+ * Replaces the occurrences of all variables in the given source data by
+ * their current values obtained from the passed in map. This method allows
+ * to specifiy a custom variable prefix and suffix
*
* @param valueMap
*the map with the values
@@ -509,7 +512,8 @@
}
/**
- * Replaces all variables in the given source data with values obtained
from system properties.
+ * Replaces all variables in the given source data with values obtained
+ * from system properties.
*
* @param source
*the source text
@@ -534,15 +538,16 @@
private String variableSuffix;
/**
- * Creates a new instance with defaults for variable prefix and suffix and
the escaping character.
+ * Creates a new instance with defaults for variable prefix and suffix
+ * and the escaping character.
*/
public VariableFormatter() {
this((VariableResolver) null, DEFAULT_PREFIX, DEFAULT_SUFFIX,
DEFAULT_ESCAPE);
}
/**
- * Creates a new instance and initializes it. Uses defaults for variable
prefix and suffix and the escaping
- * character.
+ * Creates a new instance and initializes it. Uses defaults for variable
+ * prefix and suffix and the escaping character.
*
svn commit: r419726 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Author: scolebourne
Date: Thu Jul 6 15:18:31 2006
New Revision: 419726
URL: http://svn.apache.org/viewvc?rev=419726&view=rev
Log:
Reduce scope from public to protected in parser
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java?rev=419726&r1=419725&r2=419726&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/VariableFormatter.java
Thu Jul 6 15:18:31 2006
@@ -187,7 +187,7 @@
*The token length
* @return a new token
*/
-public static FieldPosition newEscapedVariableToken(int aStartIndex,
int aLength) {
+protected static FieldPosition newEscapedVariableToken(int
aStartIndex, int aLength) {
return newToken(VariableParser.ESCAPED_VAR_TOKEN, aStartIndex,
aLength);
}
@@ -200,7 +200,7 @@
*The token length
* @return a new token
*/
-public static FieldPosition newTextToken(int aStartIndex, int aLength)
{
+protected static FieldPosition newTextToken(int aStartIndex, int
aLength) {
return newToken(VariableParser.TEXT_TOKEN, aStartIndex, aLength);
}
@@ -220,7 +220,7 @@
*The token length
* @return a new token
*/
-public static FieldPosition newVariableToken(int aStartIndex, int
aLength) {
+protected static FieldPosition newVariableToken(int aStartIndex, int
aLength) {
return newToken(VariableParser.VARIABLE_TOKEN, aStartIndex,
aLength);
}
@@ -259,7 +259,7 @@
* @param length
*the length of the source data
*/
-public VariableParser(StrMatcher startMatcher, StrMatcher endMatcher,
+protected VariableParser(StrMatcher startMatcher, StrMatcher
endMatcher,
StrMatcher escMatcher, int startPos, int length) {
this.setVarStartMatcher(startMatcher);
this.setVarEndMatcher(endMatcher);
@@ -348,7 +348,7 @@
*the array with the source data
* @return the next token or null if the end is reached
*/
-public FieldPosition nextToken(char[] data) {
+protected FieldPosition nextToken(char[] data) {
if (getTokenList().isEmpty()) {
if (!hasNext()) {
// end of data is reached
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] JRE level?
[lang] should be JDK1.2 compliant, although I tend to think of it as 1.3+ with 1.2 at users risk. Stephen Gary Gregory wrote: Hello All: Based on the project.properties file entry: maven.compile.source = 1.3 I assume that we are making Java 1.3 the requirement. We therefore should not have Java 1.4 dependencies: Severity and DescriptionPathResourceLocation Creation Time Id The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1351151797976890 13807342 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1361151797976890 13807346 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1691151797976890 13807374 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 2691151797976890 13807406 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 3161151797976890 13807407 Or am I missing something? Thanks, Gary - 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] VariableFormatter - pre 2.2
Hello All:
> At a minimum, I'd like to see MapVariableResolver packge scoped.
Looking at the message thread:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg78697.html
It seems that another proposal being discussed back in April was to make
some classes /easier/ to reuse and extend for the more advanced users by
making them come out of inner, which would also mean keeping them
public.
> However, I thnk I'd rather see VariableResolver changed to be a more
> general StrLookup class rather like StrMatcher. That way it could be
> used equally as well independent of VariableFormatter.
The challenge to me here is that I've heard some folks says they do not
want [lang] to become too framework-like. I am wondering if making
VariableResolver more generic would go in that direction. The nice thing
I see about the way it is now is that the solution is on making the
variable resolver pluggable and nothing more. Which is a draw back if
that interface is really /that great/.
FWIW, I am pretty happy with using the VariableFormatter class as is and
plan on doing so (as soon as my work schedule allows.)
Gary
> -Original Message-
> From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 05, 2006 5:07 PM
> To: Jakarta Commons Developers List
> Subject: [lang] VariableFormatter - pre 2.2
>
> Henri Yandell wrote:
> > Anyone know of any half-finished code in there at the moment?
>
> I think I'm on record for saying that the VariableFormatter class
> doesn't quite fit as is IMHO. But I've not spelt out why, so here
goes...
>
> At a minimum, I'd like to see MapVariableResolver packge scoped.
>
> However, I thnk I'd rather see VariableResolver changed to be a more
> general StrLookup class rather like StrMatcher. That way it could be
> used equally as well independent of VariableFormatter.
>
> public class StrLookup {
>String lookup(String key);
>
>// package scoped implementation for Map
> }
>
> You could envisage other (non [lang]) accessors such as OGNL, EL,
XPath
> or perhaps ones that accessed a List of strings by index.
>
> The key point is that this shouldn't be limited to just
> VariableFormatter in the same way that StrMatcher isn't limited to
> StrTokenizer. Separation of Concerns.
>
> 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]
[lang] JRE level?
Hello All: Based on the project.properties file entry: maven.compile.source = 1.3 I assume that we are making Java 1.3 the requirement. We therefore should not have Java 1.4 dependencies: Severity and DescriptionPathResourceLocation Creation Time Id The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1351151797976890 13807342 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1361151797976890 13807346 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 1691151797976890 13807374 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 2691151797976890 13807406 The method getCause() is undefined for the type Throwable Apache Jakarta Commons trunks-proper/lang/src/test/org/apache/commons/lang/exception ExceptionUtilsTestCase.java line 3161151797976890 13807407 Or am I missing something? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r419689 - in /jakarta/commons/proper/configuration/trunk/src: java/org/apache/commons/configuration/ java/org/apache/commons/configuration/event/ test/org/apache/commons/configuration/
Author: oheger
Date: Thu Jul 6 13:26:51 2006
New Revision: 419689
URL: http://svn.apache.org/viewvc?rev=419689&view=rev
Log:
Dealing with event listeners when cloning configurations
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestHierarchicalConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java?rev=419689&r1=419688&r2=419689&view=diff
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/BaseConfiguration.java
Thu Jul 6 13:26:51 2006
@@ -166,7 +166,8 @@
try
{
BaseConfiguration copy = (BaseConfiguration) super.clone();
-copy.store = (Map) ((LinkedMap) store).clone();
+copy.store = (Map) ConfigurationUtils.clone(store);
+copy.clearConfigurationListeners();
return copy;
}
catch (CloneNotSupportedException cex)
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java?rev=419689&r1=419688&r2=419689&view=diff
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/HierarchicalConfiguration.java
Thu Jul 6 13:26:51 2006
@@ -648,7 +648,8 @@
/**
* Creates a copy of this object. This new configuration object will
contain
- * copies of all nodes in the same structure.
+ * copies of all nodes in the same structure. Registered event listeners
+ * won't be cloned; so they are not registered at the returned copy.
*
* @return the copy
* @since 1.2
@@ -664,6 +665,7 @@
CloneVisitor v = new CloneVisitor();
getRootNode().visit(v);
copy.setRootNode(v.getClone());
+copy.clearConfigurationListeners();
return copy;
}
Modified:
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java?rev=419689&r1=419688&r2=419689&view=diff
==
---
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/event/EventSource.java
Thu Jul 6 13:26:51 2006
@@ -69,7 +69,7 @@
*/
public EventSource()
{
-listeners = new LinkedList();
+clearConfigurationListeners();
}
/**
@@ -118,6 +118,14 @@
{
return Collections.unmodifiableCollection(listeners);
}
+}
+
+/**
+ * Removes all registered configuration listeners.
+ */
+public void clearConfigurationListeners()
+{
+listeners = new LinkedList();
}
/**
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java?rev=419689&r1=419688&r2=419689&view=diff
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
Thu Jul 6 13:26:51 2006
@@ -26,6 +26,9 @@
import java.util.Properties;
import java.util.StringTokenizer;
+import org.apache.commons.configuration.event.
Re: [all] Nightlies are back...mostly
On 7/6/06, Oliver Heger <[EMAIL PROTECTED]> wrote: Phil, thank you very much for your work! Finally I can see, which test fails for [configuration]. Hm, it's a test dealing with Applets. I guess, you run the tests in a non GUI environment, where creating an Applet is not allowed? I modified the test and hope that the problem is now solved. Yes, the script just runs maven from the command line under Ubuntu Linux, JDK 1.5. Thanks for looking into this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Heading towards a Lang 2.2 release?
Hi All: > -Original Message- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Monday, July 03, 2006 10:03 PM > To: Jakarta Commons Developers List > Subject: [lang] Heading towards a Lang 2.2 release? > > Is anyone opposed to my starting to put together an rc1 distribution > for Lang 2.2? +1! > > The current state of play can be seen at: > > http://issues.apache.org/jira/browse/LANG > > There is one issue left in 2.2; a bug that sometimes passes tests and > sometimes fails - regardless of which, I'm not sure how to fix it even > when I do figure out how to make it repeatedly fail. I suspect I have > to sit and play with my system clock. I'm tempted to push it back to > 2.3. Can the APIs be parameterized such that we can pass in various system times during tests? Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
Phil, thank you very much for your work! Finally I can see, which test fails for [configuration]. Hm, it's a test dealing with Applets. I guess, you run the tests in a non GUI environment, where creating an Applet is not allowed? I modified the test and hope that the problem is now solved. Oliver Phil Steitz wrote: Nightlies are back up and running for most components. I still think maven2 + continuum is the way to go long term, but to get the nightlies back up, I hacked together a little bash script based on Craig's and set it up to run as a crontab on vmbuild.apache.org. It would be great if people could have a look at the nightlies themselves as well as the script, which I checked into commons-build as "commons_nightly.sh." I have no shame regarding my limited bash (or Java, actually ;-) skills, so feel free to make suggestions for improvement or submit patches. Be careful checking in the script, though, as it is executed via a crontab wrapper that svn ups it before executing it on vmbuild.apache.org. You can test it locally by changing the config to make your local host the deploy host. You have to gen an ssh key (if you don't already have one) and trust it locally to do this. The script reads lists of components from commons-build txt files like "nightly_sandbox_maven_list.txt" and executes maven clean dist for the ones in the maven lists and ant clean dist for those in the ant lists (after svn up). I split them up based on whether or not I could get "maven clean dist" to work. The ant lists consist of components for which the maven build did not work, but the ant build did. I have left a few things in the maven list even though they fail, because the reason seems trivial (e.g. clover license, or missing sun jars - I will fix the second). It svn ups the lists before executing, so if you want to move components from ant -> maven, or vice-versa, just make the changes to the files and check them in. Remember to delete as well as add; otherwise the script will run both. Logs for each component build are for the moment being written out to http://people.apache.org/~psteitz/commons-nightlies/ under dated directories. I didn't want to clutter the normal nightly location with logs, but that could be changed if we like having them there. I ommitted dormant components. If anyone feels strongly that we should be doing nightlies for any of these, the script can be patched to do that. There are no sigs or hashes. Another easy patch, but since this all runs as me, I don't want to sign. Adding hashes is no problem. Some of the maven builds do this already. Best would probably be to have the maven builds all do it and the nightly script just copy out. I am OK either way, but the script needs to be patched in either case to scp the hashes. More warts: 1) The files are not group writable on the deploy host (people.apache.org). I set the umask in the script, but somehow the permissions are not getting set right. Any pointers / patches on how to get the wrapper or script itself to do this correctly would be appreciated. 2) Ubuntu on vmbuild seems to have no zip command, so the ant builds are not getting zips generated. I guess I could break down and fork Ant again to do the zips, but maybe there is an easier way? 3) While it would be easy to get jar:deploy done from within the maven loop, that seems like running with scissors. Also, what would be deployed would be a SNAPSHOT that just over-wrote the previous (I think). This exposes another wart - though the names are munged to be dated, the internally bundled jars are not. For anyone wanting to play with this, be forwarned that Ubuntu rename is picky - you need to use the perl regexp form like the script does. Could be there is a simple maven way to get this right. Thanks in advance for feedback / patches / review of the output and help getting the failing builds restored. Phil - 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]
svn commit: r419687 - /jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/web/TestAppletConfiguration.java
Author: oheger
Date: Thu Jul 6 13:00:28 2006
New Revision: 419687
URL: http://svn.apache.org/viewvc?rev=419687&view=rev
Log:
A trial to fix the test class for AppletConfiguration, which fails in the
nightly builds
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/web/TestAppletConfiguration.java
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/web/TestAppletConfiguration.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/web/TestAppletConfiguration.java?rev=419687&r1=419686&r2=419687&view=diff
==
---
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/web/TestAppletConfiguration.java
(original)
+++
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/web/TestAppletConfiguration.java
Thu Jul 6 13:00:28 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2004 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License")
* you may not use this file except in compliance with the License.
@@ -17,6 +17,8 @@
package org.apache.commons.configuration.web;
import org.apache.commons.configuration.AbstractConfiguration;
+import org.apache.commons.configuration.BaseConfiguration;
+import org.apache.commons.configuration.MapConfiguration;
import org.apache.commons.configuration.TestAbstractConfiguration;
import java.applet.Applet;
@@ -26,10 +28,35 @@
* Test case for the [EMAIL PROTECTED] AppletConfiguration} class.
*
* @author Emmanuel Bourg
- * @version $Revision$, $Date$
+ * @version $Revision$, $Date: 2005-02-26 13:56:39 +0100 (Sa, 26 Feb
+ * 2005) $
*/
public class TestAppletConfiguration extends TestAbstractConfiguration
{
+/** A flag whether tests with an applet can be run. */
+boolean supportsApplet;
+
+/**
+ * Initializes the tests. This implementation checks whether an applet can
+ * be used. Some environments, which do not support a GUI, don't allow
+ * creating an Applet instance. If we are in such an
+ * environment, some tests need to behave differently or be completely
+ * dropped.
+ */
+protected void setUp() throws Exception
+{
+try
+{
+new Applet();
+supportsApplet = true;
+}
+catch (Exception ex)
+{
+// cannot use applets
+supportsApplet = false;
+}
+}
+
protected AbstractConfiguration getConfiguration()
{
final Properties parameters = new Properties();
@@ -37,55 +64,74 @@
parameters.setProperty("key2", "value2");
parameters.setProperty("list", "value1, value2");
-Applet applet = new Applet()
+if (supportsApplet)
{
-public String getParameter(String key)
+Applet applet = new Applet()
{
-return parameters.getProperty(key);
-}
+public String getParameter(String key)
+{
+return parameters.getProperty(key);
+}
-public String[][] getParameterInfo()
-{
-return new String[][]
+public String[][] getParameterInfo()
{
-{"key1", "String", ""},
-{"key2", "String", ""},
-{"list", "String[]", ""}
-};
-}
-};
+return new String[][]
+{
+{ "key1", "String", "" },
+{ "key2", "String", "" },
+{ "list", "String[]", "" } };
+}
+};
-return new AppletConfiguration(applet);
+return new AppletConfiguration(applet);
+}
+else
+{
+return new MapConfiguration(parameters);
+}
}
protected AbstractConfiguration getEmptyConfiguration()
{
-return new AppletConfiguration(new Applet());
+if (supportsApplet)
+{
+return new AppletConfiguration(new Applet());
+}
+else
+{
+return new BaseConfiguration();
+}
}
public void testAddPropertyDirect()
{
-try
+if (supportsApplet)
{
-super.testAddPropertyDirect();
-fail("addPropertyDirect should throw an UnsupportedException");
-}
-catch (UnsupportedOperationException e)
-{
-// ok
+try
+{
+super.testAddPropertyDirect();
+fail("addPropertyDirect should throw an UnsupportedException");
+}
+catch (UnsupportedOperationExc
Re: [lang] VariableFormatter - pre 2.2
Stephen Colebourne wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.
public class StrLookup {
String lookup(String key);
// package scoped implementation for Map
}
You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
or perhaps ones that accessed a List of strings by index.
The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.
Fine with me, but could the return value of lookup be Object instead of
String? Especially if you want to use this interface in other areas, you
might need more freedom. If only String processing needs to be
performed, the returned Object can be transformed to a String by calling
toString().
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
>
> On 7/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
> > > On 7/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > > > Have added csv. How do I go about hooking it up, doesn't look as
> > > > though it worked last night?
> > > >
> > >
> > > The script was not creating directories on the deploy host for new
> > > components, so it failed the first time. I fixed that and it ran
> > > successfully last night.
> >
> > Thanks Phil.
> >
> > Any thoughts on having the Maven ones do a snapshot deploy to the
> > snapshot repository?
> >
> Would be easy to do, but before doing it, we need
>
> 1) Verify that this is OK from repository@ standpoint. I have sort of
> lost the thread on that list and don't want to do anything
> inconsistent / illegal. Probably should ask there and get agreement,
> unless I am just out of the loop and others are already doing this.
When we (Struts and Shale) asked, we got back basically "that's what it's
for" :-). We deploy snapshots to <
http://people.apache.org/maven-snapshot-repository>.
2) Need to decide whether we want dated snaps or just overwriting. If
> the latter, we would need a way to purge old stuff (like the crontab
> that runs on Minotaur that purges out the old nightly distros).
For uploaded artifacts, I historically modified the tar.gz and zip file
names to include the date. I have the following types of commands in my
crontab on people.apache.org to clean up afterwards (all on one line):
03 04 * * * find /www/cvs.apache.org/builds/jakarta-commons/nightly -mtime
+7 -exec rm \{\} \; >/dev/null 2>&1
Which reminds me ... I need to clean out the now obsolete lines like this.
OK, so now I have to add it to mine ;-)
3) Ensure that the deploy target hosts are set correctly in all of the
> POMs - maybe modify the script to check to avoid accidental
> deployments to java-repository.
Do the commons POMs all inherit from a master? That's the easiest way to
record things like repositories in one place, although it requires a release
process for the master POM when it gets updated.
No, we eliminated the POM inheritence a while back because it made it
impossible to build the projects by themselves. Should be able to
force this on command line in any case, so this is not really a
problem.
4) Someone needs to remind me (or just patch the script) of the
> correct maven 1 target to execute. (jar:snapshot-deploy or somesuch).
Maven 1? For m2 I do "mvn install deploy" on each module, to install it
locally and deploy it to the snapshot directory (the latter works that way
automatically because the version numbers are something like "1.0.3-SNAPSHOT
").
Currently, almost all commons components are still using Maven 1.
5) I either need to get over reservations about signing myself, or be
> OK with no sigs. Is it OK to deploy unsigned stuff to the snapshot
> repo? The same actually applies to the zips, tars being generated by
> the script now.
Nightly builds and snapshots are, IMHO, use at your own risk and don't need
signing.
Phil
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBUTILS-31) fillStatement setNull bug with the Derby JDBC driver
[
http://issues.apache.org/jira/browse/DBUTILS-31?page=comments#action_12419585 ]
Francis Townsend commented on DBUTILS-31:
-
This code was coded for the JDBC 3.0 specification. It would need to be
modified to run with JDBC 2.1 drivers (check the JDBCMajor version to determine
which code to use).
Also, I have read that the Oracle JDBC driver throws an Exception.
Unfortunately, it does not look as if there is no method that can determine
this before calling the getParameterType method. Which means we would need to
catch the exception and role back to the previous code, namely use the VARCHAR
type when setting null. This would always be thrown by the Oracle driver,
severely slowing it down.
So, I would suggest we hold off putting this into the next release until we
have a better solution.
> fillStatement setNull bug with the Derby JDBC driver
>
>
> Key: DBUTILS-31
> URL: http://issues.apache.org/jira/browse/DBUTILS-31
> Project: Commons DbUtils
> Type: Improvement
> Versions: 1.0
> Environment: Derby 10.1.2.1
> Reporter: Francis Townsend
> Fix For: 1.1
>
> This has been documented many times before, but I was not happy with the
> existing code fixes. The following small code snippet should fix it for all
> conforming JDBC drivers.
> protected void fillStatement(PreparedStatement stmt, Object[] params)
> throws SQLException {
> if (params == null) {
> return;
> }
> ParameterMetaData pmd = stmt.getParameterMetaData();
> for (int i = 0; i < params.length; i++) {
> if (params[i] != null) {
> stmt.setObject(i + 1, params[i]);
> } else {
> stmt.setNull(i + 1, pmd.getParameterType(i + 1));
> }
> }
> }
> The only difference is that you get the parameter meta data and pass that
> type information to the setNull method. This should neatly fix this problem,
> with a very slight additional overhead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
Henri Yandell wrote: > On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: >> On 7/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: >> > On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: >> > > On 7/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: >> > > > Have added csv. How do I go about hooking it up, doesn't look as >> > > > though it worked last night? >> > > > >> > > >> > > The script was not creating directories on the deploy host for new >> > > components, so it failed the first time. I fixed that and it ran >> > > successfully last night. >> > >> > Thanks Phil. >> > >> > Any thoughts on having the Maven ones do a snapshot deploy to the >> > snapshot repository? >> > >> Would be easy to do, but before doing it, we need > >> 2) Need to decide whether we want dated snaps or just overwriting. If >> the latter, we would need a way to purge old stuff (like the crontab >> that runs on Minotaur that purges out the old nightly distros). > > Overwriting I think, else the repository is going to explode in size. Does currently not work. A SNAPSHOT is *never* downloaded, if there is already sitting one in the local repo - which is true after the first fetch ... MNG-1908 ... vote for it ! > > Otherwise - agreement with Craig's email. > > Hen - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jira usage
Just wanted to mention how I've been doing things in Jira for LANG. My aim is to make it so every issue in a project has a version set for it. For Sandbox, read component instead of version - less need to manage things there. I then have a filter that notifies me (could be commons-dev instead) with a list of unversioned issues for projects that have been setup in such a way. That way I'm encouraged to triage decisions on new issues, but not to have to go and do the work immediately. I think it's a good model; anyone doing similar? My aim is to expand that to CLI, DBUTILS and IO next, though looks like Stephen's doing similar things in IO. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LANG-270) [lang] minor javadoc improvements for StringUtils.stripXxx() methods
[ http://issues.apache.org/jira/browse/LANG-270?page=all ] Henri Yandell resolved LANG-270: Fix Version: 2.2 Resolution: Fixed Applied, thanks Michael. svn ci -m "Applying javadoc fixes from Michael Heuer for the stripXxx methods as mentioned in LANG-270" src/java/org/apache/commons/lang/StringUtils.java Sendingsrc/java/org/apache/commons/lang/StringUtils.java Transmitting file data . Committed revision 419651. > [lang] minor javadoc improvements for StringUtils.stripXxx() methods > > > Key: LANG-270 > URL: http://issues.apache.org/jira/browse/LANG-270 > Project: Commons Lang > Type: Improvement > Versions: 2.1 > Reporter: Michael Heuer > Priority: Trivial > Fix For: 2.2 > Attachments: diff.txt > > Minor javadoc improvements for StringUtils.stripToNull(String) and > StringUtils.stripToEmpty(String) methods; see attached svn diff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r419651 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Author: bayard
Date: Thu Jul 6 11:43:02 2006
New Revision: 419651
URL: http://svn.apache.org/viewvc?rev=419651&view=rev
Log:
Applying javadoc fixes from Michael Heuer for the stripXxx methods as mentioned
in LANG-270
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java?rev=419651&r1=419650&r2=419651&view=diff
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Thu Jul 6 11:43:02 2006
@@ -391,14 +391,14 @@
* Whitespace is defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}.
*
*
- * StringUtils.strip(null) = null
- * StringUtils.strip("") = null
- * StringUtils.strip(" ")= null
- * StringUtils.strip("abc")= "abc"
- * StringUtils.strip(" abc") = "abc"
- * StringUtils.strip("abc ") = "abc"
- * StringUtils.strip(" abc ") = "abc"
- * StringUtils.strip(" ab c ") = "ab c"
+ * StringUtils.stripToNull(null) = null
+ * StringUtils.stripToNull("") = null
+ * StringUtils.stripToNull(" ")= null
+ * StringUtils.stripToNull("abc")= "abc"
+ * StringUtils.stripToNull(" abc") = "abc"
+ * StringUtils.stripToNull("abc ") = "abc"
+ * StringUtils.stripToNull(" abc ") = "abc"
+ * StringUtils.stripToNull(" ab c ") = "ab c"
*
*
* @param str the String to be stripped, may be null
@@ -422,14 +422,14 @@
* Whitespace is defined by [EMAIL PROTECTED]
Character#isWhitespace(char)}.
*
*
- * StringUtils.strip(null) = ""
- * StringUtils.strip("") = ""
- * StringUtils.strip(" ")= ""
- * StringUtils.strip("abc")= "abc"
- * StringUtils.strip(" abc") = "abc"
- * StringUtils.strip("abc ") = "abc"
- * StringUtils.strip(" abc ") = "abc"
- * StringUtils.strip(" ab c ") = "ab c"
+ * StringUtils.stripToEmpty(null) = ""
+ * StringUtils.stripToEmpty("") = ""
+ * StringUtils.stripToEmpty(" ")= ""
+ * StringUtils.stripToEmpty("abc")= "abc"
+ * StringUtils.stripToEmpty(" abc") = "abc"
+ * StringUtils.stripToEmpty("abc ") = "abc"
+ * StringUtils.stripToEmpty(" abc ") = "abc"
+ * StringUtils.stripToEmpty(" ab c ") = "ab c"
*
*
* @param str the String to be stripped, may be null
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: On 7/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > > On 7/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > Have added csv. How do I go about hooking it up, doesn't look as > > > though it worked last night? > > > > > > > The script was not creating directories on the deploy host for new > > components, so it failed the first time. I fixed that and it ran > > successfully last night. > > Thanks Phil. > > Any thoughts on having the Maven ones do a snapshot deploy to the > snapshot repository? > Would be easy to do, but before doing it, we need 2) Need to decide whether we want dated snaps or just overwriting. If the latter, we would need a way to purge old stuff (like the crontab that runs on Minotaur that purges out the old nightly distros). Overwriting I think, else the repository is going to explode in size. Otherwise - agreement with Craig's email. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-216) MultiKey's toString method should use Arrays.toString
[ http://issues.apache.org/jira/browse/COLLECTIONS-216?page=comments#action_12419570 ] Hendrik Maryns commented on COLLECTIONS-216: Ah, I didn't notice that. However, at least the typo can be fixed. I'll submit this bug in the sourceforge collections15 project. > MultiKey's toString method should use Arrays.toString > - > > Key: COLLECTIONS-216 > URL: http://issues.apache.org/jira/browse/COLLECTIONS-216 > Project: Commons Collections > Type: Improvement > Versions: 3.2 > Reporter: Hendrik Maryns > Priority: Minor > Attachments: MultiKey.diff > > Some minor comments on MultiKey: > - its toString method unnecessarily creates an extra Object. > - there are some unnecessary casts > - there is a mistake in the javadocs (actually, this mistake, 'lookup', which > should be in two words, is prevalent in all of the map API) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
On 7/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote:
> > On 7/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > > Have added csv. How do I go about hooking it up, doesn't look as
> > > though it worked last night?
> > >
> >
> > The script was not creating directories on the deploy host for new
> > components, so it failed the first time. I fixed that and it ran
> > successfully last night.
>
> Thanks Phil.
>
> Any thoughts on having the Maven ones do a snapshot deploy to the
> snapshot repository?
>
Would be easy to do, but before doing it, we need
1) Verify that this is OK from repository@ standpoint. I have sort of
lost the thread on that list and don't want to do anything
inconsistent / illegal. Probably should ask there and get agreement,
unless I am just out of the loop and others are already doing this.
When we (Struts and Shale) asked, we got back basically "that's what it's
for" :-). We deploy snapshots to <
http://people.apache.org/maven-snapshot-repository>.
2) Need to decide whether we want dated snaps or just overwriting. If
the latter, we would need a way to purge old stuff (like the crontab
that runs on Minotaur that purges out the old nightly distros).
For uploaded artifacts, I historically modified the tar.gz and zip file
names to include the date. I have the following types of commands in my
crontab on people.apache.org to clean up afterwards (all on one line):
03 04 * * * find /www/cvs.apache.org/builds/jakarta-commons/nightly -mtime
+7 -exec rm \{\} \; >/dev/null 2>&1
Which reminds me ... I need to clean out the now obsolete lines like this.
3) Ensure that the deploy target hosts are set correctly in all of the
POMs - maybe modify the script to check to avoid accidental
deployments to java-repository.
Do the commons POMs all inherit from a master? That's the easiest way to
record things like repositories in one place, although it requires a release
process for the master POM when it gets updated.
4) Someone needs to remind me (or just patch the script) of the
correct maven 1 target to execute. (jar:snapshot-deploy or somesuch).
Maven 1? For m2 I do "mvn install deploy" on each module, to install it
locally and deploy it to the snapshot directory (the latter works that way
automatically because the version numbers are something like "1.0.3-SNAPSHOT
").
5) I either need to get over reservations about signing myself, or be
OK with no sigs. Is it OK to deploy unsigned stuff to the snapshot
repo? The same actually applies to the zips, tars being generated by
the script now.
Nightly builds and snapshots are, IMHO, use at your own risk and don't need
signing.
Phil
Craig
[jira] Commented: (COLLECTIONS-216) MultiKey's toString method should use Arrays.toString
[ http://issues.apache.org/jira/browse/COLLECTIONS-216?page=comments#action_12419569 ] Matt Benson commented on COLLECTIONS-216: - Since Arrays.toString() is only available beginning with Java 1.5, this patch cannot be applied until the [collections] trunk is 1.5-only. > MultiKey's toString method should use Arrays.toString > - > > Key: COLLECTIONS-216 > URL: http://issues.apache.org/jira/browse/COLLECTIONS-216 > Project: Commons Collections > Type: Improvement > Versions: 3.2 > Reporter: Hendrik Maryns > Priority: Minor > Attachments: MultiKey.diff > > Some minor comments on MultiKey: > - its toString method unnecessarily creates an extra Object. > - there are some unnecessary casts > - there is a mistake in the javadocs (actually, this mistake, 'lookup', which > should be in two words, is prevalent in all of the map API) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-216) MultiKey's toString method should use Arrays.toString
[ http://issues.apache.org/jira/browse/COLLECTIONS-216?page=all ] Hendrik Maryns updated COLLECTIONS-216: --- Attachment: MultiKey.diff A patch with the alterations I suggest, plus one typo. > MultiKey's toString method should use Arrays.toString > - > > Key: COLLECTIONS-216 > URL: http://issues.apache.org/jira/browse/COLLECTIONS-216 > Project: Commons Collections > Type: Improvement > Versions: 3.2 > Reporter: Hendrik Maryns > Priority: Minor > Attachments: MultiKey.diff > > Some minor comments on MultiKey: > - its toString method unnecessarily creates an extra Object. > - there are some unnecessary casts > - there is a mistake in the javadocs (actually, this mistake, 'lookup', which > should be in two words, is prevalent in all of the map API) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-216) MultiKey's toString method should use Arrays.toString
MultiKey's toString method should use Arrays.toString - Key: COLLECTIONS-216 URL: http://issues.apache.org/jira/browse/COLLECTIONS-216 Project: Commons Collections Type: Improvement Versions: 3.2 Reporter: Hendrik Maryns Priority: Minor Some minor comments on MultiKey: - its toString method unnecessarily creates an extra Object. - there are some unnecessary casts - there is a mistake in the javadocs (actually, this mistake, 'lookup', which should be in two words, is prevalent in all of the map API) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 7/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Have added csv. How do I go about hooking it up, doesn't look as > > though it worked last night? > > > > The script was not creating directories on the deploy host for new > components, so it failed the first time. I fixed that and it ran > successfully last night. Thanks Phil. Any thoughts on having the Maven ones do a snapshot deploy to the snapshot repository? Would be easy to do, but before doing it, we need 1) Verify that this is OK from repository@ standpoint. I have sort of lost the thread on that list and don't want to do anything inconsistent / illegal. Probably should ask there and get agreement, unless I am just out of the loop and others are already doing this. 2) Need to decide whether we want dated snaps or just overwriting. If the latter, we would need a way to purge old stuff (like the crontab that runs on Minotaur that purges out the old nightly distros). 3) Ensure that the deploy target hosts are set correctly in all of the POMs - maybe modify the script to check to avoid accidental deployments to java-repository. 4) Someone needs to remind me (or just patch the script) of the correct maven 1 target to execute. (jar:snapshot-deploy or somesuch). 5) I either need to get over reservations about signing myself, or be OK with no sigs. Is it OK to deploy unsigned stuff to the snapshot repo? The same actually applies to the zips, tars being generated by the script now. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-270) [lang] minor javadoc improvements for StringUtils.stripXxx() methods
[ http://issues.apache.org/jira/browse/LANG-270?page=all ] Michael Heuer updated LANG-270: --- Attachment: diff.txt > [lang] minor javadoc improvements for StringUtils.stripXxx() methods > > > Key: LANG-270 > URL: http://issues.apache.org/jira/browse/LANG-270 > Project: Commons Lang > Type: Improvement > Versions: 2.1 > Reporter: Michael Heuer > Priority: Trivial > Attachments: diff.txt > > Minor javadoc improvements for StringUtils.stripToNull(String) and > StringUtils.stripToEmpty(String) methods; see attached svn diff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-270) [lang] minor javadoc improvements for StringUtils.stripXxx() methods
[lang] minor javadoc improvements for StringUtils.stripXxx() methods Key: LANG-270 URL: http://issues.apache.org/jira/browse/LANG-270 Project: Commons Lang Type: Improvement Versions: 2.1 Reporter: Michael Heuer Priority: Trivial Attachments: diff.txt Minor javadoc improvements for StringUtils.stripToNull(String) and StringUtils.stripToEmpty(String) methods; see attached svn diff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/6/06, Phil Steitz <[EMAIL PROTECTED]> wrote: On 7/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > Have added csv. How do I go about hooking it up, doesn't look as > though it worked last night? > The script was not creating directories on the deploy host for new components, so it failed the first time. I fixed that and it ran successfully last night. Thanks Phil. Any thoughts on having the Maven ones do a snapshot deploy to the snapshot repository? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-215) Javadoc in DefaultedMap very inconsistent
[ http://issues.apache.org/jira/browse/COLLECTIONS-215?page=all ] Hendrik Maryns updated COLLECTIONS-215: --- Attachment: DefaultedMap.diff A patch including the alterations I mean. -> changed names of parameters -> changed type of value -> changed implementation of get(Object) -> made Javadocs more consistent > Javadoc in DefaultedMap very inconsistent > - > > Key: COLLECTIONS-215 > URL: http://issues.apache.org/jira/browse/COLLECTIONS-215 > Project: Commons Collections > Type: Improvement > Versions: 3.2 > Reporter: Hendrik Maryns > Attachments: DefaultedMap.diff > > The javadocs in DefaultedMap is very inconsistent. It speaks > of factory > when a transformer is meant, it speaks of transformer when value is > meant and that sort of stuff. > > Besides, it would be much cleaner to declare 'value' of type > Transformer, and create a transformer every time, except when one is > passed (the instanceof checks are wrong anyway), (I'd rename it to > transformer, too). > > Even nicer would be to split up the constructor(s) into one > that takes a > value, and one that takes a Transformer, no instanceof checks needed, > much cleaner code, generification is almost trivial :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-215) Javadoc in DefaultedMap very inconsistent
Javadoc in DefaultedMap very inconsistent - Key: COLLECTIONS-215 URL: http://issues.apache.org/jira/browse/COLLECTIONS-215 Project: Commons Collections Type: Improvement Versions: 3.2 Reporter: Hendrik Maryns The javadocs in DefaultedMap is very inconsistent. It speaks of factory when a transformer is meant, it speaks of transformer when value is meant and that sort of stuff. Besides, it would be much cleaner to declare 'value' of type Transformer, and create a transformer every time, except when one is passed (the instanceof checks are wrong anyway), (I'd rename it to transformer, too). Even nicer would be to split up the constructor(s) into one that takes a value, and one that takes a Transformer, no instanceof checks needed, much cleaner code, generification is almost trivial :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Nightlies are back...mostly
On 7/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: Have added csv. How do I go about hooking it up, doesn't look as though it worked last night? The script was not creating directories on the deploy host for new components, so it failed the first time. I fixed that and it ran successfully last night. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBUTILS-17) [dbutils] ScalarHandler subclasses that return Integers and Longs
[ http://issues.apache.org/jira/browse/DBUTILS-17?page=comments#action_12419487 ] greg hawkes commented on DBUTILS-17: No problem, Henri. I assume that you're referring to issue http://issues.apache.org/jira/browse/DBUTILS-27. I realise that this issue tackles a similar problem to my own, but I believe that mine is a more general solution to a wider range of problems. In fact, DBUTILS-27 would be simple to implement using a call to my IntScalarHandler routine. > [dbutils] ScalarHandler subclasses that return Integers and Longs > - > > Key: DBUTILS-17 > URL: http://issues.apache.org/jira/browse/DBUTILS-17 > Project: Commons DbUtils > Type: Improvement > Environment: Operating System: All > Platform: All > Reporter: greg hawkes > Priority: Minor > Fix For: 1.1 > Attachments: IntScalarHandler.java, LongScalarHandler.java > > I (and, looking around, many other people) most often use ScalarHandler to > fetch > the result of an SQL count(*) column. ScalarHandler works, but I was forever > needing to parse the result to create an Integer (and occasionally, a Long) > value. Several possible solutions have been proposed to make this task easier. > This is mine. > I have extended ScalarHandler to create IntScalarHandler and > LongScalarHandler, > which return Integers and Longs, respectively. Their usage is exactly the same > as ScalarHandler. They have been tested on Oracle, MS-SQL Server, and > PostgreSQL > databases, and have proven to be very effective. I hope that they can be > included in the DbUtils distribution, where they fit right alongside the > existing ScalarHandler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-150) [jci][GSOC] Status patchs
[ http://issues.apache.org/jira/browse/SANDBOX-150?page=all ] Peter Konstantinov updated SANDBOX-150: --- Attachment: jci-06.07.06.patch Configuration javac, parsing of result of compilation, preservation of results of compilation, fix classloader > [jci][GSOC] Status patchs > - > > Key: SANDBOX-150 > URL: http://issues.apache.org/jira/browse/SANDBOX-150 > Project: Commons Sandbox > Type: New Feature > Components: JCI > Reporter: Dmitriy Khayredinov > Assignee: Torsten Curdt > Attachments: jci-06.07.06.patch, jci-14.06.06.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 20 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-WARNING- Overriding Maven properties:
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
-WARNING- No directory
[/usr/local/gump/public/workspace/commons-jelly/target/test-reports]
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-06072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-06072006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] public CommandLine parseCommandLineOptions(String[] args)
throws ParseException {
[javac]
^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:67:
cannot find symbol
[javac] symbol : class CommandLine
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] CommandLine cmdLine = null;
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:70:
cannot find symbol
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] } catch (ParseException e) {
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org
[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 20 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-WARNING- Overriding Maven properties:
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
-WARNING- No directory
[/usr/local/gump/public/workspace/commons-jelly/target/test-reports]
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-06072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-06072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-06072006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] public CommandLine parseCommandLineOptions(String[] args)
throws ParseException {
[javac]
^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:67:
cannot find symbol
[javac] symbol : class CommandLine
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] CommandLine cmdLine = null;
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:70:
cannot find symbol
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] } catch (ParseException e) {
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org
[EMAIL PROTECTED]: Project commons-jelly (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly has an issue affecting its community integration. This issue affects 58 projects, and has been outstanding for 20 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cargo : Cargo provides a Java API to manipulate Java Containers - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - htmlunit : A tool for testing web based applications - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-framework-12 : Cactus Framework (J2EE 1.2) - jakarta-cactus-framework-13 : Cactus Framework (J2EE 1.3) - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-12 : Cactus Servlet Sample (J2EE 1.2) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jaxme2 - jaxmeapi - jaxmejs - jaxmexs - maven : Project Management Tools - maven-bootstrap : Project Management Tools - portals-jetspeed-1 : Enterprise Information Portal - strutstestcase : An extension of the standard JUnit TestCase class that provi... Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-06072006.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/loca
[EMAIL PROTECTED]: Project commons-jelly (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly has an issue affecting its community integration. This issue affects 58 projects, and has been outstanding for 20 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cargo : Cargo provides a Java API to manipulate Java Containers - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - htmlunit : A tool for testing web based applications - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-framework-12 : Cactus Framework (J2EE 1.2) - jakarta-cactus-framework-13 : Cactus Framework (J2EE 1.3) - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-12 : Cactus Servlet Sample (J2EE 1.2) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jaxme2 - jaxmeapi - jaxmejs - jaxmexs - maven : Project Management Tools - maven-bootstrap : Project Management Tools - portals-jetspeed-1 : Enterprise Information Portal - strutstestcase : An extension of the standard JUnit TestCase class that provi... Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-06072006.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/loca
svn commit: r419475 - /jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
Author: imario
Date: Thu Jul 6 00:17:42 2006
New Revision: 419475
URL: http://svn.apache.org/viewvc?rev=419475&view=rev
Log:
avoid class cast exception if file object is decorated
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
Modified:
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java?rev=419475&r1=419474&r2=419475&view=diff
==
---
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
(original)
+++
jakarta/commons/proper/vfs/trunk/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
Thu Jul 6 00:17:42 2006
@@ -29,6 +29,7 @@
import org.apache.commons.vfs.util.MonitorInputStream;
import org.apache.commons.vfs.util.MonitorOutputStream;
import org.apache.commons.vfs.util.RandomAccessMode;
+import org.apache.commons.vfs.util.FileObjectUtils;
import java.io.IOException;
import java.io.InputStream;
@@ -170,7 +171,7 @@
*/
private void getInfo(boolean flush) throws IOException
{
-final FtpFileObject parent = (FtpFileObject) getParent();
+final FtpFileObject parent = (FtpFileObject)
FileObjectUtils.getAbstractFileObject(getParent());
FTPFile newFileInfo;
if (parent != null)
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBUTILS-17) [dbutils] ScalarHandler subclasses that return Integers and Longs
[ http://issues.apache.org/jira/browse/DBUTILS-17?page=all ] Henri Yandell updated DBUTILS-17: - Bugzilla Id: (was: 38907) Fix Version: 1.1 Deal with in 1.1. There's another issue that deals with the same problem, so might be that this one becomes a WONTFIX. > [dbutils] ScalarHandler subclasses that return Integers and Longs > - > > Key: DBUTILS-17 > URL: http://issues.apache.org/jira/browse/DBUTILS-17 > Project: Commons DbUtils > Type: Improvement > Environment: Operating System: All > Platform: All > Reporter: greg hawkes > Priority: Minor > Fix For: 1.1 > Attachments: IntScalarHandler.java, LongScalarHandler.java > > I (and, looking around, many other people) most often use ScalarHandler to > fetch > the result of an SQL count(*) column. ScalarHandler works, but I was forever > needing to parse the result to create an Integer (and occasionally, a Long) > value. Several possible solutions have been proposed to make this task easier. > This is mine. > I have extended ScalarHandler to create IntScalarHandler and > LongScalarHandler, > which return Integers and Longs, respectively. Their usage is exactly the same > as ScalarHandler. They have been tested on Oracle, MS-SQL Server, and > PostgreSQL > databases, and have proven to be very effective. I hope that they can be > included in the DbUtils distribution, where they fit right alongside the > existing ScalarHandler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
