Travis, you write: "The base level of the subsystem calls the build of each of its subprojects and publishes artifacts that are a merge of its subprojects." The idea of a "merge" kinda smells bad to me.
>From the standpoint of Ivy, there is no such thing as a subsystem, even though there may be modules that serve as the interface for a particular subsystem that's exposed to other ones. If each subsystem is is really made up of multiple projects, then each project should be its own Ivy module and one should be depending on the other. The ui project for subsystem A could depend on core for subsystem A. If subsystem B only needs the core of subsystem A, then that should depend directly on the core. Now, I'm sure you're saying right now, "This guy's really oversimplifying things." But you might want to just take a step back, expunge the concepts of "merge" and "subsystem," draw a dependency graph between Ivy modules on a whiteboard and try to use different colored pens to trace different conf paths. Most important, it sounds like you could accomplish a lot by giving certain modules two special confs: "with-seam" and "without-seam". This way you can make a single, discrete decision out of the picking up of all those third-party libraries. On Wed, Sep 16, 2009 at 8:16 AM, Travis Zimmerman <[email protected] > wrote: > Thanks for the reply Mitch. > > No, the subsystems and the master are not unrelated. The master may have > code the extends any of the subsystems and the subsystems themselves > have dependencies on other subsystems. > > I think I may have over simplified the situation. Each of the subsystems > I denoted below are actually multiproject subsystems. Each (or most) > have a core or service level project and a ui or war project. The base > level of the subsystem calls the build of each of its subprojects and > publishes artifacts that are a merge of its subprojects. Each of the > subprojects publish its artifacts so that inter subsystem dependencies > are met. The master build really wants the artifact published at the > subsystem level and the "packaged" dependencies of the service level > subprojects. The dependencies of the ui projects are in the war itself > so I do not need to worry about these. > > The dependencies that are "subsytem" are configured to be transitive. > All other dependencies are configured to not be transitive, this way I > do not have to worry about carrying forward all of the dependencies seam > has. > > I actually had a conf misconfigured, so I am a little further along. > Where I am at the present is that in the master build cache directory, I > have all dependencies as expected. They are all within the cache > directory for the conf "subsystem" which I think will be fine. However, > I also now have jar and war files for the subprojects within a > subsystem. The contents for these files are published in the artifact > for the subsystem. I don't think I want to turn off transitive as I > would then be missing the third party libraries that are dependencies of > the subprojects. I am not sure how to define the subsystem ivy file so > that it is a composite of the subprojects and the thirdparty > dependencies of each without duplicating the subproject dependencies in > the subsystem. > > Any thoughts? > > >
