java:PackageDependency creates DEPENDS_ON_PACKAGE instead of DEPENDS_ON relationships

[JohT]

Bug Description

While migrating from jqa-commandline-tool 1.12.2 to jqa-commandline-tool 2.0.3 I noticed that the concept java:PackageDependency now behaves differently:

• java:PackageDependency creates DEPENDS_ON_PACKAGE ( jqassistant-rules/java.xml ) instead of DEPENDS_ON ( jqassistant-rules/dependency.xml ) relationships.
• This also applies to the rule java:ArtifactDependency that now creates DEPENDS_ON_ARTIFACT relationships.

At least for me this change has a great impact on a lot of queries and took some time to track down.

Expected Behaviour

The easiest solution for at least me would be to set the behavior back to DEPENDS_ON as it was.
But I'm also sure that there is a good reason for changing the relationship name to e.g. be more "type safe".

Suggestions and Ideas

• How about adding DEPENDS_ON alongside to the new DEPENDS_ON_PACKAGE relationship within an additional MERGE in the implementation of the concept java:PackageDependency?
• Would it make sense to create a concept like e.g. "java:LegacePackageDependency" to be able to choose and document that in the release notes?
• Or would it be possible to mention this in e.g. the release notes and maybe another migration guide?
• A workaround is to use a cypher query to create DEPENDS_ON relationships based on the new DEPENDS_ON_PACKAGE like:

  MATCH (a:Package)-[existing:DEPENDS_ON_PACKAGE]->(b:Package)
  MERGE (a)-[created:DEPENDS_ON]->(b)

Environment

• JDK: 17
• OS: MacOs

How can we reproduce the bug?

• Checkout Update to Neo4j v5 and jQAssistant CLI 2.0 JohT/code-graph-analysis-pipeline#6
• Go through the steps in start-an-analysis
• The console will show this line and after that several error messages:

  Add_weight_property_for_Interface_Dependencies_to_Package_DEPENDS_ON_Relationship.cypher (http) result lines: -1
  

How could we have prevented this Bug?

Changes in concept implementations can also lead to "breaking changes" for some users. Of course these can be valuable. In that case it would be great to have some kind of migration guide or aggregated release notes with the breaking changes.

Definition of Done for the Implementers

• We got a final feedback from the reporting user (if applicable)
• Unittests have been written (if applicable)
• Integration tests have been written (if applicable)
• Test coverage is the same or even better then before (if applicable)
• Documentation has been written (if applicable)
• Added a note on the new feature to the release notes (if applicable)

[StephanPirnbaum]

Hi,

thanks for the effort to create this ticket. We have discussed this internally and will roll back this change with 2.0.4. We consider reworking the metamodel behind jQAssistant with 3.0, but then, it'll be properly anounced and strategies for migration given.