search

m-m-m / code

Library to parse, analyze, transform and generate code
Apache License 2.0
2 stars 3 forks source link

support for module dependencies #7

Open hohwille opened 5 years ago

hohwille commented 5 years ago

In case a context is build from a local maven project, then currently dependencies are always resolved via the local repository. If these dependencies belong to a sibling module of the same local reactor project we should resolve the code from that local module instead as the artifacts in the local repo may be missing or outdated. The challenge is to find a way to solve this without causing a performance trap during the bootstrapping. We already spent a lot of energy to load things lazily to make first access fast. To resolve this we would need to read all modules from all parents and resolve their POMs (as effective model) what would require quite some parsing time. Also we need to be careful to check that GAV coordinates match exactly and otherwise we still need to fallback to the artifact from local repo. To boost performance we could maybe rely on some conventions or assumptions such that e.g. the groupId of module siblings may be the same, however this must not be the case and may therefore not work as expected in edge-cases.

jdiazgon commented 5 years ago

To resolve this we would need to read all modules from all parents and resolve their POMs

I have started to implement a way to resolve the dependencies from sibling modules. We know that the core module in devon4j defines the api module as dependency on its POM.

Therefore, what I currently implemented is a recursive method to get the dependencies from the dependencies of our dependencies... up to 4 levels of recursiveness.

This is a heuristic solution, but I have tested it and seems to work well on devon4j project. You can find here my commit.

hohwille commented 3 years ago

We can not make such assumptions as this should work for any maven project structure. Instead we can use the maven information ("reactor") and thereby find the correct code locations (including the configurations from the pom.xml of that module that can change defaults like ./target/classes). Also we need to be aware that we only do this if the GAV coordinates match exactly. That means if the version of the local module mismatches the one from the dependency then we have to stay resolving via local repo just as maven would do.