ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Use of conf in a complex project
Date Wed, 16 Sep 2009 16:09:48 GMT
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 <Travis.Zimmerman@bhmi.com
> 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?
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message