Perhaps something can be done but some people use snapshots without
any timestamps. As long as that didn't break. I think years ago it
became a lot slower in that scenario if we auto set 'changing'. Not
sure if that is the case any longer.
Cheers, Paul.
On Tue, Jan 10, 2017 at 6:48 PM, Romain Manni-Bucau
<rmannibu...@gmail.com> wrote:
> Ok, imported the project and...discovered changing() :). Think it can solve
> the issue for now. Then the remaining question is the duplication of the
> repo but guess I can live with it for now. In GrapeIvy do we want to move
>
> boolean changing = deps.containsKey('changing') ? deps.changing :
> false
>
> to
>
> boolean changing = deps.containsKey('changing') ? deps.changing ||
> version.endsWith('-SNAPSHOT') : false
>
>
> ?
>
> Not an issue if not, would just makes maven standard better integrated with
> the pitfall of having changing value forced (so less obvious).
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
> 2017-01-10 1:36 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>:
>>
>> well... contributions are welcome ;)
>>
>> On 06.01.2017 15:36, Romain Manni-Bucau wrote:
>>>
>>>
>>>
>>> 2017-01-06 15:33 GMT+01:00 Jochen Theodorou <blackd...@gmx.org
>>> <mailto:blackd...@gmx.org>>:
>>>
>>>
>>> On 06.01.2017 15:00, Romain Manni-Bucau wrote:
>>> [...]
>>>
>>> Means SNAPSHOT patterns needs to be identified (likely a flag in
>>> the
>>> @Grab(snapshot=true)?) and groovy should clean up the artifacts
>>> before
>>> resolving to avoid to let ivy mess up its repo.
>>>
>>>
>>> which means it is more than just a change in the configuration file.
>>>
>>>
>>> Both options are valid but I think you had a good point and it can be
>>> API intrusive
>>>
>>> For maven based artifact
>>> it also means you run copies instead of maven repository ones
>>> which is
>>> leading to unexpected runtime sometimes.
>>>
>>>
>>> can you explain a bit more? you mean the local ivy repo with copy?
>>>
>>>
>>> Yes, if you don't remove the snapshot copy from ~/.groovy/grapes/ then
>>> you use the last resolved one which is likely outdated with maven repo.
>>>
>>> - what kind of SPI groovy would use (ATM GrapeEngine
>>> lookup is quite
>>> hardcoded): do we want a config in groovy installation
>>> + system
>>> property?
>>>
>>> would someone want to define the engine as part of the
>>> annotation or
>>> should this be automatic in the background? We could also
>>> think of
>>> using the Java service provider interface logic - of course
>>> then we
>>> have to think about what to do if multiple engines are there
>>>
>>> sounds good in @Grab with probably a default globally settable
>>> in the
>>> script.
>>>
>>>
>>> yes I think we can do that
>>>
>>> - if we want another engine: how do we manage
>>> dependencies? do we
>>> isolate them from groovy libs?
>>>
>>>
>>> they should be optional for the delivery.... and in the
>>> light of
>>> that I think depending on spring-boot-cli is an option
>>>
>>> Alternative is to implement it in groovy without maven in a light
>>> fashion, with
>>>
>>> https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/MavenResolver.java
>>>
>>> <https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/MavenResolver.java>
>>> and
>>>
>>> https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/HttpResolver.java
>>>
>>> <https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/provisining/HttpResolver.java>
>>> you can resolve most of maven artifacts. This code needs to be
>>> reworked
>>> on its config side cause it is specific to tomee but my point is
>>> in <
>>> 400 LOC you can get a maven resolver you own and therefore
>>> supporting
>>> snapshots is very doable there.
>>>
>>>
>>> I would prefer depending on something existing, but 400 LOC is not
>>> much and if that goes without further dependencies... well then we
>>> should consider doing that
>>>
>>>
>>> Agree, I only know aether (or its forks) which are far from 400 LOC but
>>> alternatives welcomed as well if they exist
>>>
>>> bye Jochen
>>>
>>>
>>
>
