You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2017/01/06 09:45:02 UTC
MavenGrapeEngine?
Hi guys,
I quite like @Grab for small applications/demo/scripting but it has a big
pitfall in development at the moment - at least for me: it doesn't support
maven snapshots.
Concretely without tuning ivy.xml config or grapes you will resolve once
the snapshot then use an outdated version.
I opened https://issues.apache.org/jira/browse/GROOVY-8037 to try to
enhance it but there are still a few questions to solve before coding:
- does groovy prefer a snapshot hack in ivy resolution or a full
aether/maven resolution support?
- what kind of SPI groovy would use (ATM GrapeEngine lookup is quite
hardcoded): do we want a config in groovy installation + system property?
- if we want another engine: how do we manage dependencies? do we isolate
them from groovy libs?
Side note: as mentionned in the ticket spring boot has an implementation we
could probably reuse (to work with them but don't think there would be a
blocker).
Any input welcomed!
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>
Re: MavenGrapeEngine?
Posted by Graeme Rocher <gr...@gmail.com>.
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 <bs...@gmail.com> wrote:
> FYI https://github.com/igor-suhorukov/mvn-classloader
>
> On Tue, Jan 10, 2017 at 11:43 AM Romain Manni-Bucau <rm...@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 <pa...@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
>>> <rm...@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 <bl...@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
>>> >>> <ma...@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
Re: MavenGrapeEngine?
Posted by Sergei Egorov <bs...@gmail.com>.
FYI https://github.com/igor-suhorukov/mvn-classloader
On Tue, Jan 10, 2017 at 11:43 AM Romain Manni-Bucau <rm...@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 <pa...@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
> <rm...@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 <bl...@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
> >>> <ma...@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
> >>>
> >>>
> >>
> >
>
>
>
Re: MavenGrapeEngine?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <pa...@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
> <rm...@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 <bl...@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
> >>> <ma...@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
> >>>
> >>>
> >>
> >
>
Re: MavenGrapeEngine?
Posted by Paul King <pa...@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
<rm...@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 <bl...@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
>>> <ma...@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
>>>
>>>
>>
>
Re: MavenGrapeEngine?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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 1:36 GMT+01:00 Jochen Theodorou <bl...@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
>> <ma...@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/openej
>> b-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/MavenResolver.java
>> <https://github.com/apache/tomee/blob/master/container/opene
>> jb-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/MavenResolver.java>
>> and
>> https://github.com/apache/tomee/blob/master/container/openej
>> b-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/HttpResolver.java
>> <https://github.com/apache/tomee/blob/master/container/opene
>> jb-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/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
>>
>>
>>
>
Re: MavenGrapeEngine?
Posted by Jochen Theodorou <bl...@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
> <ma...@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
>
>
Re: MavenGrapeEngine?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-01-06 15:33 GMT+01:00 Jochen Theodorou <bl...@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/openej
>> b-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/MavenResolver.java
>> and
>> https://github.com/apache/tomee/blob/master/container/openej
>> b-loader/src/main/java/org/apache/openejb/loader/provisin
>> ing/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
>
>
Re: MavenGrapeEngine?
Posted by Jochen Theodorou <bl...@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.
> 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?
> - 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
> and
> 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
bye Jochen
Re: MavenGrapeEngine?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-01-06 14:54 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
> On 06.01.2017 10:45, Romain Manni-Bucau wrote:
> [...]
>
>> I opened https://issues.apache.org/jira/browse/GROOVY-8037 to try to
>> enhance it but there are still a few questions to solve before coding:
>>
>> - does groovy prefer a snapshot hack in ivy resolution or a full
>> aether/maven resolution support?
>>
>
> being more easily able to use the Spring AetherGrapeEngine would certainly
> be good, I am not sure how the ivy file has to be changed to support
> snapshots properly. But in the end I would prefer the ivy based solution,
> since it means less dependencies for groovy itself.
>
>
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. For maven based artifact it
also means you run copies instead of maven repository ones which is leading
to unexpected runtime sometimes.
> - 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.
> - 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
and
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.
>
> bye Jochen
>
Re: MavenGrapeEngine?
Posted by Jochen Theodorou <bl...@gmx.org>.
On 06.01.2017 10:45, Romain Manni-Bucau wrote:
[...]
> I opened https://issues.apache.org/jira/browse/GROOVY-8037 to try to
> enhance it but there are still a few questions to solve before coding:
>
> - does groovy prefer a snapshot hack in ivy resolution or a full
> aether/maven resolution support?
being more easily able to use the Spring AetherGrapeEngine would
certainly be good, I am not sure how the ivy file has to be changed to
support snapshots properly. But in the end I would prefer the ivy based
solution, since it means less dependencies for groovy itself.
> - 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
> - 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
bye Jochen