Maven project: remove COS notifications and deprecate COS in UI

[mbien]

• removes "COS is not enabled" notification bubbles
• add "(deprecated)" to COS checkbox text

reproducer:

run a single test method from within a maven project while having COS disabled, NB 26 should show a notification asking the user to enable COS. This should be gone now.

[matthiasblaesing]

Looks sane to me. Thank you.

[mbien]

thanks for review. merging.

[eirikbakke]

I know there is a temptation to remove Compile on Save, but please note my -1 on that for the future. See the previous discussion "Projects, Builds and IDE magic" from August 2024.

It would be great if proposals to deprecate or remove features could be discussed on the mailing list, as these are often decisions that are difficult to revert.

[neilcsmith-net]

@eirikbakke your offer to maintain this in future is noted! 😄

[mbien]

It reflects the state of the implementation. This isn't difficult to revert since it is just a label. All what is needed is a committer which wants to maintain it, fix the showstopper bugs and an implementation which works with mvn 3/4, annotation processors and common mvn plugins, then communicate it to the user that this feature will use a different compiler to copy bytecode into the build folder with all the "interesting" problems this can cause even if it perfectly works.

Even if this would be resolved, I would be -0 (I won't help and won't support it), since in context of tooling daemons this is the wrong place to implement such feature in 2025.

I doubt that letting everyone who votes -1 inherit the implementation is a good way to find maintainers though - but we could try ;)

[neilcsmith-net]

I doubt that letting everyone who votes -1 inherit the implementation is a good way to find maintainers though - but we could try ;)

I assumed this was meant as a code -1, ie. a veto. A veto needs to be technically justified and propose some alternative way forward, and a willingness to make that alternative happen. For all the reasons mentioned, and more, the current label is correct, while in theory reversible. At some point those issues may (probably inevitably will) lead to the need to remove or fix. If someone vetoes the removal they will have to propose the fix and ensure it happens.

Personally, I'd love to see the removal of CoS anyway, and was switching it off everywhere for about a decade before we changed the default. It is the wrong place to implement and in many ways antithetical to NetBeans' approach to build systems.

[eirikbakke]

@eirikbakke your offer to maintain this in future is noted! 😄

At the very least I can help test features that might accidentally break Compile-on-Save! I use this feature every day and depend on it heavily. I also have not been able to find an alternative.

[eirikbakke]

This isn't difficult to revert since it is just a label.

In that case, I'd prefer if the addition of the word "(deprecated)" is reverted.

Here is the technical justification for my -1 on removing CoS:

• It is an extremely useful feature for large projects where a clean build would take several minutes.
• The feature has remained stable for the last 15 years. The main requirement for maintenance is to make sure new changes don't actively break it. (I disagree that all currently known bugs have to be fixed for this to be a useful feature.)
• The feature had no obvious alternative the last time I investigated it (Aug 2024).
• Compile-on-Save is necessarily an imperfect feature: Sometimes, a clean build will always be needed. We have different philosophies on this. I think bugs and limitations are a part of life in IDEs, and that even imperfect features can serve a very useful purpose in some developers' workflows.
• Dropping a feature is a "one-way decision"; it permanently throws away work which may have taken people months or years to create.

Here is the technical justification for a -1 on deprecating CoS:

• The word "deprecated" has special meaning that suggests there is consensus to remove the feature in the future. But we don't have consensus on that.
• The word "deprecated" may suggest to other contributors that it's OK to introduce changes that will break CoS in the future. That could cause the feature to break for real.

[eirikbakke]

Perhaps something like this instead?

Compile on &Save (disabled by default; see caveats below)

If selected, files are compiled when you save them.

<html>This option can save time when you run or debug your application or tests in the IDE.<br><br>

<b>Caveat:</b> Compile on Save works only for certain kinds of changes, such as those that touch a single class at a time, and which do not not involve annotation processors or resource files. In other cases, a manual, clean build may be required.<br><br>This option is only useful for very large projects, where frequent Maven builds may be prohibitively slow.

[neilcsmith-net]

Here is the technical justification for my -1 on removing CoS:

• It is an extremely useful feature for large projects where a clean build would take several minutes.

• The feature has remained stable for the last 15 years. The main requirement for maintenance is to make sure new changes don't actively break it.

That's a discussion to move to the mailing list. I will argue that both those points, particularly the second, are technically invalid.

Here is the technical justification for a -1 on deprecating CoS:

• The word "deprecated" has special meaning that suggests there is consensus to remove the feature in the future. But we don't have consensus on that.

That is correct, and we should probably move to make such decisions via the mailing list, via discussion, consensus, and (if necessary) vote, similarly to the JDK 8 issue. The profiler and the changes in #8396 are possibly other things that should be decided there too.

For now, your caveat makes sense, if being a little long! 😄

Please liaise with @mbien about the change, who will make the PR for delivery, and get it opened ASAP if it's going in RC3.

[eirikbakke]

Yes, a mailing list discussion would be useful! (No hurry for me obviously, fine to do so between releases if more convenient.)

For now, your caveat makes sense, if being a little long! 😄
Please liaise with @mbien about the change, who will make the PR for delivery, and get it opened ASAP if it's going in RC3.

Here is a PR for that: #8704

(It's a bit long but perhaps the length of the caveat will also scare people to the appropriate degree :-) )