groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergei Egorov <bsid...@gmail.com>
Subject Re: MavenGrapeEngine?
Date Fri, 20 Jan 2017 22:42:01 GMT
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 <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 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
> >>>
> >>>
> >>
> >
>
>
>

Mime
View raw message