Hi all,
the test is defined as this:
void testUseGetterFieldAccess() {
assertScript '''
class A {
boolean getterCalled = false
protected int x
public int getX() {
All of the above (now below) - plus potentially changing the name of the
fatjar, should one exist in the future...
(If the "fatjar" just references all the other jars
groovy-umbrella.jar
would imho be a better name.)
On 23.11.2017 18:07, Jochen Theodorou wrote:
So what exactly do we disagree o
And to be fully lost, there are several ways to be sure that a fatjar can not
be used as a module dependencies.
By example,
- create a module-info with a module name that you can not write in java, use
an exotic character like '+' in the module name, it's legal in the classfile
[1] but not in th
So what exactly do we disagree on here? Adding a fatjar? We have one
right now, so adding is beyond the point. Making the fatjar provide a
name for the automatic module naming in JPMS? Changing the fatjar to a
lean jar, that just references all the other jars in a build system and
that cannot d
Internal repositories can be a pain: We have one, which is permanently out of
date (so goes mostly unused), because large repository sites block you if you
sync with them on a regular basis.
At least that's what our admins tell me - if someone has a more positive
experience / automatized soluti
-1 for adding a fat jar, whatever it is. I sincerely doubt a lot of people
use this directly with `java -jar ...`. Either you use the distribution,
and we would setup the classpath for you, or you use a build tool, and it's
also done for you. And I doubt large companies without access to internet
d
I was thinking the same. Without being all for changing the name,
maybe:groovy-single.jargroovy-fat.jargroovy-the-one.jar(or more fluent:
the-one-groovy.jar ;-) )?
Ursprüngliche Nachricht Von: Paul King
Datum: 23.11.17 02:43 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re:
