Can't generate aspect sources due lexical error

[Roland Kofler]

Welcome to Spring Roo. For assistance press CTRL+SPACE or type "hint" then hit ENTER.
roo> Lexical error at line 18, column 39.  Encountered: "\u2013" (8211), after : ""

This happens only on my Windows7 machine, not on my Linux Ubuntu. How can I track down the responsible file?
Searching for hypen '–' which seems to be \u2013 with eclipse file search doesn't help.

At least one person has the same problem: http://stackoverflow.com/questions/9...670646_9247502

[Chanoch]

Actually \u2013 is en-dash rather than hypen. Sometimes if I have this problem I search and replace from hyphen to hyphen and this seems to help. It sounds like there may be a hyphen in your HTML type documents - for example in javascript? If there's a piece of java trying to interpret this, the problem would be that the \ isn't escaped?

When you say that searching didn't work - did you search for hyphen or for \u2013? And why didn't it help? Because you found nothing or because you found too many references?

[Roland Kofler]

Thanks, will check this later when I get to my windows machine.
It didn't help because i found some hypens in JS comments and substitution had no effect on the error. Searched for both \u.... and hyphen.
I'll try again with your information, but since I grabbed my search char from a utf-8 description page with the \u... number, I expect no positive result.
Good to know that you solved the problem for you.

a shimmer of hope.

[Chanoch]

Sure - there's always the possibility that this is a roo bug/feature in that it is treating your JS or HTML as Java somehow and therefore requiring escaping of the \ character. I'm wondering whether there is a built in assumption in Roo that members are generally XML, properties files or java code and so it's looking for the \ to be escaped?

In your shoes if I couldn't get any further, I would be tempted to write a quick parser that looks for the \ character at column 39 in any text based file (.xml, jpsx, .java, .itd, etc etc) and see whether it narrows down the problem area. (I don't trust line numbers but that could be a 'fuzzy' factor in the search)

[Roland Kofler]

Solved the mystery. In one of the tests i was so lazy to declare a german constant with 'umlaute': ö is the culprit not en-dash.
So the parser for aspect generation reads this and can't cope with it. It's a bug IMHO, especially I hate the fact that the exception can't tell which sequence of characters is surounding the culprit. That would really kill debugging time.
Interestingly on Linux no problems.

[Chanoch]

That sounds like an interesting problem - I take it that this was something like the following?

public class GermanClass {
public static String NAME_WITH_ö_IN_IT = "SOMEVALUE";

etc etc...

I'll try and reproduce this

chanoch