@Groovy advance

classic Classic list List threaded Threaded
16 messages Options
12
Reply | Threaded
Open this post in threaded view
|

@Groovy advance

Alex Popescu
Hi!

Firstly I would like to summarize here the long discussion I had with
Jochen on annotation support.

1. Parser + AST status

The parser does not support yet array attributes. I have checked the
groovy.g grammar and found some commented definition in there.
Considering that arrays are quite used in annotations we will
definitely need to fix this.

2. Annotation verification + bytecode

Considering that there are a couple of checks that need to be
performed on annotations we have decided to introduce a specialized
visitor. It will be  responsible for a couple of tasks:

*) check that an annoatation is really an annotation (implements Anotation)
*) ensure that names get a value unless they have a default
*) check that the type of the constants matches
*) solve some more AST details

The ugly part of this story is that we will need to provide a
reflective wrapper API on top of JDK5 annotation reflection API to
allow us perform the above checks.

Now, hopefully on the bright side of the story I have attached my the
source of my current advance. Here is a short report:

- added an option named target to CompilerConfiguration
(this will allow specifying on command line, Ant task, etc if the
bytecode is intended to run on a different VM then the current one.
The accepted values are: 1.4 and 1.5. Currently, it default to the
current executing VM).

- added a couple of fields in AnnotationNode for retention policy
usage. They will be set by the above mentioned verifier

- added a boolean field to ClassNode to mark if the class is using
annotations and so to be able to later generate the correct bytecode
version. The value is set by the verifier, and read from the ACG.

- added the verifier and plugged it in. Currently it brings no
overload as it is internally disabled. I have also drafted the
necessary steps to be performed inside the verifier.

- improved support for generating the bytecode for annotated elements
in ACG. There are a couple of remaining things to be solved here:
- writting enum attributes (this must be firstly solved in the
verifier as both class type attributes and enum type attributes are
reported as PropertyExpressions)
- later after we add support for arrays perform the required steps.

The 2nd attachment contains a set of 3 annotations I am using for
testing and a set of 3 groovy scripts.

