big problem with SNAPSHOTS from Maven repo

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

big problem with SNAPSHOTS from Maven repo

Rwanou
Hi all,

The problem has already been raised here, and no real answer was given. Yesterday we faced a real problem in our deployment task, due mostly to internal processes, and also because of this bug of Gradle.

Our application depends on a home library which is present on our home Maven Repo. This library is constantly updated, and we release regularly SNAPSHOT versions on our SNAPSHOT repo. As it was stated before, running the "gralde war" or any "build" task wont look for the latest SNAPSHOT version from the server. If ever your local gradle cache contains a SNAPSHOT version of the library, let's say the one from October 1st, and there was another SNAPSHOT release of this same library on November 1st, then gradle will NOT download the latest version, and still package the war with October 1st version.

Until now our solution was to mail users and tell them to manually empty their cache. Gradle would then be forced to re-download the latest version. This is not acceptable as sometimes the users forget to do so. But the most problematic issue is that we are using Bamboo to CI our application, and we don't have access to the remote agent. We cannot purge the cache on the agent.

The solution cannot be to add a parameter to the task. Fetching for the latest SNAPSHOT MUST be transparent.

Is there anything worked out for this? Any Jira issue on this matter?

Thanks for your help and concern.

Erwan
Reply | Threaded
Open this post in threaded view
|

Re: big problem with SNAPSHOTS from Maven repo

hans_d
Administrator

On Nov 20, 2009, at 11:41 AM, Rwanou wrote:

>
> Hi all,
>
> The problem has already been raised here, and no real answer was given.
> Yesterday we faced a real problem in our deployment task, due mostly to
> internal processes, and also because of this bug of Gradle.
>
> Our application depends on a home library which is present on our home Maven
> Repo. This library is constantly updated, and we release regularly SNAPSHOT
> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
> war" or any "build" task wont look for the latest SNAPSHOT version from the
> server. If ever your local gradle cache contains a SNAPSHOT version of the
> library, let's say the one from October 1st, and there was another SNAPSHOT
> release of this same library on November 1st, then gradle will NOT download
> the latest version, and still package the war with October 1st version.
>
> Until now our solution was to mail users and tell them to manually empty
> their cache. Gradle would then be forced to re-download the latest version.
> This is not acceptable as sometimes the users forget to do so. But the most
> problematic issue is that we are using Bamboo to CI our application, and we
> don't have access to the remote agent. We cannot purge the cache on the
> agent.
>
> The solution cannot be to add a parameter to the task. Fetching for the
> latest SNAPSHOT MUST be transparent.
>
> Is there anything worked out for this? Any Jira issue on this matter?

There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629

The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.

- Hans

--
Hans Dockter
Gradle Project Manager
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: big problem with SNAPSHOTS from Maven repo

Paul Speed-2


Hans Dockter wrote:

> On Nov 20, 2009, at 11:41 AM, Rwanou wrote:
>
>> Hi all,
>>
>> The problem has already been raised here, and no real answer was given.
>> Yesterday we faced a real problem in our deployment task, due mostly to
>> internal processes, and also because of this bug of Gradle.
>>
>> Our application depends on a home library which is present on our home Maven
>> Repo. This library is constantly updated, and we release regularly SNAPSHOT
>> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
>> war" or any "build" task wont look for the latest SNAPSHOT version from the
>> server. If ever your local gradle cache contains a SNAPSHOT version of the
>> library, let's say the one from October 1st, and there was another SNAPSHOT
>> release of this same library on November 1st, then gradle will NOT download
>> the latest version, and still package the war with October 1st version.
>>
>> Until now our solution was to mail users and tell them to manually empty
>> their cache. Gradle would then be forced to re-download the latest version.
>> This is not acceptable as sometimes the users forget to do so. But the most
>> problematic issue is that we are using Bamboo to CI our application, and we
>> don't have access to the remote agent. We cannot purge the cache on the
>> agent.
>>
>> The solution cannot be to add a parameter to the task. Fetching for the
>> latest SNAPSHOT MUST be transparent.
>>
>> Is there anything worked out for this? Any Jira issue on this matter?
>
> There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629
>
> The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.
>
> - Hans
>

