Out of the box maven support?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Out of the box maven support?

Bert van Brakel
If I currently have a project in maven  (1 or 2) and I want to switch to using gradle, are there any tools for this?

It would be great if gradle just looks for a pom.xml and simply runs a maven like build. It would certainly help to convince maven users to migrate to gradle if there is zero effort to transition. Over time more stuff could be added to the gradlefile. Maybe the gradlefile could be auto generated from an existing pom (even if just in memory)?

I'm thinking along the lines of introducing gradle by stealth. Leave the existing maven stuff there, which continues to work, but add my own extra spice in using gradle. I'm hesitant to spend heaps of time replicating all the info in the poms, and keep them in sync.

Thoughts, ideas, RTFM welcome

Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support?

hans_d
Administrator
Hi Bert,

On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:

If I currently have a project in maven  (1 or 2) and I want to switch to
using gradle, are there any tools for this?

It would be great if gradle just looks for a pom.xml and simply runs a maven
like build. It would certainly help to convince maven users to migrate to
gradle if there is zero effort to transition. Over time more stuff could be
added to the gradlefile. Maybe the gradlefile could be auto generated from
an existing pom (even if just in memory)?

I'm thinking along the lines of introducing gradle by stealth. Leave the
existing maven stuff there, which continues to work, but add my own extra
spice in using gradle. I'm hesitant to spend heaps of time replicating all
the info in the poms, and keep them in sync.

Such functionality is not implemented yet but we plan to this very soon. Similar to what you have proposed we want to offer 2 things:

Using an existing pom.file: We plan to make only use of the dependency information in the pom.file. The pom would be used in a way that you can additionally declare dependencies in the gradle build script if wanted. We are not sure what to do with parent poms as Gradle has its own multi-project build structure. It seems hard to map them to each other.
 
Transform the pom file: A functionality that creates a gradlefile out of a pom. 

It is an interesting use case we haven't thought of to use Gradle to add functionality on an existing and still in use Maven build. For simple Maven builds I see no problem, if the poms use inheritance and are part of a multiproject build things look more complicated.

We want to provide this functionality for 0.2.

- Hans


Thoughts, ideas, RTFM welcome


-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support?

Bert van Brakel
hdockter wrote
On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:

> If I currently have a project in maven  (1 or 2) and I want to  
> switch to
> using gradle, are there any tools for this?
>
> It would be great if gradle just looks for a pom.xml and simply  
> runs a maven
> like build. It would certainly help to convince maven users to  

Such functionality is not implemented yet but we plan to this very  
soon. Similar to what you have proposed we want to offer 2 things:

It is an interesting use case we haven't thought of to use Gradle to  
add functionality on an existing and still in use Maven build. For  
simple Maven builds I see no problem, if the poms use inheritance and  
are part of a multiproject build things look more complicated.

We want to provide this functionality for 0.2.
great, sounds good!

However I think supplementing a current maven build may be a good way to get traction in the enterprise where folks tend to be risk adverse (fair enough), don't have time to rip everything up and start again (after all, time is money and you need to convince alot of people first of the benefits), and developers don't tend to have a lot of time to try out new tools and spend the time to set them up. If out of the box maven support exists then it's a matter of install tool, run, done. The risk and ramp up time is nil, if it doesn't work, then fall back to maven.
Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support?

hans_d
Administrator

On May 14, 2008, at 10:17 AM, Bert van Brakel wrote:


hdockter wrote:


On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:

If I currently have a project in maven  (1 or 2) and I want to  
switch to
using gradle, are there any tools for this?

It would be great if gradle just looks for a pom.xml and simply  
runs a maven
like build. It would certainly help to convince maven users to  

Such functionality is not implemented yet but we plan to this very  
soon. Similar to what you have proposed we want to offer 2 things:

It is an interesting use case we haven't thought of to use Gradle to  
add functionality on an existing and still in use Maven build. For  
simple Maven builds I see no problem, if the poms use inheritance and  
are part of a multiproject build things look more complicated.

We want to provide this functionality for 0.2.

great, sounds good!

However I think supplementing a current maven build may be a good way to get
traction in the enterprise where folks tend to be risk adverse (fair
enough), don't have time to rip everything up and start again (after all,
time is money and you need to convince alot of people first of the
benefits), and developers don't tend to have a lot of time to try out new
tools and spend the time to set them up. If out of the box maven support
exists then it's a matter of install tool, run, done. The risk and ramp up
time is nil, if it doesn't work, then fall back to maven.

