Community
Participate
Working Groups
To enable the crowd-sourcing approach mentioned in bug 449653 comment 2 I'm proposing an extension point, so that any interface with a crowd-sourcing server can be implemented in a separate plug-in outside JDT. Such a plug-in could be sketched as supporting the following tasks: (1) Detect when a library is added to a project's classpath, and take action for finding / downloading / configuring appropriate external annotations. (2) Check for updates of external annotations. (3) Hook into any manipulation of external annotations (manual, or via quick assist etc.), as to upload any changes to the crowd-sourcing server. I believe that tasks (1) & (2) can already be implemented using existing API (like IElementChangeListener etc.). It's task (3) that deserves specific support, notably for the reason that here we are dealing with details of an external annotation package, not just with a whole package as a black box. I'm intending to develop a proof-of-concept plug-in that consumes the proposed extension point, probably simulating the central repo by a simplistic local storage. If we opt for supporting the crowd-sourcing approach, publishing the extension point (ideally for Mars) would enable development of the crowd-sourcing mechanisms independent of the JDT release cycle.
Interesting. I definitely love the idea of default "local storage" plugin (which I guess will be part of JDT?). Do you plan that users could "merge" annotation profiles from different sources/contributors to planned extension point? If so, the "local storage plugin" which you plan for the "simplistic" approach could be also used to "merge with" any existing external annotations and for local testing/tuning etc. The "local profile" file can be used as "unit of share" between users? Let's imagine JDT will deliver and maintain some basic library profiles, e.g. for JDK 1.7.0_04. Having ability to "merge" JDK profile from JDT with *my own* local file I could have more (or less) stricter annotations on some API's, and also share my local file with somewhere else / feedback to JDT.
(In reply to Stephan Herrmann from comment #0) The mechanics of Code Recommenders seem to be a good fit for model download and automatic updates. We have code in place to identify a jar/project (i.e., assigning it a maven-like coordinate), to download model archives for a given coordinate, and automatically update them when newer models are available in the remote repository. If you provide an extension point, one could build a model provider that fetches models from a remote repository - similar to what we do with our code completion models.
FYI, I'm currently focusing on (3): providing a hook for *uploading*. For this purpose I'm sketching how one of the existing quick fixes for adding null annotations could switch behavior if the target type is from a library: create external annotation rather than source annotation. This would generate the event that could then be intercepted by the uploader plug-in. More comments soon.
(In reply to Andrey Loskutov from comment #1) > Interesting. I definitely love the idea of default "local storage" plugin > (which I guess will be part of JDT?). Not sure we mean the same. It is planned that JDT can natively consume external annotations from the local file system (either one zip per jar or an open directory tree with one text file per type). The mentioned POC plug-in would only serve to simulate collecting annotations from multiple sources. > Do you plan that users could "merge" annotation profiles from different > sources/contributors to planned extension point? When the textual format is defined, I'd like to leave the merging to contributed plug-ins (i.e., outside JDT). > If so, the "local storage > plugin" which you plan for the "simplistic" approach could be also used to > "merge with" any existing external annotations and for local testing/tuning > etc. The "local profile" file can be used as "unit of share" between users? So, maybe we do mean the same :) Yes, if the POC plug-in is already capable of merging, then it would be a piece of cake to extend this for merging annotations from multiple users. Still, I'm not planning to *publish* the POC plug-in as part of JDT. > Let's imagine JDT will deliver and maintain some basic library profiles, > e.g. for JDK 1.7.0_04. Also this is beyond the capabilities of JDT. I think it's best to think of a new Eclipse project as the maintainer of the annotation repo (leaving it up to that project to what degree "maintain" will mean a manual activity or if time is better spent in implementing the tools that will automate this maintenance). > Having ability to "merge" JDK profile from JDT with *my own* local file I > could have more (or less) stricter annotations on some API's, and also share > my local file with somewhere else / feedback to JDT. Yes, we'll definitely face situations where annotations from different sources have different coverage of an API. If annotations from different sources are incompatible, one of them is probably wrong :)
(In reply to Marcel Bruch from comment #2) > (In reply to Stephan Herrmann from comment #0) > > The mechanics of Code Recommenders seem to be a good fit for model download > and automatic updates. The more I think about this direction, the more I feel we should aim at smooth integration with existing build & dependency management tools. Let's assume, annotations are packaged as jar files with regular maven coordinates including a classifier "eea", like: org.apache.commons:commons-lang3-3.3.2-eea.jar If that artifact is uploaded to any upstream maven repo, simply specifying a new dependency would cause maven to fetch the artifact for you. So far this sounds like a KISS solution, with just two little "bugs": - we'd have to consume the annotations from the classpath rather than from some separate locations explicitly configured as an annotation attachment. (I guess we will have to live with this for maven builds and similar) - we have no means to specify any preferences/filters during download, because we are not in control of the download. This might imply that filtering of annotations according to your rules of trust must happen on the client side, perhaps even during compilation (driven by a custom compiler option). If the compiler has to be able to do the filtering, it must do this without the aid of any extension point, because it runs without equinox. In short: while I do see similarities with the code-trails tools concerning the *collection phase* (uploading), I think the consumption phase (downloading) is much more determined by existing (build) technology, as compared to completion models that need be available only to the IDE, not to compiler invocations from maven, gradle, ant, whatnot.
Also see bug 440474 comment 21 discussing meta data in external annotation files.
(In reply to Stephan Herrmann from comment #5) > - we'd have to consume the annotations from the classpath rather than from > some separate locations explicitly configured as an annotation attachment. > (I guess we will have to live with this for maven builds and similar) An arbitrary path location is hard to manage with different tools. For Eclipse, the annotation in .classpath is workspace relative, starting with the project. Any other tool does not know about workspace and projects which potential external locations. Thus, consuming it from the class path has benefits. The classifier approach works for Maven and likely also Gradle. For PDE we could throw the EEA files as fragments into the target platform. > - we have no means to specify any preferences/filters during download, > because we are not in control of the download. Not sure there is a need to. Following the model above, everything would be fine grained already (EEA files per library jar). The developer is in control of cherry-picking the annotations to download (Maven coordinates, target platform). > This might imply that filtering of annotations according to your > rules of trust must happen on the client side, perhaps even during > compilation (driven by a custom compiler option). Can you elaborate more on the goal of filtering? It seems that you have a specific use case in mind. > In short: while I do see similarities with the code-trails tools concerning > the *collection phase* (uploading), I think the consumption phase > (downloading) is much more determined by existing (build) technology, as > compared to completion models that need be available only to the IDE, not to > compiler invocations from maven, gradle, ant, whatnot. I would recommend de-coupling upload from download. Assuming download is handled outside of JDT (eg., Maven dependencies, target platforms, manually), upload could also be handled outside of JDT. Here is an example workflow: People interested in contributing to EEA files could clone the source repo, import it into their workspace. JDT should then be able to find the EEA file as "source" in the workspace and enable the "Annotate" actions. Thus, the hard part for JDT would be locating the EEA files either as "binary" from classpath (typically within a jar/zip) or as "source" for modification.
Bulk move out of 4.8
