[lang][text] New case conversion util
Too weird for lang or text:
public enum LetterCase {
LOWER {
@Override
public String toCaseString(final String source, final Locale
locale) {
return source.toLowerCase(locale);
}
},
UPPER {
@Override
public String toCaseString(final String source, final Locale
locale) {
return source.toUpperCase(locale);
}
};
public abstract String toCaseString(String source, Locale locale);
}
?
Gary
Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)
Hmm, I can drop the rc2, no problem but can you confirm rc3 will be this exact vote with revisions as only change? If so can try next week yes. Le 11 déc. 2017 22:15, "Thomas Vandahl" a écrit : > Hi Romain, > > On 20.11.17 09:15, Romain Manni-Bucau wrote: > > do we have a real blocker on the release? Being said having the RC or > > not now is pointless since the tag is there, are we waiting for > > anything particular? Happy to drop the RC if it brings more confusion > > than it helps. > > Would you please drop RC2 and start a new round with RC3? I abstained > from voting because the vote mail did not follow the rules (SVN > revisions and stuff). Give it another try, ok? > > Bye, Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)
Hi Romain, On 20.11.17 09:15, Romain Manni-Bucau wrote: > do we have a real blocker on the release? Being said having the RC or > not now is pointless since the tag is there, are we waiting for > anything particular? Happy to drop the RC if it brings more confusion > than it helps. Would you please drop RC2 and start a new round with RC3? I abstained from voting because the vote mail did not follow the rules (SVN revisions and stuff). Give it another try, ok? Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BCEL] thread safety
The main issue was the static Repository, but instance based Repositories are available now. On 12/11/2017 11:26 AM, Torsten Curdt wrote: It's been a looong time since I worked on BCEL and my memories might serve me wrong but I think thread safety is something that should not necessarily happen on the BCEL level. BCEL holds a lot of state. Making all that threadsafe - I'd like to see the use cases first as it might come at a cost. BCEL was even using statics to store state - I would suggest to fix that first (if it's still the case). But anyway - my 2 cents from some vague memories. cheers, Torsten On Mon, Dec 11, 2017 at 4:38 PM, Gary Gregory wrote: Thread safety or lack thereof seems to be a recurring theme in BCEL. Is anyone available to take a closer look at what it would take to update the code with thread safety in mind? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BCEL] thread safety
It's been a looong time since I worked on BCEL and my memories might serve me wrong but I think thread safety is something that should not necessarily happen on the BCEL level. BCEL holds a lot of state. Making all that threadsafe - I'd like to see the use cases first as it might come at a cost. BCEL was even using statics to store state - I would suggest to fix that first (if it's still the case). But anyway - my 2 cents from some vague memories. cheers, Torsten On Mon, Dec 11, 2017 at 4:38 PM, Gary Gregory wrote: > Thread safety or lack thereof seems to be a recurring theme in BCEL. > > Is anyone available to take a closer look at what it would take to update > the code with thread safety in mind? > > Gary >
Re: [All] "Commons Math" is not a component
On Dec 11, 2017 09:17, "Stephen Colebourne" wrote: This all seems reasonable. One things I'd suggest is getting at least one new component to a full release as soon as possible to demonstrate that the plan can work. This suggests that step 1 involves a full release for [numbers] Right, get the plan in motion, one step at a time and let the community iterate and opine. Gary Stephen On 9 December 2017 at 01:59, Gilles wrote: > Hi all. > > Stephen Colebourne correctly summarized the situation[1]: > Project management must be based on life-cycle, not the > other way around. > > Here below, a concrete plan is proposed in answer to the > suggestion (of a fork) made by Martijn Verburg[2]. > > 1. Initial (beta?) release of "Commons Numbers".[3][4] > 2. Create separate git repositories for functionalities >that have independent life-cycles and move the codes >out of "Commons Math". > 3. Modularize "Commons Math" into >a. A set of "supported" modules: functionalities having > undergone a review in order to define a stable API. >b. A set of "experimental"/"beta" modules: functionalities > that have been modified since the last release (e.g. > bug fixes[5]) but are expected to undergo API changes. >c. A "legacy" module for heavily used functionalities known > to harbour difficult design issues. > 4. Initial (beta?) release of codes in category (2) as new >components. > 5. First non-beta release of "Commons Numbers". > 6. Release v4.0 of "Commons Math". > 7. First non-beta release of codes in category (2). > 8. Progressively move code from category (3c) to (3b) and >from (3b) to (3a), or to (2). And RERO accordingly. > > Do you (PMC, committers, developers and users) foresee any > show-stoppers in the above sequence? > > Regards, > Gilles > > [1] http://markmail.org/message/w3imqvbf3wphvokj > [2] http://markmail.org/message/rribnh3tiikqtllf > [3] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git > [4] https://issues.apache.org/jira/projects/NUMBERS > [5] https://issues.apache.org/jira/projects/MATH > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CSV] Release 1.6
There is one minor new feature and a proposed fix for https://issues.apache.org/jira/browse/CSV-219 I'd like some feedback on CSV-219 before releasing. If there is anything you want in a new release, please pipe up. Gary
Re: [All] "Commons Math" is not a component
This all seems reasonable. One things I'd suggest is getting at least one new component to a full release as soon as possible to demonstrate that the plan can work. This suggests that step 1 involves a full release for [numbers] Stephen On 9 December 2017 at 01:59, Gilles wrote: > Hi all. > > Stephen Colebourne correctly summarized the situation[1]: > Project management must be based on life-cycle, not the > other way around. > > Here below, a concrete plan is proposed in answer to the > suggestion (of a fork) made by Martijn Verburg[2]. > > 1. Initial (beta?) release of "Commons Numbers".[3][4] > 2. Create separate git repositories for functionalities >that have independent life-cycles and move the codes >out of "Commons Math". > 3. Modularize "Commons Math" into >a. A set of "supported" modules: functionalities having > undergone a review in order to define a stable API. >b. A set of "experimental"/"beta" modules: functionalities > that have been modified since the last release (e.g. > bug fixes[5]) but are expected to undergo API changes. >c. A "legacy" module for heavily used functionalities known > to harbour difficult design issues. > 4. Initial (beta?) release of codes in category (2) as new >components. > 5. First non-beta release of "Commons Numbers". > 6. Release v4.0 of "Commons Math". > 7. First non-beta release of codes in category (2). > 8. Progressively move code from category (3c) to (3b) and >from (3b) to (3a), or to (2). And RERO accordingly. > > Do you (PMC, committers, developers and users) foresee any > show-stoppers in the above sequence? > > Regards, > Gilles > > [1] http://markmail.org/message/w3imqvbf3wphvokj > [2] http://markmail.org/message/rribnh3tiikqtllf > [3] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git > [4] https://issues.apache.org/jira/projects/NUMBERS > [5] https://issues.apache.org/jira/projects/MATH > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] "Commons Math" is not a component
I think I have some issues WRT "supported" and "unsupported" code that I have mentioned on this list in the past but I do not want to stand in the way of work getting done. So go for it. Our community will voice, hack and vote I hope, with as much energy, diligence, and perseverance as you have shown, which I admire and command you for greatly. Gary On Dec 8, 2017 18:59, "Gilles" wrote: > Hi all. > > Stephen Colebourne correctly summarized the situation[1]: > Project management must be based on life-cycle, not the > other way around. > > Here below, a concrete plan is proposed in answer to the > suggestion (of a fork) made by Martijn Verburg[2]. > > 1. Initial (beta?) release of "Commons Numbers".[3][4] > 2. Create separate git repositories for functionalities >that have independent life-cycles and move the codes >out of "Commons Math". > 3. Modularize "Commons Math" into >a. A set of "supported" modules: functionalities having > undergone a review in order to define a stable API. >b. A set of "experimental"/"beta" modules: functionalities > that have been modified since the last release (e.g. > bug fixes[5]) but are expected to undergo API changes. >c. A "legacy" module for heavily used functionalities known > to harbour difficult design issues. > 4. Initial (beta?) release of codes in category (2) as new >components. > 5. First non-beta release of "Commons Numbers". > 6. Release v4.0 of "Commons Math". > 7. First non-beta release of codes in category (2). > 8. Progressively move code from category (3c) to (3b) and >from (3b) to (3a), or to (2). And RERO accordingly. > > Do you (PMC, committers, developers and users) foresee any > show-stoppers in the above sequence? > > Regards, > Gilles > > [1] http://markmail.org/message/w3imqvbf3wphvokj > [2] http://markmail.org/message/rribnh3tiikqtllf > [3] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git > [4] https://issues.apache.org/jira/projects/NUMBERS > [5] https://issues.apache.org/jira/projects/MATH > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[BCEL] thread safety
Thread safety or lack thereof seems to be a recurring theme in BCEL. Is anyone available to take a closer look at what it would take to update the code with thread safety in mind? Gary