I completely agree. Soft migration paths are a very good thing. Another step would be to integrate existing Ant and Maven builds as they are, into a Gradle multi-project build. 

- Hans


-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support?

astubbs
Did something to address this make it into .2?

Fyi: I'm new to Gradle.

I created an issue regarding Maven migration here:
http://jira.codehaus.org/browse/GRADLE-154

hdockter wrote
On May 14, 2008, at 10:17 AM, Bert van Brakel wrote:

>
>
> hdockter wrote:
>>
>>
>> On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:
>>
>>> If I currently have a project in maven  (1 or 2) and I want to
>>> switch to
>>> using gradle, are there any tools for this?
>>>
>>> It would be great if gradle just looks for a pom.xml and simply
>>> runs a maven
>>> like build. It would certainly help to convince maven users to
>>
>> Such functionality is not implemented yet but we plan to this very
>> soon. Similar to what you have proposed we want to offer 2 things:
>>
>> It is an interesting use case we haven't thought of to use Gradle to
>> add functionality on an existing and still in use Maven build. For
>> simple Maven builds I see no problem, if the poms use inheritance and
>> are part of a multiproject build things look more complicated.
>>
>> We want to provide this functionality for 0.2.
>>
> great, sounds good!
>
> However I think supplementing a current maven build may be a good  
> way to get
> traction in the enterprise where folks tend to be risk adverse (fair
> enough), don't have time to rip everything up and start again  
> (after all,
> time is money and you need to convince alot of people first of the
> benefits), and developers don't tend to have a lot of time to try  
> out new
> tools and spend the time to set them up. If out of the box maven  
> support
> exists then it's a matter of install tool, run, done. The risk and  
> ramp up
> time is nil, if it doesn't work, then fall back to maven.

I completely agree. Soft migration paths are a very good thing.  
Another step would be to integrate existing Ant and Maven builds as  
they are, into a Gradle multi-project build.

- Hans

>
> --
> View this message in context: http://www.nabble.com/Out-of-the-box- 
> maven-support--tp17143114p17225951.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Hans Dockter
Gradle Project lead
http://www.gradle.org



Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support? - one off maven dependecy translation

astubbs
FYI, I submited a simple Groovy script to perform dependency translation:
http://jira.codehaus.org/browse/GRADLE-154

Groovy is cooool... :)

It's basically:
def records = new XmlParser().parseText(DEPENDENCIES_STRING)
records.each() {
    println "compile: \"${it.groupId.text()}:${it.artifactId.text()}:${it?.version?.text()}\""
}


Antony Stubbs wrote
Did something to address this make it into .2?

Fyi: I'm new to Gradle.

I created an issue regarding Maven migration here:
http://jira.codehaus.org/browse/GRADLE-154

hdockter wrote
On May 14, 2008, at 10:17 AM, Bert van Brakel wrote:

>
>
> hdockter wrote:
>>
>>
>> On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:
>>
>>> If I currently have a project in maven  (1 or 2) and I want to
>>> switch to
>>> using gradle, are there any tools for this?
>>>
>>> It would be great if gradle just looks for a pom.xml and simply
>>> runs a maven
>>> like build. It would certainly help to convince maven users to
>>
>> Such functionality is not implemented yet but we plan to this very
>> soon. Similar to what you have proposed we want to offer 2 things:
>>
>> It is an interesting use case we haven't thought of to use Gradle to
>> add functionality on an existing and still in use Maven build. For
>> simple Maven builds I see no problem, if the poms use inheritance and
>> are part of a multiproject build things look more complicated.
>>
>> We want to provide this functionality for 0.2.
>>
> great, sounds good!
>
> However I think supplementing a current maven build may be a good  
> way to get
> traction in the enterprise where folks tend to be risk adverse (fair
> enough), don't have time to rip everything up and start again  
> (after all,
> time is money and you need to convince alot of people first of the
> benefits), and developers don't tend to have a lot of time to try  
> out new
> tools and spend the time to set them up. If out of the box maven  
> support
> exists then it's a matter of install tool, run, done. The risk and  
> ramp up
> time is nil, if it doesn't work, then fall back to maven.

I completely agree. Soft migration paths are a very good thing.  
Another step would be to integrate existing Ant and Maven builds as  
they are, into a Gradle multi-project build.

- Hans

