You can do that as well, but the more steps required to get a compiler person to look at the problem, the less likely it will get looked at. Think of it this way: whoever looks into it is going to need to set up an Eclipse Debug Configuration.
The simplest thing for one of the compiler folks is to supply a two or three file zip with an ant script that launches mxmlc against one file with source-paths pointing to other files in other folders in that zip. Thanks, -Alex On 10/20/14, 4:05 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >I was already thinking of creating a falcon branch in which I would add >Flexmojos projects that repoduce some of the problems. Would that be ok? > >Chris > >________________________________________ >Von: Alex Harui <aha...@adobe.com> >Gesendet: Montag, 20. Oktober 2014 06:42 >An: dev@flex.apache.org >Betreff: Re: AW: AW: AW: Some Falcon problems with multiple source-paths. > >If you can put together a simple test case it will make it easier for >someone to look at. > >-Alex > >On 10/19/14, 11:51 AM, "Christofer Dutz" <christofer.d...@c-ware.de> >wrote: > >>Ok so I did a little more testing. >> >>To me it seems as if there were currently some troubles with multiple >>source paths as in my builds all those compilations are failling in which >>there are multiple source paths: >> >>- Module without tests, but with generated sources (src/main/flex and >>target/generated-sources/flexmojos) >>- Module with tests (src/main/flex and src/test/flex) >> >>In case of the modules with tests, the main code compiles niceley, but >>when compiling the tests it seems that classes of one source can't >>reference those of the other. >> >>Chris >> >>-----Ursprüngliche Nachricht----- >>Von: Alex Harui [mailto:aha...@adobe.com] >>Gesendet: Montag, 13. Oktober 2014 17:05 >>An: dev@flex.apache.org >>Betreff: Re: AW: AW: Some Falcon problems with multiple source-paths. >> >> >> >>On 10/13/14, 1:47 AM, "Christofer Dutz" <christofer.d...@c-ware.de> >>wrote: >> >>> >>>In the Flexicious code some Interfaces are annotated with a "Bindable" >>>metadata (At Interface Level) ... compiling such an interface causes >>>NPEs in Falcon (IntelliJ even suggests that this line could throw NPEs) >>>cause in case of a Bindable Interface the class property is never set. >>>I think we should catch this and add a Warning instead. >>IMO, we should do whatever MXMLC did. Maybe Gordon will take on trying >>to make the Flexicious DG work. >> >>> >>>I also get some strange OperandStackUnderflowProblem error without any >>>explanation when compiling these libs. >>Usually, these are a result of unexpected AST patterns and can be ignored >>until we think we are handling the reduction properly. >> >>-Alex >> >
