Matt, What particular approaches do you have in mind?
How is xbean-finder going to be plugged in? Is classscan to be dependent upon xbean-finder or vice versa? What functionality will be required from the dependency? Thanks, chas On 6/5/12 7:26 AM, "Matt Benson" <gudnabr...@gmail.com> wrote: >I would still say that time is now. We are going to want to support >different approaches to interacting with the class scanning library, >some of which may not be mutually compatible. We are going to want to >be able to plug in Geronimo's xbean-finder and see how it performs, >etc. We have so many interested participants that IMO we really need >the flexibility of multiple modules. > >Matt > >On Mon, Jun 4, 2012 at 10:47 PM, Honton, Charles ><charles_hon...@intuit.com> wrote: >> 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 >> > >--------------------------------------------------------------------- >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
