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

[OCsite]

Again thanks, but this seems sort of at the dangerous side. Correct me please 
if I am wrong, but I understand JVM loads the classes on-demand when they are 
needed, not all at the launch time.

That would mean that a well- but not completely-tested application (and we all 
know it is just not possible to test completely!) still could crash when a user 
tries something different from all the testers (and we all know users do that!) 
due to some JAR not available at the deployment site.

Or am I wrong and there is some magic which would prevent this scenario?

Thanks!
OC

> On 18 May 2020, at 16:16, Keith Suderman  wrote:
> 
> 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
> 
> 1. https://github.com/gradle/gradle-groovy-all 
> 
> 
>> On May 18, 2020, at 8:43 AM, OCsite mailto:o...@ocs.cz>> wrote:
>> 
>> Hi there,
>> 
>>> On 16 May 2020, at 14:17, OCsite mailto:o...@ocs.cz>> 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
>> 
>>> http://groovy-lang.org/releasenotes/groovy-2.5.html 
>>> 
>> 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.
> 

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

[OCsite]

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  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  wrote:
> 
> I use Maven to do my build-test-deploy, and I am currently researching 
> converting to Gradle.
> Here is my maven dependency…
>  
> 
>   org.codehaus.groovy
>   groovy-all
>   2.5.9
>   provided
>   pom
> 
>  
> 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 mailto:o...@ocs.cz>>
> Reply-To: "users@groovy.apache.org " 
> mailto:users@groovy.apache.org>>
> Date: Monday, May 18, 2020 at 5:43 AM
> To: "users@groovy.apache.org " 
> mailto:users@groovy.apache.org>>
> Subject: How to test and deploy without groovy-all? (was: More Groovy 3 woes)
>  
> Hi there,
> 
> 
>> On 16 May 2020, at 14:17, OCsite mailto:o...@ocs.cz>> 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
>  
>> http://groovy-lang.org/releasenotes/groovy-2.5.html 
>>  
> 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 

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

[Keith Suderman]

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

1. https://github.com/gradle/gradle-groovy-all

> On May 18, 2020, at 8:43 AM, OCsite  wrote:
> 
> Hi there,
> 
>> On 16 May 2020, at 14:17, OCsite mailto:o...@ocs.cz>> 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
> 
>> http://groovy-lang.org/releasenotes/groovy-2.5.html 
>> 
> 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.

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

[OCsite]

Hi there,

> On 16 May 2020, at 14:17, OCsite  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

> http://groovy-lang.org/releasenotes/groovy-2.5.html

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.