@AnnotationCollector does not work in Eclipse?!?

classic Classic list List threaded Threaded
22 messages Options
123
Reply | Threaded
Open this post in threaded view
|

@AnnotationCollector does not work in Eclipse?!?

ocs@ocs
Hello there,

anyone please have an idea why AnnotationCollector does not work for me in Eclipse? My source at the moment (removed lots of stuff to isolate the problem) looks like this:

===
package app
import cz.ocs.app.*

import groovy.transform.*
import groovy.util.logging.*
//@TypeChecked(extensions='TypeChecker.groovy')
//@InheritConstructors
@Log4j
@AnnotationCollector
@interface OCStandard {}

@OCStandard class Application /*extends OCSApplication*/ {
    static def applicationName='Test'
    static def applicationVersion=0.56
}
===

and it consistently fails with an error

===
Groovy:class app.OCStandard is not an annotation in @app.OCStandard Application.groovy /Test/Sources/app line 12 Java Problem
===

What am I missing?!? Outside of Eclipse with just groovyc the very same source is compiled without the slightest glitch. Am using Groovy 2.1, Groovy-Eclipse 2.8.0.

Thanks for any help!
OC


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: @AnnotationCollector does not work in Eclipse?!?

Jochen Theodorou
Am 14.02.2013 00:07, schrieb OC:
[...]
> ===
> Groovy:class app.OCStandard is not an annotation in @app.OCStandard Application.groovy /Test/Sources/app line 12 Java Problem
> ===

that is clearly a jdt message

> What am I missing?!? Outside of Eclipse with just groovyc the very
> same source is compiled without the slightest glitch. Am using Groovy
> 2.1, Groovy-Eclipse 2.8.0.

maybe greclipse needs special support for this and that is not yet in there.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: @AnnotationCollector does not work in Eclipse?!?

ocs@ocs
Jochen,

On Feb 14, 2013, at 7:34 AM, Jochen Theodorou wrote:

> Am 14.02.2013 00:07, schrieb OC:
> [...]
>> ===
>> Groovy:class app.OCStandard is not an annotation in @app.OCStandard Application.groovy /Test/Sources/app line 12 Java Problem
>> ===
>
> that is clearly a jdt message
>
>> What am I missing?!? Outside of Eclipse with just groovyc the very
>> same source is compiled without the slightest glitch. Am using Groovy
>> 2.1, Groovy-Eclipse 2.8.0.
>
> maybe greclipse needs special support for this and that is not yet in there.


