This message was deleted.
# dependency-management
s
This message was deleted.
t
If your goal is only to replace the artifacts (while keeping the transitive dependencies), then you should probably rather use a component metadata rule (for all variants, replace the files with the one you want ; or if you want it only for one configuration, then add a variant and apply the appropriate attributes to the configuration so that this new variant is selected).
AFAICT, using file dependencies is seen as deprecated and discouraged. You'd better have a repository from which to resolve the artifacts (that you can also "assign" to a single configuration if needed), or possibly use a composite build.
k
This is very unfortunate. In our case, we have complex dependencies. They usually involve a JNI layer with many native dependencies and no publishing to speak of. So, we have to actually have 2 projects? 1. to test based off the latest integration remotely published and with a native zip, locally extracted 2. to test based off the full installer package that contains all of the artifacts I don't see why this has to be the case. There seems to be too much thought given to metadata about the artifacts. If I substitute a module with a local file, it should just end there and accept that this is a required dependency for this/these configuration(s). Otherwise, it would be up to me to provide more checks for the substitution rule.