I'll respond and say that snapshots always update for me too.

The only case where I personally get bitten by things not updating is
when I have an application running using the jars from a gradle
generated classpath.  gradle install will not properly update the jars
and will not show an error for some reason.  It looks like it's
successful but no amount of updating of the depending projects will ever
get new jars because there aren't any.

I don't know if that's related but I thought I would point it out just
in case.  I'm not sure why the install task thinks it successfully
copied a file that it hasn't in these cases.

-Paul

P.S.: in my case, this is all in the local repositories as I don't build
often from a shared maven repo at this point.


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: big problem with SNAPSHOTS from Maven repo

Paul Speed-2
I will add that I haven't tested this under 0.8 yet as I've gotten in
the habit of killing all of my apps before running gradle install...

-Paul

Paul Speed wrote:
[snip]

>
> I'll respond and say that snapshots always update for me too.
>
> The only case where I personally get bitten by things not updating is
> when I have an application running using the jars from a gradle
> generated classpath.  gradle install will not properly update the jars
> and will not show an error for some reason.  It looks like it's
> successful but no amount of updating of the depending projects will ever
> get new jars because there aren't any.
>
> I don't know if that's related but I thought I would point it out just
> in case.  I'm not sure why the install task thinks it successfully
> copied a file that it hasn't in these cases.
>
> -Paul
>
> P.S.: in my case, this is all in the local repositories as I don't build
> often from a shared maven repo at this point.
>
>
> ---------------------------------------------------------------------
> 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: big problem with SNAPSHOTS from Maven repo

Rwanou
In reply to this post by hans_d
Thanks for pointing the JIRA.

I don't know how you could reproduce this. Should we go on DEVELOPPER ML to discuss this? Maybe I can show you some Maven internal files of the maven snapshot repo, or even give you my build files. One thing is sure, my SNAPSHOT repo keeps track of the dates of release (that's the only way I was able to fix our release in time ;o)).

But just so we are clear, here's the way I declare the dependency. Maybe the fact that I declare a module messes up the thing...

compile module("eu.sanco.gras:gras:${grasVersion}") {
                        dependency("eu.sanco:saas:1.1.7")
                        dependency("commons-lang:commons-lang:2.3")
                        dependency("commons-net:commons-net:1.4.1")
                        dependency("org.apache.axis:axis:1.4")
                        dependency("org.apache.axis:axis-saaj:1.4")
                        dependency("org.apache.axis:axis-jaxrpc:1.4")
                        dependency("opensymphony:osworkflow:2.8.0")
                        dependency("opensymphony:propertyset:1.3")
                        dependency("org.safehaus.jug:jug:2.0.0:lgpl")
                        dependency("opensymphony:oscore:2.2.4")
                        dependency("javax.mail:mail:1.4")
                }

${grasVersion} = '1.15.8-SNAPSHOT'



-----Original Message-----
From: Hans Dockter [mailto:[hidden email]]
Sent: Friday, November 20, 2009 12:13 PM
To: [hidden email]
Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo


On Nov 20, 2009, at 11:41 AM, Rwanou wrote:

>
> Hi all,
>
> The problem has already been raised here, and no real answer was given.
> Yesterday we faced a real problem in our deployment task, due mostly to
> internal processes, and also because of this bug of Gradle.
>
> Our application depends on a home library which is present on our home Maven
> Repo. This library is constantly updated, and we release regularly SNAPSHOT
> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
> war" or any "build" task wont look for the latest SNAPSHOT version from the
> server. If ever your local gradle cache contains a SNAPSHOT version of the
> library, let's say the one from October 1st, and there was another SNAPSHOT
> release of this same library on November 1st, then gradle will NOT download
> the latest version, and still package the war with October 1st version.
>
> Until now our solution was to mail users and tell them to manually empty
> their cache. Gradle would then be forced to re-download the latest version.
> This is not acceptable as sometimes the users forget to do so. But the most
> problematic issue is that we are using Bamboo to CI our application, and we
> don't have access to the remote agent. We cannot purge the cache on the
> agent.
>
> The solution cannot be to add a parameter to the task. Fetching for the
> latest SNAPSHOT MUST be transparent.
>
> Is there anything worked out for this? Any Jira issue on this matter?

There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629

The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.

- Hans

--
Hans Dockter
Gradle Project Manager
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


Reply | Threaded
Open this post in threaded view
|

Re: big problem with SNAPSHOTS from Maven repo

hans_d
Administrator
Hi Erwan,

On Nov 20, 2009, at 2:11 PM, <[hidden email]> <[hidden email]> wrote:

> Thanks for pointing the JIRA.
>
> I don't know how you could reproduce this. Should we go on DEVELOPPER ML to discuss this? Maybe I can show you some Maven internal files of the maven snapshot repo, or even give you my build files. One thing is sure, my SNAPSHOT repo keeps track of the dates of release (that's the only way I was able to fix our release in time ;o)).
>
> But just so we are clear, here's the way I declare the dependency. Maybe the fact that I declare a module messes up the thing...
>
> compile module("eu.sanco.gras:gras:${grasVersion}") {
> dependency("eu.sanco:saas:1.1.7")
> dependency("commons-lang:commons-lang:2.3")
> dependency("commons-net:commons-net:1.4.1")
> dependency("org.apache.axis:axis:1.4")
> dependency("org.apache.axis:axis-saaj:1.4")
> dependency("org.apache.axis:axis-jaxrpc:1.4")
> dependency("opensymphony:osworkflow:2.8.0")
> dependency("opensymphony:propertyset:1.3")
> dependency("org.safehaus.jug:jug:2.0.0:lgpl")
> dependency("opensymphony:oscore:2.2.4")
> dependency("javax.mail:mail:1.4")
> }
>
> ${grasVersion} = '1.15.8-SNAPSHOT'

Now I can reproduce your problem. Although they should, snapshots don't work with client modules at the moment. And there is no simple fix to this. This is related to the underlying Ivy which we use for resolving dependencies.

What you can do is to use either an ivy.xml/pom.xml to describe your gras dependency. Or to flatten it, but give up transitive dependency handling by that. Something like: compile "eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", ....

You could also use a variable for that:

GRAS = ["eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", .... ]
compile GRAS, "org.hibernate:hibernate:3.0"

Bu then all dependencies are first level dependencies.

Is gras build by Gradle?

- Hans

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

>
>
>
> -----Original Message-----
> From: Hans Dockter [mailto:[hidden email]]
> Sent: Friday, November 20, 2009 12:13 PM
> To: [hidden email]
> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>
>
> On Nov 20, 2009, at 11:41 AM, Rwanou wrote:
>
>>
>> Hi all,
>>
>> The problem has already been raised here, and no real answer was given.
>> Yesterday we faced a real problem in our deployment task, due mostly to
>> internal processes, and also because of this bug of Gradle.
>>
>> Our application depends on a home library which is present on our home Maven
>> Repo. This library is constantly updated, and we release regularly SNAPSHOT
>> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
>> war" or any "build" task wont look for the latest SNAPSHOT version from the
>> server. If ever your local gradle cache contains a SNAPSHOT version of the
>> library, let's say the one from October 1st, and there was another SNAPSHOT
>> release of this same library on November 1st, then gradle will NOT download
>> the latest version, and still package the war with October 1st version.
>>
>> Until now our solution was to mail users and tell them to manually empty
>> their cache. Gradle would then be forced to re-download the latest version.
>> This is not acceptable as sometimes the users forget to do so. But the most
>> problematic issue is that we are using Bamboo to CI our application, and we
>> don't have access to the remote agent. We cannot purge the cache on the
>> agent.
>>
>> The solution cannot be to add a parameter to the task. Fetching for the
>> latest SNAPSHOT MUST be transparent.
>>
>> Is there anything worked out for this? Any Jira issue on this matter?
>
> There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629
>
> The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> 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
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