Well thanks, but isn't Groovy 2.1 just, well, Groovy 2.1, so to speak? Darn, those differences between standalone and integrated compiler cost me more time than I spend on development which I'm paid for :( Why on earth greclipse can't simply call groovyc for builds, so as it is fully consistent?!? This approach is crazy :(

(And you would want to bring even _more_ inconsistencies by letting the IDE to do typecheking!)

Is there anybody (Andrew?) who understands the thing and can confirm whether it is so or whether I am making some kind of error at my side (aside of using the Eclipse thing at all, which I do bitterly regret all the time, but alas due to need of WebObjects plugins have no choice)?

And, in case the problem indeed happens to be that greclipse lacks some kind of special support needed, can you please perhaps guesstimate when -- if at all -- the support might occur in there?

Thanks a lot and all the best,
---
Ondra Čada
OCSoftware:     [hidden email]               http://www.ocs.cz
private         [hidden email]             http://www.ocs.cz/oc




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Type checking extensions don't work in Eclipse either?!? (was: @AnnotationCollector does not work in Eclipse?!?)

ocs@ocs
In reply to this post by ocs@ocs
Hello there,

it just gets curiouser and curiouser. Since I can't use AnnotationCollector, I'm setting up the annotations directly, like this:

===
@TypeChecked(extensions='TypeChecker.groovy')
class Application extends OCSApplication {
...
===

That, though, gives me the following error:

===
Groovy:Static type checking extension 'TypeChecker.groovy' was not found on the classpath. Application.groovy /CEBOIS/Sources/app line 0 Java Problem
===

Well I've found the culprit -- since I'm using lots of global AST transforms, I've looked around compile-time, and it looks like whilst the _transform's_ classpath is all right (it does contain whatever I've set up in the project's Build Path, among others also the TypeChecker script), the _source unit's_ classpath is completely empty.

If I add the JAR to sourceUnit.classLoader's classpath in my transform (INITIALIZATION phase), it works -- that is, the type extension script is later loaded all right. Nevertheless, it immediately crashes, for I log from it, too, and it throws classnotfound for Logger.

Then I've tried to copy the complete classpath from the transform's classloader to the source unit's one, but that did not help either -- looks like in Eclipse, the type checker runs the extension script with just another classpath, different from those two above, and (probably) again empty.

(By the way, I suspected the empty source unit classpath might be the culprit of the "class is not an annotation" problem with the AnnotationCollector. It is not -- at least, even after I fix the source unit classpath, this problem does not go away.)

Back to the typechecker extension script: I've tried to fix that by essentially removing the logger (declared it 'def' -- not 'Logger' -- and instead of creating new one I'd share it with one of my transforms), which sort of helped... in the sense the script does not crash on unknown Logger class on its creation anymore.

Instead I'm getting a ClassCastException -- see details below (*). This problem I did not succeed to solve.

It's a proper mess of galactic proportions :(

Note also please that this applies _for Eclipse builds only_ -- if I use the stand-alone groovyc, all works excellently without a glitch and without a need of all that stuff. It would be so much better if Eclipse simply called groovyc instead of doing it all in a different and completely messy way :( But Eclipse being the complete piece of c... it is, I strongly suspect for some reason it would not work either... :(

Oh, by the way: when I change the type checking script and embed it into the JAR all right and launch a new build in Eclipse (which uses new transform code all right, I'm logging out among others the build time to be completely sure), the change of the script _is not seen_ in Eclipse! The script which gets loaded into typechecker is the _old_ one. Have to quit and re-launch Eclipse to get the new one. Mad as hatter, the darned thing :-O Reminds me of the problem with reading manifest with the list of transforms, would be probably related...

Anyway -- does anybody out there see a way to fix the problems? Am I really the only one who uses Eclipse and would like to exploit things like type checking extensions or annotation collectors? Or do they work properly for others and are the problems caused here by something in WOLips plugins, which are the very reason I use Eclipse at all -- so as I can build WebObjects applications? There's nothing else in my Eclipse: just WOLips and greclipse...

All the best,
---
Ondra Čada
OCSoftware:     [hidden email]               http://www.ocs.cz
private         [hidden email]             http://www.ocs.cz/oc

(*)

Description Resource Path Location Type
General error during instruction selection: Script1 cannot be cast to org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport$TypeCheckingDSL

java.lang.ClassCastException: Script1 cannot be cast to org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport$TypeCheckingDSL
        at org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.setup(GroovyTypeCheckingExtensionSupport.java:121)
        at org.codehaus.groovy.transform.stc.DefaultTypeCheckingExtension.setup(DefaultTypeCheckingExtension.java:147)
        at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.initialize(StaticTypeCheckingVisitor.java:131)
        at org.codehaus.groovy.transform.StaticTypesTransformation.visit(StaticTypesTransformation.java:58)
        at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
        at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
        at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1200)
        at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:632)
        at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:610)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:587)
        at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
        at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
        at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
        at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
        at java.lang.Thread.run(Thread.java:680)
        Fopper.groovy /CEBOIS/Sources/others line 0 Java Problem




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: @AnnotationCollector does not work in Eclipse?!?

Jochen Theodorou
In reply to this post by ocs@ocs
Am 14.02.2013 00:07, schrieb OC:

> Hello there,
>
> anyone please have an idea why AnnotationCollector does not work for
> me in Eclipse? My source at the moment (removed lots of stuff to isolate
> the problem) looks like this:
>
> ===
> package app
> import cz.ocs.app.*
>
> import groovy.transform.*
> import groovy.util.logging.*
> //@TypeChecked(extensions='TypeChecker.groovy')
> //@InheritConstructors
> @Log4j
> @AnnotationCollector
> @interface OCStandard {}
>
> @OCStandard class Application /*extends OCSApplication*/ {
>      static def applicationName='Test'
>      static def applicationVersion=0.56
> }
> ===
>
> and it consistently fails with an error
>
> === Groovy:class app.OCStandard is not an annotation in
> @app.OCStandard  Application.groovy /Test/Sources/app line 12 Java Problem
> ===

I need to change my last mail. I think greclipse is not to blame here,
but eclipse kind of:
http://stackoverflow.com/questions/11800237/annotations-are-not-working-in-groovy-classes
"""
Looks like you have your project/workspace configured for Java 1.4 or
earlier. Annotations are not being recognized since the source level
doesn't allow them.

Go to Project -> Properties -> Java Compiler. Enable project settings
and set the compliance level to 1.5 or later.
"""

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Type checking extensions don't work in Eclipse either?!?

Jochen Theodorou
In reply to this post by ocs@ocs
Am 14.02.2013 12:17, schrieb Ondřej Čada:

> Hello there,
>
> it just gets curiouser and curiouser. Since I can't use
> AnnotationCollector, I'm setting up the annotations directly, like
> this:
>
> === @TypeChecked(extensions='TypeChecker.groovy') class Application
> extends OCSApplication { ... ===
>
> That, though, gives me the following error:
>
> === Groovy:Static type checking extension 'TypeChecker.groovy' was
> not found on the classpath. Application.groovy /CEBOIS/Sources/app
> line 0 Java Problem ===
>
> Well I've found the culprit -- since I'm using lots of global AST
> transforms, I've looked around compile-time, and it looks like whilst
> the _transform's_ classpath is all right (it does contain whatever
> I've set up in the project's Build Path, among others also the
> TypeChecker script), the _source unit's_ classpath is completely
> empty.

Looking at the work we did yesterday for
http://jira.codehaus.org/browse/GROOVY-5994 I think that you are in the
same trap. The script should have been loaded by the transform loader,
which is not the case before this fix

[...]
> (By the way, I suspected the empty source unit classpath might be the
> culprit of the "class is not an annotation" problem with the
> AnnotationCollector. It is not -- at least, even after I fix the
> source unit classpath, this problem does not go away.)

I think not, see my other mail.

[...]
> Instead I'm getting a ClassCastException -- see details below (*).
> This problem I did not succeed to solve.
>
> It's a proper mess of galactic proportions :(

That's Java class loaders for you ;) If you have the loader L1 and L2
and both load A.class directly, then A from L1 is different from A from
L2. I call it the class duplication problem. Now, let us call the
transform loader TL, the loader for the compiler itself CL and the
source unit class loader SL. Then CL needs to be a parent of TL and SL.
If not, you will have for example GroovyObject being duplicated and the
compiler can get confused. SL does not have to be set at all actually,
as long as a ClassNodeResolver is given, which  greclipse imho does.
GroovyScriptEngine is another user of this, but that only as a side note.

