For what it's worth, here is a setup I've used a few times. It requires a
little bit of infrastructure (see macros.xml for where to put ivy.jar and
ant-contrib.jar) but once you've got that configuring what you want is
pretty straightforward.

You can view this
example<http://code.google.com/p/sidekar/source/browse/#svn/trunk>in a
Java object database project... you only need to pay attention to
these
files:

build.xml <http://code.google.com/p/sidekar/source/browse/trunk/build.xml>
src/build/macros.xml<http://code.google.com/p/sidekar/source/browse/trunk/src/build/macros.xml>
src/ivy/settings.xml<http://code.google.com/p/sidekar/source/browse/trunk/src/ivy/settings.xml>
src/ivy/ivy.xml<http://code.google.com/p/sidekar/source/browse/trunk/src/ivy/ivy.xml>

-Archie

On Thu, Apr 29, 2010 at 3:31 PM, infinity2heaven
<infinity2hea...@gmail.com>wrote:

>
> I tried to use ivy multiple times in the past and refused to use it only
> because it was complex enough for my simple needs. I don't want to use
> Maven2 for the same reason. Before I grapple, let me give you my use case.
> Currently I use an ant build with simple tasks for compile, test, deploy,
> clean etc. I have a lib directory structure like this:
>
>  - lib
>    -- compile
>    -- test
>    -- runtime
>    -- ext
>
> As you figured, I drop jars (manually) into these folders and my ant build
> has a classpath.ref set accordingly for the corresponding tasks. That all
> seems so easy because I have an existing app that works, so I copy/paste
> jars into the new one. It all works fine. You don't have to read a 200 page
> manual on how to use maven or ivy, for instance.
>
> But I'm a developer too and I know that this copy/paste process sucks and
> each time I try to upgrade my libraries, it's a nightmare. There are some
> jars in my libs that I don't know why it's there, but I don't want to
> remove
> them.
>
> Ok.
>
> I've used maven for a few opensource projects, it's fine. Seems easy for
> starter projects but almost always doesn't work for existing large
> projects.
> I read about ivy, fiddled around a few times but I was still not convinced.
> People talk about Gradle, but I don't understand why would anyone learn a
> DSL for writing build scripts.
>
> Ok. Enough rant.
>
> So I returned back, decided to spent a full 3 days to figure this out and
> here's what I got so far with Ivy:
>
> - I understand how to writing a basic ivysettings file, resolve/retrieve
> jars using ivy-ant tasks and write a simple ivy.xml fle with some
> dependencies. But here's the problem: The default dependencies either load
> every other dependency or does not load at all. Put simply, I want an ant
> task that I can write where I mention, "spring framework" and I want Ivy to
> automatically download corresponding dependencies and copy them into the
> above folder structure based on the dependency type (compile, runtime ...).
>
> Is that too much to ask for? Really? Remember, I was doing this all by
> hand,
> before.
>
> I still haven't figured a clean way to do it yet. Ivy either downloads all
> into one spot, there is no clear way of distinguishing the dependency types
> with "conf" setting. My problem is, why should I know what spring needs at
> compile time or runtime? Why? Isn't that why I'm using Ivy or Gradle or
> whatever fancy tool that comes next?
>
> As I concluded today (and I could be totally wrong), there is no clean  way
> of doing this. One has to open up the pom or ivy files of individual
> libraries and figure out for themselves what to include or not.
>
> Wouldn't it be fantastic to write a build file that says -- include
> spring-<version>, hibernate-<version>, jsf-<version>, richfaces-<version>
> and be done with it?
>
>
> So here are a few configs I tried:
>
> 1)
>
>  <dependency org="org.springframework" name="org.springframework.core"
> rev="${spring.version}" />
>      <dependency org="org.springframework"
> name="org.springframework.context" rev="${spring.version}"/>
>      <dependency org="org.springframework"
> name="org.springframework.context.support" rev="${spring.version}"/>
>      <dependency org="org.springframework" name="org.springframework.beans"
> rev="${spring.version}" />
>      <dependency org="org.aspectj"
> name="com.springsource.org.aspectj.weaver" rev="1.5.4"/>
>      <dependency org="org.springframework" name="org.springframework.aop"
> rev="${spring.version}"/>
>  <dependency org="org.hibernate" name="ejb3-persistence" rev="1.0.2.GA" />
>  <dependency org="org.hibernate" name="hibernate-core"
> rev="${hibernate.version}" "/>
>
>
> 2)
>  <configurations>
>        <conf name="default" visibility="public" description="runtime
> dependencies and master artifact can be used with this conf"
> extends="runtime,master"/>
>        <conf name="master" visibility="public" description="contains only
> the artifact published by this module itself, with no transitive
> dependencies"/>
>        <conf name="compile" visibility="public" description="this is the
> default scope, used if none is specified. Compile dependencies are
> available
> in all classpaths."/>
>        <conf name="provided" visibility="public" description="this is much
> like compile, but indicates you expect the JDK or a container to provide
> it.
> It is only available on the compilation classpath, and is not
> transitive."/>
>        <conf name="runtime" visibility="public" description="this scope
> indicates that the dependency is not required for compilation, but is for
> execution. It is in the runtime and test classpaths, but not the compile
> classpath." extends="compile"/>
>        <conf name="test" visibility="private" description="this scope
> indicates that the dependency is not required for normal use of the
> application, and is only available for the test compilation and execution
> phases." extends="runtime"/>
>    </configurations>
>
>        <dependencies>
>          <dependency org="org.springframework"
> name="org.springframework.core"
> rev="${spring.version}"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>      <dependency org="org.springframework"
> name="org.springframework.context" rev="${spring.version}"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>      <dependency org="org.springframework"
> name="org.springframework.context.support" rev="${spring.version}"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>      <dependency org="org.springframework" name="org.springframework.beans"
> rev="${spring.version}"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>      <dependency org="org.aspectj"
> name="com.springsource.org.aspectj.weaver" rev="1.5.4"/>
>      <dependency org="org.springframework" name="org.springframework.aop"
> rev="${spring.version}"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>
>      <dependency org="org.hibernate" name="ejb3-persistence" rev="1.0.2.GA
> "
> transitive="true"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>      <dependency org="org.hibernate" name="hibernate-core"
> rev="${hibernate.version}"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>      <dependency org="org.jboss.el" name="jboss-el" rev="1.0_02.CR2"
> transitive="false"
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>
>      <dependency org="org.richfaces.framework" name="richfaces-api"
> force="true" rev="${richfaces.version}"/>
>      <dependency org="org.richfaces.framework" name="richfaces-impl"
> force="true" rev="${richfaces.version}"/>
>      <dependency org="org.richfaces.ui" name="richfaces-ui" force="true"
> rev="${richfaces.version}"/>
>
>
>
> What is my expectation from a "build tool?" I need to integrate Spring and
> Hibernate in my web project. But I don't want to spend two days to figure
> what are the runtime and compile time dependencies by myself. I can get
> that
> by reading a pom file of every single jar that I want and write an exclude
> for that. At this point, I'm thinking, "Why am I using ivy in the first
> place?"
>
>
> Would greatly appreciate if someone would point out what I'm doing wrong.
>
> Thanks.
>
>
> Perfect. Thanks.
>
> Also, to retrieve only jars and not source or javadocs, I figured this is a
> better way:
> In your build.xml, add a "type" qualifier for ivy:retrieve. (default takes
> in all files!)
>
> <target name="resolve" description="--> retreive dependencies with ivy">
>        <ivy:retrieve type="jar"/>
> </target>
>
>
>
>
> --
> View this message in context:
> http://old.nabble.com/example-ivy---build.xml-file-for-spring-jsf-hibernate-project-tp22461453p28405448.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>


-- 
Archie L. Cobbs

Reply via email to