RE: big problem with SNAPSHOTS from Maven repo

Rwanou
Thank you,

I was looking at it right now, and wandering how to modify my local ivydata file to revert and reproduce the issue.

Indeed "module" dependency looks like the source of the problem. Since you say there is no simple to fix that, we'll try a workaround of our own, using non-module declaration.

Gras is not build by Gradle (unfortunatly) but with Maven. Old technologies from the time our client was paranoid... That's what you get when you refuse progress...

Anyway, we now have the explanation for the problem. I hope this topic will help explain all of the other SNAPSHOTS related issues of other users. Will you edit the JIRA or do you want me to do it?

Thanks a lot for your support, keep on the good work,
Erwan

-----Original Message-----
From: Hans Dockter [mailto:[hidden email]]
Sent: Friday, November 20, 2009 3:36 PM
To: [hidden email]
Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo

Hi Erwan,

On Nov 20, 2009, at 2:11 PM, <[hidden email]> <[hidden email]> wrote:

> Thanks for pointing the JIRA.
>
> I don't know how you could reproduce this. Should we go on DEVELOPPER ML to discuss this? Maybe I can show you some Maven internal files of the maven snapshot repo, or even give you my build files. One thing is sure, my SNAPSHOT repo keeps track of the dates of release (that's the only way I was able to fix our release in time ;o)).
>
> But just so we are clear, here's the way I declare the dependency. Maybe the fact that I declare a module messes up the thing...
>
> compile module("eu.sanco.gras:gras:${grasVersion}") {
> dependency("eu.sanco:saas:1.1.7")
> dependency("commons-lang:commons-lang:2.3")
> dependency("commons-net:commons-net:1.4.1")
> dependency("org.apache.axis:axis:1.4")
> dependency("org.apache.axis:axis-saaj:1.4")
> dependency("org.apache.axis:axis-jaxrpc:1.4")
> dependency("opensymphony:osworkflow:2.8.0")
> dependency("opensymphony:propertyset:1.3")
> dependency("org.safehaus.jug:jug:2.0.0:lgpl")
> dependency("opensymphony:oscore:2.2.4")
> dependency("javax.mail:mail:1.4")
> }
>
> ${grasVersion} = '1.15.8-SNAPSHOT'

Now I can reproduce your problem. Although they should, snapshots don't work with client modules at the moment. And there is no simple fix to this. This is related to the underlying Ivy which we use for resolving dependencies.

What you can do is to use either an ivy.xml/pom.xml to describe your gras dependency. Or to flatten it, but give up transitive dependency handling by that. Something like: compile "eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", ....

You could also use a variable for that:

GRAS = ["eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", .... ]
compile GRAS, "org.hibernate:hibernate:3.0"

Bu then all dependencies are first level dependencies.

Is gras build by Gradle?

- Hans

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