> Note also please that this applies _for Eclipse builds only_ -- if I
> use the stand-alone groovyc, all works excellently without a glitch
> and without a need of all that stuff. It would be so much better if
> Eclipse simply called groovyc instead of doing it all in a different
> and completely messy way :( But Eclipse being the complete piece of
> c... it is, I strongly suspect for some reason it would not work
> either... :(

groovyc from command line and ant use SL.is(TL).. well I should say they
use a null TL, which means SL is used as fallback. gradle for example
uses the transform loader which is to be thanked for finding the
problem. Oh here I need to especially thank Peter Niederwieser for
helping me finding out the reason behind all this (that means Cedric and
me spend almost 3, Peter about 1 hour yesterday in fixing only the setup
for the class loader usage). There will be a new release tomorrow, maybe
you can then replace the groovy version used by greclipse and see if
this problem goes away?

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Type checking extensions don't work in Eclipse either?!?

Jochen Theodorou
Am 14.02.2013 15:02, schrieb Jochen Theodorou:
> There will be a new release tomorrow, maybe
> you can then replace the groovy version used by greclipse and see if
> this problem goes away?

actually you will have to wait for a new greclipse version I am afraid

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: @AnnotationCollector does not work in Eclipse?!?

ocs@ocs
In reply to this post by Jochen Theodorou
Jochen,

On Feb 14, 2013, at 2:38 PM, Jochen Theodorou wrote:

>> === Groovy:class app.OCStandard is not an annotation in
>> @app.OCStandard  Application.groovy /Test/Sources/app line 12 Java Problem
>> ===
>
> I need to change my last mail. I think greclipse is not to blame here, but eclipse kind of:
> http://stackoverflow.com/questions/11800237/annotations-are-not-working-in-groovy-classes
> """
> Looks like you have your project/workspace configured for Java 1.4 or earlier. Annotations are not being recognized since the source level doesn't allow them.
>
> Go to Project -> Properties -> Java Compiler. Enable project settings and set the compliance level to 1.5 or later.
> """


Thanks! Alas, it is not the culprit: the compliance and both .class/source compatibility are (a) set to default not project-level, (b) the value is 1.6.

Thanks and all the best,
---
Ondra Čada
OCSoftware:     [hidden email]               http://www.ocs.cz
private         [hidden email]             http://www.ocs.cz/oc




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Type checking extensions don't work in Eclipse either?!?

ocs@ocs
In reply to this post by Jochen Theodorou
Jochen,

On Feb 14, 2013, at 3:02 PM, Jochen Theodorou wrote:

> ... Looking at the work we did yesterday for http://jira.codehaus.org/browse/GROOVY-5994 I think that you are in the same trap. ...

Indeed!

>> ... It's a proper mess of galactic proportions :(
>
> That's Java class loaders for you ;) ...

Fascinating. If only those people in Sun did not think they can do better and simply used the ObjC object runtime (which they knew well, for they co-operated with NeXT in eigties!) instead of inventing the swarms of deathtraps...

> ... There will be a new release tomorrow, maybe you can then replace the groovy version used by greclipse and see if this problem goes away? ...

Would be just great -- if greclipse just called groovyc and thus one could simply switch the versions. Alas, far as I can say, it's hard-wired in there, and thus:

> actually you will have to wait for a new greclipse version I am afraid

:(

Oh, sigh.

Well at least it looks like the problem does not seem to be at my side.

Thank you very much for the excellent work and all the help,
---
Ondra Čada
OCSoftware:     [hidden email]               http://www.ocs.cz
private         [hidden email]             http://www.ocs.cz/oc




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Type checking extensions don't work in Eclipse either?!? (was: @AnnotationCollector does not work in Eclipse?!?)

Andrew Eisenberg
In reply to this post by ocs@ocs
Groovy-Eclipse does not support either type checker extensions or
AnnotationCollectors.  Groovy-Eclipse uses groovyc under the hood, but
the path to get there is different than when calling it on the command
line.  The reason for this difference is that Eclipse needs to support
multiple kinds of compilations: full builds, incremental builds, and
reconciles (ie- mini-compiles as you type).  Groovyc only supports the
first mode.  Furthermore, inside of Eclipse the artifacts generated by
compiles are more than just class files.  There is an internal model
of the project, and various caches that are populated, again not
something supported by Groovyc.

The basic architecture is that we call individual phases of groovyc
alongside compiler phases of the JDT compiler so that state is built
up for both languages at the same time.

We just haven't had the opportunity to work on type checkers and
annotation collectors yet.

On Thu, Feb 14, 2013 at 3:17 AM, Ondřej Čada <[hidden email]> wrote:

> Hello there,
>
> it just gets curiouser and curiouser. Since I can't use AnnotationCollector, I'm setting up the annotations directly, like this:
>
> ===
> @TypeChecked(extensions='TypeChecker.groovy')
> class Application extends OCSApplication {
> ...
> ===
>
> That, though, gives me the following error:
>
> ===
> Groovy:Static type checking extension 'TypeChecker.groovy' was not found on the classpath.      Application.groovy      /CEBOIS/Sources/app     line 0  Java Problem
> ===
>
> Well I've found the culprit -- since I'm using lots of global AST transforms, I've looked around compile-time, and it looks like whilst the _transform's_ classpath is all right (it does contain whatever I've set up in the project's Build Path, among others also the TypeChecker script), the _source unit's_ classpath is completely empty.
>
> If I add the JAR to sourceUnit.classLoader's classpath in my transform (INITIALIZATION phase), it works -- that is, the type extension script is later loaded all right. Nevertheless, it immediately crashes, for I log from it, too, and it throws classnotfound for Logger.
>
> Then I've tried to copy the complete classpath from the transform's classloader to the source unit's one, but that did not help either -- looks like in Eclipse, the type checker runs the extension script with just another classpath, different from those two above, and (probably) again empty.
>
> (By the way, I suspected the empty source unit classpath might be the culprit of the "class is not an annotation" problem with the AnnotationCollector. It is not -- at least, even after I fix the source unit classpath, this problem does not go away.)
>
> Back to the typechecker extension script: I've tried to fix that by essentially removing the logger (declared it 'def' -- not 'Logger' -- and instead of creating new one I'd share it with one of my transforms), which sort of helped... in the sense the script does not crash on unknown Logger class on its creation anymore.
>
> Instead I'm getting a ClassCastException -- see details below (*). This problem I did not succeed to solve.
>
> It's a proper mess of galactic proportions :(
>
> Note also please that this applies _for Eclipse builds only_ -- if I use the stand-alone groovyc, all works excellently without a glitch and without a need of all that stuff. It would be so much better if Eclipse simply called groovyc instead of doing it all in a different and completely messy way :( But Eclipse being the complete piece of c... it is, I strongly suspect for some reason it would not work either... :(
>
> Oh, by the way: when I change the type checking script and embed it into the JAR all right and launch a new build in Eclipse (which uses new transform code all right, I'm logging out among others the build time to be completely sure), the change of the script _is not seen_ in Eclipse! The script which gets loaded into typechecker is the _old_ one. Have to quit and re-launch Eclipse to get the new one. Mad as hatter, the darned thing :-O Reminds me of the problem with reading manifest with the list of transforms, would be probably related...
>
> Anyway -- does anybody out there see a way to fix the problems? Am I really the only one who uses Eclipse and would like to exploit things like type checking extensions or annotation collectors? Or do they work properly for others and are the problems caused here by something in WOLips plugins, which are the very reason I use Eclipse at all -- so as I can build WebObjects applications? There's nothing else in my Eclipse: just WOLips and greclipse...
>
> All the best,
> ---
> Ondra Čada
> OCSoftware:     [hidden email]               http://www.ocs.cz
> private         [hidden email]             http://www.ocs.cz/oc
>
> (*)
>
> Description     Resource        Path    Location        Type
> General error during instruction selection: Script1 cannot be cast to org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport$TypeCheckingDSL
>
> java.lang.ClassCastException: Script1 cannot be cast to org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport$TypeCheckingDSL
>         at org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.setup(GroovyTypeCheckingExtensionSupport.java:121)
>         at org.codehaus.groovy.transform.stc.DefaultTypeCheckingExtension.setup(DefaultTypeCheckingExtension.java:147)
>         at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.initialize(StaticTypeCheckingVisitor.java:131)
>         at org.codehaus.groovy.transform.StaticTypesTransformation.visit(StaticTypesTransformation.java:58)
>         at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:147)
>         at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:220)
>         at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1200)
>         at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:632)
>         at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:610)
>         at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:587)
>         at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
>         at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1555)
>         at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:838)
>         at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
>         at java.lang.Thread.run(Thread.java:680)
>         Fopper.groovy   /CEBOIS/Sources/others  line 0  Java Problem
>
>
>
>
> ---------------------------------------------------------------------
> 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


123