Junit5: Create a quasi-official JUnit 5 extensions project/repository

[smoyer64]

Overview

It turns out that @nicolaiparlog and I have both created Github repositories (https://github.com/CodeFX-org/junit-io and https://github.com/selesy/junit5-extensions respectively) with the intention of curating, enhancing and promoting community-developed JUnit 5 Extensions. This morning (my time at least) we started discussing the idea of merging our projects and sharing the work of creating the tools that extend JUnit 5 in small but broad ways.

I don't expect that large extensions or engine developers will be interested in this at all, but I think that for the smaller projects, collecting the commonly needed functions into one project will allow it to share the "project infrastructure". For Extensions that are only a class or two, who want's to maintain an entire project?

• ( ) Proposal. Create a quasi-official repository under the junit-team group for community-developed JUnit 5 extensions. Publish these extensions to Maven central with org.junit.jupiter.community (or something else so long as it's obviously not part of the core system), and work to align the code quality, style and conventions with the core JUnit 5 project. Nicolai and I are volunteering to be the initial curators/committers as time permits.

Nicolai and I will be talking at some point next week to discuss how to best merge the code we've both been working on and one of the topics is where to put the project. I thought his project's name was superior but he pointed out that it's too ambiguous to do well with search engines.

I see a lot of advantages to having a "non-core" team. The core team won't be burdened by the additional code or by managing additional contributions. The JUnit 5 adopters will have a central location to look for extensions that they need and, it's my belief that as more use-cases are explored, we'll prove out the underlying design of JUnit 5, and can help drive the framework's future. For me, the last week of working on #343 has shown that the best way to wring out new code is to get it into use. Sorry for the deluge of issues and PRs.

Thanks for the consideration!

[marcphilipp]

Makes sense IMHO if these extensions are small and there are designated curators (as you suggested). Otherwise, finding a release strategy and keeping consistency would be very hard.

@junit-team/junit-committers What do you guys think?

[TimvdLippe]

This was also discussed in https://github.com/junit-team/junit5/issues/321 For Mockito this still is an open question where we put our extension.

[smoyer64]

@TimvdLippe

Since the Mockito project provides already provides a JUnit 4 @Rule I guess I would have expected the Mockito Extension would be part of Mockito. If I were one of the curators, I'd tend to prefer hosting small utility extensions and would want to avoid being the mediator between two much bigger projects (in this case JUnit and Mockito).

I'm not trying to single out Mockito either ... I'm hoping to push the CDI (Weld) extension I mentioned in another issue back into the weld project and the upRest framework I'm working on will probably remain standalone. On the other hand, the conditional test execution extensions I've been working on have no outside dependencies and would be useful to a much broader community - it's those types of extensions I'm looking to aggregate. Note that it's still going to take some packaging work to make sure we don't end up with a behemoth JAR.

On a personal note, JUnit + Mockito with some CDI thrown in is my favorite environment - Thanks so much for providing JUnit's "better half" (no disrespect to JUnit - in a great marriage, each of the partners thinks of the other as their better half).

[kcooney]

I am fine with junit-team hosting a repository of smaller general utilities
if we have dedicated maintainers. I also agree that libraries like Mockito
and Spring should ideally host their own extensions.

In the past, we have avoided having JUnit itself have many extensions (even
general-purpose extensions) is that 1) it makes the platform large, 2)
JUnit tends to be conservative about making breaking changes (due to having
a large user base), 3) JUnit doesn't release new versions often, and 4) it
isn't always clear what a good API is for a particular problem.

Having general purpose extensions grow "in the wild" avoids all the above
problems. It does, of course, have its own problems, including
discoverability and finding long-term maintainers. Still, in theory allows
competing solutions to be created, and allows JUnit to "harvest" the best
solutions.

I can't say what model would work best for these kinds of projects. What we
did in the past had mixed results, so I am fine with trying other
approaches.

• Kevin

On Feb 24, 2017 9:24 AM, "Steve Moyer" [e-mail] wrote:

@TimvdLippe https://github.com/TimvdLippe

Since the Mockito project provides already provides a JUnit 4 @Rule I
guess I would have expected the Mockito Extension would be part of
Mockito. If I were one of the curators, I'd tend to prefer hosting small
utility extensions and would want to avoid being the mediator between two
much bigger projects (in this case JUnit and Mockito).

I'm not trying to single out Mockito either ... I'm hoping to push the CDI
(Weld) extension I mentioned in another issue back into the weld project
and the upRest framework I'm working on will probably remain standalone. On
the other hand, the conditional test execution extensions I've been working
on have no outside dependencies and would be useful to a much broader
community - it's those types of extensions I'm looking to aggregate. Note
that it's still going to take some packaging work to make sure we don't end
up with a behemoth JAR.

On a personal note, JUnit + Mockito with some CDI thrown in is my favorite
environment - Thanks so much for providing JUnit's "better half" (no
disrespect to JUnit - in a great marriage, each of the partners thinks of
the other as their better half).

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/junit-team/junit5/issues/675#issuecomment-282334790,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdL7rA43XrGlpfzPQTaKKdh0v3iFuaBks5rfwRQgaJpZM4MJKu0
.

