The same applies to changing access modifiers. JUnit 5 encourages use of
package private everything as it’s the least typing and now supported (as in v5
will reflectively allow access to your test code if it’s not public).
—
Matt Sicker
> On Feb 17, 2022, at 19:59, Gary Gregory wrote:
>
> On
On Thu, Feb 17, 2022 at 8:47 PM Itamar C wrote:
> On Thu, Feb 17, 2022 at 8:16 PM Gilles Sadowski
> wrote:
>
> > Which discussion (since this thread covered more than one subject)?
> > If you mean the "migration to Junit 5" task for [Codec], it's already
> > there.[1]
> > If you mean the method
On Thu, Feb 17, 2022 at 8:16 PM Gilles Sadowski
wrote:
> Which discussion (since this thread covered more than one subject)?
> If you mean the "migration to Junit 5" task for [Codec], it's already
> there.[1]
> If you mean the method rename (to remove the "test" prefix), then
> the "dev" ML is wh
Hi.
Le jeu. 17 févr. 2022 à 21:33, Itamar C a écrit :
>
> Hello,
>
> My suggestion: I'll work on the methods without renaming and after the
> migration is completed, if we decide to rename, it's not difficult to
> rename all test methods with a script and put in a new PR.
>
> A simple regexp like
Hello,
My suggestion: I'll work on the methods without renaming and after the
migration is completed, if we decide to rename, it's not difficult to
rename all test methods with a script and put in a new PR.
A simple regexp like
"^\\s*@Test\\s*\n\\s*(.+)\\s+test(\\w)(\\w+)\\s*\\(.*"
changing to
m.
Hello.
Le jeu. 17 févr. 2022 à 16:18, Gary Gregory a écrit :
>
> Well, it is explicitly in the sense that I would guess that 95% of the test
> methods in Commons follows that style and that one our documented
> guidelines is "follow the style of the file you are editing".
When migrating to the n
Well, it is explicitly in the sense that I would guess that 95% of the test
methods in Commons follows that style and that one our documented
guidelines is "follow the style of the file you are editing".
Gary
On Thu, Feb 17, 2022, 09:16 Gilles Sadowski wrote:
> Hello.
>
> Le jeu. 17 févr. 2022
Hello.
Le jeu. 17 févr. 2022 à 13:11, Gary Gregory a écrit :
>
> I have encountered what Sebb mentions more than once, I do like the "test"
> prefix to make it obvious what is and is not intended to be a test. Same
> reason I like to make test methods public: clear intent. I know Junit 5
> propos
I have encountered what Sebb mentions more than once, I do like the "test"
prefix to make it obvious what is and is not intended to be a test. Same
reason I like to make test methods public: clear intent. I know Junit 5
proposes to change these conventions, the benefit do not outweigh the
conventio
On Thu, 17 Feb 2022 at 01:16, Gilles Sadowski wrote:
>
> Hello.
>
> > [...]
> >
> > One more practical question: since the tests are not anymore based on the
> > methods name and are indicated by annotations now, I've seen tests without
> > this "test" in the beginning. Looks like common practice
I suggest just migrate 1 or 2 tests first, and create a pr, and we discuss
it there.
Discussing without codes seems hollow.
Gilles Sadowski 于2022年2月17日周四 09:16写道：
> Hello.
>
> > [...]
> >
> > One more practical question: since the tests are not anymore based on the
> > methods name and are indic
Hello.
> [...]
>
> One more practical question: since the tests are not anymore based on the
> methods name and are indicated by annotations now, I've seen tests without
> this "test" in the beginning. Looks like common practice (including it's
> the way it's presented in the JUnit 5 docs). Since
Please do not remove "test" from method names, it's the convention we use
today, there is no reason to make a PR noisier than it has to be. Recall
that a human has to do a review ;-)
TY,
Gary
On Wed, Feb 16, 2022, 19:28 Itamar C wrote:
> >
> > > There is too much information and some of them ar
>
> > There is too much information and some of them are inconsistent. For
> > example:
> > https://issues.apache.org/jira/projects/CODEC/issues/CODEC-286 is open
> > but
> > https://github.com/apache/commons-codec/pull/40 is closed
> >
> > Maybe there should be a better integration between GH and
Commons VFS needs help migrating to Junit 5. It still has tests on Junit 3.
Gary
On Wed, Feb 16, 2022, 13:11 Matt Sicker wrote:
> IntelliJ has a useful feature for helping automate migration of JUnit
> tests. Works wherever you have tests that don't use rules or
> parameterized tests (those nee
IntelliJ has a useful feature for helping automate migration of JUnit
tests. Works wherever you have tests that don't use rules or
parameterized tests (those need to be manually migrated still).
On Wed, Feb 16, 2022 at 9:17 AM Alex Herbert wrote:
>
> On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski
On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski wrote:
> > I've finally found that CODEC-285 is an issue that maybe I can help
> > (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm not sure
> > from where I should start: create a branch from the master or from some
> > branch in thos
Hello.
Le mer. 16 févr. 2022 à 15:05, Itamar C a écrit :
>
> That's my first message on this list, but I've been reading the messages
> for some months.
>
> I'm interested in contributing to Apache Commons, but it was a little
> confusing to find where to help. Some of the issues in Jira are very
That's my first message on this list, but I've been reading the messages
for some months.
I'm interested in contributing to Apache Commons, but it was a little
confusing to find where to help. Some of the issues in Jira are very old,
but not solved. It's difficult for a newcomer like me to underst
Le lun. 14 févr. 2022 à 16:11, Xeno Amess a écrit :
>
> > Code not actively developed does not attract newcomers.
> Well I have to say the reason for "codes not actively developed" is a
> strong lack of alive committers, or more detailed, reviewers.
In part, yes, but they are the consequence of
Hello.
Le lun. 14 févr. 2022 à 16:46, Xeno Amess a écrit :
>
> (sigh) Do you think make some public activities would help? Like helding
> some online summer camp or something?
Well, there is, at least, GSoC.
Yet, AFAIK, there is no prior thinking about how to respond to
such initiatives, not eve
(sigh) Do you think make some public activities would help? Like helding
some online summer camp or something?
> it is a request in a queue
And it is actually not a queue, but a mixture of stack and priority queue.
When we meet some very important prs like critical bug fix or safety
things, we will review them first.
But for normal prs, actually we treat prs like stack.
Two prs with the same importance, o
> Remember that creating a PR is not a guarantee of anything, it is a
request
in a queue, a queue managed by volunteers.
Yes, legally and mortally it is.
But if we get more reviewers I think it will help the repos be more popular.
The tough thing is I totally have no idea how to get us some more
Remember that creating a PR is not a guarantee of anything, it is a request
in a queue, a queue managed by volunteers.
Gary
On Mon, Feb 14, 2022, 10:12 Xeno Amess wrote:
> > Code not actively developed does not attract newcomers.
> Well I have to say the reason for "codes not actively develope
> Code not actively developed does not attract newcomers.
Well I have to say the reason for "codes not actively developed" is a
strong lack of alive committers, or more detailed, reviewers.
I have still 100+ unsolved prs in commons projects, some of which be 1 or 2
years ago, but it seems there ju
Le lun. 14 févr. 2022 à 14:34, Gary Gregory a écrit :
>
> My guess is that this is a combination of the maturity of the components
The "maturity" rationale is not an explanation; it is a cause.
Code not actively developed does not attract newcomers.
It is not an "opinion" anymore; it is backed by
My guess is that this is a combination of the maturity of the components
and people having moved on to jobs or hobbies that no longer requires these
components.
Gary
On Mon, Feb 14, 2022, 08:32 Xeno Amess wrote:
> > [2] Backed by the numbers provided the project's report to the ASF
> board (wh
> [2] Backed by the numbers provided the project's report to the ASF
board (where the number of "committers" is utterly misleading wrt
its actual effect on maintenance capacity).
I'm also interested in why there are so many committers while small
amounts of which really do commit during these yea
Hello.
Le lun. 14 févr. 2022 à 00:23, GitBox a écrit :
>
>
> nhojpatrick commented on pull request #104:
> URL: https://github.com/apache/commons-codec/pull/104#issuecomment-1038472244
>
>
>@garydgregory i agree it could be considered clutter. If all projects are
> kept active current it's n
30 matches
Mail list logo
