Skip to main content

[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


Back to the top