On Feb 26, 2009, at 2:49 PM, Bernard Niset wrote:
Hi Hans,
As a current Ant and Ivy user, gradle is really the build tool I
have been dreaming about for a long time. So thanks a lot for making
it possible...
I will probably have more requests in the future, but one that comes
from the top of my head: is it possible to use a native ivy
configuration (ivy.xml file) instead of dependency DSL ?
The format of the ivy.xml file is very concise and easy to use. I
would say probably easier then current DSL ;-).
I agree that the ivy.xml has a nice syntax. And we should definitely
make it possible to import it. There are Jira's for this, they just
have to be implemented :). The implementation should be pretty much
straight forward. Our idea is to have an Ivy plugin, which would read
the ivysettings.xml and the ivy.xml. The plugin may also provide some
translation layer to adapt the ivy.xml (mainly the configurations) to
the build-by-convention assumptions of the java plugin. Of course
another nice feature would be a script that translates an ivy.xml into
the Gradle notation.
Having said this, the way we model the domain has subtle difference to
how Ivy models it. Gradle and Ivy have different constraints. We want
to provide a very good DSL and toolset for the usage within a dynamic
language. Yet there was so many other stuff to do, that the current
DSL is mostly the DSL of 0.1. Now finally with 0.6 we spend a lot of
energy in making the Gradle DSL nicer to read and more concise. As
time evolve I think we will discover more and more scenarios were the
dynamic declaration of dependencies is very handy and in fact will be
simpler and yet more powerful compared to an XML approach.
- Hans
Kind regards,
Bernard.
Hans Dockter wrote:
On Feb 25, 2009, at 9:26 AM, Levi Hoogenberg wrote:
Ah, good to know. I got lazy and just added an empty 'default'
configuration to my repository. Glad to see you got it working.
On Wed, Feb 25, 2009 at 9:21 AM, Bernard Niset
<[email protected]> wrote:
Thanks Levi and Neil,
I finally got it working with this setup:
compile("codehaus:groovy:1.5.
6") {
dependencyConfigurationMappings.mappings.clear()
dependencyConfigurations( 'all') }
The dependencyConfigurationss ('all') does the same thing as Levi
suggested. The syntax was correct but it didn't fully solve the
problem. I believe this add configurations to the dependency
whereas what I needed was using only the 'all' configuration.
That's why I add to do
dependencyConfigurationMappings.mappings.clear() to remove the
'default' configuration.
This configuration DSL of Gradle should really be better explained
in Documentation.
Now I can continue evaluating Gradle for my build process.
I agree. Fortunately things will be simpler in Gradle 0.6 (see my
other posting on the new DSL).
You just need to write:
compile.dependsOn("codehaus:groovy:1.5.6") {
dependencyConfigurations = ['all']
}
As dependencies belong to one and only one configuration in 0.6, we
don't have to deal with many-to-many mappings any longer.
- Hans
Kind regards,
Bernard.
Levi Hoogenberg wrote:
Hi,
the syntax I use is
compile('codehaus:groovy:1.5.6') {
dependencyConfigurationMappings.add 'all'
}
Levi
On Tue, Feb 24, 2009 at 11:34 PM, Bernard Niset
<[email protected]> wrote:
Hi all,
I am desperately looking for the syntax to specify a dependency
to a specific conf specified in the ivy.xml file. I have been
trying things like the following and other variants, I can't find
a way to make it work.
dependencies
{
...
compile "apache:commons-io:1.4",
"apache:log4j:1.2.14",
"gradle:gradle:0.5.2"
compile("codehaus:groovy:1.5.6") { configurations:["all"] }
...
}
Thanks for any help,
Bernard.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
