handling cyclic dependencies

["Parsons, David" <dc...@rsasecurity.com>]

We are building a system in which the dependencies among logical components
may form cycles.  I am trying to devise a clean way to build and test this
using maven.  The basic idea is to break at least one component from each
cycle into multiple artifacts.  E.g. if A depends on B and B depends on A, I
can break the B component into two projects: one for the interfaces and
object factories (which don't depend on A) and another for the
implementations (which do).  Then the build dependencies are: A depends on
B-interface; and B-impl depends on both A and B-interface.
 
Using these dependencies, I have succeeded in getting the maven reactor to
build the jars in the correct order, i.e. B-interface; A; B-impl.  In order
to do so, however, I had to suppress the unit tests for component A from
running.  This is because they require that the B-impl classes be on the
classpath, which is not described in the dependencies (and cannot be, since
that would reintroduce a cycle).
 
So basically, it seems I need to do a 2-pass build, first to build the jars
and then to run the tests.  The first pass requires that unit testing be
suppressed.  The second pass requires that an additional dependency be added
(or that, in some other way unknown to me, the classpath be extended during
the JUnit run).  How can this be done?
 
More generally, is there a standard maven-centric way to deal with issues of
cyclic dependencies?  BTW I am a maven newbie so the usual pleas apply about
not beating me up if this is already documented somewhere.
 
Many thanks in advance - David Parsons

Re: handling cyclic dependencies

[Gilles Dodinet <rh...@free.fr>]

Parsons, David wrote:

>Using these dependencies, I have succeeded in getting the maven reactor to
>build the jars in the correct order, i.e. B-interface; A; B-impl.  In order
>to do so, however, I had to suppress the unit tests for component A from
>running.  This is because they require that the B-impl classes be on the
>classpath, which is not described in the dependencies (and cannot be, since
>that would reintroduce a cycle).
>

David,

since you're testing A, B-impl shouldnot be required for those tests. so 
cannot you use some dummy implementations of your interfaces or some 
kind of simple mocks ?

-- gd


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: handling cyclic dependencies

[Michal Maczka <mm...@interia.pl>]

> -----Original Message-----
> From: Parsons, David [mailto:dcparsons@rsasecurity.com]
> Sent: Tuesday, February 03, 2004 8:57 PM
> To: 'users@maven.apache.org'
> Subject: handling cyclic dependencies
>
>
> We are building a system in which the dependencies among logical
> components
> may form cycles.  I am trying to devise a clean way to build and test this
> using maven.  The basic idea is to break at least one component from each
> cycle into multiple artifacts.  E.g. if A depends on B and B
> depends on A, I
> can break the B component into two projects: one for the interfaces and
> object factories (which don't depend on A) and another for the
> implementations (which do).  Then the build dependencies are: A depends on
> B-interface; and B-impl depends on both A and B-interface.
>
> Using these dependencies, I have succeeded in getting the maven reactor to
> build the jars in the correct order, i.e. B-interface; A; B-impl.
>  In order
> to do so, however, I had to suppress the unit tests for component A from
> running.  This is because they require that the B-impl classes be on the
> classpath, which is not described in the dependencies (and cannot
> be, since
> that would reintroduce a cycle).
>
> So basically, it seems I need to do a 2-pass build, first to
> build the jars
> and then to run the tests.  The first pass requires that unit testing be
> suppressed.  The second pass requires that an additional
> dependency be added
> (or that, in some other way unknown to me, the classpath be
> extended during
> the JUnit run).  How can this be done?
>
> More generally, is there a standard maven-centric way to deal
> with issues of
> cyclic dependencies?  BTW I am a maven newbie so the usual pleas
> apply about
> not beating me up if this is already documented somewhere.
>
> Many thanks in advance - David Parsons
>

All "smart books" and "theoretical studies" I know are clarly saying that
cyclic dependencies are evil and should be avoided by all means.
I haven't yet seen a situation when you reallly need to have them.
There is always a clean solution which leads to acyclic graphs of
dependencies.
Maven just that it helps you to understand desing problems and is refusing
to work with cycles.


If you have cyclic dependencies that __always__ means that there is
something wrong with your modules.
Either split them or merge them.


Michal



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org