Last, but not least: I would really appreciate if somebody can check
the code and check it in, as it is quite difficult for me to keep up
with the SVN changes and continue to work on those sources (I already
got 2 conflicts that I have to fix before submitting :( ). As I
already mentioned the submitted code has no impact on the current
execution of the existing groovy scripts. Unfortunately, when running
the groovy:test target I am getting 2 Failures (from further
investigation these are in SecurityTest and SignedJarTest but I am
quite sure they are not generated by my changes).

groovy:test:
   [echo] Setting property java.awt.headless to true
   [junit] Running UberTestCase
   [junit] Tests run: 679, Failures: 0, Errors: 0, Time elapsed: 15.891 sec
   [junit] Running UberTestCase2
   [junit] Tests run: 175, Failures: 0, Errors: 0, Time elapsed: 6.562 sec
   [junit] Running UberTestCase3
   [junit] Tests run: 232, Failures: 0, Errors: 0, Time elapsed: 13.391 sec
   [junit] Running UberTestCase4
   [junit] Tests run: 109, Failures: 2, Errors: 0, Time elapsed: 4.281 sec
   [junit] [ERROR] TEST UberTestCase4 FAILED
   [junit] Running UberTestCaseLongRunningTests
   [junit] Tests run: 380, Failures: 0, Errors: 0, Time elapsed: 8.109 sec
   [junit] Running UberTestCaseTCK
   [junit] Tests run: 34, Failures: 0, Errors: 0, Time elapsed: 1.047 sec

Please let me know what do you think.

./alex
--
.w( the_mindstorm )p.
 ___________________________________
  Alexandru Popescu, OSS Evangelist
TestNG/AspectJ/WebWork/Struts2/more...
  Information Queue ~ www.InfoQ.com

groovy-core.zip (58K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: @Groovy advance

Jochen Theodorou
Alexandru Popescu schrieb:
> Hi!
>
> Firstly I would like to summarize here the long discussion I had with
> Jochen on annotation support.

it would be good to just post the diffs. They are more readable than a
complete ACG.

> 1. Parser + AST status
>
> The parser does not support yet array attributes. I have checked the
> groovy.g grammar and found some commented definition in there.
> Considering that arrays are quite used in annotations we will
> definitely need to fix this.

I think we can really go and uses our lists here and do the
transformation statically with the need to have a list of constants.

[...]
> - added an option named target to CompilerConfiguration
> (this will allow specifying on command line, Ant task, etc if the
> bytecode is intended to run on a different VM then the current one.
> The accepted values are: 1.4 and 1.5. Currently, it default to the
> current executing VM).

what is missing is initialization through property in the secound
constructor. Since we already have targetDirectory I think that target
alone is a bit too short. I suggest targetBytecode. And I suggest to not
to limit that to pre and post 1.4 only. We may have to face 1.6 in the
future, too.

[...]
> - improved support for generating the bytecode for annotated elements
> in ACG. There are a couple of remaining things to be solved here:
> - writting enum attributes (this must be firstly solved in the
> verifier as both class type attributes and enum type attributes are
> reported as PropertyExpressions)

what do we need to resolve here?

[...]
> The 2nd attachment contains a set of 3 annotations I am using for
> testing and a set of 3 groovy scripts.

hmm... right, never thought about how we do test that stuff... We can
not have annotation based classes in a java4 build... hmmm

> Last, but not least: I would really appreciate if somebody can check
> the code and check it in, as it is quite difficult for me to keep up
> with the SVN changes and continue to work on those sources (I already
> got 2 conflicts that I have to fix before submitting :( ). As I
> already mentioned the submitted code has no impact on the current
> execution of the existing groovy scripts. Unfortunately, when running
> the groovy:test target I am getting 2 Failures (from further
> investigation these are in SecurityTest and SignedJarTest but I am
> quite sure they are not generated by my changes).

well I would agree, but it would be good to test it on a fresh checkout
first. This needs to be fixed.

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: @Groovy advance

Alex Popescu
On 1/18/07, Jochen Theodorou <[hidden email]> wrote:
> Alexandru Popescu schrieb:
> > Hi!
> >
> > Firstly I would like to summarize here the long discussion I had with
> > Jochen on annotation support.
>
> it would be good to just post the diffs. They are more readable than a
> complete ACG.
>

Frankly speaking i don't think a unified patch format would have
really been more readable.

> > 1. Parser + AST status
> >
> > The parser does not support yet array attributes. I have checked the
> > groovy.g grammar and found some commented definition in there.
> > Considering that arrays are quite used in annotations we will
> > definitely need to fix this.
>
> I think we can really go and uses our lists here and do the
> transformation statically with the need to have a list of constants.
>
> [...]
> > - added an option named target to CompilerConfiguration
> > (this will allow specifying on command line, Ant task, etc if the
> > bytecode is intended to run on a different VM then the current one.
> > The accepted values are: 1.4 and 1.5. Currently, it default to the
> > current executing VM).
>
> what is missing is initialization through property in the secound
> constructor. Since we already have targetDirectory I think that target
> alone is a bit too short. I suggest targetBytecode. And I suggest to not
> to limit that to pre and post 1.4 only. We may have to face 1.6 in the
> future, too.
>

Agreed. But now we just have 1.4 and 1.5 as options. And I like
keeping things simple :-).

> [...]
> > - improved support for generating the bytecode for annotated elements
> > in ACG. There are a couple of remaining things to be solved here:
> > - writting enum attributes (this must be firstly solved in the
> > verifier as both class type attributes and enum type attributes are
> > reported as PropertyExpressions)
>
> what do we need to resolve here?
>

An attribute with the type Class is returned as a PropertyExpression
where the object is the (I forgot what) and .class is a
ConstantExpression.
This needs to be addressed and reported as a ClassExpression or
something like this.

> [...]
> > The 2nd attachment contains a set of 3 annotations I am using for
> > testing and a set of 3 groovy scripts.
>
> hmm... right, never thought about how we do test that stuff... We can
> not have annotation based classes in a java4 build... hmmm
>

Considering that the build must remain on JDK1.4, then there will be
no way to include tests in the build. Probably an option would be to
have to separate set of tests one running against VM1.4 and other
running against VM1.5 if it is available.

> > Last, but not least: I would really appreciate if somebody can check
> > the code and check it in, as it is quite difficult for me to keep up
> > with the SVN changes and continue to work on those sources (I already
> > got 2 conflicts that I have to fix before submitting :( ). As I
> > already mentioned the submitted code has no impact on the current
> > execution of the existing groovy scripts. Unfortunately, when running
> > the groovy:test target I am getting 2 Failures (from further
> > investigation these are in SecurityTest and SignedJarTest but I am
> > quite sure they are not generated by my changes).
>
> well I would agree, but it would be good to test it on a fresh checkout
> first. This needs to be fixed.
>

In fact it was tested agaist the latest SVN trunk version (in fact a
couple of hours old, this made me solve a couple of conflicts :-( ).

BR,

./alex
--
.w( the_mindstorm )p.

> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> Groovy Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: @Groovy advance

Dierk König
What kind of tests will we have for the Annotation support?

Dierk

> -----Original Message-----
> From: Alexandru Popescu [mailto:[hidden email]]
> Sent: Donnerstag, 18. Januar 2007 0:21
> To: [hidden email]
> Subject: Re: [groovy-dev] @Groovy advance
>
>
> On 1/18/07, Jochen Theodorou <[hidden email]> wrote:
> > Alexandru Popescu schrieb:
> > > Hi!
> > >
> > > Firstly I would like to summarize here the long discussion I had with
> > > Jochen on annotation support.
> >
> > it would be good to just post the diffs. They are more readable than a
> > complete ACG.
> >
>
> Frankly speaking i don't think a unified patch format would have
> really been more readable.
>
> > > 1. Parser + AST status
> > >
> > > The parser does not support yet array attributes. I have checked the
> > > groovy.g grammar and found some commented definition in there.
> > > Considering that arrays are quite used in annotations we will
> > > definitely need to fix this.
> >
> > I think we can really go and uses our lists here and do the
> > transformation statically with the need to have a list of constants.
> >
> > [...]
> > > - added an option named target to CompilerConfiguration
> > > (this will allow specifying on command line, Ant task, etc if the
> > > bytecode is intended to run on a different VM then the current one.
> > > The accepted values are: 1.4 and 1.5. Currently, it default to the
> > > current executing VM).
> >
> > what is missing is initialization through property in the secound
> > constructor. Since we already have targetDirectory I think that target
> > alone is a bit too short. I suggest targetBytecode. And I suggest to not
> > to limit that to pre and post 1.4 only. We may have to face 1.6 in the
> > future, too.
> >
>
> Agreed. But now we just have 1.4 and 1.5 as options. And I like
> keeping things simple :-).
>
> > [...]
> > > - improved support for generating the bytecode for annotated elements
> > > in ACG. There are a couple of remaining things to be solved here:
> > > - writting enum attributes (this must be firstly solved in the
> > > verifier as both class type attributes and enum type attributes are
> > > reported as PropertyExpressions)
> >
> > what do we need to resolve here?
> >
>
> An attribute with the type Class is returned as a PropertyExpression
> where the object is the (I forgot what) and .class is a
> ConstantExpression.
> This needs to be addressed and reported as a ClassExpression or
> something like this.
>
> > [...]
> > > The 2nd attachment contains a set of 3 annotations I am using for
> > > testing and a set of 3 groovy scripts.
> >
> > hmm... right, never thought about how we do test that stuff... We can
> > not have annotation based classes in a java4 build... hmmm
> >
>
> Considering that the build must remain on JDK1.4, then there will be
> no way to include tests in the build. Probably an option would be to
> have to separate set of tests one running against VM1.4 and other
> running against VM1.5 if it is available.
>
> > > Last, but not least: I would really appreciate if somebody can check
> > > the code and check it in, as it is quite difficult for me to keep up
> > > with the SVN changes and continue to work on those sources (I already
> > > got 2 conflicts that I have to fix before submitting :( ). As I
> > > already mentioned the submitted code has no impact on the current
> > > execution of the existing groovy scripts. Unfortunately, when running
> > > the groovy:test target I am getting 2 Failures (from further
> > > investigation these are in SecurityTest and SignedJarTest but I am
> > > quite sure they are not generated by my changes).
> >
> > well I would agree, but it would be good to test it on a fresh checkout
> > first. This needs to be fixed.
> >
>
> In fact it was tested agaist the latest SVN trunk version (in fact a
> couple of hours old, this made me solve a couple of conflicts :-( ).
>
> BR,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> > bye blackdrag
> >
> > --
> > Jochen "blackdrag" Theodorou
> > Groovy Tech Lead (http://groovy.codehaus.org)
> > http://blackdragsview.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: @Groovy advance

Jochen Theodorou
Dierk Koenig schrieb:
> What kind of tests will we have for the Annotation support?

I don't know. I see it as big problem since we can't simply write an
annotation and then test if it is accessible. We could write a test that
is only executed when running >= java4... Then the real test itself must
be embedded in a string to avoid precompilation

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: @Groovy advance

Alex Popescu
In reply to this post by Dierk König
On 1/18/07, Dierk Koenig <[hidden email]> wrote:
> What kind of tests will we have for the Annotation support?
>

As I already said in my previous message:

[quote]
Considering that the build must remain on JDK1.4, then there will be
no way to include tests in the build. Probably an option would be to
have two separate set of tests one running against VM1.4 and other
running against VM1.5 if it is available.
[/quote]

Except that I don't see any other solutions (at least solution that
will not require to hack for weeks :-) ).

./alex
--
.w( the_mindstorm )p.


> Dierk
>
> > -----Original Message-----
> > From: Alexandru Popescu [mailto:[hidden email]]
> > Sent: Donnerstag, 18. Januar 2007 0:21
> > To: [hidden email]
> > Subject: Re: [groovy-dev] @Groovy advance
> >
> >
> > On 1/18/07, Jochen Theodorou <[hidden email]> wrote:
> > > Alexandru Popescu schrieb:
> > > > Hi!
> > > >
> > > > Firstly I would like to summarize here the long discussion I had with
> > > > Jochen on annotation support.
> > >
> > > it would be good to just post the diffs. They are more readable than a
> > > complete ACG.
> > >
> >
> > Frankly speaking i don't think a unified patch format would have
> > really been more readable.
> >
> > > > 1. Parser + AST status
> > > >
> > > > The parser does not support yet array attributes. I have checked the
> > > > groovy.g grammar and found some commented definition in there.
> > > > Considering that arrays are quite used in annotations we will
> > > > definitely need to fix this.
> > >
> > > I think we can really go and uses our lists here and do the
> > > transformation statically with the need to have a list of constants.
> > >
> > > [...]
> > > > - added an option named target to CompilerConfiguration
> > > > (this will allow specifying on command line, Ant task, etc if the
> > > > bytecode is intended to run on a different VM then the current one.
> > > > The accepted values are: 1.4 and 1.5. Currently, it default to the
> > > > current executing VM).
> > >
> > > what is missing is initialization through property in the secound
> > > constructor. Since we already have targetDirectory I think that target
> > > alone is a bit too short. I suggest targetBytecode. And I suggest to not
> > > to limit that to pre and post 1.4 only. We may have to face 1.6 in the
> > > future, too.
> > >
> >
> > Agreed. But now we just have 1.4 and 1.5 as options. And I like
> > keeping things simple :-).
> >
> > > [...]
> > > > - improved support for generating the bytecode for annotated elements
> > > > in ACG. There are a couple of remaining things to be solved here:
> > > > - writting enum attributes (this must be firstly solved in the
> > > > verifier as both class type attributes and enum type attributes are
> > > > reported as PropertyExpressions)
> > >
> > > what do we need to resolve here?
> > >
> >
> > An attribute with the type Class is returned as a PropertyExpression
> > where the object is the (I forgot what) and .class is a
> > ConstantExpression.
> > This needs to be addressed and reported as a ClassExpression or
> > something like this.
> >
> > > [...]
> > > > The 2nd attachment contains a set of 3 annotations I am using for
> > > > testing and a set of 3 groovy scripts.
> > >
> > > hmm... right, never thought about how we do test that stuff... We can
> > > not have annotation based classes in a java4 build... hmmm
> > >
> >
> > Considering that the build must remain on JDK1.4, then there will be
> > no way to include tests in the build. Probably an option would be to
> > have to separate set of tests one running against VM1.4 and other
> > running against VM1.5 if it is available.
> >
> > > > Last, but not least: I would really appreciate if somebody can check
> > > > the code and check it in, as it is quite difficult for me to keep up
> > > > with the SVN changes and continue to work on those sources (I already
> > > > got 2 conflicts that I have to fix before submitting :( ). As I
> > > > already mentioned the submitted code has no impact on the current
> > > > execution of the existing groovy scripts. Unfortunately, when running
> > > > the groovy:test target I am getting 2 Failures (from further
> > > > investigation these are in SecurityTest and SignedJarTest but I am
> > > > quite sure they are not generated by my changes).
> > >
> > > well I would agree, but it would be good to test it on a fresh checkout
> > > first. This needs to be fixed.
> > >
> >
> > In fact it was tested agaist the latest SVN trunk version (in fact a
> > couple of hours old, this made me solve a couple of conflicts :-( ).
> >
> > BR,
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> > > bye blackdrag
> > >
> > > --
> > > Jochen "blackdrag" Theodorou
> > > Groovy Tech Lead (http://groovy.codehaus.org)
> > > http://blackdragsview.blogspot.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: @Groovy advance

Dierk König
And if we run the build on Java 5, what tests do we have then?

Dierk

> -----Original Message-----
> From: Alexandru Popescu [mailto:[hidden email]]
> Sent: Donnerstag, 18. Januar 2007 10:43
> To: [hidden email]
> Subject: Re: [groovy-dev] @Groovy advance
>
>
> On 1/18/07, Dierk Koenig <[hidden email]> wrote:
> > What kind of tests will we have for the Annotation support?
> >
>
> As I already said in my previous message:
>
> [quote]
> Considering that the build must remain on JDK1.4, then there will be
> no way to include tests in the build. Probably an option would be to
> have two separate set of tests one running against VM1.4 and other
> running against VM1.5 if it is available.
> [/quote]
>
> Except that I don't see any other solutions (at least solution that
> will not require to hack for weeks :-) ).
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
> > Dierk
> >
> > > -----Original Message-----
> > > From: Alexandru Popescu [mailto:[hidden email]]
> > > Sent: Donnerstag, 18. Januar 2007 0:21
> > > To: [hidden email]
> > > Subject: Re: [groovy-dev] @Groovy advance
> > >
> > >
> > > On 1/18/07, Jochen Theodorou <[hidden email]> wrote:
> > > > Alexandru Popescu schrieb:
> > > > > Hi!
> > > > >
> > > > > Firstly I would like to summarize here the long
> discussion I had with
> > > > > Jochen on annotation support.
> > > >
> > > > it would be good to just post the diffs. They are more
> readable than a
> > > > complete ACG.
> > > >
> > >
> > > Frankly speaking i don't think a unified patch format would have
> > > really been more readable.
> > >
> > > > > 1. Parser + AST status
> > > > >
> > > > > The parser does not support yet array attributes. I have
> checked the
> > > > > groovy.g grammar and found some commented definition in there.
> > > > > Considering that arrays are quite used in annotations we will
> > > > > definitely need to fix this.
> > > >
> > > > I think we can really go and uses our lists here and do the
> > > > transformation statically with the need to have a list of constants.
> > > >
> > > > [...]
> > > > > - added an option named target to CompilerConfiguration
> > > > > (this will allow specifying on command line, Ant task, etc if the
> > > > > bytecode is intended to run on a different VM then the
> current one.
> > > > > The accepted values are: 1.4 and 1.5. Currently, it default to the
> > > > > current executing VM).
> > > >
> > > > what is missing is initialization through property in the secound
> > > > constructor. Since we already have targetDirectory I think
> that target
> > > > alone is a bit too short. I suggest targetBytecode. And I
> suggest to not
> > > > to limit that to pre and post 1.4 only. We may have to face
> 1.6 in the
> > > > future, too.
> > > >
> > >
> > > Agreed. But now we just have 1.4 and 1.5 as options. And I like
> > > keeping things simple :-).
> > >
> > > > [...]
> > > > > - improved support for generating the bytecode for
> annotated elements
> > > > > in ACG. There are a couple of remaining things to be solved here:
> > > > > - writting enum attributes (this must be firstly solved in the
> > > > > verifier as both class type attributes and enum type
> attributes are
> > > > > reported as PropertyExpressions)
> > > >
> > > > what do we need to resolve here?
> > > >
> > >
> > > An attribute with the type Class is returned as a PropertyExpression
> > > where the object is the (I forgot what) and .class is a
> > > ConstantExpression.
> > > This needs to be addressed and reported as a ClassExpression or
> > > something like this.
> > >
> > > > [...]
> > > > > The 2nd attachment contains a set of 3 annotations I am using for
> > > > > testing and a set of 3 groovy scripts.
> > > >
> > > > hmm... right, never thought about how we do test that
> stuff... We can
> > > > not have annotation based classes in a java4 build... hmmm
> > > >
> > >
> > > Considering that the build must remain on JDK1.4, then there will be
> > > no way to include tests in the build. Probably an option would be to
> > > have to separate set of tests one running against VM1.4 and other
> > > running against VM1.5 if it is available.
> > >
> > > > > Last, but not least: I would really appreciate if
> somebody can check
> > > > > the code and check it in, as it is quite difficult for me
> to keep up
> > > > > with the SVN changes and continue to work on those
> sources (I already
> > > > > got 2 conflicts that I have to fix before submitting :( ). As I
> > > > > already mentioned the submitted code has no impact on the current
> > > > > execution of the existing groovy scripts. Unfortunately,
> when running
> > > > > the groovy:test target I am getting 2 Failures (from further
> > > > > investigation these are in SecurityTest and SignedJarTest but I am
> > > > > quite sure they are not generated by my changes).
> > > >
> > > > well I would agree, but it would be good to test it on a
> fresh checkout
> > > > first. This needs to be fixed.
> > > >
> > >
> > > In fact it was tested agaist the latest SVN trunk version (in fact a
> > > couple of hours old, this made me solve a couple of conflicts :-( ).
> > >
> > > BR,
> > >
> > > ./alex
> > > --
> > > .w( the_mindstorm )p.
> > >
> > > > bye blackdrag
> > > >
> > > > --
> > > > Jochen "blackdrag" Theodorou
> > > > Groovy Tech Lead (http://groovy.codehaus.org)
> > > > http://blackdragsview.blogspot.com/
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >     http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: @Groovy advance

Alex Popescu
On 1/18/07, Dierk Koenig <[hidden email]> wrote:
> And if we run the build on Java 5, what tests do we have then?
>

I am not very good at predicting the future :-), but I can create a
set of scripts with different annotation types and assertion about
accessing them through JDK5 annotation reflection API. However,
currently I just wrote a couple of simple scripts that are helping me
with the my work on this.

./alex
--
.w( the_mindstorm )p.

> Dierk
>
> > -----Original Message-----
> > From: Alexandru Popescu [mailto:[hidden email]]
> > Sent: Donnerstag, 18. Januar 2007 10:43
> > To: [hidden email]
> > Subject: Re: [groovy-dev] @Groovy advance
> >
> >
> > On 1/18/07, Dierk Koenig <[hidden email]> wrote:
> > > What kind of tests will we have for the Annotation support?
> > >
> >
> > As I already said in my previous message:
> >
> > [quote]
> > Considering that the build must remain on JDK1.4, then there will be
> > no way to include tests in the build. Probably an option would be to
> > have two separate set of tests one running against VM1.4 and other
> > running against VM1.5 if it is available.
> > [/quote]
> >
> > Except that I don't see any other solutions (at least solution that
> > will not require to hack for weeks :-) ).
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >
> > > Dierk
> > >
> > > > -----Original Message-----
> > > > From: Alexandru Popescu [mailto:[hidden email]]
> > > > Sent: Donnerstag, 18. Januar 2007 0:21
> > > > To: [hidden email]
> > > > Subject: Re: [groovy-dev] @Groovy advance
> > > >
> > > >
> > > > On 1/18/07, Jochen Theodorou <[hidden email]> wrote:
> > > > > Alexandru Popescu schrieb:
> > > > > > Hi!
> > > > > >
> > > > > > Firstly I would like to summarize here the long
> > discussion I had with
> > > > > > Jochen on annotation support.
> > > > >
> > > > > it would be good to just post the diffs. They are more
> > readable than a
> > > > > complete ACG.
> > > > >
> > > >
> > > > Frankly speaking i don't think a unified patch format would have
> > > > really been more readable.
> > > >
> > > > > > 1. Parser + AST status
> > > > > >
> > > > > > The parser does not support yet array attributes. I have
> > checked the
> > > > > > groovy.g grammar and found some commented definition in there.
> > > > > > Considering that arrays are quite used in annotations we will
> > > > > > definitely need to fix this.
> > > > >
> > > > > I think we can really go and uses our lists here and do the
> > > > > transformation statically with the need to have a list of constants.
> > > > >
> > > > > [...]
> > > > > > - added an option named target to CompilerConfiguration
> > > > > > (this will allow specifying on command line, Ant task, etc if the
> > > > > > bytecode is intended to run on a different VM then the
> > current one.
> > > > > > The accepted values are: 1.4 and 1.5. Currently, it default to the
> > > > > > current executing VM).
> > > > >
> > > > > what is missing is initialization through property in the secound
> > > > > constructor. Since we already have targetDirectory I think
> > that target
> > > > > alone is a bit too short. I suggest targetBytecode. And I
> > suggest to not
> > > > > to limit that to pre and post 1.4 only. We may have to face
> > 1.6 in the
> > > > > future, too.
> > > > >
> > > >
> > > > Agreed. But now we just have 1.4 and 1.5 as options. And I like
> > > > keeping things simple :-).
> > > >
> > > > > [...]
> > > > > > - improved support for generating the bytecode for
> > annotated elements
> > > > > > in ACG. There are a couple of remaining things to be solved here:
> > > > > > - writting enum attributes (this must be firstly solved in the
> > > > > > verifier as both class type attributes and enum type
> > attributes are
> > > > > > reported as PropertyExpressions)
> > > > >
> > > > > what do we need to resolve here?
> > > > >
> > > >
> > > > An attribute with the type Class is returned as a PropertyExpression
> > > > where the object is the (I forgot what) and .class is a
> > > > ConstantExpression.
> > > > This needs to be addressed and reported as a ClassExpression or
> > > > something like this.
> > > >
> > > > > [...]
> > > > > > The 2nd attachment contains a set of 3 annotations I am using for
> > > > > > testing and a set of 3 groovy scripts.
> > > > >
> > > > > hmm... right, never thought about how we do test that
> > stuff... We can
> > > > > not have annotation based classes in a java4 build... hmmm
> > > > >
> > > >
> > > > Considering that the build must remain on JDK1.4, then there will be
> > > > no way to include tests in the build. Probably an option would be to
> > > > have to separate set of tests one running against VM1.4 and other
> > > > running against VM1.5 if it is available.
> > > >
> > > > > > Last, but not least: I would really appreciate if
> > somebody can check
> > > > > > the code and check it in, as it is quite difficult for me
> > to keep up
> > > > > > with the SVN changes and continue to work on those
> > sources (I already
> > > > > > got 2 conflicts that I have to fix before submitting :( ). As I
> > > > > > already mentioned the submitted code has no impact on the current
> > > > > > execution of the existing groovy scripts. Unfortunately,
> > when running
> > > > > > the groovy:test target I am getting 2 Failures (from further
> > > > > > investigation these are in SecurityTest and SignedJarTest but I am
> > > > > > quite sure they are not generated by my changes).
> > > > >
> > > > > well I would agree, but it would be good to test it on a
> > fresh checkout
> > > > > first. This needs to be fixed.
> > > > >
> > > >
> > > > In fact it was tested agaist the latest SVN trunk version (in fact a
> > > > couple of hours old, this made me solve a couple of conflicts :-( ).
> > > >
> > > > BR,
> > > >
> > > > ./alex
> > > > --
> > > > .w( the_mindstorm )p.
> > > >
> > > > > bye blackdrag
> > > > >
> > > > > --
> > > > > Jochen "blackdrag" Theodorou
> > > > > Groovy Tech Lead (http://groovy.codehaus.org)
> > > > > http://blackdragsview.blogspot.com/
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list please visit:
> > > > >
> > > > >     http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: @Groovy advance

Dierk König
> .. but I can create a
> set of scripts with different annotation types and assertion about
> accessing them through JDK5 annotation reflection API.

Thanks, that'd be much appreciated.
Sorry for pestering but for me that's a crucial part of the contribution.

ciao
Dierk

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: @Groovy advance

Alex Popescu
On 1/18/07, Dierk Koenig <[hidden email]> wrote:
> > .. but I can create a
> > set of scripts with different annotation types and assertion about
> > accessing them through JDK5 annotation reflection API.
>
> Thanks, that'd be much appreciated.
> Sorry for pestering but for me that's a crucial part of the contribution.
>

Np. For me too. As you can see in my initial email from this thread I
have already included a draft of these. And without knowing if these
tests would be really usefull and used in the end, I wouldn't spend
more time on it (I love clean code, I like having tests, but I hate
wasting time and effort :-) )

BR,

./alex
--
.w( the_mindstorm )p.
 ___________________________________
  Alexandru Popescu, OSS Evangelist
TestNG/AspectJ/WebWork/Struts2/more...
  Information Queue ~ www.InfoQ.com



> ciao
> Dierk
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

12