More Groovy 3 woes

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

More Groovy 3 woes

OCsite
Hi there,

having enclosed all the “foo as bar”'s in ternary operators in parentheses, I have bumped into a completely weird problem which I can't wrap my head on -- for many classes I am with Groovy 3 getting completely weird errors of kind

“constructor X in class Y cannot be applied to given types”

What gives and how to solve the problem? Note again that the code _did_ build and _did work properly_ (tested zillion times) with Groovy 2, so there can't be anything seriously wrong with the sources. Looks like another breaking change :(

I succeeded to isolate it into a pretty small source with just one pretty standard JAR like this:

===
194 ocs /tmp> <CreateSignatureBase.java
/*
 * Copyright 2015 The Apache Software Foundation.

 * OC: removed almost all code, leaving just what's needed to crash

 */

package org.apache.pdfbox.examples.signature;

import java.io.IOException;
import java.io.InputStream;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.UnrecoverableKeyException;
import java.security.cert.CertificateException;
import org.apache.pdfbox.pdmodel.interactive.digitalsignature.SignatureInterface;

public abstract class CreateSignatureBase implements SignatureInterface
{
    public CreateSignatureBase(KeyStore keystore, char[] pin)
            throws KeyStoreException, UnrecoverableKeyException, NoSuchAlgorithmException, IOException, CertificateException
    { }
    @Override
    public byte[] sign(InputStream content) throws IOException
    {
        return null;
    }
}

195 ocs /tmp> <myclass.groovy
package cz.ocs.utilities

import groovy.transform.*
import org.apache.pdfbox.pdmodel.*
import org.apache.pdfbox.examples.signature.CreateSignatureBase

@InheritConstructors class CreateSignature extends CreateSignatureBase {
    void signPDF(PDDocument pdd, OutputStream out) {

    }
}

196 ocs /tmp> /usr/local/groovy-2.4.17/bin/groovyc -cp /Extensions/pdfbox-2.0.17.jar -j myclass.groovy CreateSignatureBase.java
197 ocs /tmp> /usr/local/groovy-3.0.3/bin/groovyc -cp /Extensions/pdfbox-2.0.17.jar -j myclass.groovy CreateSignatureBase.java
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Compile error during compilation with javac.
/var/folders/zh/h4cv6xjx033frtt9y72ch8980000gp/T/groovy-generated-8946934250394256568-java-source/cz/ocs/utilities/CreateSignature.java:12: error: constructor CreateSignatureBase in class CreateSignatureBase cannot be applied to given types;
@groovy.transform.InheritConstructors() public class CreateSignature
                                               ^
  required: KeyStore,char[]
  found: no arguments
  reason: actual and formal argument lists differ in length
1 error


1 error

198 ocs /tmp>

===

Thanks and all the best,
OC


Reply | Threaded
Open this post in threaded view
|

Re: More Groovy 3 woes

Daniel.Sun
Hi OC,

> having enclosed all the “foo as bar”'s in ternary operators in parentheses
We have fixed some issues related to ternary operator since Groovy 3 was
released. Please provide a code snippet to show the ternary operator issue
you mentioned.

> “constructor X in class Y cannot be applied to given types”
I find you are trying to compile a groovy file and a java file together. It
looks like a joint compilation issue. Let me try to reproduce the issue on
my machine and fix it.

P.S. long time no see, welcome back to groovy mailing list ;-)

Cheers,
Daniel Sun



-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
Apache Groovy committer & PMC member

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: More Groovy 3 woes

Daniel.Sun
In reply to this post by OCsite
The joint compilation issue should be fixed in Groovy 3.0.4, which will be
released in a couple of days.

If you want to try in a hurry, here is link to SNAPSHOT:
https://github.com/apache/groovy/actions/runs/106435124


Cheers,
Daniel Sun



-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
Apache Groovy committer & PMC member

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: More Groovy 3 woes

OCsite
In reply to this post by Daniel.Sun
Daniel,

On 16 May 2020, at 2:42, Daniel.Sun <[hidden email]> wrote:
having enclosed all the “foo as bar”'s in ternary operators in parentheses
We have fixed some issues related to ternary operator since Groovy 3 was
released. Please provide a code snippet to show the ternary operator issue
you mentioned.

I actually have, “1>2?[3] as Set:null”. I'll get shortly back to it in an answer to your next message.

P.S. long time no see, welcome back to groovy mailing list ;-)

