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
