I'd like to wait until we have use cases that require reorganization. I suspect that we're not going to want to replace BCEL with asm, but we might need to support additional URL types. (I'm sure we're going to need to support the JBoss vfs URLs) Plugging in URL providers may be smaller than a multi-module project.
Regards, chas -----Original Message----- From: Matt Benson [mailto:gudnabr...@gmail.com] Sent: Sunday, June 03, 2012 8:40 AM To: dev@commons.apache.org Subject: [classscan] organization I propose that we, in the immediate future, reorganize [classscan] into multiple modules. I fully expect that by the time we get everyone's input/features/alternative implementations for X/Y/Z in place, we will want the flexibility. I am fine with starting small, e.g. core/bcel modules, although I would expect that bcel might eventually be moved beneath another division of "scanners" or the like. The technical hurdle to doing this is that MetaRegistry currently references oacc.bcel.Cache, mapping it to its SINGLETON reference. I don't see that this is necessary; I would prefer that the bcel module provide an entry in META-INF/services. It's not even necessary that we upgrade to Java 6 for this; Java 6 users can use ServiceLoader while those using Java 5 can use whatever workalike option they prefer or instantiate the MetaRegistry implementation directly. In any case core should not depend on a particular scanning package/module. I don't JFDI because (a) I don't have time just at the moment, and (b) I like consensus. Thoughts? Matt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