[nipafx]

@smoyer64 opened that ticket while we were still discussing things via mail. Later in that discussion I realized that dovetailing with _junit-team_ is not my favorite approach (nothing against you folks :wink: ). I'm quoting myself from that mail:

Now that you brought it up I thought a little bit about it. It would bring us closer to the "original" JUnit team but don't think that's necessarily good.

For one, it would mean that we would have to make some decisions together. This is not generally a bad thing but it could create friction where none is required.

Another consequence is that we would implicitly represent JUnit. Again, not generally a bad thing, but I think this has a very low but non-zero chance to cause conflict.

Both of these arguments are not really hard reasons, though, and the upsides you describe are much more real. But I have a beef with them as well (the most important argument to me). Because the added legitimacy would mean that other, not so privileged JUnit extensions might be seen as lesser alternatives, not because of technical merit but solely based on not being associated with the JUnit team. I don't think that would be fair.

I think my reservations could maybe best be summarized with a technical metaphor: The proposal creates a tighter-than-necessary coupling between JUnit 5 and "our" extension project. I don't think that's warranted and feels a little awkward.

I would be interested to hear the team's (or anybody's, really) opinion on that.

[marcphilipp]

I think @nicolaiparlog raises some valid points here. In the end, it's the decision of the curators. If we find out that a loose coupling does not work out, we could always decide to make it tighter later.

[smoyer64]

After more discussion, @nicolaiparlog and I have agreed that, at least for the time being we'll keep the ties between the junit-team and our community extensions informal. Our collaboration with the junit-team members has been positive and we definitely want to keep the communication flowing.

We do want to ask for explicit permission to use the JUnit name:

1. We've decided to call the JUnit community extensions project: junit-pioneer (and have created a Github organization with that name.

2. We're planning to use a root package name of org.junit.pioneer.* or perhaps just pionier.*.

3. We're planning to use a root groupId of org.junit-pioneer for the artifact(s) produced by the project.

It's our intention to mimic the junit5 project's conventions and infrastructure including the software license so there should never be an issue with using the JUnit name in conjunction with a commercial offering. Our major concern with item number 2 above is that we don't want a name-space collision in the future. Is this proposal acceptable? ... And thanks!

[nipafx]

More generally, is it ok to use the word "JUnit" in our project?

If so, it would of course show up in lots of places, like domain, GitHub group name, artifact IDs, packages, ... you name it (pun intended). We really like the name but we're not going to use it if the team has any qualms with that.

[sormuras]

_Fair winds and following seas_ to https://github.com/junit-pioneer

From my point-of-view we could create an empty module called "junit-community-pioneer" which delegates to your project. That would a) delegate users to promoted community project(s) and b) reserve that name in the JUnit universe.
Which leads me to a minor change request: org.junit.community.pioneer.* would match the existing fully-qualified package naming convention better.

More generally, is it ok to use the word "JUnit" in our project?

IMHO, yes. But I'm just a little mote of the team.

[nipafx]

Fair winds and following seas

Had to google that... 😆 Thanks!

org.junit.community.pioneer.* would match the existing fully-qualified package naming convention better.

True. We're still not sure on how to name packages and will take that into account.

[smoyer64]

Fair winds and following seas

I didn't have to Google that ... but you probably would guess that looking at my gravatar!

[marcphilipp]

I have no objections against calling it junit-pioneer. I'm not so sure about the package name and the group ID, though. I think those should reflect the independence of the project from "junit.org", i.e. the core JUnit. In addition, with Maven central (Sonatype), authorization is also tied to group IDs.

io.github.junit-pioneer is a bit long...

[jbduncan]

io.github.junit-pioneer is a bit long...

But it's less long than org.junit.community.pioneer, so I'm personally happy with it as an alternative.

[nipafx]

I'm not so sure about the package name and the group ID, though. I think those should reflect the independence of the project from "junit.org", i.e. the core JUnit.

That's a "no" for naming the packages org.junit.pioneer but does it also apply to packages org.junitpioneer (no dot) or the artifact ID org.junit-pioneer (with dash)? Technically both are distinct from org.junit but people could potentially confuse them.

[marcphilipp]

I have no objections against org.junitpioneer or org.junit-pioneer. However, as you've mentioned, those might be confusing.

[nipafx]

I thought about JUnit being a part of the name a little longer. The project is tightly coupled to the framework. Much more than, for example, Spock, which builds _on top_ of it, because it integrates _with_ it. Even conceptually, Pioneer is totally useless without JUnit.

I think that should be reflected in the name, so I'd want JUnit to be part of it.

Steve and I are not sure how exactly we want to name group ID and packages but the closest we would come to org.junit would be org.junitpioneer. I'm pretty sure we'll start putting this proposal into action some time early next week but until then opposing views by @junit-team are very welcome. :smiley:

[smoyer64]

@nicolaiparlog and @smoyer64 are collaborating as the maintainers of https://github.com/junit-pioneer/junit-pioneer. Feel free to submit useful extensions, libraries and frameworks there!