On 14/12/2011 23:12, sebb wrote:
> On 14 December 2011 22:22, Mark Thomas wrote:
>> On 14/12/2011 19:12, sebb wrote:
>>> On 14 December 2011 18:29, Mark Thomas wrote:
JNDI assumes resources are essentially beans i.e. have zero argument
constructors and getters/setters. If this is not th
The intended purpose is to be able to format Strings with text intermixed with
variable String values that conform to correct punctuation.
i.e.
Building up the correct display String depending on which variables are
correctly entered.
"Please specify the following: " followed by a comma delimit
package util.lang;
import org.apache.commons.lang.StringUtils;
public class EnhancedBuilder {
private StringBuilder builder = new StringBuilder();
private String previous = null;
private boolean first = true;
private boolean finaliz
On 15 December 2011 08:26, Mark Thomas wrote:
> On 14/12/2011 23:12, sebb wrote:
>> On 14 December 2011 22:22, Mark Thomas wrote:
>>> On 14/12/2011 19:12, sebb wrote:
On 14 December 2011 18:29, Mark Thomas wrote:
> JNDI assumes resources are essentially beans i.e. have zero argument
>>>
On 15 December 2011 03:32, William Speirs wrote:
> Anyone have any idea on this? Should I be seeing basic auth for my
> challenge? Where can I set the password as I was never prompted to
> enter it.
>
> At this point, can someone else deploy RC1 while I figure out what is
> wrong on my end?
I don
On 15 December 2011 08:37, Darryl Smith wrote:
> The intended purpose is to be able to format Strings with text intermixed
> with variable String values that conform to correct punctuation.
>
The normal route for enhancement requests is via the issue tracker, i.e. JIRA
http://commons.apache.org/
On 15 December 2011 10:30, wrote:
> Author: ebourg
> Date: Thu Dec 15 10:30:01 2011
> New Revision: 1214691
>
> URL: http://svn.apache.org/viewvc?rev=1214691&view=rev
> Log:
> Removed unnecessary final modifiers
Why?
> Modified:
>
> commons/proper/cli/trunk/src/main/java/org/apache/commons/
Le 15/12/2011 11:36, sebb a écrit :
Removed unnecessary final modifiers
Why?
As stated, because these method parameters don't need to be final.
final should always be used where possible on fields.
Both to document that the field is not intended to be entirely
replaced, and also to help
On 15 December 2011 10:56, Emmanuel Bourg wrote:
> Le 15/12/2011 11:36, sebb a écrit :
>
>
>>> Removed unnecessary final modifiers
>>
>>
>> Why?
>
>
> As stated, because these method parameters don't need to be final.
>
>
>
>> final should always be used where possible on fields.
>>
>> Both to doc
At first glance, I don't know how "general" this is. It seems very
limited in scope. However, I can see how I would have used this in my
code at times. I guess I'm on the fence about this one.
On Thu, Dec 15, 2011 at 3:37 AM, Darryl Smith
wrote:
> The intended purpose is to be able to format S
It would be very similar to how we discussed either using Comparable
objects or providing a Comparator. So, you'd either use Summable (or
whatever it's called) objects or allow the user to provide a
BinaryOperation object (that matches the type of course):
public interface BinaryOperation
{
pub
It seems to me it would be simpler to implement a String format extension for
specifying collections (%l):
“Please specify the following: %l%n“, [Name, Cell, Email Address]
-Adrian
On 12/15/2011 11:25 AM, James Carman wrote:
At first glance, I don't know how "general" this is. It seems very
On Dec 15, 2011, at 4:42, sebb wrote:
> On 15 December 2011 03:32, William Speirs wrote:
>> Anyone have any idea on this? Should I be seeing basic auth for my
>> challenge? Where can I set the password as I was never prompted to
>> enter it.
>>
>> At this point, can someone else deploy RC1 while
On Dec 15, 2011, at 3:38, Darryl Smith
wrote:
The intended purpose is to be able to format Strings with text intermixed
with variable String values that conform to correct punctuation.
i.e.
Building up the correct display String depending on which variables are
correctly entered.
“Please
Hi,
On 15 December 2011 11:35, James Carman wrote:
> public interface BinaryOperation
> {
> public T execute(T operand1, T operand2);
> }
>
> Perhaps we can come up with an interface that combines the two
> aspects. I'm trying to think of mathematically what that would be
> called. By the wa
On Dec 15, 2011, at 6:37, Adrian Crum
wrote:
> It seems to me it would be simpler to implement a String format extension for
> specifying collections (%l):
>
> “Please specify the following: %l%n“, [Name, Cell, Email Address]
>
That feels better to me than a SB wrapper. And much easier to read
Hi all guys,
thanks a lot for the very hight valuable feedbacks, impressive,
without any doubt.
IMHO Matthew's stuff should be absolutely part of a commons component,
if they don't find a home in [graph] at 100%, they should be included
in [math]!!!
Discrete math has always been one of my preferr
We may be modeling the domain properly with all of this terminology, but is
this going to be understandable to the common user?
On Dec 15, 2011 7:38 AM, "Matthew Pocock"
wrote:
> Hi,
>
> On 15 December 2011 11:35, James Carman
> wrote:
>
>
> > public interface BinaryOperation
> > {
> > public T
Hi,
On 15/12/2011 14:20, James Carman wrote:
We may be modeling the domain properly with all of this terminology, but is
this going to be understandable to the common user?
I highly appreciated the last contributions (thanks guys!) but I also
agree on this point, so let's start from the end.
Hi
I promised to start the Sanselan release process early this week, but I've
been having problem after problem:
1. The instructions on http://commons.apache.org/releases/prepare.html say
that you run a variation of "mvn install" to build the release... but this
only generates the .jar files, not
Hi Damjan!
I suggest you approaching the wiki page[1] first to see how components
are released in commons, at least the described method is the one I
follow when proposing RCs.
HTH, have a nice day!
-Simo
[1] http://wiki.apache.org/commons/CreatingReleases
http://people.apache.org/~simonetripod
On 15 December 2011 16:58, Damjan Jovanovic wrote:
> Hi
>
> I promised to start the Sanselan release process early this week, but I've
> been having problem after problem:
>
> 1. The instructions on http://commons.apache.org/releases/prepare.html say
> that you run a variation of "mvn install" to
I use http://wiki.apache.org/commons/UsingNexus
Gary
On Thu, Dec 15, 2011 at 11:58 AM, Damjan Jovanovic wrote:
> Hi
>
> I promised to start the Sanselan release process early this week, but I've
> been having problem after problem:
>
> 1. The instructions on http://commons.apache.org/releases/pr
On 15 December 2011 17:10, sebb wrote:
> On 15 December 2011 16:58, Damjan Jovanovic wrote:
>> Hi
>>
>> I promised to start the Sanselan release process early this week, but I've
>> been having problem after problem:
>>
>> 1. The instructions on http://commons.apache.org/releases/prepare.html say
Hello,
>>
>> Hello,
>> I've tried to make the doc of distribution.FastCosineTranform clearer.
>> I would be grateful for any feedback!
>> Have a nice day!
>> Sébastien
>>
> Some further thoughts: I think the formulas for the "standard" and
> "orthogonal" normalization should be moved to the header
Le 15/12/2011 20:50, Sébastien Brisard a écrit :
> Hello,
>>>
>>> Hello,
>>> I've tried to make the doc of distribution.FastCosineTranform clearer.
>>> I would be grateful for any feedback!
>>> Have a nice day!
>>> Sébastien
>>>
>> Some further thoughts: I think the formulas for the "standard" and
On 15 December 2011 23:13, Henri Biestro (Commented) (JIRA)
wrote:
>
> [
> https://issues.apache.org/jira/browse/JEXL-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170565#comment-13170565
> ]
>
> Henri Biestro commented on JEXL-124:
> ---
On 15 December 2011 23:10, wrote:
> Author: henrib
> Date: Thu Dec 15 23:10:21 2011
> New Revision: 1214986
>
> URL: http://svn.apache.org/viewvc?rev=1214986&view=rev
> Log:
> Fix for JEXL-124
>
> Modified:
>
> commons/proper/jexl/tags/COMMONS_JEXL_2_1-RC3/src/main/java/org/apache/commons/jex
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 gene...@gump.apache.org.
Project commons-exec-test has an issue affecting its community integration.
This i
Hi,
I'm still working on MATH-677, and would like to remove the
IllegalArgumentExceptions thrown if the length of the data set is not
a power of two. I was simply considering throwing
MathIllegalArgumentException, but this is discouraged in the Javadoc.
Can I break this rule, or should I create a N
On 12/15/11 8:57 PM, Sébastien Brisard wrote:
> Hi,
> I'm still working on MATH-677, and would like to remove the
> IllegalArgumentExceptions thrown if the length of the data set is not
> a power of two. I was simply considering throwing
> MathIllegalArgumentException, but this is discouraged in th
On Thu, Dec 15, 2011 at 7:33 PM, sebb wrote:
> On 15 December 2011 17:10, sebb wrote:
> > On 15 December 2011 16:58, Damjan Jovanovic
> wrote:
> >> Hi
> >>
> >> I promised to start the Sanselan release process early this week, but
> I've
> >> been having problem after problem:
> >>
> >> 1. The
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 gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Thank you, this seems like what I needed. It turns out gpg-agent has to be
used to sign.
Unfortunately the Internet bandwidth required to upload all the files is
vast, so a Sanselan release is probably only going to happen in January.
In the meanwhile, does my key have to linked into the web of t
Should not commit that late...
Reverted RC3, applied fix on 2.0 branch.
Thanks for catching this!
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1214986-in-commons-proper-jexl-tags-COMMONS-JEXL-2-1-RC3-src-main-java-org-apache-coma-tp4202553p4203622.htm
I'd say 2.1.1 asap since some JEXL users will not use anything but release
builds.
And if another issue pops up, then a 2.1.2 will be needed (keeping my
fingers crossed)...
Do you or do I publish it ?
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/Re-jira-Commented-JE
36 matches
Mail list logo
