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 15:17:02 GMT
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" <gudnabrsam@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_Honton@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: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
>>
>
>---------------------------------------------------------------------
>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