Remove unused code

[laeubi]

I ran http://www.ucdetector.org/ on m2e-core and it found some unused code (maybe due to removal of old code), for example

org.eclipse.m2e.core.project.IMavenProjectFacade.getResourceLocations()

do we want remove such unused code parts? It also suggest some changes in the visibility of methods and constructors.

This is just an idea that came in my head given the recent removal of deprecated code it might be a good opportunity to also remove unused code (or make it less visible).

[HannesWell]

I ran http://www.ucdetector.org/ on m2e-core and it found some unused code (maybe due to removal of old code), for example

org.eclipse.m2e.core.project.IMavenProjectFacade.getResourceLocations()

do we want remove such unused code parts? It also suggest some changes in the visibility of methods and constructors.

Maybe these methods are useful for downstream consumers, even if not used in M2E directly? But I have admit that I cannot tell if it is.

Yes in general the current situation would be a good opportunity. The only thing that's not ideal is that we have marked those methods as deprecated before, so the migration could become a bit more difficult. I actually don't want to do another 1. 20.2 release just do add deprecations, but we could list the removed methods and their replacement in the release notes.

And there are more places for API changes:

• ProjectConfigurationManager contains some TODOs for API removal and promotion.

[laeubi]

Maybe these methods are useful for downstream consumers, even if not used in M2E directly?

Maybe they then can add this code to their downstream plugin ;-)

[mickaelistria]

Or maybe the connector is critically important to many, but not well maintained so they'd be broken, and just breaking it will make m2e unusable to tons of users who'll have to switch to other IDEs. Breaking APIs and consumers without notice is putting a risk on the ecosystem. That's why it needs extra care.

[laeubi]

Or maybe the connector is critically important to many, but not well maintained

As this often mentioned in other areas where we are in fear-of-change:
This is actually a strange argument, if something is "critically important to many" then why it is "not well maintained", these both things are mutual exclusive to me ...

[mickaelistria]

This is actually a strange argument, if something is "critically important to many" then why it is "not well maintained"

Because the Eclipse Platform and ecosystem has been promoting and actually successfully providing very stable APIs for a long long time, and that has allowed a lot of extensions to run without requiring maintenance. But I agree it's usually annoying and it's often worth trying to remove API, it just requires some more investigation in some cases.

[HannesWell]

To get a better overview of the usage of the API I think it would help (but it is not necessary) to have the m2e-discover-catalog in the eclipse-m2e organization as suggested in #426 (comment)

Maybe we could then also improve the contact to the connector projects (given they are maintained).

[mickaelistria]

I'm fine removing this code in a major new release if we do it safely:

• There is a better alternative in maintained API
• We document somewhere what the alternative is
• We warn on the mailing-list and other relavant about the removal
• We quickly search if the method seems useful to the wider world (running some GitHub Search and looking up at other sources of main m2e connectors)