Thanks! Well for a long time I had to focus on the application itself, keeping the build scripts, ASTTs and version of groovy itself unchanged :) Now's the time we are refactoring our application core, which |'d like to accompany by switching to the newest (stable) Groovy available, so I'm back with new problems :)

Thanks and all the best,
OC

Reply | Threaded
Open this post in threaded view
|

Re: More Groovy 3 woes

OCsite
In reply to this post by Daniel.Sun
Daniel,

On 16 May 2020, at 10:58, Daniel.Sun <[hidden email]> wrote:
The joint compilation issue should be fixed in Groovy 3.0.4, which will be
released in a couple of days.

If you want to try in a hurry, here is link to SNAPSHOT:
https://github.com/apache/groovy/actions/runs/106435124

great, thanks; I've suceeded to check quickly and my project is built completely! Great!

(Incidentally, seems the compiler now does not understand the --indy switch. I'd sugges — if it does not make any sense anymore —, to still recognise it and just emit a warning that the switch does not do anything anymore. That it prevents compilation is pretty bad for project backward compatibility.

Running's not that easy. First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone? The only solution I've found to be able to run my application was to add all JARs from groovy/lib to classpath; that's darn inconvenient for testing and would be a proper hell for deployment :(

Aside of that it seems it runs more or less all right. Some of my ASTTs seem to be incompatible with the new stuff alas, but that I'll have to pursue in detail before I either simply fix it at my side or ask here for a help :)

Thanks again a big lot!
OC

Reply | Threaded
Open this post in threaded view
|

How to test and deploy without groovy-all? (was: More Groovy 3 woes)

OCsite
Hi there,

On 16 May 2020, at 14:17, OCsite <[hidden email]> wrote:
First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?

I still can't see a reasonable solution for that :( All the documentation I've found so far is

which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?

Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.

The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).

So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.

What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple

java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application

did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.

What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.

Thanks a lot,
OC

[1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.
Reply | Threaded
Open this post in threaded view
|

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

ericksn

I use Maven to do my build-test-deploy, and I am currently researching converting to Gradle.

Here is my maven dependency…

 

    <dependency>

      <groupId>org.codehaus.groovy</groupId>

      <artifactId>groovy-all</artifactId>

      <version>2.5.9</version>

      <scope>provided</scope>

      <type>pom</type>

    </dependency>

 

Now, while I do admit I have not tried a build yet with Groovy 3, the Maven dependency for groovy-all does exist…

 

 

 

From: OCsite <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, May 18, 2020 at 5:43 AM
To: "[hidden email]" <[hidden email]>
Subject: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

 

Hi there,



On 16 May 2020, at 14:17, OCsite <[hidden email]> wrote:

First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?

 

I still can't see a reasonable solution for that :( All the documentation I've found so far is

 

which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?

 

Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.

 

The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).

 

So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.

 

What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple

 

java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application

 

did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.

 

What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.

 

Thanks a lot,

OC

 

[1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.

Reply | Threaded
Open this post in threaded view
|

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

Erik Husby-3
I use the Maven-shade-plugin that produces a single jar that contains all the dependencies of the project. 

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
I can then use a script that contains the Java command like so. (as part of the build, the script is filtered to get the project variables inserted.)
java -cp `dirname $0`/${project.build.finalName}.jar ${main.class} $@

On Mon, May 18, 2020 at 9:59 AM Nelson, Erick <[hidden email]> wrote:

I use Maven to do my build-test-deploy, and I am currently researching converting to Gradle.

Here is my maven dependency…

 

    <dependency>

      <groupId>org.codehaus.groovy</groupId>

      <artifactId>groovy-all</artifactId>

      <version>2.5.9</version>

      <scope>provided</scope>

      <type>pom</type>

    </dependency>

 

Now, while I do admit I have not tried a build yet with Groovy 3, the Maven dependency for groovy-all does exist…

 

 

 

From: OCsite <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, May 18, 2020 at 5:43 AM
To: "[hidden email]" <[hidden email]>
Subject: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

 

Hi there,



On 16 May 2020, at 14:17, OCsite <[hidden email]> wrote:

First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?

 

I still can't see a reasonable solution for that :( All the documentation I've found so far is

 

which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?

 

Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.

 

The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).

 

So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.

 

What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple

 

java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application

 

did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.

 

What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.

 

Thanks a lot,

OC

 

