commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honton, Charles" <Charles_Hon...@intuit.com>
Subject RE: [classscan] organization
Date Tue, 05 Jun 2012 03:47:38 GMT
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:gudnabrsam@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message