commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [classscan] organization
Date Tue, 05 Jun 2012 14:26:35 GMT
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.


On Mon, Jun 4, 2012 at 10:47 PM, Honton, Charles
<> 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 []
> Sent: Sunday, June 03, 2012 8:40 AM
> To:
> 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:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message