|
Hi all,
I just wanted to confirm that this is considered out of scope for 1.3.7. There are a lot of people wanting this as evidenced by: http://jira.codehaus.org/browse/GRAILS-5700 I went ahead and created http://jira.codehaus.org/browse/GRAILS-7203 to track this issue due to GRAILS-5700 being about upgrading Ivy and that was done. To fix this requires subclassing IbliblioResolver from Ivy and patching it somewhat. I already have the changes to make and was planning on adding it to 1.4 when I am done with rearranging the dependency management bits. I could add this to 1.3.7 with a minimum of fuss if we wanted to. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Hey Luke, I'm going to give a +1 to getting this change into 1.3.7. We use snapshot dependencies all the time and our current work around is painfully slow. The sooner your fixes are in, the happier my team will be.
|
|
On 01/02/2011, at 1:44 AM, TylerBall wrote: > Hey Luke, I'm going to give a +1 to getting this change into 1.3.7. We use > snapshot dependencies all the time and our current work around is painfully > slow. The sooner your fixes are in, the happier my team will be. I've put together a solution that works for Grails 1.3 for anyone needing this now. https://github.com/alkemist/grails-snapshot-dependencies-fix --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Yeah, I'm going to give a +1 for this too. We also need a working solution for this sooner rather than later.
|
|
On 01/02/2011, at 7:41 PM, Marco Vermeulen wrote: > Yeah, I'm going to give a +1 for this too. We also need a working solution > for this sooner rather than later. Marco, did you see my solution for 1.3? https://github.com/alkemist/grails-snapshot-dependencies-fix --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Thanks Luke,
Sorry, in my eagerness I had not seen your earlier post. Will most certainly give it a try tomorrow. Cheers, Marco. |
|
In reply to this post by ld@ldaley.com
Thanks for your solution. I've incorporated it into our maven-driven multi-module, multi-dev project thats under CI. 1. Does anyone have a good idea for obtaining a path to the users local m2 repo from inside BuildConfig.grovy? We use maven filtering of the settings.repository property into a property file which is then read by BuildConfig.groovy to obtain the path to the users local m2 repo. 2. I've encountered some intermittent behaviour with resolution. Sometimes it works, sometimes it doesnt, Is there any logic on how often this fix re-evaluates the snapshot or does it check the repo every time? I've got this fix implemented 8 times across our project so a real fix in 1.3.8 or 1.4 would really be appreciated. Michael On 02/02/2011, at 9:18 PM, Luke Daley wrote:
|
|
On 18/02/2011, at 9:01 AM, Michael Lawler wrote: > Thanks for your solution. I've incorporated it into our maven-driven multi-module, multi-dev project thats under CI. > > 1. Does anyone have a good idea for obtaining a path to the users local m2 repo from inside BuildConfig.grovy? We use maven filtering of the settings.repository property into a property file which is then read by BuildConfig.groovy to obtain the path to the users local m2 repo. Grails uses this technique to find the local m2 repo: "${System.getProperty('user.home')}/.m2" > 2. I've encountered some intermittent behaviour with resolution. Sometimes it works, sometimes it doesnt, So what happens? There is a new version in the local repo but the Grails build doesn't see it? Ivy is comparing modification times on the files (one in cache vs. one in repo) to determine if something has changed. > Is there any logic on how often this fix re-evaluates the snapshot or does it check the repo every time? Not in Grails, but Ivy might be hiding this somewhere from me. I'll have a look. > I've got this fix implemented 8 times across our project so a real fix in 1.3.8 or 1.4 would really be appreciated. Unlikely for 1.3.8 (if there is one), but this will definitely work out of the box for 1.4 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
On 18/02/2011, at 10:43 AM, Luke Daley wrote:
I've configured your example BuildConfig.groovy code to point at "file:///Users/michael/.m2/repository" so that its looking at my local m2 repo. I can see that an earlier module build is installing jar artefact A into my local repo under version 1.1.1-SNAPSHOT and the jar file has an updated timestamp, but my grails module is not seeing the new version of the jar. The ivy cache is holding an older version. I note that maven doesnt provided an updated POM timestamp in the m2 repo so I touched that too to see if it would make a difference. No dice. Is a file:// based repo URL compatible with the SnapshotAwareM2Resolver?
|
|
In reply to this post by ld@ldaley.com
Apologies, this is working fine, the error was in my configuration.
I had ordered the snapshot aware resolver too late in the repositories closure() My bad. On 18/02/2011, at 10:43 AM, Luke Daley wrote:
|
|
Glad to hear it's working.
On 28/02/2011, at 12:18 PM, Michael Lawler wrote:
|
|
This post was updated on .
Is there a way to make this work with a flatDir? (local folder)
Even if it's update every time that works for me. Thanks |
|
Not that I'm aware, flatDir doesn't contain the necessary maven metadata
-- Graeme Rocher On Friday, February 24, 2012 at 1:40 AM, Jim wrote:
|
|
non plugin dependencies are only implicitly changing when they are being looked for in a maven repository. If they are coming from any other kind of repository you'll need to set the changing flag to true. And in this case, the last modified property of the dependency is used. If it's a local file repo then that's usually reliable. If it's a remote repository it relies on the last modified HTTP header. On 24/02/2012, at 8:08 AM, Graeme Rocher wrote:
|
| Powered by Nabble | Edit this page |
