commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [classscan] organization
Date Sun, 03 Jun 2012 18:55:26 GMT
Hi, Matt!

I second Gary on that, there are enough preconditions to forget Java5
and focus on Java6 only.

You also have my +1 on supporting the SPI pattern on that!

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sun, Jun 3, 2012 at 6:29 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> On Jun 3, 2012, at 11:40, Matt Benson <gudnabrsam@gmail.com> wrote:
>
>> 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?
>
> Forget java 5 and use 6.
>
> Gary
>
>>
>> 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


Mime
View raw message