On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I have a question that I hope isn't too basic. I've been trying to > reconcile the behavior of dependency management with my expectations. I'll > state in advance that I'm more than willing to admit that my expectations > might be unrealistic. > > We've got a "home grown" dependency mechanism that works as follows: If > artifact A requires artifact B and artifact B does not exist it builds > artifact B before building artifact A.
That isn't really a dependency mechanism in Maven - that is a module hierarchy. As long as module B exists in the set of modules along with A, and A depends on B, then B will be built first. To further clarify what I'd like to do, I had originally started with the > <modules> element but quickly ran into this screnario: artifacts A and B > are built in the same POM (<packaging>pom</packaging>), and both require > artifact C. This does not make it past the reactor engine, which will not > allow artifact C to appear more than once. True - why would you want the same artifact built more than once? Is this behavior possible with the <dependencyManagement> tags? So far it > doesn't seem likely, but perhaps I'm not understanding dependency > management, which brings us back to that start of this message. I'm not understanding what you want to do. Is what behavior possible? Making the reactor build a project twice? If that is your question, then no. To clarify: all dependencyManagement does is pre-configure a set of dependencies for use by inheriting projects. For example, if project P is the parent with a depMan containing junit:junit:4.0, then an inheriting child project C can add a dependency junit:junit, and junit will be automatically configured to be version 4.0... the child need not specify anything. This gives you a single point of management for dependency configurations like versions, or exclusions. -- Eric Redmond http://blog.propellors.net Thanks > Robert Egan > > This email message and any attachments may contain confidential, > proprietary or non-public information. The information is intended solely > for the designated recipient(s). If an addressing or transmission error > has misdirected this email, please notify the sender immediately and > destroy this email. Any review, dissemination, use or reliance upon this > information by unintended recipients is prohibited. Any opinions > expressed in this email are those of the author personally.
