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 <[email protected]>:
> 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
> <[email protected]> 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 <[email protected]>:
> >>
> >> well... contributions are welcome ;)
> >>
> >> On 06.01.2017 15:36, Romain Manni-Bucau wrote:
> >>>
> >>>
> >>>
> >>> 2017-01-06 15:33 GMT+01:00 Jochen Theodorou <[email protected]
> >>> <mailto:[email protected]>>:
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>
> >
>
