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 Hans Dockter <ma...@dockter.biz> on 2008/04/22 14:01:15 UTC
[ANN] Gradle, a new build system, which uses Ivy
We are very excited to announce Gradle, a new build system.
We announce it on this list, as Gradle uses Ivy for its dependency
management.
To learn more about Gradle, have a look at http://www.gradle.org
or its 50+ pages userguide: http://gradle.org/userguide/release/
userguide.pdf
The rest of this posting is dedicated to Ivy and dependency
management in general.
Before I've started to develop Gradle I had only a faint idea about
Ivy. I had been using Maven for years, and I had started to develop a
new build system out of this not very satisfying experience. When I
was starting to develop the dependency management, I had a closer
look at Ivy and I decided to give it a try. I'm so happy that this
turned out to be a very good decision.
- Gradle integrates deeply with Ivy via its API. Although I guess not
many projects use Ivy via the API, the API has been almost perfect to
our needs. There was not a single ugly hack necessary, to make Ivy do
what Gradle needs. It was possible to introduce new concepts for
dependency management by using Ivy as a low level API. This says a
lot of the quality of Ivy's code base (and I guess about the virtues
of test driven development). I'm very impressed.
- Ivy has taught me a lot about the problem space of dependency
management (although I have considered myself as an experienced
build master for enterprise projects). The unit for measuring the
differences to Maven in solving this problem space is light-years :).
I'm still overwhelmed by the complexity of Ivy. Although I've worked
a lot with Ivy in the last 6 months I still consider myself being
just on the intermediate level. I'm still confused or unknowing about
the role of an IvyNode in the resolve process, the resolve process
details themselves, the usage of IvyContext, and many more things.
It would be terrific if an Ivy code expert would join me for a code
review on Gradle's usage of Ivy.
Ivy is so tremendously superior to the Maven2 dependency management,
and yet it seems Maven2 is taking up more and more of the market
share. Ivy scales up extremely well. What I think is missing is an
EasyIvy which does pretty much what Maven does. But without locking
you in, into this simplified approach. Gradle is offering exactly
this (and many other things).
Another thing that Gradle adds on top of Ivy are Client Modules. They
enable support for transitive dependency management without the need
for pom.xml or ivy.xml files. Thanks to Ivy's flexible repository
layout patterns, you can thus easily use a flat project folder (under
version control) containing the libraries and do something like:
dependencies {
clientModule('compile', ":groovy-all:1.5.5") {
dependency(":commons-cli:1.0")
clientModule(":ant:1.7.0") {
dependencies(":ant-junit:1.7.0:", ":ant-
launcher:1.7.0")
}
}
}
No ivy.xml necessary. No organisation id. No remote repositories. You
can check out the project and build it without the need to download
anything and yet have support for transitive dependency management.
It is a choice we give to our users. It is another part of the
EasyIvy idea.
There have been only a few things I was missing. The Ivy API does not
provide functionality for getting a list of files pointing to the
local location of the resolved libraries. I had to do a copy'n'paste
from Ivy's Ant cachepath task. On first sight, the same seems to be
true for doing reports. I need to have a close look on this topic.
I think it is an exciting time for build systems. Gradle is written
in Groovy and the build scripts are in Groovy. We think internal
DSL's based on a general purpose language like Groovy are better
suited for writing build scripts than XML. This is a different
discussion though.
Thanks a lot for Ivy
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
Re: [ANN] Gradle, a new build system, which uses Ivy
Posted by Xavier Hanin <xa...@gmail.com>.
Hans,
Thanks for sharing this news with us, it's very exciting to see a new build
system born, especially when it uses Ivy :-)
I'm currently reading the user guide, you've really done an excellent job!
>From what I read it seems to be a very flexible and powerful build tool. And
I really like your words on Ivy:
"Our dependency management is based on Apache Ivy, the most advanced and
powerful dependency management in the Java world."
The most advanced and powerful, nothing less :-) I guess the Ivy team and
community can be proud of it, I wish you the best!
Xavier
On Tue, Apr 22, 2008 at 2:01 PM, Hans Dockter <ma...@dockter.biz> wrote:
> We are very excited to announce Gradle, a new build system.
>
> We announce it on this list, as Gradle uses Ivy for its dependency
> management.
>
> To learn more about Gradle, have a look at http://www.gradle.org
>
> or its 50+ pages userguide: http://gradle.org/userguide/release/
> userguide.pdf
>
> The rest of this posting is dedicated to Ivy and dependency management in
> general.
>
> Before I've started to develop Gradle I had only a faint idea about Ivy. I
> had been using Maven for years, and I had started to develop a new build
> system out of this not very satisfying experience. When I was starting to
> develop the dependency management, I had a closer look at Ivy and I decided
> to give it a try. I'm so happy that this turned out to be a very good
> decision.
> - Gradle integrates deeply with Ivy via its API. Although I guess not many
> projects use Ivy via the API, the API has been almost perfect to our needs.
> There was not a single ugly hack necessary, to make Ivy do what Gradle
> needs. It was possible to introduce new concepts for dependency management
> by using Ivy as a low level API. This says a lot of the quality of Ivy's
> code base (and I guess about the virtues of test driven development). I'm
> very impressed.
> - Ivy has taught me a lot about the problem space of dependency management
> (although I have considered myself as an experienced build master for
> enterprise projects). The unit for measuring the differences to Maven in
> solving this problem space is light-years :).
>
> I'm still overwhelmed by the complexity of Ivy. Although I've worked a lot
> with Ivy in the last 6 months I still consider myself being just on the
> intermediate level. I'm still confused or unknowing about the role of an
> IvyNode in the resolve process, the resolve process details themselves, the
> usage of IvyContext, and many more things. It would be terrific if an Ivy
> code expert would join me for a code review on Gradle's usage of Ivy.
>
> Ivy is so tremendously superior to the Maven2 dependency management, and
> yet it seems Maven2 is taking up more and more of the market share. Ivy
> scales up extremely well. What I think is missing is an EasyIvy which does
> pretty much what Maven does. But without locking you in, into this
> simplified approach. Gradle is offering exactly this (and many other
> things).
>
> Another thing that Gradle adds on top of Ivy are Client Modules. They
> enable support for transitive dependency management without the need for
> pom.xml or ivy.xml files. Thanks to Ivy's flexible repository layout
> patterns, you can thus easily use a flat project folder (under version
> control) containing the libraries and do something like:
>
> dependencies {
> clientModule('compile', ":groovy-all:1.5.5") {
> dependency(":commons-cli:1.0")
> clientModule(":ant:1.7.0") {
> dependencies(":ant-junit:1.7.0:",
> ":ant-launcher:1.7.0")
> }
> }
> }
>
> No ivy.xml necessary. No organisation id. No remote repositories. You can
> check out the project and build it without the need to download anything and
> yet have support for transitive dependency management. It is a choice we
> give to our users. It is another part of the EasyIvy idea.
>
> There have been only a few things I was missing. The Ivy API does not
> provide functionality for getting a list of files pointing to the local
> location of the resolved libraries. I had to do a copy'n'paste from Ivy's
> Ant cachepath task. On first sight, the same seems to be true for doing
> reports. I need to have a close look on this topic.
>
> I think it is an exciting time for build systems. Gradle is written in
> Groovy and the build scripts are in Groovy. We think internal DSL's based on
> a general purpose language like Groovy are better suited for writing build
> scripts than XML. This is a different discussion though.
>
> Thanks a lot for Ivy
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: [ANN] Gradle, a new build system, which uses Ivy
Posted by Steve Loughran <st...@apache.org>.
Hans Dockter wrote:
> Hi Steve,
>
> On Apr 22, 2008, at 2:41 PM, Steve Loughran wrote:
>
>> Hans Dockter wrote:
>>> We are very excited to announce Gradle, a new build system.
>>> We announce it on this list, as Gradle uses Ivy for its dependency
>>> management.
>>> To learn more about Gradle, have a look at http://www.gradle.org
>>> or its 50+ pages userguide:
>>> http://gradle.org/userguide/release/userguide.pdf
>>
>>
>> Nice to see such detailed docs.
>>
>>> Ivy is so tremendously superior to the Maven2 dependency management,
>>> and yet it seems Maven2 is taking up more and more of the market
>>> share. Ivy scales up extremely well. What I think is missing is an
>>> EasyIvy which does pretty much what Maven does. But without locking
>>> you in, into this simplified approach. Gradle is offering exactly
>>> this (and many other things).
>>
>> To be honest, I think its eclipse that is taking up more and more
>> market share. We no longer have a java world of non-standard IDEs and
>> console only development. Some
>
> My focus is project automation. For example Gradle is being build by
> Gradle. The actual Java/Groovy stuff (producing the jar) is a tiny part
> of the build and is provided out of the box by Gradle. The interesting
> thing are for example:
>
> Automatic Release Management: We just execute gradle release: Our build
> knows the version of the last release. Then it checks the svn path of
> the working copy. If we are in a release branch and there has been a
> release before, the build does a revision release (including tagging).
> If we are in trunk it does a major/minor release, creates the branch and
> tags the release.
> Userguide: The userguide is generated. Most of the examples in the
> userguide are also integration tests. Our build executes these
> integration tests, and if they pass, the output and the sources of the
> tests are included in the userguide.
> Upload: We have the task uploadDists. Gradle allows a build to check the
> execution graph and do further configuration before anything is
> executed. If the 'release' is in the graph, we upload the distributions
> to the release destination. If the 'release' task is not in the graph,
> the version number gets an additional snapshot id and is uploaded to the
> snapshot repository.
>
> I could list more things we do for project automation. And after all
> Gradle is a rather simple project from a build perspective. No question,
> I love good IDEs'. But this is all stuff an IDE can't offer. We could
> add many more things why build tools are so important. But I guess I
> don't have to tell you :) And Gradle claims that these things can be
> implemented much easier as with the current tools.
oh, I dont disagree. As I type an xubuntu vmware image is running the
tests and is then about to <scp> up the RPMs for remote installation in
a test RHEL4 vmware image. Try doing that in the IDE without some helper
apps.
>
> I'm working on a paper comparing the approaches of Ant and Maven vs.
> using an internal DSL (e..g. Gradle's Groovy DSL). I've taken a few
> quotes from your book to underline my points :) When the first draft is
> ready, I can send it to you, if you like.
That's cool. I could send you a link to something I'm just writing in my
spare time too.
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: [ANN] Gradle, a new build system, which uses Ivy
Posted by Hans Dockter <ma...@dockter.biz>.
Hi Steve,
On Apr 22, 2008, at 2:41 PM, Steve Loughran wrote:
> Hans Dockter wrote:
>> We are very excited to announce Gradle, a new build system.
>> We announce it on this list, as Gradle uses Ivy for its dependency
>> management.
>> To learn more about Gradle, have a look at http://www.gradle.org
>> or its 50+ pages userguide: http://gradle.org/userguide/release/
>> userguide.pdf
>
>
> Nice to see such detailed docs.
>
>> Ivy is so tremendously superior to the Maven2 dependency
>> management, and yet it seems Maven2 is taking up more and more of
>> the market share. Ivy scales up extremely well. What I think is
>> missing is an EasyIvy which does pretty much what Maven does. But
>> without locking you in, into this simplified approach. Gradle is
>> offering exactly this (and many other things).
>
> To be honest, I think its eclipse that is taking up more and more
> market share. We no longer have a java world of non-standard IDEs
> and console only development. Some
My focus is project automation. For example Gradle is being build by
Gradle. The actual Java/Groovy stuff (producing the jar) is a tiny
part of the build and is provided out of the box by Gradle. The
interesting thing are for example:
Automatic Release Management: We just execute gradle release: Our
build knows the version of the last release. Then it checks the svn
path of the working copy. If we are in a release branch and there has
been a release before, the build does a revision release (including
tagging). If we are in trunk it does a major/minor release, creates
the branch and tags the release.
Userguide: The userguide is generated. Most of the examples in the
userguide are also integration tests. Our build executes these
integration tests, and if they pass, the output and the sources of
the tests are included in the userguide.
Upload: We have the task uploadDists. Gradle allows a build to check
the execution graph and do further configuration before anything is
executed. If the 'release' is in the graph, we upload the
distributions to the release destination. If the 'release' task is
not in the graph, the version number gets an additional snapshot id
and is uploaded to the snapshot repository.
I could list more things we do for project automation. And after all
Gradle is a rather simple project from a build perspective. No
question, I love good IDEs'. But this is all stuff an IDE can't
offer. We could add many more things why build tools are so
important. But I guess I don't have to tell you :) And Gradle claims
that these things can be implemented much easier as with the current
tools.
>
>> There have been only a few things I was missing. The Ivy API does
>> not provide functionality for getting a list of files pointing to
>> the local location of the resolved libraries. I had to do a
>> copy'n'paste from Ivy's Ant cachepath task. On first sight, the
>> same seems to be true for doing reports. I need to have a close
>> look on this topic.
>
> Something to put into the api then.
>
>
>> I think it is an exciting time for build systems. Gradle is
>> written in Groovy and the build scripts are in Groovy. We think
>> internal DSL's based on a general purpose language like Groovy are
>> better suited for writing build scripts than XML. This is a
>> different discussion though.
>
> Nice to see what you've done; I've put up a blog entry that will
> come out into planet apache shortly.
Very cool. Thanks.
I'm working on a paper comparing the approaches of Ant and Maven vs.
using an internal DSL (e..g. Gradle's Groovy DSL). I've taken a few
quotes from your book to underline my points :) When the first draft
is ready, I can send it to you, if you like.
>
>
> --
> Steve Loughran http://www.1060.org/blogxter/publish/5
> Author: Ant in Action http://antbook.org/
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
Re: [ANN] Gradle, a new build system, which uses Ivy
Posted by Steve Loughran <st...@apache.org>.
Hans Dockter wrote:
> We are very excited to announce Gradle, a new build system.
>
> We announce it on this list, as Gradle uses Ivy for its dependency
> management.
>
> To learn more about Gradle, have a look at http://www.gradle.org
>
> or its 50+ pages userguide:
> http://gradle.org/userguide/release/userguide.pdf
Nice to see such detailed docs.
>
> Ivy is so tremendously superior to the Maven2 dependency management, and
> yet it seems Maven2 is taking up more and more of the market share. Ivy
> scales up extremely well. What I think is missing is an EasyIvy which
> does pretty much what Maven does. But without locking you in, into this
> simplified approach. Gradle is offering exactly this (and many other
> things).
To be honest, I think its eclipse that is taking up more and more market
share. We no longer have a java world of non-standard IDEs and console
only development. Some
> There have been only a few things I was missing. The Ivy API does not
> provide functionality for getting a list of files pointing to the local
> location of the resolved libraries. I had to do a copy'n'paste from
> Ivy's Ant cachepath task. On first sight, the same seems to be true for
> doing reports. I need to have a close look on this topic.
Something to put into the api then.
> I think it is an exciting time for build systems. Gradle is written in
> Groovy and the build scripts are in Groovy. We think internal DSL's
> based on a general purpose language like Groovy are better suited for
> writing build scripts than XML. This is a different discussion though.
Nice to see what you've done; I've put up a blog entry that will come
out into planet apache shortly.
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: [ANN] Gradle, a new build system, which uses Ivy
Posted by Hans Dockter <ma...@dockter.biz>.
Hi Carlton,
On Apr 22, 2008, at 4:11 PM, Brown, Carlton wrote:
>> -----Original Message-----
>> From: Hans Dockter [mailto:mail@dockter.biz]
>> Sent: Tuesday, April 22, 2008 8:01 AM
>> To: ivy-user@ant.apache.org
>> Subject: [ANN] Gradle, a new build system, which uses Ivy
>>
>> We are very excited to announce Gradle, a new build system.
>>
>> We announce it on this list, as Gradle uses Ivy for its
>> dependency management.
>>
>> To learn more about Gradle, have a look at http://www.gradle.org
>>
>> or its 50+ pages userguide: http://gradle.org/userguide/release/
>> userguide.pdf
>
> I do like the use case of being able to resolve certain dependencies
> inline without an ivy.xml file. I can see where that would be
> convenient in some situations. But other than that, how is this
> really
> different from Gant? Both Gant and Gradle seem to have a goal of
> using
> Ant with Groovy instead of XML.
I don't want to abuse the Ivy mailing list too much. It would be
great if you can post questions of this kind to the Gradle mailing
list. This one I gonna answer here.
It is not the _goal_ of Gradle to use Ant without XML. It is a
feature of Gradle that you can use Ant _tasks_ (but you don't need to).
One might divide Ant into two layers. The first layer is the Ant
language. It contains the syntax for the build.xml, the handling of
the targets, special constructs like macrodefs, ...The second layer
of Ant is its tasks and types.
Calling Ant Tasks with Groovy is a build-in Groovy feature. Thus Gant
and Gradle offer this feature by simply using Groovy (with a tiny bit
of sugar on top).
The interesting thing is the language layer. Both Gradle and Gant
have there own implementation for this layer. For Gradle this layer
contains support for multi-project builds, pluggable build-by-
convention frameworks (e.g. for Java projects),
a rich api for targets (Gradles calls them differently). There are
many more features on top of that.
Gradle enables using Ant tasks but Gradle is a completely different
animal to Ant when it comes to writing the actual build script and
organizing your build logic. This is not just a difference between
Groovy and XML.
>
> -----------------------------------------
> ====================================================
> This message contains PRIVILEGED and CONFIDENTIAL
> information that is intended only for use by the
> named recipient. If you are not the named recipient,
> any disclosure, dissemination, or action based on
> the contents of this message is prohibited. In such
> case please notify us and destroy and delete all
> copies of this transmission. Thank you.
> ====================================================
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
RE: [ANN] Gradle, a new build system, which uses Ivy
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
> -----Original Message-----
> From: Hans Dockter [mailto:mail@dockter.biz]
> Sent: Tuesday, April 22, 2008 8:01 AM
> To: ivy-user@ant.apache.org
> Subject: [ANN] Gradle, a new build system, which uses Ivy
>
> We are very excited to announce Gradle, a new build system.
>
> We announce it on this list, as Gradle uses Ivy for its
> dependency management.
>
> To learn more about Gradle, have a look at http://www.gradle.org
>
> or its 50+ pages userguide: http://gradle.org/userguide/release/
> userguide.pdf
I do like the use case of being able to resolve certain dependencies
inline without an ivy.xml file. I can see where that would be
convenient in some situations. But other than that, how is this really
different from Gant? Both Gant and Gradle seem to have a goal of using
Ant with Groovy instead of XML.
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================
Re: [ANN] Gradle, a new build system, which uses Ivy
Posted by Hans Dockter <ma...@dockter.biz>.
Hi Nicolas,
On Apr 23, 2008, at 12:26 PM, Nicolas Lalevée wrote:
> Le mardi 22 avril 2008, Hans Dockter a écrit :
>> We are very excited to announce Gradle, a new build system.
>>
>> We announce it on this list, as Gradle uses Ivy for its dependency
>> management.
>>
>> To learn more about Gradle, have a look at http://www.gradle.org
>>
>> or its 50+ pages userguide: http://gradle.org/userguide/release/
>> userguide.pdf
>>
>> The rest of this posting is dedicated to Ivy and dependency
>> management in general.
>>
>> Before I've started to develop Gradle I had only a faint idea about
>> Ivy. I had been using Maven for years, and I had started to develop a
>> new build system out of this not very satisfying experience. When I
>> was starting to develop the dependency management, I had a closer
>> look at Ivy and I decided to give it a try. I'm so happy that this
>> turned out to be a very good decision.
>> - Gradle integrates deeply with Ivy via its API. Although I guess not
>> many projects use Ivy via the API, the API has been almost perfect to
>> our needs. There was not a single ugly hack necessary, to make Ivy do
>> what Gradle needs. It was possible to introduce new concepts for
>> dependency management by using Ivy as a low level API. This says a
>> lot of the quality of Ivy's code base (and I guess about the virtues
>> of test driven development). I'm very impressed.
>> - Ivy has taught me a lot about the problem space of dependency
>> management (although I have considered myself as an experienced
>> build master for enterprise projects). The unit for measuring the
>> differences to Maven in solving this problem space is light-years :).
>>
>> I'm still overwhelmed by the complexity of Ivy. Although I've worked
>> a lot with Ivy in the last 6 months I still consider myself being
>> just on the intermediate level. I'm still confused or unknowing about
>> the role of an IvyNode in the resolve process, the resolve process
>> details themselves, the usage of IvyContext, and many more things.
>> It would be terrific if an Ivy code expert would join me for a code
>> review on Gradle's usage of Ivy.
>>
>> Ivy is so tremendously superior to the Maven2 dependency management,
>> and yet it seems Maven2 is taking up more and more of the market
>> share. Ivy scales up extremely well. What I think is missing is an
>> EasyIvy which does pretty much what Maven does. But without locking
>> you in, into this simplified approach. Gradle is offering exactly
>> this (and many other things).
>>
>> Another thing that Gradle adds on top of Ivy are Client Modules. They
>> enable support for transitive dependency management without the need
>> for pom.xml or ivy.xml files. Thanks to Ivy's flexible repository
>> layout patterns, you can thus easily use a flat project folder (under
>> version control) containing the libraries and do something like:
>>
>> dependencies {
>> clientModule('compile', ":groovy-all:1.5.5") {
>> dependency(":commons-cli:1.0")
>> clientModule(":ant:1.7.0") {
>> dependencies(":ant-junit:1.7.0:", ":ant-
>> launcher:1.7.0")
>> }
>> }
>> }
>>
>> No ivy.xml necessary. No organisation id. No remote repositories. You
>> can check out the project and build it without the need to download
>> anything and yet have support for transitive dependency management.
>> It is a choice we give to our users. It is another part of the
>> EasyIvy idea.
>
> Here you introduced a new vocabulary to define dependencies. I
> don't see any
> reason to do so. The ivy.xml are not harder or simpler to read or
> write than
> the language to introduce. And you loose every work on tools which
> have been
> develop to manage ivy.xml files, like IvyDE and Ivy RoundUp
> Repository.
I agree that the ivy.xml is a expressive as the syntax above. I
always liked the conciseness of the ivy.xml.
Gradle can always produce an ivy.xml out of the information we have
and actually does so. If Gradle uploads artifacts to a repository,
they are uploaded with there ivy.xml. Therefore the Ivy RoundUp
repository for example is open to Gradle users.
There are two reasons why we have introduced an internal notation:
Most importantly, because we have introduced new kinds of
dependencies (Client Modules and Project Dependencies). There is no
way to express them via an ivy.xml. And we don't want to require two
different files for maintaiing the dependencies. The other reason has
to do with dynamicity. With Gradle you can do the declaration of the
dependencies with a full-blown OO language. You can write: dependency
(getStringFromTheMoonDataBaseAndApplyTheQuantumFilter()). I'm not
saying that this is a major use case. But one of Gradle's principles
is 'Maximum Freedom'. And I'm sure there are people who are going to
have use cases for this dynamicity.
What price do we pay for this? We loose any existing support for
writing our dependency declaration. I don't think this is very
dramatic. And I hope that in the future there will be some explicit
IDE support for Gradle. I don't know anything about IvyDE. If IvyDE
allows that its services are used in isolation we could make use of
this. For example, as Gradle always has an ivy.xml file under the
hood) we could ask IvyDE to generate the .classpath and .project
files. In fact it would be cool if this functionality would be
available to console commands.
Having said this, we want to offer choice to our users. Not just
because of your email. It has been always on our roadmap to support
existing ivy.xml files. I don't think this is going to be difficult.
>
> Althoutgh Gradle seems interesting by its integration with Ant
> tasks. And then
> we should be able to use the Ivy Ant tasks.
Using Ivy from Gradle via its Ant tasks is possible. But you would
loose very nice functionality, in particular when doing multi-project
builds.
>
> Nicolas
>
>
>
>>
>> There have been only a few things I was missing. The Ivy API does not
>> provide functionality for getting a list of files pointing to the
>> local location of the resolved libraries. I had to do a copy'n'paste
>> from Ivy's Ant cachepath task. On first sight, the same seems to be
>> true for doing reports. I need to have a close look on this topic.
>>
>> I think it is an exciting time for build systems. Gradle is written
>> in Groovy and the build scripts are in Groovy. We think internal
>> DSL's based on a general purpose language like Groovy are better
>> suited for writing build scripts than XML. This is a different
>> discussion though.
>>
>> Thanks a lot for Ivy
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project lead
>> http://www.gradle.org
>
>
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
Re: [ANN] Gradle, a new build system, which uses Ivy
Posted by Nicolas Lalevée <ni...@joost.com>.
Le mardi 22 avril 2008, Hans Dockter a écrit :
> We are very excited to announce Gradle, a new build system.
>
> We announce it on this list, as Gradle uses Ivy for its dependency
> management.
>
> To learn more about Gradle, have a look at http://www.gradle.org
>
> or its 50+ pages userguide: http://gradle.org/userguide/release/
> userguide.pdf
>
> The rest of this posting is dedicated to Ivy and dependency
> management in general.
>
> Before I've started to develop Gradle I had only a faint idea about
> Ivy. I had been using Maven for years, and I had started to develop a
> new build system out of this not very satisfying experience. When I
> was starting to develop the dependency management, I had a closer
> look at Ivy and I decided to give it a try. I'm so happy that this
> turned out to be a very good decision.
> - Gradle integrates deeply with Ivy via its API. Although I guess not
> many projects use Ivy via the API, the API has been almost perfect to
> our needs. There was not a single ugly hack necessary, to make Ivy do
> what Gradle needs. It was possible to introduce new concepts for
> dependency management by using Ivy as a low level API. This says a
> lot of the quality of Ivy's code base (and I guess about the virtues
> of test driven development). I'm very impressed.
> - Ivy has taught me a lot about the problem space of dependency
> management (although I have considered myself as an experienced
> build master for enterprise projects). The unit for measuring the
> differences to Maven in solving this problem space is light-years :).
>
> I'm still overwhelmed by the complexity of Ivy. Although I've worked
> a lot with Ivy in the last 6 months I still consider myself being
> just on the intermediate level. I'm still confused or unknowing about
> the role of an IvyNode in the resolve process, the resolve process
> details themselves, the usage of IvyContext, and many more things.
> It would be terrific if an Ivy code expert would join me for a code
> review on Gradle's usage of Ivy.
>
> Ivy is so tremendously superior to the Maven2 dependency management,
> and yet it seems Maven2 is taking up more and more of the market
> share. Ivy scales up extremely well. What I think is missing is an
> EasyIvy which does pretty much what Maven does. But without locking
> you in, into this simplified approach. Gradle is offering exactly
> this (and many other things).
>
> Another thing that Gradle adds on top of Ivy are Client Modules. They
> enable support for transitive dependency management without the need
> for pom.xml or ivy.xml files. Thanks to Ivy's flexible repository
> layout patterns, you can thus easily use a flat project folder (under
> version control) containing the libraries and do something like:
>
> dependencies {
> clientModule('compile', ":groovy-all:1.5.5") {
> dependency(":commons-cli:1.0")
> clientModule(":ant:1.7.0") {
> dependencies(":ant-junit:1.7.0:", ":ant-
> launcher:1.7.0")
> }
> }
> }
>
> No ivy.xml necessary. No organisation id. No remote repositories. You
> can check out the project and build it without the need to download
> anything and yet have support for transitive dependency management.
> It is a choice we give to our users. It is another part of the
> EasyIvy idea.
Here you introduced a new vocabulary to define dependencies. I don't see any
reason to do so. The ivy.xml are not harder or simpler to read or write than
the language to introduce. And you loose every work on tools which have been
develop to manage ivy.xml files, like IvyDE and Ivy RoundUp Repository.
Althoutgh Gradle seems interesting by its integration with Ant tasks. And then
we should be able to use the Ivy Ant tasks.
Nicolas
>
> There have been only a few things I was missing. The Ivy API does not
> provide functionality for getting a list of files pointing to the
> local location of the resolved libraries. I had to do a copy'n'paste
> from Ivy's Ant cachepath task. On first sight, the same seems to be
> true for doing reports. I need to have a close look on this topic.
>
> I think it is an exciting time for build systems. Gradle is written
> in Groovy and the build scripts are in Groovy. We think internal
> DSL's based on a general purpose language like Groovy are better
> suited for writing build scripts than XML. This is a different
> discussion though.
>
> Thanks a lot for Ivy
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org