Any ideas ??
De : COPPENS, Fabien
Envoyé : mardi 28 août 2007 17:32
À : 'users@maven.apache.org'
Objet : Cyclic dependency problem
Hi all.
I have just joined the list, so please forgive me if the exact same question
has already been posted.
Here is my
Hello,
I would suggest breaking explicitly the dependency by creating
separate projects for the ejbs and the pure java code they encapsulate
and expose.
HTH
--
OQube software engineering \ génie logiciel
Arnaud Bailly, Dr.
\web http://www.oqube.com
Hi,
the excludes won't help here. Maven calculates the dependencies based on
the projects in your reactor build. And as both, the main ejb-jar and
the ejb-client-jar are built by the same project the cyclic dependency
remains.
Your best option is to factor out the exposed ejb interfaces to
Hi all.
I have just joined the list, so please forgive me if the exact same
question has already been posted.
Here is my use case :
I have a project CORE_A which exposes a facade in the form of an EJB,
which is built in a separate project EJB_A.
I have a project CORE_B which exposes a facade in
All,
I have some rather complex objects that need to be viewed at varying
'depths'. In fact, in many ways the entire database contains objects
that are inter-related and I only want to be looking at a subset at any
one time. This is causing me some grief in my module and testing layout.
Let's
andy law (RI) wrote on Thursday, January 25, 2007 1:47 PM:
[snip]
Has anyone else done anything as complex (read: STUPID) as
this and can
anyone suggest any sensible, practical solutions?
Use a dynamic mock implementation like jMock. With the CGLIB extension you may
even mock classes not
andy law (RI) wrote on Thursday, January 25, 2007 1:47 PM:
[snip]
Has anyone else done anything as complex (read: STUPID) as
this and can
anyone suggest any sensible, practical solutions?
Use a dynamic mock implementation like jMock. With the CGLIB extension you
may even mock classes not
