Indeed, but I missed your point about sources (time to go to bed) and thought that you wanted to duplicate sources. But then it looks good already, isn't it? Or I again missed what embarrasses you in the current solution?
On Thu, Jan 9, 2014 at 11:16 PM, Mirko Friedenhagen <mfriedenha...@gmail.com > wrote: > Hello Evgeny, > > that is very unmavenly ;-). I have a prototype at > https://github.com/mfriedenhagen/org.jacoco.filteringsamples. > Regards Mirko > -- > http://illegalstateexception.blogspot.com/ > https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) > https://bitbucket.org/mfriedenhagen/ > > > On Thu, Jan 9, 2014 at 10:35 PM, Evgeny Mandrikov <mandri...@gmail.com> > wrote: > > Hi, > > > > I have feeling that you ( "we" :) ) could simply use single module and > > define several executions of: > > > > maven-compiler-plugin for compilation > > maven-assembly-plugin to create JARs and attach them as additional > project > > artifacts > > > > But I never tried this. > > > > On Thu, Jan 9, 2014 at 10:13 PM, Mirko Friedenhagen > > <mfriedenha...@gmail.com> wrote: > >> > >> Hello, > >> > >> in the JaCoCo project (a Java code coverage library which uses a Java > >> agent approach during runtime) we produce some false positives of > >> uncovered code because of unreachable (e.g. private constructor of a > >> util class) or synthetic java code (e.g. enum values()). > >> > >> As we inspect the class files only, we may not (or better do not want > >> to) rely on parsing the source code for discovering such conditions. > >> During some experiments we detected that different compilers (javac vs > >> eclipse ecj) produce very different byte code in classes for the > >> above. This might be the case for different versions of Sun/Oracle JDK > >> or JDKs of other vendors as well. I already took a look at "Using > >> Non-Javac Compilers" of the maven-compiler-plugin[1] > >> > >> Now my question: > >> - What would be the best approach to produce JARs which contain class > >> files of above mentioned false positives produced by the different > >> compilers? > >> - My first idea was to define a define a multi module project with a > >> JAR module which will only produce a source jar, which will be > >> unpacked as "generated-sources" in sibling modules which are then > >> compiled by the different compilers. > >> > >> For additional ideas or caveats I would be grateful. > >> > >> > >> Regards Mirko > >> [0] https://github.com/jacoco/jacoco/wiki/FilteringOptions > >> [1] > >> > http://maven.apache.org/plugins/maven-compiler-plugin/non-javac-compilers.html > >> -- > >> http://illegalstateexception.blogspot.com/ > >> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) > >> https://bitbucket.org/mfriedenhagen/ > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "JaCoCo Developers" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to jacoco-dev+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > -- > > Best regards, > > Evgeny Mandrikov aka Godin <http://godin.net.ru> > > http://twitter.com/_godin_ > > > > -- > > You received this message because you are subscribed to the Google Groups > > "JaCoCo Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to jacoco-dev+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups > "JaCoCo Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jacoco-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Best regards, Evgeny Mandrikov aka Godin <http://godin.net.ru> http://twitter.com/_godin_
