[
https://issues.apache.org/jira/browse/GROOVY-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles resolved GROOVY-3714.
---------------------------------
Resolution: Fixed
see GROOVY-10300
> "groovy" command line program doesn't resolve inner classes properly when
> they're in another file
> -------------------------------------------------------------------------------------------------
>
> Key: GROOVY-3714
> URL: https://issues.apache.org/jira/browse/GROOVY-3714
> Project: Groovy
> Issue Type: Sub-task
> Components: command line processing
> Affects Versions: 1.7-beta-1
> Reporter: Martin C. Martin
> Assignee: Eric Milles
> Priority: Major
>
> Martin C. Martin schrieb:
> > Foo.groovy:
> >
> > class Foo {
> > static class Bar {
> > static float yum = 3.5
> > }
> > }
> >
> > Test.groovy:
> >
> > println Foo.Bar.yum
> >
> > > rm Foo*class Test*class
> >
> > > groovy Test
> hmm... in one file it works... uh oh... I get a bad feeling... I think it is
> because ResolveVisitor finds Foo to be a class and then queues Foo, but
> wrongly assumes that it is done then. So Test.groovy is completed before
> Foo.groovy is parsed, meaning Foo will be recognized as class, but Foo.Bar
> will not.
> > > groovyc Test
> >
> > > groovy Test
> >
> > 3.5
> "groovy Test" does not run the class file, it runs the groovy file. That
> means it is equal to compiling Foo.groovy and then compiling Test.groovy. If
> you had given both files to the compiler, this would also work.
> [...]
> > JIRA?
> yes, but I wonder how to resolve the issue. Because if I am right we have a
> problem here. Normal compilation as done with eclipse or groovyc should not
> be affected, since you there compiler usually all files and not let the
> compiler pick them up.
> I could of course say, that if a file is picked up, we have to resolve the
> file again, but that would probably very bad for performance. Hmm.. or not,
> if the cache is kept... the caches saves misses as well... we only would have
> to go through all of the AST again and potentially remove noClass entries for
> Foo.Bar. Or I save the path and stop the compiler there, to let it continue
> later... only that this is a functionality that does exist only in my fantasy
> yet... I miss continuations here somehow ;)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
