It looks like you're on the right track with (2). On the ant target, use
the pattern attribute and the conf attribute to get things in the right
directory.
Here's an example of what I use:
<ivy:retrieve
pattern="${build.lib}/[artifact]-[revision](-[classifier]).[ext]"
sync="true" conf="runtime" />
The pattern attribute tells ivy where to copy the files to. In my case, I
download all the dependencies specified with the "runtime" conf to the
directory specified by build.lib ant variable. The
[artifact]-[revision](-[classifier]).[ext] portion tells Ivy how I want the
jar files named in the build lib directory.
In what I've posted, if build.lib = "lib" and my only dependency entry with
a conf of "runtime" is log4j version 1.2.15, I end up with the following
directory structure
-- lib
-- log4j-1.2.15.jar
Hope this helps.
Thanks,
topher
On Thu, Apr 29, 2010 at 2:59 PM, Archie Cobbs <archie.co...@gmail.com>wrote:
> 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
>