[1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.



--
---

Erik Husby
Principal Development Operations Engineer
Broad Institute
Rm. 2195, 320 Charles St, Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.714.8443
email: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

Keith Suderman
In reply to this post by OCsite
I can only comment on our experience:

- For most of our projects simply replacing groovy-all with the core groovy module has worked fine as most of our projects don't (didn't) make use of the classes that are not present in the core groovy module.
- For the projects that did need missing classes we simply add the needed groovy-* modules.  We've never had to add more that two or three other modules and it is almost always just groovy-json and/or groovy-xml
- If you _really_ need the entire contents of groovy/lib on the classpath you can try building your own groovy-all jar file.  There are instructions for doing this with 2.5.x [1], but it should be possible to do the same for 3.x

I am not sure of your use case, but we've never even come close to needing everything from groovy/lib on the classpath.

I hope that gives you some ideas.
- Keith


On May 18, 2020, at 8:43 AM, OCsite <[hidden email]> wrote:

Hi there,

On 16 May 2020, at 14:17, OCsite <[hidden email]> wrote:
First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?

I still can't see a reasonable solution for that :( All the documentation I've found so far is

which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?

Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.

The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).

So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.

What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple

java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application

did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.

What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.

Thanks a lot,
OC

[1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.

Reply | Threaded
Open this post in threaded view
|

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

OCsite
In reply to this post by ericksn
Well thanks, but I do not even know what Maven or Gradle is. I presume those probably would be build systems, which both could generate the proper groovy-all JAR, right? Systems presumably well-known and used daily by all those who maintain and improve Groovy itself (kudos to you all!), but of no use for us who only use Groovy to build other applications and who need just groovyc to compile, plus standard jar to pack the result and standard java to launch it.

Of course if need be I could learn and use one of them, but it seems sort of at the superfluous side to learn a whole new ecosystem, completely unneeded otherwise, just to create the one sole JAR needed for deployment. Aside of that it seems sort of at the absurd side that each Groovy user does this by himself again, again and again, for each new version? Wouldn't it be infinitely better, more convenient and reasonable to do this task only once at the build site and include the -all JAR to the binary distro, precisely the same way it used to be before 2.5?

Incidentally meantime I have searched the maillist too, and found Cédric's recommendation to do without the thing:

On 24 Oct 2019, at 9:51, Cédric Champeau <[hidden email]> wrote:
Easiest is _not_ to use groovy-all, which is really a convenience to get _all_ Groovy modules. It's extremely unlikely you need them all, as your message indicates (you don't need testng, but I'm pretty sure you don't need groovy-swing either).

That, of course, would be a best approach, but I can't see how to ensure that?

Actually when I have read the 2.5 release notes for the first time, I presumed that's precisely what happened: that groovy-all is not needed anymore, for the excellent Groovy team, ever on search for improvements, invented some smart magical way to import all the needed JARs automatically without a need to install them at the deployment site manually and placing them to the classpath (presumably, loading them from the Net and caching somehow in case upon the next launch the site happens to be offline, yadda yadda yadda). That would be a help indeed. Alas, when I launched my first 3-based build, the “cannot load app.Application” result proved it is not so :(

Thanks again and do please forgive if this sounds a bit rant-like, but this really seems a bit absurd. I could understand if for some reason the Groovy team decided to distribute just the sources and whomever who wants to use Groovy would have to build and pack himself, that would make sense; but given there actually is a binary distro, I can't see why it lacks the -all JAR far as it still is needed for deployment, and leaves it on each user to find a way to build the thing himself :/

All the best,
OC

On 18 May 2020, at 15:59, Nelson, Erick <[hidden email]> wrote:

I use Maven to do my build-test-deploy, and I am currently researching converting to Gradle.
Here is my maven dependency…
 
    <dependency>
      <groupId>org.codehaus.groovy</groupId>
      <artifactId>groovy-all</artifactId>
      <version>2.5.9</version>
      <scope>provided</scope>
      <type>pom</type>
    </dependency>
 
Now, while I do admit I have not tried a build yet with Groovy 3, the Maven dependency for groovy-all does exist…
 
<image001.png>
 
 
From: OCsite <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, May 18, 2020 at 5:43 AM
To: "[hidden email]" <[hidden email]>
Subject: How to test and deploy without groovy-all? (was: More Groovy 3 woes)
 
Hi there,


On 16 May 2020, at 14:17, OCsite <[hidden email]> wrote:
First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?
 
I still can't see a reasonable solution for that :( All the documentation I've found so far is
 
which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?
 
Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at.../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.
 
The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load theapp.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).
 
So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.
 
What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple
 
java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application
 
did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.
 
What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.
 
Thanks a lot,
OC
 
[1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.

1234