Document ProjectDependencyConfig

[ppalaga]

@aloubyansky this just adds a bunch of TODOs and questions about the various configuration options which I kindly ask you to address.

[ppalaga]

These 3 points are addressed in #383

[ppalaga]

I think it would be good to discuss the terminology a bit. Here are some initial ideas:

Root artifacts - I heart this from you @aloubyansky and I like the term. Those are artifacts whose transitive dependencies are to be tracked. There are several ways how the set of root artifacts can be defined/selected:

1. By filtering from the Initial universe of artifacts "BOM driven". The filters are given by include and exclude patterns. This is very powerful and practical.
2. By Enumerating some specific GAVs
3. Union of 1. and 2.
4. ?

Initial universe of artifacts - I kinda miss this term in the docs and I think it would be useful to introduce it. The term Universe comes from the set theory which I generally find a good place to steal terminology from.
The Initial universe of artifacts has to be defined for BOM driven filtering. Enumerating specific GAVs does not require it.
The Initial universe of artifacts is defined by one ("Project BOM", "Own BOM", "Primary BOM") or more (primary plus "additional", "secondary" or "non-project") BOMs.

It is currently not clear to me, whether pointing domino at a source tree

A. Defines the initial universe per se or
B. Helps to specify the initial BOM
C. Defines the set of root artifacts and the filtering and BOMs are not relevant at all

[ppalaga]

It is currently not clear to me, whether pointing domino at a source tree

A. Defines the initial universe per se or
B. Helps to specify the initial BOM
C. Defines the set of root artifacts and the filtering and BOMs are not relevant at all

I must say I currently find only B. useful - i.e. if the root BOM is only specified as g:a then the version could be read from the current source tree.
I think we could save us some implementation complexity if we do not do anything else. I would even not bother doing anything for Gradle.
If the user installs the artifacts locally by building the source tree, then Domino should be able to operate on Local Maven repository where all relevant pom.xml files can be found, no?

[aloubyansky]

No, it doesn't have to be built.

[aloubyansky]

All domino does is resolves dependency graphs and walks them. For that it needs to know the root nodes and possibly version constraints that should be enforced.

The notion of a project BOM is just a convenience to determine the root nodes in some cases.

Project directory is used only to determine the root nodes that should be processed and initialize the Maven resolver with the workspace POMs, so the dependencies are resolvable w/o building the project.