Gary Gregory schrieb am So., 6. Nov. 2016 um
19:00 Uhr:
> The whole post is interesting. Sounds like a fork is inevitable. So much
> work though...
>
There already is a fork. See [1]
Benedikt
[1] https://github.com/spotbugs/spotbugs
>
> Gary
>
> On Nov 6, 2016 9:32 AM, "Stian Soiland-Reyes"
done: https://issues.apache.org/jira/browse/INFRA-12866
Am 07.11.2016 um 08:13 schrieb Benedikt Ritter:
Hi,
Pascal Schumacher schrieb am So., 6. Nov. 2016
um 10:49 Uhr:
Are you sure this works for commons-io?
I tried a configuration similar to commons-lang, but get:
"remote: You are not au
I think the maintainer of FindBugs replied yesterday to the HackerNews thread
https://news.ycombinator.com/item?id=12885549
Looks like there will be some activity in the next weeks :) hopefully someone
else will be added as project admin too
Bruno
- Original Message -
> From: Stian S
A classic Monty Python "I'm not dead yet!"
Gary
On Mon, Nov 7, 2016 at 11:23 AM, Bruno P. Kinoshita <
brunodepau...@yahoo.com.br.invalid> wrote:
> I think the maintainer of FindBugs replied yesterday to the HackerNews
> thread
> https://news.ycombinator.com/item?id=12885549
>
> Looks like there
On 6 November 2016 at 19:56, Gary Gregory wrote:
> Hi all,
>
> I see ivars left at the package access level. This must be an oversight,
> right?
>
> We can only fix that in 2.0 and a new package. What a bummer!
I'm not sure I understand.
Why would making package-protected fields private affect co
On Mon, Nov 7, 2016 at 4:11 PM, sebb wrote:
> On 6 November 2016 at 19:56, Gary Gregory wrote:
> > Hi all,
> >
> > I see ivars left at the package access level. This must be an oversight,
> > right?
> >
> > We can only fix that in 2.0 and a new package. What a bummer!
>
> I'm not sure I understa
I think it should be access level should be protected, not package-protected.
Is the ivars in CryptoInputStream? Some fields are also needed by its subclass
(not only for the classes in the package), such as CtrCryptoInputStream.
Regards,
Dapeng
-Original Message-
From: Gary Gregory [ma
There are a bunch of ivars that are at the package level. A per-class scan
is warranted IMO.
Gary
On Mon, Nov 7, 2016 at 5:32 PM, Sun, Dapeng wrote:
> I think it should be access level should be protected, not
> package-protected.
>
> Is the ivars in CryptoInputStream? Some fields are also need
I think so. Thank Gary, I will look into it.
Regards,
Dapeng
-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Tuesday, November 8, 2016 9:34 AM
To: Commons Developers List
Subject: Re: [crypto] package access on ivars?
There are a bunch of ivars that are at t
Hi,
I was looking through the pom and notice that [lang] is a dependency of [text],
and the pom references [lang, 3.4]. Does anyone have any problems with
upgrading to 3.5? The only thing that seems at all concerning is the comment in
the code stating:
the meaning of which isn’t enti
Update away. I'm not sure why shading is in the picture though.
Gary
On Mon, Nov 7, 2016 at 6:18 PM, Rob Tompkins wrote:
> Hi,
>
> I was looking through the pom and notice that [lang] is a dependency of
> [text], and the pom references [lang, 3.4]. Does anyone have any problems
> with upgrading
+1 to update away
I think it could be a mistake while creating the initial project structure.
Don't remember why there would be a dependency between [text] and [lang].
>
> From: Gary Gregory
>To: Commons Developers List
>Sent: Tuesday, 8 November 2016 3:53 PM
GitHub user yairzaslavsky opened a pull request:
https://github.com/apache/commons-io/pull/27
[IO-510] Adding ReadAHeadInputStream
Adding ReadAHeadInputStream which acts
similar to BufferedInputStream only it uses
a thread to fill in the buffer with reads
from the interna
On Sun, Nov 6, 2016 at 7:44 AM, Oliver Heger
wrote:
> Hi,
>
> sorry, I don't want to stand in the way of the release. It is just that
> in the past we used to be very careful with artifacts deployed to Maven
> central and their compatibility. When I did alpha and beta releases for
> [configuratio
Le 8 nov. 2016 07:25, "Gary Gregory" a écrit :
>
> On Sun, Nov 6, 2016 at 7:44 AM, Oliver Heger
> wrote:
>
> > Hi,
> >
> > sorry, I don't want to stand in the way of the release. It is just that
> > in the past we used to be very careful with artifacts deployed to Maven
> > central and their comp
Github user asfgit closed the pull request at:
https://github.com/apache/commons-io/pull/26
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is e
Hi Don,
I spent some time yesterday playing with the current code in [text], trying to
count delete/insert/substitutions [1], but it doesn't seem to be very easy - if
possible at all with just two arrays representing the last two rows, instead of
the full matrix.
I see no reason for having you
quoting Chris Lambertus from the ticket:
This needs to be requested on a per-repo basis, as it is not part of our
standard configuration. Right now, there is an auth override for the following
repos.
commons-compress = cn=committers,ou=groups,dc=apache,dc=org
commons-lang = cn=committers,ou=g
Hello everybody,
what about enabling travis-ci for commons-io, so that pull requests are
tested automatically?
I'm willing to do the work if everybody is o.k. with this.
Thanks,
Pascal
-
To unsubscribe, e-mail: dev-unsubsc
I don't think binary compatibility should include package level access, as
long as that package is only used within a single Commons JAR, then we are
free to change those, at least in a new minor release. (I would say even
patch level unless serialisation is used).
In particular, package level acc
2016-11-08 8:33 GMT+01:00 Pascal Schumacher :
> Hello everybody,
>
> what about enabling travis-ci for commons-io, so that pull requests are
> tested automatically?
You can also setup Jenkins to build PRs
https://builds.apache.org/view/S-Z/view/Struts/job/Struts-JDK7-pull-request/
Regards
--
Ł
On Mon, Nov 7, 2016 at 11:29 PM, Pascal Schumacher wrote:
> quoting Chris Lambertus from the ticket:
>
> This needs to be requested on a per-repo basis, as it is not part of our
>> standard configuration. Right now, there is an auth override for the
>> following repos.
>>
>> commons-compress = cn
22 matches
Mail list logo
