[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [recommenders-dev] [models] identification of nested jars
|
Hi all,
I had a more in-depths discussion with Marcel today:
- We agreed in general that the NestedJarProjectCoordinateAdvisor has
too many nasty side-effects. In particular, a single dependency JAR
referenced from two projects would now result in two different
DependencyInfos (with different SURROUNDING_PROJECT_FILE hints). Thus,
the "Project Coordinates" view is swamped with otherwise identical JARs.
Moreover, you could (and would have to!) assign manual mappings for each
JAR separately. That's IMHO not a feature but a bug. We should consider
removing this again.
- The persisted identified-project-coordinates.json is only a local
cache; as it contains absolute path names, it cannot easily be shared by
developers.
- Fingerprints are great to identify JARs, but they don't work for
dependencies of type "PROJECT" (say a project you build with Ant, which
only has a build.xml, no pom.xml and no META-INF/MANIFEST.MF).
- Any path-based matching needs not only the ability to abstract from
abstract paths, but also the ability to cope with changing timestamps in
filename. Thus, a wildcard mechanism is needed.
- Ideally, individual developers don't have to manually configure
anything (besides the models repository URI).
Based on these constraints we came up with the WorkspaceMappingsAdvisor
(anyone know a better name). The WorkspaceMappingsAdvisor requests a
mapping.properties file from the model repository. This file is of the
following format:
example-1.?/lib/*.jar=org.example:example:1.0.0
example-2.0=org.example:example:2.0.0
So, you have wildcards (* and ?) and the paths are matched as suffixes.
In the above, example-2.0 may, e.g., be a project's name in your
workspace. Mappings are matched from top to bottom; the first match wins.
The change is currently in Gerrit [1]. If you want to try out this new
advisor, create a local (file:-based) repository and deploy a
mappings.properties file there:
mvn deploy:deploy-file -Dfile=mappings.properties
-Durl=file:/path/to/repo -DgroupId=org.eclipse.recommenders
-DartifactId=mappings -Dpackaging=properties -Dversion=1.0.0-SNAPSHOT
You may need to delete any cached coordinates, as Code Recommenders
won't know that the mappings may have become invalid once a new advisor
becomes available:
rm .metadata/.plugins/org.eclipse.recommenders.models.rcp/caches/
@Olav: Is there any "click a button" solution to flushing the cache?
Anyways, the last remaining ugliness of this solution is that it doesn't
react to changes in your configured model repositories (like the
ModelIndexBundleSymbolicNameAdvisor and ModelIndexFingerprintAdvisor, I
think). These (IDE-independent) advisors would need to be made aware of
changes in the repository configuration -- if we go down the route of
storing the mapping in a model repository.
Any comments are welcome.
Andreas
[1] <https://git.eclipse.org/r/#/c/18436/>
--
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940