Add project site links to javadoc

[NPException]

This just adds project site documentation links to the java doc of extensions, as suggested in #149.

Closes #149.

---

I hereby agree to the terms of the JUnit Pioneer Contributor License Agreement.

[Bukama]

One question: Why do you not close the <p> tags?

[NPException]

One question: Why do you not close the <p> tags?

The existing sections in those javadocs do not have closing <p> tags either, so I assumed this was the desired style. Personally I'd prefer to have closing tags as well, but I didn't want to break existing conventions.

[Bukama]

One question: Why do you not close the <p> tags?

The existing sections in those javadocs do not have closing <p> tags either, so I assumed this was the desired style. Personally I'd prefer to have closing tags as well, but I didn't want to break existing conventions.

From my personal point of view: Open tags are not a convention, but a bug.

[NPException]

From my personal point of view: Open tags are not a convention, but a bug.

I think I agree. I added one more commit that closes all <p> tags in the Javadoc of all classes affected by this issue/PR.

[Bukama]

Thank you. I'm fine with it.

[Michael1993]

LGTM, personally I prefer all <p> and </p> tags to be on new lines, but that's probably only because that's how IntelliJ does it.

[NPException]

LGTM, personally I prefer all <p> and </p> tags to be on new lines, but that's probably only because that's how IntelliJ does it.

No, that was all manually done by me. I chose to put the closing tag on the same line for existing sentences because I've seen it done like that in other places in the project. I'll happily move them on a new line if that is fine with everyone.

[Michael1993]

LGTM, personally I prefer all <p> and </p> tags to be on new lines, but that's probably only because that's how IntelliJ does it.

No, that was all manually done by me. I chose to put the closing tag on the same line for existing sentences because I've seen it done like that in other places in the project. I'll happily move them on a new line if that is fine with everyone.

No need, it doesn't really add any real value. It's not worth working on it.

[aepfli]

i am not sure if i am a fan of closing

tags. The reason is, it is not the default case. Oracle Java docs, also does not have closing tags (i see this as the default). Furthermore i understand the nature from HTML where this is coming from, but i also do think there is a difference to it than plain HTML. (and it is still valid as p tags do not have to be closed)

In HTML you structure a page, and open and closing gives you a lot of help, to figure out the structure. In Java doc, we just use it for a break and to ensure that there is a break.

Addtionally i want to discuss if an
@see <a href="http://google.com">http://google.com</a> would be also beneficiary, so it will be displayed under See also:

[NPException]

Oracle Java docs, also does not have closing tags (i see this as the default).

I was not aware that this is the case in the base java docs. In that case, I too would vote to leave the tags open.

Addtionally i want to discuss if an
@see <a href="http://google.com">http://google.com</a> would be also beneficiary, so it will be displayed under See also:

I have no opinion/preference on this. @Michael1993 @Bukama what is your opinion on the topic?

[Bukama]

Oracle Java docs, also does not have closing tags (i see this as the default).

I was not aware that this is the case in the base java docs. In that case, I too would vote to leave the tags open.

Addtionally i want to discuss if an
@see <a href="http://google.com">http://google.com</a> would be also beneficiary, so it will be displayed under See also:

I have no opinion/preference on this. @Michael1993 @Bukama what is your opinion on the topic?

We could use @see only, because the then generated see also is nothing else than for further information look at this link

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
0.0% Duplication