Hi Mauro,
I think I can shed some light at where OC is coming from. Basically, if
you have a project with very few dependencies and therefore few JARs, it
is without any doubt convenient to have just a single
groovy-all- JAR: You can check with one glance what Groovy
version you are using,
Il 19/05/20 12:37, Andy Duncan ha scritto:
I woke up early this morning and thought I could put my time to use
writing a simple Gradle project that demonstrates how effective it can
be at getting a project up and running;
https://github.com/andyjduncan/gradle-example
And let's not forget
rent package name) then all bets
> would be off.
>
> Cheers, Paul.
>
>
> Thanks,
> OC
>
>> From: OCsite mailto:o...@ocs.cz>>
>> Reply-To: "users@groovy.apache.org <mailto:users@groovy.apache.org>"
>> mailto:users@groov
:-
>
If it never gets in a repo, I would say the risk is low. If anyone ever
puts it in a repo (without embedding under a different package name) then
all bets would be off.
Cheers, Paul.
> Thanks,
> OC
>
> *From: *OCsite
>> *Reply-To: *"users@groovy.apache
Jochen,
first, this debate might be getting a bit at the moot side: meantime, I have
decided just to slightly improve my scripts to simply add groovy/lib/*.jar to
the classpath for the deployment.
It will make installation of new Groovy versions to the servers a bit more
difficult than it
I woke up early this morning and thought I could put my time to use writing
a simple Gradle project that demonstrates how effective it can be at
getting a project up and running;
https://github.com/andyjduncan/gradle-example
Cloning a repository and bootstrapping the whole build process with
t;mailto:users@groovy.apache.org>"
> mailto:users@groovy.apache.org>>
> Date: Monday, May 18, 2020 at 11:47 AM
> To: "users@groovy.apache.org <mailto:users@groovy.apache.org>"
> mailto:users@groovy.apache.org>>
> Subject: Re: How to test and deplo
Il 18/05/20 18:47, OCsite ha scritto:
To write and maintain my own launch script takes about one
thousandth time and effort as compared with learning a whole new
ecosystem which I do not need at all (well, perhaps now for the
first time and for
On 19.05.20 03:53, OCsite wrote:
Well, thanks, I'll check the thing, though at the first look it rather
seems to be a tool for a Gradle project owner who wants to move his
projects into Xcode. Me, I'm precisely the opposite case — I've got
Xcode projects which I /possibly might/ want to move
*From: *OCsite
> *Reply-To: *"users@groovy.apache.org"
> *Date: *Monday, May 18, 2020 at 11:47 AM
> *To: *"users@groovy.apache.org"
> *Subject: *Re: How to test and deploy without groovy-all?
>
>
>
> External e-mail. Use caution! / Courriel externe.
Well, thanks, I'll check the thing, though at the first look it rather seems to
be a tool for a Gradle project owner who wants to move his projects into Xcode.
Me, I'm precisely the opposite case — I've got Xcode projects which I possibly
might want to move into Gradle.
If at all. I still
Gradle has a plugin for XCode anyway (never used it).
https://docs.gradle.org/current/userguide/xcode_plugin.html
--
Bob
On Mon, May 18, 2020 at 3:38 PM Andy Duncan
wrote:
> Hi,
>
> If you're bundling up Grooby applications for deployment on to servers,, I
> would echo what others have said
Hi,
If you're bundling up Grooby applications for deployment on to servers,, I
would echo what others have said and look into Gradle, along with the
Shadow plugin [1]
. Having lived through the age of Ant and committing all of the binary
dependencies in my projects to source control, having a
You misread or misinterpreted what i said: i never said "I am told to
*embed* most of Groovy and other libraries into *each application".*
I was talking about* builds.*
*T*
On Mon, May 18, 2020, 20:16 OCsite wrote:
> Thanks! This is one absolutely excellent example of the Java approach to
>
Thanks! This is one absolutely excellent example of the Java approach to all
problems :)
So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put one
groovy-all for each Groovy version we need to support once to each of our
servers — which JAR indeed would contain a few parts
The lack of groovy-all is just on par with literally everything else
"monolithic". You don't have spring-all, jetty-all, jackson-all, do you?
Nowadays developers use tools to maintain their dependencies (and
transitive ones). Basically no need for a "monolithic" ALL that you for
sure does not use
ect: Re: How to test and deploy without groovy-all?
External e-mail. Use caution! / Courriel externe. Faites attention!
On 18 May 2020, at 18:12, Mauro Molinari
mailto:mauro...@tiscali.it>> wrote:
Il 18/05/20 17:48, OCsite ha scritto:
(Actually I can't imagine
> On 18 May 2020, at 18:12, Mauro Molinari wrote:
>
> Il 18/05/20 17:48, OCsite ha scritto:
>> (Actually I can't imagine the Maven/Gradle workflow to be considerably
>> different: the principle of creating the application package and installing
>> it plus all the JARs needed to the server and
Il 18/05/20 17:48, OCsite ha scritto:
(Actually I can't imagine the Maven/Gradle workflow to be
considerably different: the principle of creating the
application package and installing it plus all the JARs needed
to the
Thanks again, but...
> On 18 May 2020, at 17:07, Mauro Molinari wrote:
>
> Il 18/05/20 16:29, OCsite ha scritto:
>> Or am I wrong and there is some magic which would prevent this scenario?
> Your application will fail at compilation time if some JAR is missing.
>
... I am afraid this won't do.
Il 18/05/20 16:29, OCsite ha scritto:
Or am I wrong and there is some magic which would
prevent this scenario?
Your application will fail at compilation time if some
JAR is missing. If you plan to run with Groovy 3.x binary code
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
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
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
24 matches
Mail list logo
