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,

I still like the approach. Especially because it does not need much new code and fixes the issue I had quite well.

Regarding notifications:
We’d need an rcp-aware wrapper around the advisor that listens and responds to that event. It may make the user aware that there is now a conflict when a new file was downloaded that maps an existing element to another coordinate. Without thinking about it in all details, that solution sounds reasonable to me and worth looking into.

Marcel

Am 15.11.2013 um 16:37 schrieb Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>:

> 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
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/recommenders-dev



Back to the top