Hi Simo! I think we need to meet somewhere in the middle anyway.
My code is most times pretty much targeted at a certain problem. Thus making it sometimes hard to extend later. The meiyo interfaces I looked at are otoh so generic that they could probably also serve as RFC-2324 HTCPCP/1.0 implementation - just kidding ;) Nah serious, a few Ideas from Meyio (e.g. the Callback for the Filter) are really cool and we should incorporate them into classscan. A few other interfaces are imo a bit too generic. The hardest nut will most probably be the design of the Filter. The requirements are: 1.) performance 2.) exclude/include logic for packages 3.) must be able to collect different things for different classcan-clients 4.) perform the scan only once (should we allow lazy scanning?) Some classscan-clients maybe first need to read some config files for getting exclude/include info. I imagine to set the 'heavy granular' criterias like * what to collect (class info, annotations on classes, annotations on fields, annotations on methods) * which archives to collect upfront. The rest might get filtered via callbacks in a tree like manner. E.g. if a Filter from one classcan-client returns that it doesnt need this package, then we don't need to invoke this classcan-client until we are finished processing. LieGrue, strub PS: the moinmoin wiki really su***s. It refuses to send me a register/pwd_recovery mail :( Will dump this info into the wiki once I get access. --- On Wed, 7/27/11, Simone Tripodi <simonetrip...@apache.org> wrote: > From: Simone Tripodi <simonetrip...@apache.org> > Subject: Re: [sandbox] [classscan] classscan API design review needed > To: "Commons Developers List" <dev@commons.apache.org>, gudnabr...@gmail.com > Date: Wednesday, July 27, 2011, 7:44 PM > Hi Jakob, > I'm worried I was not able to explain my ideas well; my > intentions are > not proposing to modify how classscan behaves, but rather > how it > looks! > Having an expression language rather than a configuration > based on n > parameters is IMHO still a valid contribution that the > existing > sandbox component could bring in the new one. > +1 to Matt's idea, I'll start adding my contributions as > soon as possible. > Have a nice day, all the best!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Jul 27, 2011 at 7:13 PM, Matt Benson <gudnabr...@gmail.com> > wrote: > > http://wiki.apache.org/commons/classscan > > > > On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr <jakob.korh...@gmail.com> > wrote: > >> +1 > >> > >> Regards, > >> Jakob > >> > >> 2011/7/27 Matt Benson <gudnabr...@gmail.com>: > >>> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr > <jakob.korh...@gmail.com> > wrote: > >>>> Hi Mark, Simone, > >>>> > >>>> I would prefer a way in which the > classscan-clients can tell the > >>>> classscan-server in what they are > interested in via an API like Mark > >>>> proposed (e.g. subscribe()) before the > scanning of a specific artifact > >>>> (e.g. jar) starts. I guess this could be > kinda like the > >>>> ProcessAnnotatedType API in CDI. For > example, the classscan-server > >>>> discovers a jar, then asks all its clients > if the jar should be > >>>> scanned (--> clients can perform checks > for beans.xml or > >>>> faces-config.xml) and if at least one > client says yes, it will be > >>>> scanned. Then the classscan-server knows > exactly which > >>>> jars/wars/packages/... need to be scanned > and which don't (thus > >>>> improving performance). Then while > scanning, the classscan-server > >>>> calls the specific callback methods only > on the subscribed > >>>> classscan-clients. > >>>> > >>>> Regards, > >>>> Jakob > >>> > >>> Hi, Jakob-- > >>> I know that retaining the ability to select > particular classpath > >>> elements (or in xbean-finder terms, Archives) > for scanning by a > >>> particular client is one of Mark's top > priorities, so this is > >>> definitely on the table. Maybe we should > start a page in the Commons > >>> wiki to enumerate all the desired features and > hopefully a comfortable > >>> set of APIs will start to gel. > >>> > >>> Matt > >>> > >>>> > >>>> 2011/7/27 Simone Tripodi <simonetrip...@apache.org>: > >>>>> Hi Mark!!! > >>>>> after had a (quick, honestly) look at > your APIs I'm more convinced we > >>>>> can merge our efforts to provide our > users a kickass library to scan > >>>>> the classpath. > >>>>> > >>>>> Your ScanJob class could be configured > with my Meiyo EDSL filters[1] > >>>>> instead of passing parameters to the > constructor, allowing users > >>>>> expressing more complex ScanJob > settings, like excluding/including > >>>>> classes under specific packages > annotated whit specific annotations > >>>>> that implement interface X etc etc > etc > >>>>> I have the feel that while you focused > on performances, I was more > >>>>> focused on end users APIs, it would be > a shame if we do not > >>>>> cooperate!!! > >>>>> > >>>>> WDYT? Hope there will be the chance to > release yet another great > >>>>> commons tool soon!!! > >>>>> All the best, > >>>>> Simo > >>>>> > >>>>> [1] http://s.apache.org/Vsb > >>>>> > >>>>> http://people.apache.org/~simonetripodi/ > >>>>> http://www.99soft.org/ > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Jul 26, 2011 at 11:19 PM, Mark > Struberg <strub...@yahoo.de> > wrote: > >>>>>> Hi folks! > >>>>>> > >>>>>> We need a few idea and > brainstorming on the filter/selection mechanism for our new > classscan-api (yes, 3 's' in classscan). > >>>>>> > >>>>>> There are some specs which require > some marker files to actually enable the class scanning. > E.g. the JSR-299 CDI spec defines that only jars with > META-INF/beans.xml get scanned. For JSR-314 (JSF2) you need > to have a META-INF/faces-config.xml marker file present. > >>>>>> Other frameworks don't have such a > restriction, but most do. > >>>>>> > >>>>>> There are 2 ways to handle this: > >>>>>> 1.) each classscan-client tells > the classscan-server the list of marker files it needs. > >>>>>> 2.) The classscan-client registers > a Filter callback (similar to Simos mechanism) and the > classcan-server calls a 'scanningJarStarted(...)' and > scanningJarEnded (bet we find some better name which also > would fit in OSGi environments) and the Filter can call some > veto() or subscribe() to the classscan-server. > >>>>>> > >>>>>> We also need some way to include + > exclude packages from the scanning. Any idea on the API is > welcome. The current ScanJob class (see my github [1]) which > was supposed to be an upfront information doesn't work out > in the end I fear. But maybe it's a starting point for our > discussion. > >>>>>> > >>>>>> > >>>>>> txs and LieGrue, > >>>>>> strub > >>>>>> > >>>>>> [1] > >>>>>> https://github.com/struberg/Apache-commons-classscanner/blob/b45c1b6080e91f6e36f7b7a39aa1b2c4d7bde1e0/classscan-api/src/main/java/org/apache/commons/classscan/api/ScanJob.java > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> 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 > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Jakob Korherr > >>>> > >>>> blog: http://www.jakobk.com > >>>> twitter: http://twitter.com/jakobkorherr > >>>> work: http://www.irian.at > >>>> > >>>> > --------------------------------------------------------------------- > >>>> 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 > >>> > >>> > >> > >> > >> > >> -- > >> Jakob Korherr > >> > >> blog: http://www.jakobk.com > >> twitter: http://twitter.com/jakobkorherr > >> work: http://www.irian.at > >> > >> > --------------------------------------------------------------------- > >> 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
