1

I just played around a bit with jQAssistant v1.0.0 using the command line tool to scan a few JAR archives of my project like bin\jqassistant.cmd scan -f lib. Unfortunately, this creates a sub-graph for every jar that are only connected through a common :Directory node. For example, I get 15 nodes (:Type {name: "int"}) which is obviously not useful. Specifically, I cannot create any queries spanning the whole project that is divided in separate jars (e.g. layers, api, impl). So I get one :Archive node that contains an interface and three other :Archive nodes requiring that interface but with four different interface nodes having the same fqn.

Am I doing something wrong or is this not working across multiple JARs? Thanks in advance.

aklemp
  • 13
  • 4

1 Answers1

1

This behavior currently is by intention - if JAR file are scanned from the CLI no information is known about dependencies between these files. Therefore the scope of type resolution is limited to the context of the JAR file a class is located in. There has already been a discussion to add a config property to the Java scanner which enables a global type resolution over all scanned artifacts.

Right now you can try to apply the concept "classpath:Resolve" to your database:

jqassistant.sh analyze -concepts classpath:Resolve

It will take some time but the result should match your needs.

Dirk Mahler
  • 1,186
  • 1
  • 6
  • 7
  • Thank you for the tip. This does the trick. Meanwhile I tried a Maven multi-module project and it only has a single node representing my interface. However, types like java.lang.Long still appear multiple times. The generated graph is not trivial and I have to test things out. E.g. getting dependencies between the `:Maven:Project`s... – aklemp Nov 30 '15 at 16:43
  • If you need help - just drop the message here at SO. How important would it be to have just a single node for java.lang.Long & Co.? Or in other words: what's the problem if there's more than one node?Just want to understand it. – Dirk Mahler Nov 30 '15 at 20:30
  • Probably I'm not used to graph databases yet. I'm still thinking of normalization like relational databases. In terms of checking constraints like in jQAssistant this may not be a problem except maybe more complex queries. E.g. find classes extending the super-type of a specific class would require helpers like `classpath:Resolve` or specific queries if the super-type appears several times. But visualization of graphs gets overly complex with redundant nodes. Maybe it is also a performance issue in large projects. – aklemp Dec 01 '15 at 10:13
  • The question is difficult to answer - there are some use cases where mapping required classes to one node could be wrong, e.g. scanning two libraries as JAR files from CLI (i.e. without dependency information) and each of them in different versions (A1.0, A2.0, B1.0, B2.0) where types of A require types of B. I the context of Maven projects the artifact dependencies are known - thus it would be possible to re-use required types if they are reachable via the dependency graph from the currently scanned artifact. For most project setups this should reduce things to single nodes. Opinions? – Dirk Mahler Dec 03 '15 at 11:47
  • You are right, that there are complex scenarios like different versions. When the archives have correct manifest with version information, this could be taken into consideration. The own project probably does not contain artifacts in different versions to be added to the same graph. This is again another story for 3rd-party dependencies. It is probably necessary to check the graphs of existing software created through CLI and check for specific redundancy patterns and find solutions for them. Using the Maven dependency information to reuse nodes is of course a good thing. – aklemp Dec 04 '15 at 10:40
  • Had a look at it, quite easy to implement - here's the official issue: https://github.com/buschmais/jqassistant/issues/327 – Dirk Mahler Dec 14 '15 at 18:49