groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Rocher <graeme.roc...@gmail.com>
Subject Re: MavenGrapeEngine?
Date Tue, 24 Jan 2017 13:56:04 GMT
IMO we should be looking to create a JARJARed version of Aether and
removing Ivy all together

Ivy is broken fundamentally in numerous ways and is no longer
developed and maintained. I cannot recommend that anyone uses @Grab
currently because it breaks down in pretty much any real world
scenarios.

There is an Aether implementation as part of Spring Boot
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-cli/src/main/java/org/springframework/boot/cli/compiler/grape/AetherGrapeEngine.java

That should be merged into Groovy. The only downside is that Aether is
several jars rather than just a single one as is the case with Ivy.

For this we would need to create a JARJAR'ed version of those dependencies.

Cheers

On Fri, Jan 20, 2017 at 11:42 PM, Sergei Egorov <bsideup@gmail.com> wrote:
> FYI https://github.com/igor-suhorukov/mvn-classloader
>
> On Tue, Jan 10, 2017 at 11:43 AM Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
>>
>> Hmm, ibiblio (localm2 in grapesConfig.xml) has
>> setChangingPattern(".*-SNAPSHOT"); so should have worked OOTB....but
>>
>> org.apache.ivy.plugins.resolver.ChainResolver#getDependency checks the ivy
>> (default) cache before using resolvers so resolvers are basically skipped
>> and even the localm2 good behavior is ignored cause in
>> org.apache.ivy.plugins.resolver.BasicResolver#getDependency
>> shouldReturnResolvedModule() makes  it bypassed
>>
>> Looks like a bug in ivy, wdyt? Adding in this test a changing pattern test
>> (String.valueOf(dd.getAttribute("revision")).matches(getChangingPattern()))
>> would make it working.
>>
>> Of course this is doable in groovy but should probably be reported to ivy.
>>
>> Wdyt?
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>>
>> 2017-01-10 10:10 GMT+01:00 Paul King <paulk@asert.com.au>:
>>>
>>> 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
>>> >>>
>>> >>>
>>> >>
>>> >
>>
>>
>



-- 
Graeme Rocher

Mime
View raw message