+1, the risk is more or less 0 since we can still use branches for
potential fixes for "old" projects using frozen java and maven versions
anyway
Guess we can even be very precautionous doing 1. an upgrade to bytecode
version without any code change (to change the major version in bytecode),
2. a
so what is the status of this?
will we discuss in 2025 about being able to use java 8 apis or do we have
to wait 2030?
Sorry to be sarcastic but not moving forward it's certainly a reason why we
do not have more people participating in the project
It is so frustrating to be stuck with old
For what's worth I am talking about maven-javadoc-plugin (just realized
this is the main maven mail group)
On Sat, Oct 26, 2019 at 6:51 PM Max Zhu wrote:
> hi,
>
> Wondering if it makes sense to extend option to javadoc.io.
>
> For example, google gson (https://github.com/google/gson) has
I wrote an extra integration test, it confirms still change is indeed required
to match the original requirements.
Robert
On 27-10-2019 20:26:37, Petar Tahchiev wrote:
I think it's fine. I don't think it's going to break anything. For some
reason these changes got left behind and I had to add
This is often the convention I use but it looks going against what we run.
Engines come with a convention so we don't need to add yet another one IMHO.
Or the corrolar would be we should warn the user he did something useless
at least - which means doing the same work than supporting any
I would argue the opposite, maven/surefire gives you configuration and
control over what to files to look at for tests, and potentially what
files to ignore/exclude.
IntelliJ is just a blunder bust for searching '*', but yes might be
seamed as more user friendly.
For some projects I've both
Hi everyone,
Today a colleague asked me why "FooWhateverBla" test was not executed with
maven whereas it works well in Intellij.
Indeed I explained him Surefire does its own scanning and the hardcoded
defaults but I actually wonder why we still do that and if it is not just
something inherited
