mbien commented on PR #5609:
URL: https://github.com/apache/netbeans/pull/5609#issuecomment-1477897301
please clarify what this PR is supposed to achieve and how it benefits the
project. PRs are supposed to improve the project.
if this intends to actually test nb-javac:
- I would tend to agree with @dbalek + @jlahoda and say it is ok to add a
few lines to the ant task if they make it easier for the nb-javac project to
run CI tests which compile NetBeans there. I am still not happy about it, since
this locks every single module into using the same task in future, which should
not be a requirement, since javac works just fine (and a search will show you
it is still used).
- I still don't know why nb-javac has to build NetBeans as a test case, it
can be literally any other project and doing this via a gradle/maven plugin has
actually practical use cases, since those things are still used IRL in contrast
to ant
This is however is not what I see in this PR! This PR adds a CI workflow. If
nb-javac stages a new build It makes absolutely no sense to test it here, check
if NB builds and if not, fix something in nb-javac which is a completely
different project. The NetBeans project is also not running maven tests here to
check if something fails before upgrading maven - this already happened!
Regarding reproducible builds:
1) I don't see anything indicating that anyone wants to work on this.
Interest in CI topics is in general fairly low, as long CI works, nobody cares
about it. (and I completely understand, since it is just a tool and a solved
problem). Why do I think that would be the case? I migrated travis to gh and
the feedback threads I opened on the dev list are basically empty, I almost
merged some of the PRs without being able to motivate anyone to approve them
(only the usual suspects took a look (thanks again)), and yes I usually added
[everyone](4431). Again: as long the build works nobody cares
2) reproducible builds in java do not require to separate the compiler from
the JDK, I have helped with reproducible builds before in other projects and
that wasn't even on the table there. The JDK is a convenient bundle you can
depend on - its a feature not a bug
3) trying to achieve reproducible builds with ~450 ant projects going to be
hell.
> It might. But a 'fear that something might happen' should not cause to
block a change just because "it might be extended in the future, maybe"
@sdedic I disagree. If there is no clear benefit to the project in the first
place, it should be enough of a reason to not merge something (we have done
that before). The argument to merge it is the exact same. Someone might find it
potentially useful in hypothetical reproducible builds some time in future,
just in case someone wanted to swap out a compiler. Again: if this is about a
test case for nb-javac -> wrong repository.
regarding JDK 8:
It's dead Jim. For those who haven't migrated yet: maven central is full
with NB versions which still support it (and there will be a few more, I am
sure). If someone wants to participate, please do so and I am sure we will find
a way to branch NB (assuming everyone agrees and we find a release manager) -
lets get involved if you have specific requirements - now is the time.
nb-javac does not backport the java ecosystem to JDK 8
I have never been in or heard of a team who didn't allow intellij or android
studio because it uses JDK 17 to run on (it wouldn't surprise me at all if they
move to 21 shortly after it lands). No matter what the support contracts were.
I am sure they exist somewhere but I don't think we have to take them into
account in the minimum requirements (again: get involved).
yes this absolutely should have been discussed on the dev list, like I wrote
in the first comment of this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
