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 Tue, 10 Jan 2017 08:48:16 GMT
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 <blackdrag@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 <blackdrag@gmx.org
>> <mailto: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
>>         <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
>>
>>
>>
>

Mime
View raw message