See bug #189026 comment #13. P2 since Plugin Manager does not honor the user's request and there is no workaround that I know.
Immediate fix is to remove any reference to apisupport from java.kit. That will regress bug #189026, so the proper approach is to fix FoD so that it enables apisupport.kit (if necessary) when an NBM project is opened. Whether or not apisupport.kit is also enabled when a Java SE project is opened is a much less important matter; seems stupid to me but not a serious problem.
Whether or not java.kit shall also recommend apisupport.kit is discussed in issue 168618.
The issue of autoupdate ignoring user request is reported as 189784.
I want to see justification why the fact that enabling Java SE also enables apisupport.kit is P2. Imho it is not. This behaves exactly as designed in 6.7 and since then there was no report related to any problems associated with it. Just right now Jesse become concerned. But that is not enough for P2. Making P3.
(In reply to comment #1)
> I want to see justification why the fact that enabling Java SE also enables
> apisupport.kit is P2.
That is not the issue here. I find it weird and undesirable, but not a P2; FoD may turn on whole blocks of stuff that you do not strictly need yet, according to its policy.
The issue here is that declaring a recommendation of java -> apisupport prevents apisupport from being explicitly disabled, i.e. it is impossible for the user to fully customize which plugins are enabled, even when not using FoD at all. That is a P2.
In general, kits may not OIDE-M-Recommends other kits. As soon as the outstanding erroneous occurrences are fixed I will also fix ValidateModulesTest to prevent regressions in this area. FoD is free to use some other mechanism to decide to enable big blocks of functionality such as clusters.
*** This bug has been marked as a duplicate of bug 168618 ***