Circular dependency enforcer fires for test dependencies

[axtimwalde]

I believe this is overdoing it because such tests will work.

Proposed solution: Do not check test dependencies for circular dependencies.

[ctrueden]

@axtimwalde Could you please point me to a project with such structure, so that I can reproduce?

[axtimwalde]

https://github.com/saalfeldlab/n5-imglib2
is now a dependency of bigdataviewer-core but it also uses it for interactive tests. Currently I have to fall back to a version of bigdataviewer-core that did not yet depend on n5-imglib2, but this is not a sustainable solution. While such tests are not a show-stopper, they are useful during development to check things.

[ctrueden]

FWIW, I think this is why we made imglib2-tests a separate component: to avoid such circular test dependencies.

I don't think the enforcer rule in question has any flags we can toggle. We could disable the rule completely. Would that suit you?

[axtimwalde]

imglib2-tests is a separate component which makes it extra hard to work on e.g. imglib2 when it is in motion. Surely, one can toggle off all enforcers (the SNAPSHOT one in particular to test things) but that renders those rules pointless. Eclipse makes this sort of workable but I do not want to think about project switching in IntelliJ. I think if the enforcer rule cannot distinguish between real problems and legit stuff I am in favor of disabling it.

[ctrueden]

To me, bigdataviewer-core depending on n5-imglib2, but n5-imglib2 tests depending on bigdataviewer-core, is a strong code smell, and very confusing. Does n5-imglib2 really need to lean on bigdataviewer-core for unit tests? It must be for manual integration tests, no? If so, why can't these integration tests move into bigdataviewer-core, which already depends on n5-imglib2? If it were my project, I would not keep the dependency structure this way.

That said, bigdataviewer-core and n5-imglib2 are not my projects, and I want you to be happy. So: scijava/pom-scijava-base@6b86bea! Will cut a release and update pom-scijava accordingly when I do the next BOM update.

[axtimwalde]

Thanks a lot :)!!! To explain why this isn't smelling bad ;): The manual tests in n5-imglib2 use bigdataviewer as a tool to test n5-imglib2 during development of n5-imglib2, not bigdataviewer. They are not concerned about integration. It was ok to use a pre-n5-imglib2 integration bigdataviewer version for a while for that purpose but that becomes increasingly frustrating because bigdataviewer evolves for good reasons and becomes an ever more useful testing tool for development. Brief: these tests are for n5-imglib2 and use bigdataviewer. bigdataviewer now depends on n5-imglib2. This is fine and not a circular dependency.