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 <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
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/openej
>> b-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/MavenResolver.java
>> <https://github.com/apache/tomee/blob/master/container/opene
>> jb-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/MavenResolver.java>
>> and
>> https://github.com/apache/tomee/blob/master/container/openej
>> b-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/HttpResolver.java
>> <https://github.com/apache/tomee/blob/master/container/opene
>> jb-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/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
>>
>>
>>
>