>
>
>
> -----Original Message-----
> From: Hans Dockter [mailto:[hidden email]]
> Sent: Friday, November 20, 2009 12:13 PM
> To: [hidden email]
> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>
>
> On Nov 20, 2009, at 11:41 AM, Rwanou wrote:
>
>>
>> Hi all,
>>
>> The problem has already been raised here, and no real answer was given.
>> Yesterday we faced a real problem in our deployment task, due mostly to
>> internal processes, and also because of this bug of Gradle.
>>
>> Our application depends on a home library which is present on our home Maven
>> Repo. This library is constantly updated, and we release regularly SNAPSHOT
>> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
>> war" or any "build" task wont look for the latest SNAPSHOT version from the
>> server. If ever your local gradle cache contains a SNAPSHOT version of the
>> library, let's say the one from October 1st, and there was another SNAPSHOT
>> release of this same library on November 1st, then gradle will NOT download
>> the latest version, and still package the war with October 1st version.
>>
>> Until now our solution was to mail users and tell them to manually empty
>> their cache. Gradle would then be forced to re-download the latest version.
>> This is not acceptable as sometimes the users forget to do so. But the most
>> problematic issue is that we are using Bamboo to CI our application, and we
>> don't have access to the remote agent. We cannot purge the cache on the
>> agent.
>>
>> The solution cannot be to add a parameter to the task. Fetching for the
>> latest SNAPSHOT MUST be transparent.
>>
>> Is there anything worked out for this? Any Jira issue on this matter?
>
> There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629
>
> The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> 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
>
>


---------------------------------------------------------------------
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: big problem with SNAPSHOTS from Maven repo

hans_d
Administrator

On Nov 20, 2009, at 3:43 PM, <[hidden email]> wrote:

> Thank you,
>
> I was looking at it right now, and wandering how to modify my local ivydata file to revert and reproduce the issue.
>
> Indeed "module" dependency looks like the source of the problem. Since you say there is no simple to fix that, we'll try a workaround of our own, using non-module declaration.
>
> Gras is not build by Gradle (unfortunatly) but with Maven. Old technologies from the time our client was paranoid... That's what you get when you refuse progress...

Why do you need a module? Doesn't the pom.xml of gras contain the correct dependencies for gras?

- Hans

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

>
> Anyway, we now have the explanation for the problem. I hope this topic will help explain all of the other SNAPSHOTS related issues of other users. Will you edit the JIRA or do you want me to do it?
>
> Thanks a lot for your support, keep on the good work,
> Erwan
>
> -----Original Message-----
> From: Hans Dockter [mailto:[hidden email]]
> Sent: Friday, November 20, 2009 3:36 PM
> To: [hidden email]
> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>
> Hi Erwan,
>
> On Nov 20, 2009, at 2:11 PM, <[hidden email]> <[hidden email]> wrote:
>
>> Thanks for pointing the JIRA.
>>
>> I don't know how you could reproduce this. Should we go on DEVELOPPER ML to discuss this? Maybe I can show you some Maven internal files of the maven snapshot repo, or even give you my build files. One thing is sure, my SNAPSHOT repo keeps track of the dates of release (that's the only way I was able to fix our release in time ;o)).
>>
>> But just so we are clear, here's the way I declare the dependency. Maybe the fact that I declare a module messes up the thing...
>>
>> compile module("eu.sanco.gras:gras:${grasVersion}") {
>> dependency("eu.sanco:saas:1.1.7")
>> dependency("commons-lang:commons-lang:2.3")
>> dependency("commons-net:commons-net:1.4.1")
>> dependency("org.apache.axis:axis:1.4")
>> dependency("org.apache.axis:axis-saaj:1.4")
>> dependency("org.apache.axis:axis-jaxrpc:1.4")
>> dependency("opensymphony:osworkflow:2.8.0")
>> dependency("opensymphony:propertyset:1.3")
>> dependency("org.safehaus.jug:jug:2.0.0:lgpl")
>> dependency("opensymphony:oscore:2.2.4")
>> dependency("javax.mail:mail:1.4")
>> }
>>
>> ${grasVersion} = '1.15.8-SNAPSHOT'
>
> Now I can reproduce your problem. Although they should, snapshots don't work with client modules at the moment. And there is no simple fix to this. This is related to the underlying Ivy which we use for resolving dependencies.
>
> What you can do is to use either an ivy.xml/pom.xml to describe your gras dependency. Or to flatten it, but give up transitive dependency handling by that. Something like: compile "eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", ....
>
> You could also use a variable for that:
>
> GRAS = ["eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", .... ]
> compile GRAS, "org.hibernate:hibernate:3.0"
>
> Bu then all dependencies are first level dependencies.
>
> Is gras build by Gradle?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
>>
>>
>>
>> -----Original Message-----
>> From: Hans Dockter [mailto:[hidden email]]
>> Sent: Friday, November 20, 2009 12:13 PM
>> To: [hidden email]
>> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>>
>>
>> On Nov 20, 2009, at 11:41 AM, Rwanou wrote:
>>
>>>
>>> Hi all,
>>>
>>> The problem has already been raised here, and no real answer was given.
>>> Yesterday we faced a real problem in our deployment task, due mostly to
>>> internal processes, and also because of this bug of Gradle.
>>>
>>> Our application depends on a home library which is present on our home Maven
>>> Repo. This library is constantly updated, and we release regularly SNAPSHOT
>>> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
>>> war" or any "build" task wont look for the latest SNAPSHOT version from the
>>> server. If ever your local gradle cache contains a SNAPSHOT version of the
>>> library, let's say the one from October 1st, and there was another SNAPSHOT
>>> release of this same library on November 1st, then gradle will NOT download
>>> the latest version, and still package the war with October 1st version.
>>>
>>> Until now our solution was to mail users and tell them to manually empty
>>> their cache. Gradle would then be forced to re-download the latest version.
>>> This is not acceptable as sometimes the users forget to do so. But the most
>>> problematic issue is that we are using Bamboo to CI our application, and we
>>> don't have access to the remote agent. We cannot purge the cache on the
>>> agent.
>>>
>>> The solution cannot be to add a parameter to the task. Fetching for the
>>> latest SNAPSHOT MUST be transparent.
>>>
>>> Is there anything worked out for this? Any Jira issue on this matter?
>>
>> There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629
>>
>> The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project Manager
>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

