Hi! Yes, I wrote all that stuff myself, and on github is only a CLONE and no one else committed or contributed to it so far :)
So I'm perfectly free to push this as my very own contribution to any ASF repo at whatever time _without_ a need to do incubation or whatever. But in any case, we will need to review/rework that stuff anyway as there is a new requirement which I became aware recently: We need to provide class scanning on a per-ClassLoader level. Many frameworks (EJB, CDI, ...) need to take care about Class visibility and might even have to deal with 'shared-contexts'. Thus the commons-classscan as well as xbean-finder must be aware of the ClassLoader hierarchy. Especially in multi-webapp environments this might (as side effect) also bring a pretty neat performance improvement as we don't need to scan those shared class paths redundantly! But I need to think about that stuff a bit longer and hack some prototypes in OWB for example. LieGrue, strub >________________________________ > From: Matt Benson <gudnabr...@gmail.com> >To: Commons Developers List <dev@commons.apache.org> >Sent: Wednesday, April 11, 2012 7:57 PM >Subject: Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for >class path scanning / class metadata > >Actually, on this subject, I was able to establish on the >legal-discuss ML recently that code authored entirely by an existing >committer, even if it has been "exposed" on e.g. github, needs no >formal SG to be incorporated into an ASF codebase. Sorry for having >pushed for this in the case of [meiyo], but the point is that Mark >Struberg is after all free to add his >https://github.com/struberg/Apache-commons-classscanner code to >[classscan]. This will give us a little more to discuss wrt merging >its and [meiyo]'s features. As I recall, Mark was having trouble >logging into the Moin wiki, which is where I had hoped we could >establish a concrete set of goals. We could potentially do this in >JIRA instead. > >Matt > >On Wed, Apr 11, 2012 at 11:35 AM, James Carman ><ja...@carmanconsulting.com> wrote: >> The problem is that they might not have that luxury (using APT). The >> specification (in the case of EJBs) says that classpath scanning must >> be supported. >> >> On Wed, Apr 11, 2012 at 12:13 PM, Honton, Charles >> <charles_hon...@intuit.com> wrote: >>> Simo, >>> >>> How much time is too long? One minute? One second? Ten seconds? >>> >>> Thanks, >>> chas >>> >>> -----Original Message----- >>> From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf >>> Of Simone Tripodi >>> Sent: Wednesday, April 11, 2012 12:17 AM >>> To: Commons Developers List >>> Subject: Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for >>> class path scanning / class metadata >>> >>> Same here, as main Meiyo contributor I'm of course interested, but no >>> available cycles ATM, hopefully during the weekend :( >>> >>> Anyway, just to speak about it, I am changing my mind about classpath >>> scanning, that - even only when bootstrapping, of course - is a time >>> consuming operation. >>> I'd invite you on thinking about an AnnotationProcessor that at >>> compile-time generates the SPI META-INF/services files for >>> @EJB/@Entity annotated classes - bootstrap would be of course faster! >>> >>> all the best, have a nice day! >>> -Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://simonetripodi.livejournal.com/ >>> http://twitter.com/simonetripodi >>> http://www.99soft.org/ >>> >>> >>> >>> On Tue, Apr 10, 2012 at 12:20 AM, James Carman >>> <ja...@carmanconsulting.com> wrote: >>>> I am interested. I do want to keep it as simple as possible to set up >>>> and retrieve the information. I haven't had a chance to take a look >>>> at your stuff, yet, though. Perhaps I can get a few cycles this week. >>>> >>>> On Mon, Apr 9, 2012 at 5:29 PM, Honton, Charles >>>> <charles_hon...@intuit.com> wrote: >>>>> There's been sporadic talk on this newsgroup since September 2010 about >>>>> providing a commons component which can scan a classpath and provide >>>>> metadata about the classes. I have a clean (license-wsie) concrete >>>>> interface and implementation to share. This code will support the >>>>> following use cases: >>>>> >>>>> 1. An ioc container used during unit testing that replaces the full-blown >>>>> EJB container. The ioc container will auto-stitch the @Stateless unit >>>>> under test with default @EJB implementations available from the >>>>> classpath. The container allows replacement of default implementations >>>>> with specific mocks. Framework needs to find @EJB interfaces and >>>>> implementations available from jars in classpath. >>>>> >>>>> 2. Augment a code container to implement a domain event pub/sub >>>>> framework. Auto-stitch the subscribers that want specific events to the >>>>> publication of events. Framework needs to find implementations available >>>>> to ear. >>>>> >>>>> 3. A JPA implementation must find all classes marked with @Entity within >>>>> the same jar that contains a META-INF/persistence.xml file. >>>>> >>>>> Anyone still interested in supporting classpath / introspection features? >>>>> >>>>> Implementation available for download from >>>>> <https://github.com/chonton/meiyo-sandbox> >>>>> http://github.com/chonton/meiyo-sandbox >>>>> >>>>> Reports viewable at http://chonton.github.com/meiyo-sandbox/ >>>>> >>>>> Regards, >>>>> chas >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
