commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [classscan] organization
Date Tue, 05 Jun 2012 16:00:31 GMT
I think Matt is talking about introducing a SPI concept.

On Tue, Jun 5, 2012 at 11:17 AM, Honton, Charles
<Charles_Honton@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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message