| <?xml version="1.0" encoding="utf-8"?> | |
| <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" | |
| "concept.dtd"> | |
| <concept id="cjcircle" xml:lang="en-us"> | |
| <title outputclass="id_title">Cyclical dependencies between J2EE modules</title> | |
| <shortdesc outputclass="id_shortdesc"></shortdesc> | |
| <prolog><metadata> | |
| <keywords><indexterm>dependencies<indexterm>cycles between modules</indexterm></indexterm> | |
| <indexterm>J2EE<indexterm>cyclical dependencies between modules</indexterm></indexterm> | |
| <indexterm>projects<indexterm>cyclical dependencies</indexterm></indexterm> | |
| </keywords> | |
| </metadata></prolog> | |
| <conbody outputclass="id_conbody"> | |
| <p outputclass="anchor_topictop"></p> | |
| <p>A cyclical dependency between two or more | |
| modules in an enterprise application most commonly occurs when projects are | |
| imported from outside the Workbench. When a cycle exists between two or more | |
| modules in an enterprise application, the <tm tmclass="special" tmowner="Sun Microsystems, Inc." | |
| tmtype="tm" trademark="Java">Java</tm> builder cannot accurately compute the | |
| build order of the projects. Full builds fail under these conditions, or require | |
| several invocations.</p> | |
| <p>Therefore, the best practice is to componentize your projects or modules. | |
| This allows you to have your module dependencies function as a tree instead | |
| of a cycle diagram. This practice has the added benefit of producing a better | |
| factored and layered application.</p> | |
| <p outputclass="anchor_topicbottom"></p> | |
| </conbody> | |
| </concept> |