groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: MavenGrapeEngine?
Date Fri, 06 Jan 2017 14:36:17 GMT
2017-01-06 15:33 GMT+01:00 Jochen Theodorou <blackdrag@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
>> and
>> https://github.com/apache/tomee/blob/master/container/openej
>> b-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
>
>

Mime
View raw message