Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Robert Muir
Thanks Dawid! I tried it out locally, working fine on the mac for me now with 13!

On Thu, Jan 9, 2020 at 8:23 AM <[hidden email]> wrote:
This is an automated email from the ASF dual-hosted git repository.

dweiss pushed a commit to branch gradle-master
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git


The following commit(s) were added to refs/heads/gradle-master by this push:
     new 0166e89  Upgrading palantir's plugin to 1.14.0
0166e89 is described below

commit 0166e89dba1359f443067750789aae36c2d6d35c
Author: Dawid Weiss <[hidden email]>
AuthorDate: Thu Jan 9 14:23:35 2020 +0100

    Upgrading palantir's plugin to 1.14.0
---
 build.gradle | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build.gradle b/build.gradle
index 428d7b3..2f2fe07 100644
--- a/build.gradle
+++ b/build.gradle
@@ -1,7 +1,7 @@

 plugins {
   id "base"
-  id "com.palantir.consistent-versions" version "1.13.1"
+  id "com.palantir.consistent-versions" version "1.14.0"
   id 'de.thetaphi.forbiddenapis' version '2.7' apply false
 }


Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Dawid Weiss-2
> Thanks Dawid! I tried it out locally, working fine on the mac for me now with 13!

Yep, works for me too. It still doesn't work with Java 14 so the
general issue will require cross-compilation
strategy and remains open, but it's a start.

Something is off with palantir's plugin too. Maybe we'll just switch
to explicit version numbers instead
at some point if it turns out too painful to use this plugin, we'll see.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Robert Muir
Maybe there is an alternative solution to this. I got the hint from Uwe that only recent groovy uses ASM in this way. Actually older versions of gradle don't do it and use simple reflection. Because of this, the ant build (despite calling out to groovy) still works with EA builds, because it uses the older version!

So maybe we should open an issue at the groovy bugtracker: if the ASM can't read the classfiles because they are too new, fall back to reflection?

On Thu, Jan 9, 2020 at 11:08 AM Dawid Weiss <[hidden email]> wrote:
> Thanks Dawid! I tried it out locally, working fine on the mac for me now with 13!

Yep, works for me too. It still doesn't work with Java 14 so the
general issue will require cross-compilation
strategy and remains open, but it's a start.

Something is off with palantir's plugin too. Maybe we'll just switch
to explicit version numbers instead
at some point if it turns out too painful to use this plugin, we'll see.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Dawid Weiss-2
I implemented testing against arbitrary JVMs yesterday - it is nicely
self-contained:
https://github.com/apache/lucene-solr/commit/4599c51f0d324464ddcaadbbaad76d9cdc0cc3fe

I'm also thinking that having a separate (and stable) JVM used for
build itself may guard us
against odd jvm-related failures when you wish to run tests against
bleeding edge JVMs.

We could also specify JVM used for compilation this way but I didn't
think it's that crucial
at the moment.

D.

On Fri, Jan 10, 2020 at 12:26 AM Robert Muir <[hidden email]> wrote:

>
> Maybe there is an alternative solution to this. I got the hint from Uwe that only recent groovy uses ASM in this way. Actually older versions of gradle don't do it and use simple reflection. Because of this, the ant build (despite calling out to groovy) still works with EA builds, because it uses the older version!
>
> So maybe we should open an issue at the groovy bugtracker: if the ASM can't read the classfiles because they are too new, fall back to reflection?
>
> On Thu, Jan 9, 2020 at 11:08 AM Dawid Weiss <[hidden email]> wrote:
>>
>> > Thanks Dawid! I tried it out locally, working fine on the mac for me now with 13!
>>
>> Yep, works for me too. It still doesn't work with Java 14 so the
>> general issue will require cross-compilation
>> strategy and remains open, but it's a start.
>>
>> Something is off with palantir's plugin too. Maybe we'll just switch
>> to explicit version numbers instead
>> at some point if it turns out too painful to use this plugin, we'll see.
>>
>> Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Robert Muir
Yeah, the elasticsearch way. But that is really broken. Java 13 shouldn't be "unsupported", it is a released JVM: been out for months! Sorry, I think its a fucking crazy world if we let groovy just "get away" with this. Let's fix it!

