I think Matt is talking about introducing a SPI concept. On Tue, Jun 5, 2012 at 11:17 AM, Honton, Charles <charles_hon...@intuit.com>wrote:
> 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 > >
