You did convinced me this need an different approach, you just didn't convinced me that the suggested one is the right one :P
I need to think more about this problem. On Mon, Jul 26, 2010 at 9:45 PM, Jesse Sightler <[email protected]>wrote: > Hi VELO, > > Issue created: > https://issues.sonatype.org/browse/FLEXMOJOS-334 > > <https://issues.sonatype.org/browse/FLEXMOJOS-334>I have also implemented > a patch with the below solution. Would it be possible to integrate this > into the main distribution? > > It would help our team out quite a bit. Let me know if there's anything > further that needs to be done here. > > Thanks, > Jess > > > On Mon, Jul 26, 2010 at 5:38 PM, Marvin Froeder <[email protected]> wrote: > >> Well, all set, now is just a matter of writing a jira ticket and wait for >> someone willing to fix it. >> >> VELO >> >> On Mon, Jul 26, 2010 at 5:35 PM, Jesse Sightler <[email protected] >> > wrote: >> >>> >>> >>> On Mon, Jul 26, 2010 at 3:57 PM, Marvin Froeder <[email protected]>wrote: >>> >>>> >>>> >>>> On Mon, Jul 26, 2010 at 4:42 PM, Jesse Sightler < >>>> [email protected]> wrote: >>>> >>>>> On Mon, Jul 26, 2010 at 3:38 PM, Marvin Froeder <[email protected]>wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Jul 26, 2010 at 4:25 PM, Jesse Sightler < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Yes, I can see where this could get complicated (parsing link >>>>>>> reports). Perhaps an workaround would be to give the user the option to >>>>>>> only compile classes directly referenced by TestRunner (and the test >>>>>>> cases >>>>>>> associated with it)? >>>>>>> >>>>>>> When done this way, I could add a reference to "new App()" in one of >>>>>>> my test cases, and the Flex compiler would figure out the rest. >>>>>>> >>>>>> >>>>>> The problem letting flex compiler dealing with the problem is the >>>>>> coverage report would be unreliable.... it will give you 100% of class >>>>>> coverage every time.... even if you have ZERO tests. >>>>>> >>>>> >>>>> I'm not sure why that would be the case. Assuming that the entire swf >>>>> is instrumented, and that the instrumentation knows how many class files >>>>> are >>>>> in the SWF (and thus a correct line count), then only the lines actually >>>>> run >>>>> would be shown as covered. >>>>> >>>>> If I placed the "new App()" line in a method that is never called (a >>>>> common way to force inclusion without actually executing the codepath), >>>>> then >>>>> the swf should include all relevant classes, but only the lines actually >>>>> run >>>>> by my test case(s) would be excersized. >>>>> >>>> >>>> The key word here is IF, if you add..... this manual actions users tend >>>> to forget. >>>> >>> >>> I agree with that risk assesment. I believe that it could be adequately >>> addressed by leaving the default to the current configuration. For simple >>> projects where there are no includes or other non-compilable files, the >>> default behaviour insures solid accuracy (as intended). >>> >>> But for the case where people need to dig through the documentation and >>> turn it off (often large projects, with lots of team members), the option >>> would be here to provide something which is currently not possible. >>> >>> Honestly, I wish our codebase weren't in a shape that requires a feature >>> like this, but I suspect I am not the only person who would benefit greatly >>> from this enhancement. >>> >>> Thanks, >>> Jess >>> >>> >>> >>> >>>> >>>> >>>>> >>>>> Then, the report should be correct, based upon the actual classes in >>>>> the SWF. >>>>> >>>>> Or am I missing something about the way in which apparat calculates >>>>> line count? Ie, why should the apparat report include lines that are >>>>> never >>>>> executed at all because of this change? >>>>> >>>>> Thanks, >>>>> Jess >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> It would not help with some of the scenarios that you mention (as it >>>>>>> would not include unused classes), but it would be perfect for our >>>>>>> environment (and I suspect quite a few others as well). >>>>>>> >>>>>>> Obviously, parsing the link-report is an option as well, but that >>>>>>> looks more difficult. >>>>>>> >>>>>>> Thanks, >>>>>>> Jess >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 26, 2010 at 2:41 PM, Marvin Froeder <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 26, 2010 at 3:26 PM, Jesse Sightler < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi VELO, >>>>>>>>> >>>>>>>>> I have attached a sample of why I think this solution is unworkable >>>>>>>>> for a large number of projects out there. >>>>>>>>> >>>>>>>>> The key point in the sample (so that you don't have to open it to >>>>>>>>> understand the problem) is that it contains a class file with an AS3 >>>>>>>>> include >>>>>>>>> directive. Ie, the structure is as follows: >>>>>>>>> >>>>>>>>> - src/main/flex >>>>>>>>> - App.as (uses an "include" to bring in sampleInclude.as) >>>>>>>>> - sampleInclude.as >>>>>>>>> >>>>>>>>> With the packaging set to swf, and the sourceFile set to App.as, >>>>>>>>> the "compile" operation performs correctly. However, "test" attempts >>>>>>>>> to >>>>>>>>> compile both App.as and sampleInclude.as separately. This fails, as >>>>>>>>> sampleInclude.as is only intended to be included in other files (never >>>>>>>>> compiled by itself directly). >>>>>>>>> >>>>>>>>> The merits of this design (include files) are certainly debatable, >>>>>>>>> but as I don't always win such debates ( ;) ), I would prefer that >>>>>>>>> the tool >>>>>>>>> be able to deal with this, and similar scenarios involving files >>>>>>>>> within >>>>>>>>> source control that are not compilable as well. >>>>>>>>> >>>>>>>>> Perhaps there could be an option to have it only compile the same >>>>>>>>> source files that are compiled as part of the normal SWF generation? >>>>>>>>> That >>>>>>>>> would solve the problem for me. The coverage would also accurately >>>>>>>>> reflect >>>>>>>>> the statistics that I am interested in (ie, coverage of classes that >>>>>>>>> are >>>>>>>>> actually compiled into the swf). I can understand your view as well, >>>>>>>>> though, so perhaps this has to be optional. >>>>>>>>> >>>>>>>> That is the ideal fix, but the question at hand is, how? Do you know >>>>>>>> anyway way to determine that (one that doesn't demand parsing link >>>>>>>> reports).... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Are there any other workarounds that we can use at this point? >>>>>>>>> >>>>>>>> >>>>>>>> No, not at the moment, but well, you can download the source, >>>>>>>> comment out the include section until something fancy came up. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Again, thanks for your response, >>>>>>>>> Jess >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jul 26, 2010 at 12:57 PM, Marvin Froeder <velo.br@ >>>>>>>>> gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Coverage does need to include all src/main/flex classes into the >>>>>>>>>> test SWF in order to produce reliable test results. Otherwise it >>>>>>>>>> will >>>>>>>>>> always reports 100% of classes coverage. >>>>>>>>>> There is no other way to deal with that right now, but I'm open >>>>>>>>>> for suggestions. >>>>>>>>>> >>>>>>>>>> Anyway, if you know that classes are broken, why don't you remove >>>>>>>>>> they from src/main/flex or at least name they as .txt, .old or >>>>>>>>>> something >>>>>>>>>> else?! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> VELO >>>>>>>>>> >>>>>>>>>> On Mon, Jul 26, 2010 at 1:21 PM, jsight < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> I am attempting to run test classes and coverage reports on a >>>>>>>>>>> fairly >>>>>>>>>>> large SWF project. The project compiles perfectly as long as >>>>>>>>>>> there >>>>>>>>>>> are no tests. >>>>>>>>>>> >>>>>>>>>>> If I include test classes in src/test/flex, the build of the >>>>>>>>>>> actual >>>>>>>>>>> app fails. >>>>>>>>>>> >>>>>>>>>>> All of the errors are on classes that would not normally be >>>>>>>>>>> included >>>>>>>>>>> in the SWF itself. I cannot seem to control which classes from >>>>>>>>>>> src/ >>>>>>>>>>> main get compiled. >>>>>>>>>>> >>>>>>>>>>> Is there a way to have it select the same classes as would >>>>>>>>>>> normally be >>>>>>>>>>> compiled without tests? >>>>>>>>>>> >>>>>>>>>>> The SWF compiles perfectly if the test files are not included at >>>>>>>>>>> all, >>>>>>>>>>> and it compiles ok before getting to the test phase of execution >>>>>>>>>>> as >>>>>>>>>>> well. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google >>>>>>>>>>> Groups "Flex Mojos" group. >>>>>>>>>>> To post to this group, send email to [email protected] >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> [email protected]<flex-mojos%[email protected]> >>>>>>>>>>> For more options, visit this group at >>>>>>>>>>> http://groups.google.com/group/flex-mojos >>>>>>>>>>> >>>>>>>>>>> http://flexmojos.sonatype.org/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>>> Groups "Flex Mojos" group. >>>>>>>>>> To post to this group, send email to [email protected] >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> [email protected]<flex-mojos%[email protected]> >>>>>>>>>> For more options, visit this group at >>>>>>>>>> http://groups.google.com/group/flex-mojos >>>>>>>>>> >>>>>>>>>> http://flexmojos.sonatype.org/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the >>>>>>>> Google >>>>>>>> Groups "Flex Mojos" group. >>>>>>>> To post to this group, send email to [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected]<flex-mojos%[email protected]> >>>>>>>> For more options, visit this group at >>>>>>>> http://groups.google.com/group/flex-mojos >>>>>>>> >>>>>>>> http://flexmojos.sonatype.org/ >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Flex Mojos" group. >>>>>>> To post to this group, send email to [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected]<flex-mojos%[email protected]> >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/flex-mojos >>>>>>> >>>>>>> http://flexmojos.sonatype.org/ >>>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Flex Mojos" group. >>>>>> To post to this group, send email to [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected]<flex-mojos%[email protected]> >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/flex-mojos >>>>>> >>>>>> http://flexmojos.sonatype.org/ >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Flex Mojos" group. >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected]<flex-mojos%[email protected]> >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/flex-mojos >>>>> >>>>> http://flexmojos.sonatype.org/ >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Flex Mojos" group. >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected]<flex-mojos%[email protected]> >>>> For more options, visit this group at >>>> http://groups.google.com/group/flex-mojos >>>> >>>> http://flexmojos.sonatype.org/ >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Flex Mojos" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected]<flex-mojos%[email protected]> >>> For more options, visit this group at >>> http://groups.google.com/group/flex-mojos >>> >>> http://flexmojos.sonatype.org/ >>> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Flex Mojos" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected]<flex-mojos%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/flex-mojos >> >> http://flexmojos.sonatype.org/ >> > > -- > You received this message because you are subscribed to the Google > Groups "Flex Mojos" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<flex-mojos%[email protected]> > For more options, visit this group at > http://groups.google.com/group/flex-mojos > > http://flexmojos.sonatype.org/ > -- You received this message because you are subscribed to the Google Groups "Flex Mojos" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/flex-mojos http://flexmojos.sonatype.org/
