You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by DECLOEDT Loic EVADERIS <Lo...@cea.fr> on 2016/03/23 10:08:03 UTC

groovy issue with @Grab

Hi,
I am taking the opportunity to inform you of an issue we have seen since a long time.
When a @Grab statement is in a script, the next statement MUST be a variable statement. For example, a code like this:
@Grapes([
  @Grab('org.apache:commons-lang:2.6')
])

// this var declaration is required to avoid startup error
//def i = 0

println "test1"

println org.apache.commons.lang.WordUtils.capitalize("this is another test")
will fail like this:
groovy test.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/home/ldecloed/Groovy/workspace/issueGrabStatement/test.groovy: 8: unexpected token: println @ line 8, column 1.
   println "test1"
   ^

1 error

Although it works without problem if the 'i' variable declaration is uncommented.
Is it a known issue ?

Regards,
Loïc

--
Loïc Decloedt
CAD & Software Manager
eVaderis
[eVaderis-logo-CMJN-small1]

Minatec Entreprise BHT
7, Parvis Louis Néel
38054 Grenoble Cedex 9
France
Office : 04 38 7 80874


RE: groovy issue with @Grab

Posted by DECLOEDT Loic EVADERIS <Lo...@cea.fr>.
Hi Guillaume, Joechen
Just to bounce back on your suggestion, we have a use-case where we cannot directly annotate the corresponding import. Generally, we have a main run script which uses classes defined in other groovy files. In this case, we gather all @Grab in the main script for sake of clarity. But I may happen that the imported packages are used in complementary files. For example, we could have something like:
Helper.groovy
import static org.apache.commons.lang3.text.WordUtils.*
class Helper {
  static String capitalize(String s) {
    return capitalize(s)
  }
}

Run.groovy
@Grab('org.apache.commons:commons-lang3:3.4')
// user var to support annotation
def i=0
Helper.capitalize(“this is a test”)

In this case, we have to fall-back to inserting something annotable after Grab. This is not a big deal, I just wanted to highlight this use case. Generally, we tend to make our run scripts as minimal as possible and implement main code in other class files to improve reuse. I agree however that, practically speaking, our run scripts are not as minimal as this one.
Thanks for your quick replies anyway.

Regards,

Loïc

De : DECLOEDT Loic EVADERIS
Envoyé : mercredi 23 mars 2016 11:13
À : users@groovy.apache.org
Objet : RE: groovy issue with @Grab

Ok, these explanations make sense to me. Annotating the imports with their corresponding @Grab statement is indeed an elegant solution. We will update or internal scripts to follow this.

Thanks,

Loïc

De : Guillaume Laforge [mailto:glaforge@gmail.com]
Envoyé : mercredi 23 mars 2016 10:51
À : users@groovy.apache.org<ma...@groovy.apache.org>
Objet : Re: groovy issue with @Grab

And it'd be more idiomatic to write the example below as:

@Grab('org.apache.commons:commons-lang3:3.4')
import static org.apache.commons.lang3.text.WordUtils.*

println capitalize("this is another test")