>
> --
> View this message in context: http://www.nabble.com/Out-of-the-box- 
> maven-support--tp17143114p17225951.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Hans Dockter
Gradle Project lead
http://www.gradle.org



Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support? - one off maven dependecy translation

Marko Bauhardt-3
Hi Antony,
cool. this is very helpfully to porting our maven projects into gradle  
projects.

thanks
marko



On Jul 10, 2008, at 1:37 PM, Antony Stubbs wrote:

>
> FYI, I submited a simple Groovy script to perform dependency  
> translation:
> http://jira.codehaus.org/browse/GRADLE-154
>
> Groovy is cooool... :)
>
> It's basically:
> def records = new XmlParser().parseText(DEPENDENCIES_STRING)
> records.each() {
>    println "compile:
> \"${it.groupId.text()}:${it.artifactId.text()}:${it?.version?.text()}
> \""
> }
>
>
>
> Antony Stubbs wrote:
>>
>> Did something to address this make it into .2?
>>
>> Fyi: I'm new to Gradle.
>>
>> I created an issue regarding Maven migration here:
>> http://jira.codehaus.org/browse/GRADLE-154
>>
>>
>> hdockter wrote:
>>>
>>>
>>> On May 14, 2008, at 10:17 AM, Bert van Brakel wrote:
>>>
>>>>
>>>>
>>>> hdockter wrote:
>>>>>
>>>>>
>>>>> On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:
>>>>>
>>>>>> If I currently have a project in maven  (1 or 2) and I want to
>>>>>> switch to
>>>>>> using gradle, are there any tools for this?
>>>>>>
>>>>>> It would be great if gradle just looks for a pom.xml and simply
>>>>>> runs a maven
>>>>>> like build. It would certainly help to convince maven users to
>>>>>
>>>>> Such functionality is not implemented yet but we plan to this very
>>>>> soon. Similar to what you have proposed we want to offer 2 things:
>>>>>
>>>>> It is an interesting use case we haven't thought of to use  
>>>>> Gradle to
>>>>> add functionality on an existing and still in use Maven build. For
>>>>> simple Maven builds I see no problem, if the poms use  
>>>>> inheritance and
>>>>> are part of a multiproject build things look more complicated.
>>>>>
>>>>> We want to provide this functionality for 0.2.
>>>>>
>>>> great, sounds good!
>>>>
>>>> However I think supplementing a current maven build may be a good
>>>> way to get
>>>> traction in the enterprise where folks tend to be risk adverse  
>>>> (fair
>>>> enough), don't have time to rip everything up and start again
>>>> (after all,
>>>> time is money and you need to convince alot of people first of the
>>>> benefits), and developers don't tend to have a lot of time to try
>>>> out new
>>>> tools and spend the time to set them up. If out of the box maven
>>>> support
>>>> exists then it's a matter of install tool, run, done. The risk and
>>>> ramp up
>>>> time is nil, if it doesn't work, then fall back to maven.
>>>
>>> I completely agree. Soft migration paths are a very good thing.
>>> Another step would be to integrate existing Ant and Maven builds as
>>> they are, into a Gradle multi-project build.
>>>
>>> - Hans
>>>
>>>>
>>>> --
>>>> View this message in context: http://www.nabble.com/Out-of-the-box-
>>>> maven-support--tp17143114p17225951.html
>>>> Sent from the gradle-user mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> --
>>> Hans Dockter
>>> Gradle Project lead
>>> http://www.gradle.org
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> -----
> ___________________________
>
> http://stubbisms.wordpress.com http://stubbisms.wordpress.com
> --
> View this message in context: http://www.nabble.com/Out-of-the-box-maven-support--tp17143114p18381000.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support? - one off maven dependecy translation

astubbs
Ping!
Added exclusion support and corrected scope mapping.

Marko Bauhardt-3 wrote
Hi Antony,
cool. this is very helpfully to porting our maven projects into gradle  
projects.

thanks
marko



On Jul 10, 2008, at 1:37 PM, Antony Stubbs wrote:

>
> FYI, I submited a simple Groovy script to perform dependency  
> translation:
> http://jira.codehaus.org/browse/GRADLE-154
>
> Groovy is cooool... :)
>
> It's basically:
> def records = new XmlParser().parseText(DEPENDENCIES_STRING)
> records.each() {
>    println "compile:
> \"${it.groupId.text()}:${it.artifactId.text()}:${it?.version?.text()}
> \""
> }
>
>
>
> Antony Stubbs wrote:
>>
>> Did something to address this make it into .2?
>>
>> Fyi: I'm new to Gradle.
>>
>> I created an issue regarding Maven migration here:
>> http://jira.codehaus.org/browse/GRADLE-154
>>
>>
>> hdockter wrote:
>>>
>>>
>>> On May 14, 2008, at 10:17 AM, Bert van Brakel wrote:
>>>
>>>>
>>>>
>>>> hdockter wrote:
>>>>>
>>>>>
>>>>> On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:
>>>>>
>>>>>> If I currently have a project in maven  (1 or 2) and I want to
>>>>>> switch to
>>>>>> using gradle, are there any tools for this?
>>>>>>
>>>>>> It would be great if gradle just looks for a pom.xml and simply
>>>>>> runs a maven
>>>>>> like build. It would certainly help to convince maven users to
>>>>>
>>>>> Such functionality is not implemented yet but we plan to this very
>>>>> soon. Similar to what you have proposed we want to offer 2 things:
>>>>>
>>>>> It is an interesting use case we haven't thought of to use  
>>>>> Gradle to
>>>>> add functionality on an existing and still in use Maven build. For
>>>>> simple Maven builds I see no problem, if the poms use  
>>>>> inheritance and
>>>>> are part of a multiproject build things look more complicated.
>>>>>
>>>>> We want to provide this functionality for 0.2.
>>>>>
>>>> great, sounds good!
>>>>
>>>> However I think supplementing a current maven build may be a good
>>>> way to get
>>>> traction in the enterprise where folks tend to be risk adverse  
>>>> (fair
>>>> enough), don't have time to rip everything up and start again
>>>> (after all,
>>>> time is money and you need to convince alot of people first of the
>>>> benefits), and developers don't tend to have a lot of time to try
>>>> out new
>>>> tools and spend the time to set them up. If out of the box maven
>>>> support
>>>> exists then it's a matter of install tool, run, done. The risk and
>>>> ramp up
>>>> time is nil, if it doesn't work, then fall back to maven.
>>>
>>> I completely agree. Soft migration paths are a very good thing.
>>> Another step would be to integrate existing Ant and Maven builds as
>>> they are, into a Gradle multi-project build.
>>>
>>> - Hans
>>>
>>>>
>>>> --
>>>> View this message in context: http://www.nabble.com/Out-of-the-box-
>>>> maven-support--tp17143114p17225951.html
>>>> Sent from the gradle-user mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>
>>> --
>>> Hans Dockter
>>> Gradle Project lead
>>> http://www.gradle.org
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> -----
> ___________________________
>
> http://stubbisms.wordpress.com http://stubbisms.wordpress.com
> --
> View this message in context: http://www.nabble.com/Out-of-the-box-maven-support--tp17143114p18381000.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support? - one off maven dependecy translation

hans_d
Administrator
Hi Antony,

On Jul 10, 2008, at 11:44 PM, Antony Stubbs wrote:

>
> Ping!
> Added exclusion support and corrected scope mapping.

Perfect :) I plan for today to merge this into trunk.

- Hans

