Remove @Deprecated items

[laeubi]

I'd like to discuss how we should handle @Deprecated features. While looking at the extension support story, I noticed there are a lot of @Deprecated methods in IMaven some are still called some are not.

In either case I wonder how/if we plan to remove those?
Can we remove anything not actively used by m2e anymore?

[mickaelistria]

In either case I wonder how/if we plan to remove those?

Not really to be honest.

Can we remove anything not actively used by m2e anymore?

If it's internal yes. If it's public API, no.

[HannesWell]

Can we remove anything not actively used by m2e anymore?

If it's internal yes. If it's public API, no.

Never? Not even if we follow Eclipse's API-Removal-Process?

[HannesWell]

I already ask myself this question for the same reason.
Especially since m2e does not have a API-check setup (which does not have to mean anything).
If possible and we don't harm users/down-stream projects, personally I prefer to keep the code clean.

Eclipse has a dedicated API-Removal-Process that should also apply to M2E, shouldn't it?
https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

If we strictly want to follow semantic versioning, we could also think about m2e - 2.0, but this should be planned carefully in the long term and could involve more than just removal of long deprecated API.

[laeubi]

I'm not even sure if the Eclipse API removal process applies to m2e? In any case i think we really should get rid of some of this stuff whatever we choose.

[mickaelistria]

I suggest you listen to Erich Gamma's opinion about the reasons of sustainability and success of Eclipse Platform and IDE in https://www.youtube.com/watch?v=5B0HERBB2Kc ; you'll hear API stability is in his opinion one of the main reasons.

We cannot remove things that were open at the risk of breaking consumers. This kind of behavior could basically break the entire ecosystem: many plugins relying on m2e and still using those APIs could stop working and cause bugs in the IDE, users would then be unhappy and switch to some other tools which would show higher quality.
We need to try removing stuff, but we need an explicit process to define how and when we do that; so that plugin developers can anticipate necessary changes in their downstream code. So far, there is unfortunately no process in place, so it means that any breaking change is unexpected. It wouldn't be acceptable to remove public content now. Or we need to audit each removal and evaluate the external impact: verify ourselves it doesn't break main connectors, main consumers... that's really a lot of work.
If we want to bend semantic versioning a bit, we can work on setting up a process, leveraging @Deprecated(forRemoval=true) with some documentation about suitable replacement and the target date for a removal and announces on the mailing-list and mailing-list of related projects about the API removal.

So at this stage, removing @Deprecated elements from API is not possible, but to make it possible in the future, we need to define an explicit API policy.
Again, for internal stuff, there is no issue to remove anything.

[laeubi]

opinion about the reasons of sustainability and success of Eclipse Platform and IDE

Actually it is only that what you have name it an opinion without any proof. We don't know how eclipse platform would have evolved otherwise. So what "competitors" are there that have vanished? Isn't it that InteliJ is also successful for a long time and I'm not aware of any such policy there. Or if we are going to take "platform" a bit broader, we can surly use karaf and its ecosystem where there are literally no restrictions an they are evolving with a great success having many many cool features where eclipse simply could not compete.

To add another opinion to this discussion, one could always see the other side of the coin that eclipse platform is carry the burden of "lazy" developers (or the community of these "critical" plugins) not willing to keep up with recent changes for many years for no gain (e.g. getting more contributors or just say new ones taking the place of those who loses interest).

On the other hand things evolve faster and faster not only with features also with critical bugfixes due to security problems and java versions or collaboration paradigms, people simply expect state-of-the art tools and I never heard of a user switching its IDE or platform because of an API break for long time deprecated feature but simply because other tools offer them more modern or better tooling / features. So from an outside view, eclipse often is seen as a slowly dying dinosaur.

[HannesWell]

We need to try removing stuff, but we need an explicit process to define how and when we do that; so that plugin developers can anticipate necessary changes in their downstream code. So far, there is unfortunately no process in place, so it means that any breaking change is unexpected. It wouldn't be acceptable to remove public content now. Or we need to audit each removal and evaluate the external impact: verify ourselves it doesn't break main connectors, main consumers... that's really a lot of work. If we want to bend semantic versioning a bit, we can work on setting up a process, leveraging @Deprecated(forRemoval=true) with some documentation about suitable replacement and the target date for a removal and announces on the mailing-list and mailing-list of related projects about the API removal.

So at this stage, removing @Deprecated elements from API is not possible, but to make it possible in the future, we need to define an explicit API policy. Again, for internal stuff, there is no issue to remove anything.

I agree with Mickael in that regard that we should not simply remove deprecated elements without further noticed and I also support the suggestion to set up an API deprecation/removal process (we could simply use the process of platform), maybe in conjunction with setting up the PDE API-tools for m2e to make developers more aware of API changes.
The suggested path of marking elements to remove with @Deprecated(forRemoval=true), adding notes about when the removal finally happens and announcing it as loud as possible is IMHO reasonable and a good balance between progress and not breaking down-stream users immediately.

I suggest to create a dedicated issue where we collect the elements to remove and specify the removal-plan so that the deprecation/removal remarks can refer to it. If we take the Eclipse-Project API-Removal process as reference we could discuss an expedited removal of only one year (or less?) for elements that should be removed urgently and are likely not widely used downstream (with corresponding notice)?

That's not ideal for us developers respectively for very fast evolution but at least we have started the process which is better than doing nothing. And for the future the removal should be planned and announced with the deprecation.