Re: groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc: Internal groovyc error: code 1 ?

2021-03-01 Thread Paul King
Just a complete guess but does your 3.0.7/2.5.14 global libraries include
the lib/groovy-jaxb jar and not the lib/extras-jaxb/*.jar files?

On Tue, Mar 2, 2021 at 3:41 AM MG  wrote:

> Hi,
>
> I tried to do a spike to switch the (large) IntelliJ build-based* Groovy
> project I am working on to from Groovy 2.5.10 to the current Groovy 3
> release (3.0.7) today, but immediately got a "Groovyc: Internal groovyc
> error: code 1" that (contrary to previous times I encountered that error)
> did not go away through a rebuild of the current module or the whole
> project.
>
> The same problem then occurred with the current Groovy 2.5 release
> (2.5.14).
>
> I have now created a minimal IntelliJ Groovy project, that contains a
> single test that outputs the Groovy version - and to my surprise this still
> gives "Groovyc: Internal groovyc error: code 1" in the 'Builder "Groovy
> stub generator" requested rebuild of module chunk "GroovyMinimal"' phase...
> The minimal project builds & runs without problems when switching back to
> Groovy 2.5.10.
>
> My complete build environment is:
> IntellliJ 2020.2.3
> AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using 11.0.10.5)
> Windows 10 Pro 64-bit (build 19041.804)
> Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
> (Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)
>
> The project consists only of the (non-global) respective Groovy library
> dependency, and the following Groovy test file (for simplicity I use the
> JUnit that comes with this particular IntelliJ version in the minimal
> project):
>
> package minimal.groovy
> import org.junit.Ignoreimport org.junit.Testclass MinimalTest {
>  @Test @Ignore void test() {
>   println "Grooovy: ${GroovySystem.version}" }
> }
>
>
> Is this a known problem ? If not, feedback from other Groovy users would
> be appreciated. I am evidently trying to find a solution to this problem,
> but also to discern the extent of it: E.g. does it also occur when using
> Maven or Gradle as a build system (which would surprise me, since that is
> what most people use) ? If your build works fine with Groovy 2.5.14 /
> 3.0.7, what is your build environment ?
>
> Thanks, cheers,
> mg
>
> *Since the question typically pops up: The environment I work in does not
> allow access to build repositories on the internet, and it is not possible
> to automatically mirror repositories locally, and we have no complicated
> build steps, so using Gradle (or Maven) would have no real advantage for
> us, so we use the build system that is best integrated with our IDE and has
> good (apart from some minor hickups) minimal rebuild support, etc, i.e. an
> IntelliJ build.
>
>
>
>
>
>
>
>


groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc: Internal groovyc error: code 1 ?

2021-03-01 Thread MG

Hi,

I tried to do a spike to switch the (large) IntelliJ build-based* Groovy 
project I am working on to from Groovy 2.5.10 to the current Groovy 3 
release (3.0.7) today, but immediately got a "Groovyc: Internal groovyc 
error: code 1" that (contrary to previous times I encountered that 
error) did not go away through a rebuild of the current module or the 
whole project.


The same problem then occurred with the current Groovy 2.5 release (2.5.14).

I have now created a minimal IntelliJ Groovy project, that contains a 
single test that outputs the Groovy version - and to my surprise this 
still gives "Groovyc: Internal groovyc error: code 1" in the 'Builder 
"Groovy stub generator" requested rebuild of module chunk 
"GroovyMinimal"' phase...
The minimal project builds & runs without problems when switching back 
to Groovy 2.5.10.


My complete build environment is:
IntellliJ 2020.2.3
AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using 11.0.10.5)
Windows 10 Pro 64-bit (build 19041.804)
Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
(Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)

The project consists only of the (non-global) respective Groovy library 
dependency, and the following Groovy test file (for simplicity I use the 
JUnit that comes with this particular IntelliJ version in the minimal 
project):


package minimal.groovy

import org.junit.Ignore import org.junit.Test class MinimalTest {
 @Test @Ignore void test() {
  println"Grooovy: ${GroovySystem.version}" }
}


Is this a known problem ? If not, feedback from other Groovy users would 
be appreciated. I am evidently trying to find a solution to this 
problem, but also to discern the extent of it: E.g. does it also occur 
when using Maven or Gradle as a build system (which would surprise me, 
since that is what most people use) ? If your build works fine with 
Groovy 2.5.14 / 3.0.7, what is your build environment ?


Thanks, cheers,
mg

*Since the question typically pops up: The environment I work in does 
not allow access to build repositories on the internet, and it is not 
possible to automatically mirror repositories locally, and we have no 
complicated build steps, so using Gradle (or Maven) would have no real 
advantage for us, so we use the build system that is best integrated 
with our IDE and has good (apart from some minor hickups) minimal 
rebuild support, etc, i.e. an IntelliJ build.










Parsing a script is really slow in OSGI

2021-03-01 Thread J . Brebec
Hello,

I use Groovy (v3.0.7) in an OSGI container (Karaf with Equinox), and the 
parsing of a Groovy scripts takes seconds (7, 8s). In my unit test, the same 
script loads in ms.

If a script uses a property "a", or the map operator "a.b", then a lot of 
classes are tried to be resolved (like groovy.lang.Script$a, class b in package 
a, and resources groovy.lang.Script$a.groovy, ...). Due to 
Dynamic-ImportPackage or Buddy-Policy, the lookup are delegated to almost all 
my bundle.

Does anyone has the same issue, or a workaround ?

Regards,
Jérémie