On Fri, May 15, 2009 at 6:44 PM, Phil Steitz wrote:
> Christian Grobmeier wrote:
>>
>> Dear Commons-Folks,
>>
>> Yonik Seeley and I propose the creation of a new Sandbox component
>> within Apache Commons. We would like to name it Commons JSON since it
>> should deal with everything around JSON.
>
On Fri, May 15, 2009 at 2:36 AM, Ceki Gulcu wrote:
>
> Henri Yandell wrote:
>> We got into this mess because there wasn't a solution and we needed
>> something for Commons libraries. Personally I think there is gain in
>> gently end of lifeing Commons Logging in favour of a focused logging
>> pro
Ted Dunning wrote:
Phil, I think we have much of the same desires and motivations, but we seem
to come to somewhat, but not entirely different conclusions.
Assuming that (1) can be dealt with and assuming that (3) is already dealt
with, do you still mind the inclusion of *optional*, automaticall
Christian Grobmeier wrote:
Dear Commons-Folks,
Yonik Seeley and I propose the creation of a new Sandbox component
within Apache Commons. We would like to name it Commons JSON since it
should deal with everything around JSON.
Yonik did already implement a JSON-Parser in Apache Labs name Noggit:
Phil, I think we have much of the same desires and motivations, but we seem
to come to somewhat, but not entirely different conclusions.
Assuming that (1) can be dealt with and assuming that (3) is already dealt
with, do you still mind the inclusion of *optional*, automatically generated
native co
Luc Maisonobe wrote:
Ted Dunning a écrit :
On Thu, May 14, 2009 at 3:18 AM, Sam Halliday wrote:
I am a maintainer of the matrix-toolkits-java
Which is an impressive piece of work, especially the transparent but
non-binding interface to the Atlas and Blas native packages. My co
The artifacts look good, the build works fine with JDK 1.4 and 1.6.
I think md5 checksums are required for all artifacts. They are currently
missing.
The PMD report contains a bunch of errors. I also ran findbugs and got
32 errors. None of them seem to be critical, so this is not a blocker.
Hi there,
after thinking a longer time about the thing with CLI2 which i had asked
for i would like to suggest to improve the project ...
I'm willing to invest the time to the project...
The most important thing for me is that CLI2 has a thing like
command Options
So the first thing i would
sebb wrote:
On 15/05/2009, nicolas de loof wrote:
I'm +1 to have a 0.0 version in central under commons-logging groupId.
- this can't break the LATEST rule
- this will only apply if user explicitly declare this version as dependency
(or dependencyManagement)
- this don't break the existin
If you using the maven, than have you the dependencies to common-chain
and automatically dependency to servlet api. Ok, you can es excluded
with maven. But you have a code with possible Errors.
Niall Pemberton schrieb:
On Fri, May 15, 2009 at 8:28 AM, Alexander Vaysberg wrote:
Hi,
i like
On Fri, May 15, 2009 at 8:28 AM, Alexander Vaysberg wrote:
> Hi,
> i like the common-chain. That is a simple and nice. But chain in one jar has
> a problem. The chain has a dependency to servlet api. I think this not gut.
> The better was it separate to chain-core.jar (for project without servlet
On 15/05/2009, nicolas de loof wrote:
> I'm +1 to have a 0.0 version in central under commons-logging groupId.
> - this can't break the LATEST rule
> - this will only apply if user explicitly declare this version as dependency
> (or dependencyManagement)
> - this don't break the existing commo
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
I'm +1 to have a 0.0 version in central under commons-logging groupId.
- this can't break the LATEST rule
- this will only apply if user explicitly declare this version as dependency
(or dependencyManagement)
- this don't break the existing commosn-logging user-base
- this avoid introducing some th
Henri Yandell wrote:
On Thu, May 14, 2009 at 7:46 AM, Ceki Gulcu wrote:
Hi Ralph and co,
The issue has been raised on the Maven list about 5 times, and if I
remember correctly, it was raised by yourself once or twice. However,
I am not aware of any progress on the issue.
Anyway, my request i
> I am a new in dev group and I don't how I it's make? Can you me help with
> this?
Please read this:
http://commons.apache.org/patches.html
basically it says you should check out the component, do your mod and
then create the patch. If you use eclipse, it has some cool features
in the context me
I am a new in dev group and I don't how I it's make? Can you me help
with this?
Christian Grobmeier schrieb:
i like the common-chain. That is a simple and nice. But chain in one jar has
a problem. The chain has a dependency to servlet api. I think this not gut.
The better was it separate to chai
> i like the common-chain. That is a simple and nice. But chain in one jar has
> a problem. The chain has a dependency to servlet api. I think this not gut.
> The better was it separate to chain-core.jar (for project without servlet
> api) and chain- web.jar(for web.). And with maven module was si
*bounce*
Generified!
Sure there's probably some left to go, but this feels very happy :)
On Fri, May 15, 2009 at 12:36 AM, Henri Yandell (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Henri Yan
Hi,
from version 5 the apache POM uses Nexus instance (
https://repository.apache.org/content/repositories/snapshots) as
snapshotRepository.
Is there any plan to upgrade commons-*-parent POMs to apache:6 to use this
infrastructure for SNAPSHOT deployment ?
Cheers,
Nicolas
Hi,
i like the common-chain. That is a simple and nice. But chain in one jar
has a problem. The chain has a dependency to servlet api. I think this
not gut. The better was it separate to chain-core.jar (for project
without servlet api) and chain- web.jar(for web.). And with maven
module was s
21 matches
Mail list logo