On Fri, Jan 10, 2020 at 2:53 AM Dawid Weiss <[hidden email]> wrote:
I implemented testing against arbitrary JVMs yesterday - it is nicely
self-contained:
https://github.com/apache/lucene-solr/commit/4599c51f0d324464ddcaadbbaad76d9cdc0cc3fe

I'm also thinking that having a separate (and stable) JVM used for
build itself may guard us
against odd jvm-related failures when you wish to run tests against
bleeding edge JVMs.

We could also specify JVM used for compilation this way but I didn't
think it's that crucial
at the moment.

D.

On Fri, Jan 10, 2020 at 12:26 AM Robert Muir <[hidden email]> wrote:
>
> Maybe there is an alternative solution to this. I got the hint from Uwe that only recent groovy uses ASM in this way. Actually older versions of gradle don't do it and use simple reflection. Because of this, the ant build (despite calling out to groovy) still works with EA builds, because it uses the older version!
>
> So maybe we should open an issue at the groovy bugtracker: if the ASM can't read the classfiles because they are too new, fall back to reflection?
>
> On Thu, Jan 9, 2020 at 11:08 AM Dawid Weiss <[hidden email]> wrote:
>>
>> > Thanks Dawid! I tried it out locally, working fine on the mac for me now with 13!
>>
>> Yep, works for me too. It still doesn't work with Java 14 so the
>> general issue will require cross-compilation
>> strategy and remains open, but it's a start.
>>
>> Something is off with palantir's plugin too. Maybe we'll just switch
>> to explicit version numbers instead
>> at some point if it turns out too painful to use this plugin, we'll see.
>>
>> Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Dawid Weiss-2
> Yeah, the elasticsearch way. But that is really broken. Java 13 shouldn't be "unsupported", it is a released JVM: been out for months! Sorry, I think its a fucking crazy world if we let groovy just "get away" with this.

Java 13 is supported and works with Gradle 6... so it must be fixed
somewhere down the chain -- perhaps they just updated groovy?

> Let's fix it!

I think they have already:
https://issues.apache.org/jira/browse/GROOVY-9020

As for the more general issue with asmlib I think Uwe had some ideas
how to make it more lenient but I don't really have an opinion on
that.

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Robert Muir
This isn't rocket science: they can fall back to reflection if using ASM fails. Using ASM is some idiotic optimization, like most (ill-conceived) algorithms in the groovy langugage, we just need to fix it to be sane.

On Fri, Jan 10, 2020 at 3:21 AM Dawid Weiss <[hidden email]> wrote:
> Yeah, the elasticsearch way. But that is really broken. Java 13 shouldn't be "unsupported", it is a released JVM: been out for months! Sorry, I think its a fucking crazy world if we let groovy just "get away" with this.

Java 13 is supported and works with Gradle 6... so it must be fixed
somewhere down the chain -- perhaps they just updated groovy?

> Let's fix it!

I think they have already:
https://issues.apache.org/jira/browse/GROOVY-9020

As for the more general issue with asmlib I think Uwe had some ideas
how to make it more lenient but I don't really have an opinion on
that.

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lucene-solr] branch gradle-master updated: Upgrading palantir's plugin to 1.14.0

Robert Muir
And you DEFINITELY cant crash in this way, and then add insult to injury by leaving a daemon running. Seriously, the damn thing can use reflection.

On Fri, Jan 10, 2020 at 3:28 AM Robert Muir <[hidden email]> wrote:
This isn't rocket science: they can fall back to reflection if using ASM fails. Using ASM is some idiotic optimization, like most (ill-conceived) algorithms in the groovy langugage, we just need to fix it to be sane.

On Fri, Jan 10, 2020 at 3:21 AM Dawid Weiss <[hidden email]> wrote:
> Yeah, the elasticsearch way. But that is really broken. Java 13 shouldn't be "unsupported", it is a released JVM: been out for months! Sorry, I think its a fucking crazy world if we let groovy just "get away" with this.

Java 13 is supported and works with Gradle 6... so it must be fixed
somewhere down the chain -- perhaps they just updated groovy?

> Let's fix it!

I think they have already:
https://issues.apache.org/jira/browse/GROOVY-9020

As for the more general issue with asmlib I think Uwe had some ideas
how to make it more lenient but I don't really have an opinion on
that.

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]