>
>
> Marko Bauhardt-3 wrote:
>>
>> Hi Antony,
>> cool. this is very helpfully to porting our maven projects into  
>> gradle
>> projects.
>>
>> thanks
>> marko
>>
>>
>>
>> On Jul 10, 2008, at 1:37 PM, Antony Stubbs wrote:
>>
>>>
>>> FYI, I submited a simple Groovy script to perform dependency
>>> translation:
>>> http://jira.codehaus.org/browse/GRADLE-154
>>>
>>> Groovy is cooool... :)
>>>
>>> It's basically:
>>> def records = new XmlParser().parseText(DEPENDENCIES_STRING)
>>> records.each() {
>>>    println "compile:
>>> \"${it.groupId.text()}:${it.artifactId.text()}:${it?.version?.text
>>> ()}
>>> \""
>>> }
>>>
>>>
>>>
>>> Antony Stubbs wrote:
>>>>
>>>> Did something to address this make it into .2?
>>>>
>>>> Fyi: I'm new to Gradle.
>>>>
>>>> I created an issue regarding Maven migration here:
>>>> http://jira.codehaus.org/browse/GRADLE-154
>>>>
>>>>
>>>> hdockter wrote:
>>>>>
>>>>>
>>>>> On May 14, 2008, at 10:17 AM, Bert van Brakel wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> hdockter wrote:
>>>>>>>
>>>>>>>
>>>>>>> On May 9, 2008, at 9:57 AM, Bert van Brakel wrote:
>>>>>>>
>>>>>>>> If I currently have a project in maven  (1 or 2) and I want to
>>>>>>>> switch to
>>>>>>>> using gradle, are there any tools for this?
>>>>>>>>
>>>>>>>> It would be great if gradle just looks for a pom.xml and simply
>>>>>>>> runs a maven
>>>>>>>> like build. It would certainly help to convince maven users to
>>>>>>>
>>>>>>> Such functionality is not implemented yet but we plan to this  
>>>>>>> very
>>>>>>> soon. Similar to what you have proposed we want to offer 2  
>>>>>>> things:
>>>>>>>
>>>>>>> It is an interesting use case we haven't thought of to use
>>>>>>> Gradle to
>>>>>>> add functionality on an existing and still in use Maven  
>>>>>>> build. For
>>>>>>> simple Maven builds I see no problem, if the poms use
>>>>>>> inheritance and
>>>>>>> are part of a multiproject build things look more complicated.
>>>>>>>
>>>>>>> We want to provide this functionality for 0.2.
>>>>>>>
>>>>>> great, sounds good!
>>>>>>
>>>>>> However I think supplementing a current maven build may be a good
>>>>>> way to get
>>>>>> traction in the enterprise where folks tend to be risk adverse
>>>>>> (fair
>>>>>> enough), don't have time to rip everything up and start again
>>>>>> (after all,
>>>>>> time is money and you need to convince alot of people first of  
>>>>>> the
>>>>>> benefits), and developers don't tend to have a lot of time to try
>>>>>> out new
>>>>>> tools and spend the time to set them up. If out of the box maven
>>>>>> support
>>>>>> exists then it's a matter of install tool, run, done. The risk  
>>>>>> and
>>>>>> ramp up
>>>>>> time is nil, if it doesn't work, then fall back to maven.
>>>>>
>>>>> I completely agree. Soft migration paths are a very good thing.
>>>>> Another step would be to integrate existing Ant and Maven  
>>>>> builds as
>>>>> they are, into a Gradle multi-project build.
>>>>>
>>>>> - Hans
>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://www.nabble.com/Out-of-the- 
>>>>>> box-
>>>>>> maven-support--tp17143114p17225951.html
>>>>>> Sent from the gradle-user mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>>    http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Hans Dockter
>>>>> Gradle Project lead
>>>>> http://www.gradle.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> ___________________________
>>>
>>> http://stubbisms.wordpress.com http://stubbisms.wordpress.com
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Out-of-the-box-maven-support-- 
>>> tp17143114p18381000.html
>>> Sent from the gradle-user mailing list archive at Nabble.com.
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
>>
>>
>>
>>
>
>
> -----
> ___________________________
>
> http://stubbisms.wordpress.com http://stubbisms.wordpress.com
> --
> View this message in context: http://www.nabble.com/Out-of-the-box- 
> maven-support--tp17143114p18392532.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support? - one off maven dependecy translation

hans_d
Administrator
Hi Antony,

On Jul 11, 2008, at 8:25 AM, Hans Dockter wrote:

> Hi Antony,
>
> On Jul 10, 2008, at 11:44 PM, Antony Stubbs wrote:
>
>>
>> Ping!
>> Added exclusion support and corrected scope mapping.
>
> Perfect :) I plan for today to merge this into trunk.

Sorry, I was occupied by other stuff. It is not in trunk yet but will  
be there soon. I'll let you know.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Out of the box maven support? - one off maven dependecy translation

astubbs
No worries! No rush... I'll take the time to insert the comments I made from my blog post about it:
http://stubbisms.wordpress.com/2008/07/11/groovy-converter-from-maven-to-gradle-depedencies-gradle-154/

hdockter wrote
Hi Antony,

On Jul 11, 2008, at 8:25 AM, Hans Dockter wrote:

> Hi Antony,
>
> On Jul 10, 2008, at 11:44 PM, Antony Stubbs wrote:
>
>>
>> Ping!
>> Added exclusion support and corrected scope mapping.
>
> Perfect :) I plan for today to merge this into trunk.

Sorry, I was occupied by other stuff. It is not in trunk yet but will  
be there soon. I'll let you know.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email