I just committed the new text.translate package to Lang (r787560, see
LANG-505).
It rips the guts out of StringEscapeUtils and Entities, merges them
into a common paradigm and allows for reusable building blocks so the
answer to "I don't want low unicode escaped in my XML" can be "copy
and paste t
On Fri, Jun 19, 2009 at 9:06 AM, Phil Steitz wrote:
> Mark Thomas wrote:
>
>> Phil Steitz wrote:
>>
>>
>>> Dheeraj Kumar wrote:
>>>
>>>
Hello,
Congratulations on Pool 1.5.1 release.
I was looking for Java 1.5 generics support on Apache Commons Pool and
found out RoadMap
Is configuration2 binary incompatible with configuration (1)? If it
is, then you should consider changing the package name and using:
artifactId: commons-configuration2
groupId: org.apache.commons
This would be for consistency's sake.
On Mon, Jun 22, 2009 at 8:05 PM, Ralph Goers wrote:
> config
configuration2 should use groupId org.apache.commons and an artifactId
of commons-configuration. I am not going to worry about configuration3
- we are still a long way off from completing configuration2.
Ralph
On Jun 22, 2009, at 3:22 PM, Emmanuel Bourg wrote:
Jörg Schaible a écrit :
Simp
Jörg Schaible a écrit :
Simply because the groupId change is a one time action only and will not
scale for configuration3 ;-)
Bah, when Commons Configuration started, Maven didn't have groupIds,
there was a unique id. That was 5 years ago. Configuration 2 is far from
finished, Configuration
Emmanuel Bourg wrote:
> Jörg Schaible a écrit :
>
>> The artifactId *is* the base name of the jar file. If you configure a
>> final name, this has only an effect on the name of the jar in your target
>> directory, but not in any repository (local or remote). Therefore it does
>> not make sense to
Emmanuel Bourg wrote:
> Jörg Schaible a écrit :
>
>> We already discussed this in legnth and the consensus was to have both
>> Senselan and Imaging in the name while the package name is kept.
>
> Hum I missed this discussion. That's fine then.
It would not have been my choice either, but we've
Jörg Schaible a écrit :
The artifactId *is* the base name of the jar file. If you configure a final
name, this has only an effect on the name of the jar in your target
directory, but not in any repository (local or remote). Therefore it does
not make sense to redefine it for a standard project b
Rahul Akolkar wrote:
> On Fri, Jun 19, 2009 at 11:07 AM, Emmanuel Bourg wrote:
>> Ralph Goers a écrit :
>>
>
>>
>>> 2. In all the various logging discussions that have taken place on this
>>> list in the last few months, many initiated by me, the concensus seems
>>> to be that commons logging is
Jörg Schaible a écrit :
We already discussed this in legnth and the consensus was to have both
Senselan and Imaging in the name while the package name is kept.
Hum I missed this discussion. That's fine then.
Emmanuel Bourg
-
Emmanuel Bourg wrote:
> Jörg Schaible a écrit :
>
>> Yes, because then the artifact name is the same as for the 1.x series and
>> it is no longer possible to use both artifacts at the same time with
>> Maven.
>
> As long as the groupId/artifactId for Commons Configuration 1.x and 2.x
> are diffe
Jörg Schaible a écrit :
Yes, because then the artifact name is the same as for the 1.x series and it
is no longer possible to use both artifacts at the same time with Maven.
As long as the groupId/artifactId for Commons Configuration 1.x and 2.x
are different shouldn't they be able to coexist
Emmanuel Bourg wrote:
> That looks nice.
>
> Regarding the community issue, maybe a more explicit name would help
> dragging attention to the project? It's probably easier to understand
> the intent of a "Commons Images" package than "Commons Senselan" (which
> will comes second after "Three witc
Emmanuel Bourg wrote:
> The artifact generated for Commons Configuration 2 is currently:
>
>commons-configuration2-2.0.jar
>
> which could be confused with Commons Configuration 2.2. Is there any
> objection to change it to:
>
>commons-configuration-2.0.jar
Yes, because then the artifa
I now have all testcases passing except for th WebDAV testcases, as
described below. I've created a new issue and attached a patch file with my
proposed changes (note this also contains the fix for VFS-245):
https://issues.apache.org/jira/browse/VFS-266
What are the next steps from here?
On M
I fixed the HTTP failure by disabling the "welcome" page in welcome.conf (I
don't know if this is standard Apache configuration or something peculiar to
CentOS). All of the HTTP tests are now passing with my changes.
For the WebDAV failure, this is what I see in the access_log file:
192.168.200.1
Guillaume Nodet a écrit :
> FWIW, looking at [1], I've spotted the following bug:
>
>/** A fraction representing "4/5". */
> public static final Fraction TWO_FIFTHS = new Fraction(4, 5);
>
> Looks like a bad copy / paste error.
>
> [1]
> http://svn.apache.org/repos/asf/commons/proper/ma
The artifact generated for Commons Configuration 2 is currently:
commons-configuration2-2.0.jar
which could be confused with Commons Configuration 2.2. Is there any
objection to change it to:
commons-configuration-2.0.jar
Emmanuel Bourg
--
That looks nice.
Regarding the community issue, maybe a more explicit name would help
dragging attention to the project? It's probably easier to understand
the intent of a "Commons Images" package than "Commons Senselan" (which
will comes second after "Three witches watch three Swatch watches"
FYI.
Craig
Begin forwarded message:
From: Craig L Russell
Date: June 21, 2009 7:11:48 PM PDT
To: Incubator
Subject: [VOTE] Graduation for Sanselan
Reply-To: gene...@incubator.apache.org
Hi,
Sanselan has been in incubation since September 2007. Sanselan is a
pure-java image library for re
FWIW, looking at [1], I've spotted the following bug:
/** A fraction representing "4/5". */
public static final Fraction TWO_FIFTHS = new Fraction(4, 5);
Looks like a bad copy / paste error.
[1]
http://svn.apache.org/repos/asf/commons/proper/math/trunk/src/java/org/apache/commons/math/fr
On 22/06/2009, sebb wrote:
> On 22/06/2009, Siegfried Goeschl wrote:
> > Hi Mark,
> >
> > the intention is to CLEARLY use a invalid URI/URL to cause some
> > exceptions during regression tests - during the last RC we had issues
> > with OpenDNS and using ".invalid" was the agreed workarou
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-email has an issue affecting its community integration.
This issue
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-configuration-test has an issue affecting its community
integrati
Siegfried Goeschl wrote:
Hi Emmanuel,
see my comments below ...
Cheers,
Siegfried Goeschl
Emmanuel Bourg wrote:
A few comments:
- 1.0-rc6-SNAPSHOT is still mentioned as "in svn" in the change notes.
I guess the changes for the two 1.0-rc could be merged into the
changes for 1.0
I g
Hi Emmanuel,
see my comments below ...
Cheers,
Siegfried Goeschl
Emmanuel Bourg wrote:
> A few comments:
>
> - 1.0-rc6-SNAPSHOT is still mentioned as "in svn" in the change notes.
> I guess the changes for the two 1.0-rc could be merged into the
> changes for 1.0
I guess that would be bending o
On 22/06/2009, Siegfried Goeschl wrote:
> Hi Mark,
>
> the intention is to CLEARLY use a invalid URI/URL to cause some
> exceptions during regression tests - during the last RC we had issues
> with OpenDNS and using ".invalid" was the agreed workaround (which did
> not work either)
The use of
Hi Mark,
the intention is to CLEARLY use a invalid URI/URL to cause some
exceptions during regression tests - during the last RC we had issues
with OpenDNS and using ".invalid" was the agreed workaround (which did
not work either)
See http://tools.ietf.org/html/rfc2606
=== QUOTE from RFC2006 ===
On 22/06/2009, Mark Struberg wrote:
>
> Hi Ziggi!
>
>
> > +) using "http://example.invalid"; for a bad url
>
>
> hmm, sorry if I missed the point, but what exactly is wrong with that very
> URI? The 'invalid' tld? What about 'local' URIs for e.g. company internal
> resources? Remember our mave
On 22/06/2009, billbar...@apache.org wrote:
> Author: billbarker
> Date: Mon Jun 22 00:26:09 2009
> New Revision: 787118
>
> URL: http://svn.apache.org/viewvc?rev=787118&view=rev
> Log:
> Yes, sebb is correct. After running tests, readResolve needs to be visible
> to subclasses to be used.
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-math has an issue affecting its community integration.
This issue
31 matches
Mail list logo
