Merge org.eclipse.jdt.apt.core into org.eclipse.jdt.core?

[mickaelistria]

APT has been a standard of Java language for a very long time. While it was for some time a separate project and a separate plugin, we can question whether this is a good thing to keep it so nowadays (see #2497 (comment) for an example where the split is causing some extra difficulty).
What about merging org.eclipse.jdt.apt.core into org.eclipse.jdt.core ?

[mickaelistria]

cc @testforstephen @jukzi

[stephan-herrmann]

Cc: @jarthana who used to work on jdt.apt a lot (while semantic code changes have been rare these days / years).

I don't even know if actually removing a plug-in is permitted. We know of m2e requiring this plugin, so the change could be coordinated with them, but there might easily be more clients out there, for which this would be a breaking change.

Perhaps you were thinking of only moving the code and leaving the plugin as an empty shell with a re-exported dependency on jdt.core?

[mickaelistria]

Indeed, suddenly removing a bundle is not a good idea.

Perhaps you were thinking of only moving the code and leaving the plugin as an empty shell with a re-exported dependency on jdt.core?

Yes, I had that in mind, sorry for not clarifying it in 1st place.
For those case, we can go through an iterative deprecation process: bundle being empy "proxy" and we state in the doc and the bundle name that it's being deprecated, and that Import-Package can be used for backward and forward compatibility, but we don't touch anything else; then in a next iteration we remove it from feature but keep it in p2 repo so people may have to play with their .target if they need to keep the bundle; and next step can be full removal.
But to be honest, the final goal isn't really to remove the bundle (although it will be cleaner if we do eventually), but really more to facilitate joined development and consumption of core + APT.

[mickaelistria]

@jarthana What do you think about this proposal.
@stephan-herrmann do you think I should bring this question to jdt-dev mailing-list for more visibility?

[jarthana]

@jarthana What do you think about this proposal. @stephan-herrmann do you think I should bring this question to jdt-dev mailing-list for more visibility?

If we stick to just moving the code and keep the bundle, +1 from me.

[mickaelistria]

So here is the current PR: #2548 . Please have a quick look to tell whether this is the right direction.
I think this is fully backward compatible in term of API and extension point, the main issue is about API versioning making PDE unhappy and also the codestyle being different. I suggest we discuss them slightly later, after we agree that the proposed approach to the merge is good in principle.