RE: big problem with SNAPSHOTS from Maven repo

Rwanou
As I was stating before, the GRAS library was developped quite some time ago, with old versions of libraries. Due to client requests we could not just upgrade the whole thing. I'm still gonna try to upgrade everything and redifine the pom.xml.

But this wont solve the problem. It is not because the library is define as a module that Gradle should not look for the most recent version of it. This bug is now not as critical as it was before, but to me, it remains a bug.

Erwan


-----Original Message-----
From: Hans Dockter [mailto:[hidden email]]
Sent: Friday, November 20, 2009 9:11 PM
To: [hidden email]
Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo


On Nov 20, 2009, at 3:43 PM, <[hidden email]> wrote:

> Thank you,
>
> I was looking at it right now, and wandering how to modify my local ivydata file to revert and reproduce the issue.
>
> Indeed "module" dependency looks like the source of the problem. Since you say there is no simple to fix that, we'll try a workaround of our own, using non-module declaration.
>
> Gras is not build by Gradle (unfortunatly) but with Maven. Old technologies from the time our client was paranoid... That's what you get when you refuse progress...

Why do you need a module? Doesn't the pom.xml of gras contain the correct dependencies for gras?

- Hans

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

>
> Anyway, we now have the explanation for the problem. I hope this topic will help explain all of the other SNAPSHOTS related issues of other users. Will you edit the JIRA or do you want me to do it?
>
> Thanks a lot for your support, keep on the good work,
> Erwan
>
> -----Original Message-----
> From: Hans Dockter [mailto:[hidden email]]
> Sent: Friday, November 20, 2009 3:36 PM
> To: [hidden email]
> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>
> Hi Erwan,
>
> On Nov 20, 2009, at 2:11 PM, <[hidden email]> <[hidden email]> wrote:
>
>> Thanks for pointing the JIRA.
>>
>> I don't know how you could reproduce this. Should we go on DEVELOPPER ML to discuss this? Maybe I can show you some Maven internal files of the maven snapshot repo, or even give you my build files. One thing is sure, my SNAPSHOT repo keeps track of the dates of release (that's the only way I was able to fix our release in time ;o)).
>>
>> But just so we are clear, here's the way I declare the dependency. Maybe the fact that I declare a module messes up the thing...
>>
>> compile module("eu.sanco.gras:gras:${grasVersion}") {
>> dependency("eu.sanco:saas:1.1.7")
>> dependency("commons-lang:commons-lang:2.3")
>> dependency("commons-net:commons-net:1.4.1")
>> dependency("org.apache.axis:axis:1.4")
>> dependency("org.apache.axis:axis-saaj:1.4")
>> dependency("org.apache.axis:axis-jaxrpc:1.4")
>> dependency("opensymphony:osworkflow:2.8.0")
>> dependency("opensymphony:propertyset:1.3")
>> dependency("org.safehaus.jug:jug:2.0.0:lgpl")
>> dependency("opensymphony:oscore:2.2.4")
>> dependency("javax.mail:mail:1.4")
>> }
>>
>> ${grasVersion} = '1.15.8-SNAPSHOT'
>
> Now I can reproduce your problem. Although they should, snapshots don't work with client modules at the moment. And there is no simple fix to this. This is related to the underlying Ivy which we use for resolving dependencies.
>
> What you can do is to use either an ivy.xml/pom.xml to describe your gras dependency. Or to flatten it, but give up transitive dependency handling by that. Something like: compile "eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", ....
>
> You could also use a variable for that:
>
> GRAS = ["eu.sanco.gras:gras:${grasVersion}", "eu.sanco:saas:1.1.7", .... ]
> compile GRAS, "org.hibernate:hibernate:3.0"
>
> Bu then all dependencies are first level dependencies.
>
> Is gras build by Gradle?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
>>
>>
>>
>> -----Original Message-----
>> From: Hans Dockter [mailto:[hidden email]]
>> Sent: Friday, November 20, 2009 12:13 PM
>> To: [hidden email]
>> Subject: Re: [gradle-user] big problem with SNAPSHOTS from Maven repo
>>
>>
>> On Nov 20, 2009, at 11:41 AM, Rwanou wrote:
>>
>>>
>>> Hi all,
>>>
>>> The problem has already been raised here, and no real answer was given.
>>> Yesterday we faced a real problem in our deployment task, due mostly to
>>> internal processes, and also because of this bug of Gradle.
>>>
>>> Our application depends on a home library which is present on our home Maven
>>> Repo. This library is constantly updated, and we release regularly SNAPSHOT
>>> versions on our SNAPSHOT repo. As it was stated before, running the "gralde
>>> war" or any "build" task wont look for the latest SNAPSHOT version from the
>>> server. If ever your local gradle cache contains a SNAPSHOT version of the
>>> library, let's say the one from October 1st, and there was another SNAPSHOT
>>> release of this same library on November 1st, then gradle will NOT download
>>> the latest version, and still package the war with October 1st version.
>>>
>>> Until now our solution was to mail users and tell them to manually empty
>>> their cache. Gradle would then be forced to re-download the latest version.
>>> This is not acceptable as sometimes the users forget to do so. But the most
>>> problematic issue is that we are using Bamboo to CI our application, and we
>>> don't have access to the remote agent. We cannot purge the cache on the
>>> agent.
>>>
>>> The solution cannot be to add a parameter to the task. Fetching for the
>>> latest SNAPSHOT MUST be transparent.
>>>
>>> Is there anything worked out for this? Any Jira issue on this matter?
>>
>> There is an issue for this: http://jira.codehaus.org/browse/GRADLE-629
>>
>> The problem is that I can't reproduce it. I did attach a test project to this issue which uses snapshots. If I run this test project, always the newest snapshot is automatically picked up as you would expect. It would be awesome if you could send us a test build that reproduces this behavior. Otherwise it is very hard to figure out what is going on.
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project Manager
>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>


---------------------------------------------------------------------
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