groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: MavenGrapeEngine?
Date Tue, 10 Jan 2017 09:10:24 GMT
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
<rmannibucau@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 <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/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
>>>
>>>
>>
>

Mime
View raw message