Hi all,
I'm thinking of committing this patch. There's a test which kind of covers this issue. Not completly but enough I guess. It's a complicated issue, so the test is complicated as well :) There are two ways to prepare this test, it's just a matter of taste. 1: Let Ant compile 2 files and delete the one which is an dependency for the other. [+] You still have the sourcecode available [-] You have call ant on resources:testResources. There will be some magic in the target/test-classes, since the inputfile was a build.xml, output only 1 source.class 2: Commit the generated class in the test-resouces folder [+] No magic going on, straightforward [-] Loss of sourcecode another option is of course to skip the test. Any thoughts? Robert > Date: Tue, 24 Feb 2009 14:14:19 -0600 > From: [email protected] > To: [email protected] > Subject: [qdox-dev] [jira] Commented: (QDOX-148) Allow to disable usage of > "default" class loaders > > > [ > http://jira.codehaus.org/browse/QDOX-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166913#action_166913 > ] > > Benjamin Bentmann commented on QDOX-148: > ---------------------------------------- > > Looks good to me :-) > > > Allow to disable usage of "default" class loaders > > ------------------------------------------------- > > > > Key: QDOX-148 > > URL: http://jira.codehaus.org/browse/QDOX-148 > > Project: QDox > > Issue Type: New Feature > > Components: Parser > > Affects Versions: 1.6.1 > > Reporter: Benjamin Bentmann > > Attachments: qdox-148.1.patch, qdox-148.patch, qdox-148.patch > > > > > > Both available constructors of {{JavaDocBuilder}} will eventually call > > {code:java} > > classLibrary.addDefaultLoader(); > > {code} > > As far as I see, there is currently no way to disable/remove these default > > loaders. > > This is problematic when the code using QDox and the code being analyzed > > depend on the same class file (but possibly a different version). Imagine a > > project with an annotated source file S that extends a class C from a > > third-party JAR. Further imagine a build tool that employs QDox to scan the > > previously mentioned source file S. When the scan walks up to the super > > class C of S, QDox ends up in {{ClassLibrary.getClass()}} and iterates over > > the class loaders to load the class C from its binary. Now imagine the > > build tool itself also depends on this binary class C and the build tool's > > class loader was used to create the {{JavaDocBuilder}} instance used for > > the scan. In this scenario, QDox will load C from the dependencies of the > > build tool instead of the dependencies of the project whose sources are > > actually scanned. In other words, the class path of the QDox client > > pollutes the analysis. > > Possible solutions could be a additional constructors for > > {{JavaDocBuilder}} to disable addition of the default class loaders or a > > new method {{clearClassLoaders()}} in {{ClassLibrary}}. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://jira.codehaus.org/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
