You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by infinity2heaven <in...@gmail.com> on 2010/04/29 22:31:59 UTC
Re: example ivy & build.xml file for spring/jsf/hibernate project
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.
Re: example ivy & build.xml file for spring/jsf/hibernate project
Posted by Chris Marks <to...@gmail.com>.
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 <ar...@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
> <in...@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
>
Re: example ivy & build.xml file for spring/jsf/hibernate project
Posted by Archie Cobbs <ar...@gmail.com>.
On Fri, Apr 30, 2010 at 10:00 AM, infinity2heaven <infinity2heaven@gmail.com
> wrote:
> You are now asking me to learn these things which has nothing to do with my
> original problem -- new macros (500 page macrodef file), Ivy 2.0 features
> called packager (apart from the already existing concepts around ivy).
>
> Think for yourself. I am not a framework developer (I can be but that's not
> what I do). I'm just a framework/library user and I'm looking for a key
> abstraction here. I don't know if I want to know the internals or want to
> read a 200 page manual for something like that.
>
Just to be clear, I'm not asking you to do anything. I'm just offering this
"for what it's worth".
In your case, it may very well be worth exactly what you paid for it :-)
> Is what I'm asking that hard? If there is no straight answer, I'd imagine
> it
> is and maybe I should go back and stick to copy/paste jars. (Mind you, I
> use
> Maven for my hobby projects) but I work for a large corporation that are
> resistant to change for this exact reason.
>
I have been in the same place before and understand your frustration. But
realize that most of the complexity of ivy derives from the inherent
complexity of the problem domain that it is trying to address. If ivy were a
lot simpler, it simply would not completely work.
It's a short term/long term trade-off kindof thing. You use ivy if you want
to invest in a short term cost (learning curve) for a longer term payoff in
future maintainability.
At some point in the past I was in a similar situation as yours and decided
to "bite the bullet' and go ahead and try to understand this stuff and put
it into a form that I could use efficiently... the example given is what I
eventually came up with that works for me. Of course up to you to decide
whether this kindof thing is worth the trouble in your own situation.
-Archie
--
Archie L. Cobbs
Re: example ivy & build.xml file for spring/jsf/hibernate project
Posted by Niklas Matthies <ml...@nmhq.net>.
On Fri 2010-04-30 at 08:00h, infinity2heaven wrote on ivy-user:
:
> Is what I'm asking that hard?
I would maybe put it this way: Ivy is a tool for library providers to
make things simpler for their library users. But for the library
providers themselves, doing this in a good way is not necessarily very
simple, depending on the complexity of the library. The problem you
have is that the providers of the libraries you're interested in
either don't use Ivy at all, so you have to do their work, or they use
Ivy in different ways (different conf setup etc.), so you have to do
some integration work to match it up with the conventions used by
other libraries, and with your own.
The flexibility that makes Ivy powerful means at the same time that
there are no fixed predetermined conventions, so everyone uses
slightly different (or sometime very different) setups.
And then Ivy only does the dependency management part, so the task of
writing build scripts that meet your needs remains yours.
But to answer your question: Yes, it's that hard, unfortunately.
-- Niklas Matthies
Re: example ivy & build.xml file for spring/jsf/hibernate project
Posted by infinity2heaven <in...@gmail.com>.
Thanks for your reply. Looking at your sidekar project, it appears that you
have thought this through throughly and derived some great approaches for
your build system. I applaud that.
I spent 30 mins looking into it and figured it's going to take a whole day
to put my understanding together. After all that, there could be issues that
I have and I will end up coming back to this forum asking for the same and
someone else will refer me to their internal library built around Ivy and I
will learn that too. At some point later, I will end up learning 2 new
libraries but I fear that my original problem is not unresolved.
You are now asking me to learn these things which has nothing to do with my
original problem -- new macros (500 page macrodef file), Ivy 2.0 features
called packager (apart from the already existing concepts around ivy).
Think for yourself. I am not a framework developer (I can be but that's not
what I do). I'm just a framework/library user and I'm looking for a key
abstraction here. I don't know if I want to know the internals or want to
read a 200 page manual for something like that.
Is what I'm asking that hard? If there is no straight answer, I'd imagine it
is and maybe I should go back and stick to copy/paste jars. (Mind you, I use
Maven for my hobby projects) but I work for a large corporation that are
resistant to change for this exact reason.
Archie Cobbs-3 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
>
--
View this message in context: http://old.nabble.com/example-ivy---build.xml-file-for-spring-jsf-hibernate-project-tp22461453p28413244.html
Sent from the ivy-user mailing list archive at Nabble.com.
Re: example ivy & build.xml file for spring/jsf/hibernate project
Posted by Archie Cobbs <ar...@gmail.com>.
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
<in...@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