(I've also upgraded the version of commons-lang)

Guillaume


On Wed, Mar 23, 2016 at 10:33 AM, Jochen Theodorou <bl...@gmx.org>> wrote:


On 23.03.2016 10:08, DECLOEDT Loic EVADERIS wrote:
Hi,

I am taking the opportunity to inform you of an issue we have seen since
a long time.

When a @Grab statement is in a script, the next statement MUST be a
variable statement. For example, a code like this:

@Grapes([

   @Grab('org.apache:commons-lang:2.6')

])

// this var declaration is required to avoid startup error

//def i = 0

an annotation has to annotate something. Java allows annotations on variable declarations, classes, methods, packages and imports (at least I think it was both), as well as parameters. Since we follow the Java rules for annotation placement, the same applies to us.... we have been talking about extending this, but the current parser gets in the way of doing that, since such a change is highly ambiguous in many cases. After all, you are replacing a clear distinction of for example statements and their introducing keywords with something all have in common.

[...]
Is it a known issue ?

yes, we hope once the long work on the new grammar is done, this issue can be tackled.

bye Jochen



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Product Ninja & Advocate at Restlet<http://restlet.com>

Blog: http://glaforge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>

RE: groovy issue with @Grab

Posted by DECLOEDT Loic EVADERIS <Lo...@cea.fr>.
Ok, these explanations make sense to me. Annotating the imports with their corresponding @Grab statement is indeed an elegant solution. We will update or internal scripts to follow this.

Thanks,

Loïc

De : Guillaume Laforge [mailto:glaforge@gmail.com]
Envoyé : mercredi 23 mars 2016 10:51
À : users@groovy.apache.org
Objet : Re: groovy issue with @Grab

And it'd be more idiomatic to write the example below as:

@Grab('org.apache.commons:commons-lang3:3.4')
import static org.apache.commons.lang3.text.WordUtils.*

println capitalize("this is another test")

(I've also upgraded the version of commons-lang)

Guillaume


On Wed, Mar 23, 2016 at 10:33 AM, Jochen Theodorou <bl...@gmx.org>> wrote:


On 23.03.2016 10:08, DECLOEDT Loic EVADERIS wrote:
Hi,

I am taking the opportunity to inform you of an issue we have seen since
a long time.

When a @Grab statement is in a script, the next statement MUST be a
variable statement. For example, a code like this:

@Grapes([

   @Grab('org.apache:commons-lang:2.6')

])

// this var declaration is required to avoid startup error

//def i = 0

an annotation has to annotate something. Java allows annotations on variable declarations, classes, methods, packages and imports (at least I think it was both), as well as parameters. Since we follow the Java rules for annotation placement, the same applies to us.... we have been talking about extending this, but the current parser gets in the way of doing that, since such a change is highly ambiguous in many cases. After all, you are replacing a clear distinction of for example statements and their introducing keywords with something all have in common.

[...]
Is it a known issue ?

yes, we hope once the long work on the new grammar is done, this issue can be tackled.

bye Jochen



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Product Ninja & Advocate at Restlet<http://restlet.com>

Blog: http://glaforge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>

Re: groovy issue with @Grab

Posted by Guillaume Laforge <gl...@gmail.com>.
And it'd be more idiomatic to write the example below as:

@Grab('org.apache.commons:commons-lang3:3.4')
import static org.apache.commons.lang3.text.WordUtils.*

println capitalize("this is another test")

(I've also upgraded the version of commons-lang)

Guillaume


On Wed, Mar 23, 2016 at 10:33 AM, Jochen Theodorou <bl...@gmx.org>
wrote:

>
>
> On 23.03.2016 10:08, DECLOEDT Loic EVADERIS wrote:
>
>> Hi,
>>
>> I am taking the opportunity to inform you of an issue we have seen since
>> a long time.
>>
>> When a @Grab statement is in a script, the next statement MUST be a
>> variable statement. For example, a code like this:
>>
>> @Grapes([
>>
>>    @Grab('org.apache:commons-lang:2.6')
>>
>> ])
>>
>> // this var declaration is required to avoid startup error
>>
>> //def i = 0
>>
>
> an annotation has to annotate something. Java allows annotations on
> variable declarations, classes, methods, packages and imports (at least I
> think it was both), as well as parameters. Since we follow the Java rules
> for annotation placement, the same applies to us.... we have been talking
> about extending this, but the current parser gets in the way of doing that,
> since such a change is highly ambiguous in many cases. After all, you are
> replacing a clear distinction of for example statements and their
> introducing keywords with something all have in common.
>
> [...]
>
>> Is it a known issue ?
>>
>
> yes, we hope once the long work on the new grammar is done, this issue can
> be tackled.
>
> bye Jochen
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Product Ninja & Advocate at Restlet <http://restlet.com>

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Re: groovy issue with @Grab

Posted by Jochen Theodorou <bl...@gmx.org>.

On 23.03.2016 10:08, DECLOEDT Loic EVADERIS wrote:
> Hi,
>
> I am taking the opportunity to inform you of an issue we have seen since
> a long time.
>
> When a @Grab statement is in a script, the next statement MUST be a
> variable statement. For example, a code like this:
>
> @Grapes([
>
>    @Grab('org.apache:commons-lang:2.6')
>
> ])
>
> // this var declaration is required to avoid startup error
>
> //def i = 0

an annotation has to annotate something. Java allows annotations on 
variable declarations, classes, methods, packages and imports (at least 
I think it was both), as well as parameters. Since we follow the Java 
rules for annotation placement, the same applies to us.... we have been 
talking about extending this, but the current parser gets in the way of 
doing that, since such a change is highly ambiguous in many cases. After 
all, you are replacing a clear distinction of for example statements and 
their introducing keywords with something all have in common.

[...]
> Is it a known issue ?

yes, we hope once the long work on the new grammar is done, this issue 
can be tackled.

bye Jochen