| [recommenders-dev] [models] identification of nested jars |
|
Hi, today I finished the implementation of a new advisor [NestedJarProjectCoordinateAdvisor] (Marcel provided a first draft last week.). You can find the corresponding change in gerrit [1]. By default the NestedJarProjectCoordinateAdvisor is disabled (Because it is only needed in special cases and also has side effects. See below) If you want to activate it, you have to manipulate the preference file manually. (The preference page to configure this in a more comfortable way is currently in CQ). To activate the advisor you have to add in .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.recommenders.models.rcp.prefs the following line: advisor.list.sorted=org.eclipse.recommenders.internal.models.rcp.ManualProjectCoordinateAdvisor;org.eclipse.recommenders.models.advisors.MavenPomPropertiesAdvisor;org.eclipse.recommenders.models.advisors.JREExecutionEnvironmentAdvisor;org.eclipse.recommenders.models.advisors.JREReleaseFileAdvisor;org.eclipse.recommenders.models.advisors.JREDirectoryNameAdvisor;org.eclipse.recommenders.models.advisors.MavenPomXmlAdvisor;org.eclipse.recommenders.models.advisors.ModelIndexBundleSymbolicNameAdvisor;org.eclipse.recommenders.models.advisors.ModelIndexFingerprintAdvisor;org.eclipse.recommenders.models.advisors.OsgiManifestAdvisor;org.eclipse.recommenders.models.advisors.MavenCentralFingerprintSearchAdvisor;org.eclipse.recommenders.internal.models.rcp.NestedJarProjectCoordinateAdvisor; --------- The new advisor was recommended to handle a special case described in the following:  Here we have got a project (Test) which we can identify. In this case we get groupid, artifactid and version out of the pom.xml. In the project we have a nested jars (l1.jar) which itself don't include any information to identify it. So the mapping between DependencyInfo and ProjectCoordinate looks like:  The new requirement was that the coordinate for the nested jar (l1.jar) should be the same as the coordiante for the surrounding project when the jar can't be identified. The NestedJarProjectCoordinateAdvisor take care of this requirement: Every jar in a project gets the coordinate of the surrounding project.  As we see the nested jar l1.jar is now mapped to the coordinate of the surrounding project. But we also see that this advisor should only be a fallback strategy which should only be used when all other strategie fails. This strategy should always be the last strategy in the order! Another side-effect is that when we have more than one project which contains the same jars they are shown in the Project Coordinates View repeated - for each project once. Having a workspace with many projects can make this view useless:  The NestedJarProjectCoordinateAdvisor provide the required functionality. But the question that arises is whether this is the best solution? An alternative would be to provide a better manual mapping support with multi selection and multi assignment to simplify the manual mapping process. Also an export/import functionality for the manual mappings could help since this would enable the sharing of manual mappings between users. Using the manual mappings for this special case sounds suitable (therefor they were introduced). I would suggest to improve the manual mapping configuration in the future to displace the NestedJarProjectCoordinateAdvisor with a better fitting solution. What do you think? Regards, Olav [1] - https://git.eclipse.org/r/#/c/18338/ |