As Anthony said as you have a chicken-egg problem and you need to break the
cycle somehow.
To cut the loop I would eventually either:
Solution 1: split the projects into:
1. the library itself without tests
2. the test library, depending on the lib
3. the library tests depending on both the lib and the test library
Solution 2: use a previous version of test lib
Here your framework could depend on your test lib in version N-1. The
layout would be:
1. library version N and its tests depending on test-lib version N-1
2. test framework library version N
The first solution is easier I think and allows to develop & use new
features (in both lib & test lib) without having to release to be able to
use them.
Matthieu
On Mon, Mar 25, 2019 at 10:44 PM Anthony Whitford <[email protected]>
wrote:
> You can specify a dependency version using an expression like this:
> <version>${project.version}</version>
>
> ${project.version} refers to the POM’s project/version value.
>
> Note that you can declare project properties, and use those in expressions
> too. See this for more details:
> -
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> <
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> >
>
>
> Having said that…. It sounds like you have a chicken-egg problem and that
> really needs to be fixed. While Maven certainly supports dynamic
> dependency management, it will highlight and prevent poor software
> engineering practices such as cyclic dependencies. You will discover that
> even if you can get a cyclic build working, the release process will be
> broken. And, you will undoubtedly run into build race conditions and other
> bad things.
>
> So, you need to figure out how to isolate the common dependencies into a
> third library to break the cyclic dependency. Instead of something like
> this:
> - A depends on B, B depends on A (BAD!)
> How about:
> - A depends on C, B depends on C (OK!)
>
> C may be just Interfaces — maybe no implementation.
> Your Tess can depend on A — but A should not depend on the Tests — it
> defeats the value of isolating the Tests.
>
>
> Hope this helps,
>
> Anthony
>
>
> > On Mar 25, 2019, at 11:28 AM, Philipp Kraus <
> [email protected]> wrote:
> >
> > Hello,
> >
> > I am building an additional testing framework for my framework. I now
> have the following cyclic import of the dependencies "MyFramework imports
> MyTestingFramework" and "MyTestingFramework imports MyFramework".
> > For example, if MyFramework is version 0.2.1-SNAPSHOT, then
> MyTestingFramework should use the version 0.2.1-SNAPSHOT. Is there a way to
> get the dependency dynamically?
> >
> > I hope it was understandable
> > Thanks a lot
> >
> > Phil
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
