Community
Participate
Working Groups
I suggest to provide the code mining support for version control via EGit or via the team repository. It is currently located here https://github.com/angelozerr/jdt-codemining but should IMHO be moved to EGit or team.
+1 for moving it to EGit would need to go in an optional bundle since it requires Photon but the other EGit bundles can also be installed in older Eclipse versions
(In reply to Matthias Sohn from comment #1) > would need to go in an optional bundle in a separate feature, too. (I think.) And dependencies would need proper version ranges. Remember the problems we had with the "smart import" bundle... which were ultimately caused by a missing upper version constraint.
yes, this time we should get this right from the beginning
The implementation still relies on additional jface text API which is not part of Photon (at least : https://github.com/angelozerr/jdt-codemining/tree/master/org.eclipse.jdt.codemining/src/org/eclipse/jface/text/revisions/provisional How can we proceed with that? Is it planned to actually make that jface text API, such that it can be used by other team providers? Or should we just make this provisional API part of the egit implementation for the time being (in that case I would try to create a gerrit change with all necessary content)? Generally, the existing github code still needs some polishing, since some parts of the egit code mining are actually in the jdt bundle (like there is just a single preference page for all minings).
> The implementation still relies on additional jface text API which is not part of Photon (at least : https://github.com/angelozerr/jdt-codemining/tree/master/org.eclipse.jdt.codemining/src/org/eclipse/jface/text/revisions/provisional Indeed, that's why I have created an issue for that https://bugs.eclipse.org/bugs/show_bug.cgi?id=534600 > How can we proceed with that? Is it planned to actually make that jface text API, such that it can be used by other team providers? Yes it's my idea with https://bugs.eclipse.org/bugs/show_bug.cgi?id=534600 This idea gives the capability to avoid having dependencies beyween JDT <-> EGit and have JDT <-> Platform Text <-> EGit dependencies. > Or should we just make this provisional API part of the egit implementation for the time being (in that case I would try to create a gerrit change with all necessary content)? No if we do that, JDT will have dependencies to EGit to consume codemining revisions. > Generally, the existing github code still needs some polishing, since some parts of the egit code mining are actually in the jdt bundle (like there is just a single preference page for all minings). You cannot manage a generic codemining preferences for EGit because it depends on the AST of your language: show mining in method, class for Java, show mining method for PHP etc. In other words, preferences for show revisinon code minings is managed by the project like JDT, PHP, etc project not by EGit. The https://github.com/angelozerr/jdt-codemining/tree/master/org.eclipse.jdt.codemining/src/org/eclipse/jface/text/revisions/provisional is general for any project like JDT, PHP: it provides code mining for revision, but it requires to create those code mining instances in the well position. It depends on a project. For instance for JDT, a code mining provider creates thoses instances in the well position (before Java method and class) (see https://github.com/angelozerr/jdt-codemining/blob/master/org.eclipse.jdt.codemining/src/org/eclipse/jdt/internal/ui/javaeditor/codemining/JavaCodeMiningProvider.java#L203)
