ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Dockter <m...@dockter.biz>
Subject Re: [ANN] Gradle, a new build system, which uses Ivy
Date Wed, 23 Apr 2008 12:00:40 GMT
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





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