groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: MavenGrapeEngine?
Date Tue, 10 Jan 2017 00:36:54 GMT
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