>> Perhaps someone could add the source/target properties?
>
> No idea how to do that and the POM reference didn't tell me either.
> Please forgive the mvn neophyte.
Here it is:
https://issues.apache.org/jira/browse/SANDBOX-288
You have to check the compiler-plugin for the information:
http://mav
> I put everything concerning the magic number issue into this jira issue:
>
> https://issues.apache.org/jira/browse/SANDBOX-285
>
> Is this sufficient?
>
> I am still investigating the second issue, reading from the stream
> directly works fine, but it fails if it is wrapped into a InputStreamRead
On 2009-02-11, sebb wrote:
> The Compress pom.xml does not specify what Java version is being
> targetted.
Last week it was 1.4
> Perhaps someone could add the source/target properties?
No idea how to do that and the POM reference didn't tell me either.
Please forgive the mvn neophyte.
Stefan
On 2009-02-11, sebb wrote:
> That seems likely to produce some confusion - would it not be better
> to default to UTF-8?
Yes, that's been my initial question. Is it OK to have no default at
all or should we keep with UTF-8?
Given that ZipArchiveInputStream doesn't support anything but UTF-8 at
The Compress pom.xml does not specify what Java version is being targetted.
Perhaps someone could add the source/target properties?
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev
On 11/02/2009, Stefan Bodewig wrote:
> On 2009-02-11, Torsten Curdt wrote:
>
> > I am also not so sure this really all that bad. I guess there are 3
> scenarios
>
> > 1: the archive standard is known to use a specific encoding
> > 2: the encoding is specified inside the archive (which is simi
I fixed the second issue and reported it here:
https://issues.apache.org/jira/browse/SANDBOX-286
Again, is this sufficient?
Kind regards,
Ingo
Ingo Rockel schrieb:
> Torsten Curdt wrote:
>>> Is there any interest in these patches?
>> Please - bring them on and file them in jira ! :)
>>
Torsten Curdt wrote:
>> Is there any interest in these patches?
>
> Please - bring them on and file them in jira ! :)
>
I put everything concerning the magic number issue into this jira issue:
https://issues.apache.org/jira/browse/SANDBOX-285
Is this sufficient?
I am still investigating the se
On 2009-02-11, Torsten Curdt wrote:
> I am also not so sure this really all that bad. I guess there are 3 scenarios
> 1: the archive standard is known to use a specific encoding
> 2: the encoding is specified inside the archive (which is similar to 1)
> 3: we have no clue about the encoding of t
> Is there any interest in these patches?
Please - bring them on and file them in jira ! :)
> Or is the commons-compress
> project dead?
No, it's not ... it just got it's make-over and more people seem to be
interested in it :)
> I hope this list is the right place to address this issue to.
De
Hi,
I just fixed a bug with a wrong magic number for bzip2 files in
commons-compress, it checked for 'h' as first byte but it has to be
'BZh' in the first three bytes according to
http://en.wikipedia.org/wiki/Bzip2
which works fine for bzip2-compressed files (the check for 'h' did not).
I'm curre
Do you mean a CIDR calculator?
If so, I put a rudimentary implementation into [net] 2.0 last year.
See the implementation here:
http://svn.apache.org/viewvc/commons/proper/net/branches/NET_2_0/src/main/java/org/apache/commons/net/util/SubnetUtils.java?revision=740965&view=markup
And example us
On Tue, Feb 10, 2009 at 11:09 PM, Rory Winston wrote:
> Sounds great a DNS client was one area I felt could be added to [net]
> for a while now (the other being ssh/scp support).
It's not really a DNS client (although java DNS is notoriously
broken), the code is really a netmask calculator
Rory Winston ha scritto:
Hi Robert
Sounds great a DNS client was one area I felt could be added to
[net] for a while now (the other being ssh/scp support).
Can you point me to the existing client code in james?
If I remember correctly the code Robert is talking about is not a DNS
clie
I've fixed a bunch of bugs in the bugfixing branch. I think I've fixed
all except bug DBUTILS-30/-28 (they're dupes).
https://svn.apache.org/repos/asf/commons/sandbox/dbutils/bugfixing
http://svn.apache.org/viewvc/commons/sandbox/dbutils/bugfixing/
http://svn.apache.org/viewvc/commons/sandbox
I am also not so sure this really all that bad. I guess there are 3 scenarios
1: the archive standard is known to use a specific encoding
2: the encoding is specified inside the archive (which is similar to 1)
3: we have no clue about the encoding of the strings in the archive
Unless I am missing
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-cli has an issue affecting its community integration.
This issue a
17 matches
Mail list logo
