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 14:24:12 GMT
Travis, is it true that your master and subsystem confs are unrelated to
each other, i.e. neither extends the other? If that's the case, you might
have a simplified ivy.xml like this. Note that this is the ivy.xml for an
EAR project but it could just as well apply to a WAR or JAR project:
  <configurations>
    <conf name="master" />
    <conf name="subsystem" />
  </configurations>

  <publications>
    <artifact name="enterprise-app" type="ear" conf="master" />
  </publications>

  <dependencies>
    <dependency org="com.foo" name="bar" rev="1.0" conf="subsystem->master"
/>
  </dependencies>

What's happening here is that the publication of the artifact is only
happening without its transitive dependencies. You're publishing
enterprise-app.ear in the master conf, but because the dependency is only
being picked up in the subsystem conf, never the twain shall meet. This may
not be such a problem with the root, most-dependent project, the EAR, but if
it's dependency modules are only publishing themselves in master but only
picking up their own dependencies in subsystem, you're cutting off
transitivity one level at a time.

Why not make your dependencies' confs be something like "master->master",
call the ivy:cachefileset Ant task when you need to assemble all the needed
JARs, and then see what shows up when you go to copy that fileset to your
desired destination?

(Actually, the "master" scope in Maven, I believe, is designed just for
this--to publish a project's artifacts without its dependencies. So in a way
you're using the word "master" correctly, although don't ask me what the
value of that is in Maven.)

On Wed, Sep 16, 2009 at 6:31 AM, Travis Zimmerman <Travis.Zimmerman@bhmi.com
> wrote:

>
> I have a situation where we are trying to build a complex project that
> contains multiple modules that reside in their own branch in our SCM
> system. All modules are retrieved from scm separately and do not reside
> within a common directory. The deliverable for the entire project is an
> .ear file, each of the modules will either be a library, an ejb or a war
> that is packaged within the ear file. To make things more complex, some
> of the modules are optional and may not be delivered or built.
>
> I am attempting to solve a portion of the complexity using Ivy and the
> usage of confs to pull together the dependencies and help build the ear
> file and application.xml. I do not believe all of this is supported but
> I would like to make sure I am going down the right path to make the
> most use of Ivy. I have defined several of my own "confs" to help
> achieve this goal. The first is "packaged" which implies that the
> dependency needs to be added to the ear file in its lib directory. The
> second is "subsystem" which states that the dependency is a module with
> in my project. I also then make use of the standard confs "compile',
> "master" and "test". My goal is to leave the declaration of dependencies
> to the actual module that actually has that dependency. However, when
> building the ear file, I need some way of discovering that one of the
> modules I depend on has a dependency on a library that needs to be added
> to the ear file. It is also possible that this dependency is an ejb and
> should be added as its own module in the ear file.
>
>
> Below is a simplified example of the situation that we have, I hope that
> this makes it easier to understand.
>
> Module A - The master has dependencies on all of the modules and knows
> which other modules should be included.
>    depends - Module B conf - subsystem->master
>    depends - Module C conf - subsystem->master
>    depends - Module D conf - subsystem->master
>    depends - Module E conf - subsystem->master
>
>    artifact - myproject.ear conf - subsystem
>
> Module B
>    depends - Module C conf - subsystem->master
>
>    artifact - module-b.jar conf - subsystem
>
> Module C
>    depends - Module D conf - subsystem->master
>    depends - Module E conf - subsystem->master
>    depends - servlet-api conf - compile->master
>    depends - commons-beans conf - packaged->master
>
>    artifact - module-c.jar conf - subsystem
>    artifact - module-c-ui.war conf - subsystem
>
> Module D
>    depends - Module E conf - subsystem->master
>    depends - jakarta oro conf - packaged->master
>
>    artifact - module-d.jar conf - subsystem->master
>    artifact - module-d-ui.war conf - subsystem->master
>
> Module E
>    depends - jboss.seam conf - packaged->master
>    depends - testng conf - test->test
>
>    artifact - module-e.jar conf - subsystem->master
>
>
> My approach is to define the dependencies using the conf and retrieve
> them during the build to a local cache ( within the module directory )
> by conf type. When building Module A I need to create an ear file and
> add the dependencies. After performing calling the retrieve I would end
> up with a local cache directory with something like the following
> contents
>
> ModueA/
>    .libcache/
>        subsystem/
>            /ejbs
>                module-e.jar
>            /jars
>                module-b.jar
>                module-c.jar
>                module-d.jar
>            /wars
>                module-d-ui.war
>                module-c-ui.war
>        packaged/
>            /ejbs
>                jboss-seam.jar
>            /jars
>                jakarta-oro.jar
>                commons-beans.jar
>
>
> I believe with things properly copied to these directories I can
> dynamically build the application.xml file and the ear file without
> having to duplicate the declaration of dependencies. What is actually
> happening is that all of the dependencies end up in my subsystem cache
> and I no longer can determine what I need to do with the artifacts.
>
> Does this approach look valid and am I on the correct path? Is all of
> this supported; if not which portion do I need to provide and what
> approach should I take to provide it?
>
>
> I appreciate any and all feed back.
>
> Thanks in advance.
>
>

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