On Mar 24, 2011, at 12:22 PM, Mark Struberg wrote: > I'd like to cook up something for a JSR, but need some more time. > David wrote xbean-finder and we could easily move this to commons or extract > it into a single jar in geronimo.
It's already a single jar with just the org.apache.xbean.finder code. But I'm open to whatever. > But first things first: will start with the owb-1.1.0 release now ;) Thanks for that btw! I really like all the recent work. And I meant to say "thanks" for cloning that static related jira. Perfect use of that feature. On that static note, I was amazed at how much static code we still had after eliminating 95% of what showed up in the tests in the build and then in the standalone part of the TCK. I didn't get around to the Web Profile part of the TCK. But it seems either we need to write some more tests or delete some more code :) I'm sure it will be some of both. -David > --- On Thu, 3/24/11, Sven Linstaedt <[email protected]> wrote: > >> From: Sven Linstaedt <[email protected]> >> Subject: Re: Classpath Scanner proposal >> To: "[email protected]" <[email protected]> >> Date: Thursday, March 24, 2011, 7:09 PM >> Hi Mark, >> >> that sounds absolutely reasonable. I am just interested in >> the state of progress. Afaik xbean-finder is not a project, >> but rather a single class of some Apache project, is not it? >> So there are no plans any more to introduce this kind of >> service via JSR? >> >> Regards out of the train >> >> Sven >> >> -- sent by phone >> >> Am 21.03.2011 um 18:42 schrieb Mark Struberg <[email protected]>: >> >>> Hi Sven! >>> >>> Yea, I'm aiming for something like that. The major >> benefit would be that we do not trash our ClassLoader with >> all the reflection stuff only needed for the initial class >> scanning. This is currently eating up lots of PermGenSpace. >> >>> >>> Btw, the reflections project is based on the original >> scannotation code from Bill Burke, so we aint that far away >> ;) >>> We are also looking for probably moving it over to >> xbean-finder which David wrote for OpenEJB and is now also >> being used in geronimo and a few other apache projects. But >> we'll do that after 1.1.0 ;) >>> >>> txs and LieGrue, >>> strub >>> >>> --- On Mon, 3/21/11, Sven Linstaedt <[email protected]> >> wrote: >>> >>>> From: Sven Linstaedt <[email protected]> >>>> Subject: Re: Classpath Scanner proposal >>>> To: [email protected] >>>> Date: Monday, March 21, 2011, 5:35 PM >>>> Another interesting use case would >>>> look like using some kind of >>>> pre-generated scanning information created during >>>> build-time. >>>> >>>> Artifacts are in general considered final after >> creation, >>>> so scans done at >>>> runtime will return the same result. This result >> could be >>>> generated during >>>> build-time and inlined into the artifact in a >> serialized >>>> form, which in turn >>>> in used during runtime to further speed up scan >> jobs. [1] >>>> is doing something >>>> similar by providing a maven plugin. >>>> >>>> br, Sven >>>> >>>> >>>> [1] http://code.google.com/p/reflections/ >>>> >>>> >>>> 2011/2/27 Mark Struberg <[email protected]> >>>> >>>>> I think it should be enough if the >> classscanner >>>> implementation itself >>>>> shades any such 3rd party jar into a inner >>>> dependency. >>>>> My main focus currently is to design the API >> flexible >>>> enough to allow all >>>>> necessary use cases to work. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> --- On Sun, 2/27/11, Jan-Kees van Andel <[email protected]> >>>> wrote: >>>>> >>>>>> From: Jan-Kees van Andel <[email protected]> >>>>>> Subject: Re: Classpath Scanner proposal >>>>>> To: [email protected], >>>> [email protected] >>>>>> Date: Sunday, February 27, 2011, 1:35 PM >>>>>> +1, although I think Jar hell is a >>>>>> real issue. Think about libraries like >>>>>> cglib, asm or commons-*** and the pain >> they >>>> sometimes >>>>>> cause. >>>>>> >>>>>> But we can easily work around it, for >> example by >>>> packaging >>>>>> all >>>>>> using-frameworks as uber-jars and >> renaming >>>>>> the "org.apache.commons.classscan" >> packages to >>>> something >>>>>> like >>>> "org.apache.myfaces.org.apache.commons.classscan" >>>>>> and >>>> >> "org.apache.webbeans.org.apache.commons.classscan". >>>>>> This way we prevent >>>>>> any future versioning issues that >> libraries like >>>> cglib and >>>>>> asm currently >>>>>> have. >>>>>> >>>>>> Regards, >>>>>> Jan-Kees >>>>>> >>>>>> >>>>>> 2011/2/27 Mark Struberg <[email protected]> >>>>>> >>>>>>> Hi Jan-Kees! >>>>>>> >>>>>>> Txs for this info! >>>>>>> >>>>>>> Of course, I think the downside of >> getting >>>> another >>>>>> dependency to myfaces >>>>>>> would highly be outvalued by the >> benefit >>>> we'd gain >>>>>> from it :) >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> --- On Sun, 2/27/11, Jan-Kees van >> Andel >>>> <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>>> From: Jan-Kees van Andel <[email protected]> >>>>>>>> Subject: Re: Classpath Scanner >>>> proposal >>>>>>>> To: [email protected], >>>>>> [email protected], >>>>>> "Mark >>>>>>> Struberg" <[email protected]> >>>>>>>> Date: Sunday, February 27, 2011, >> 12:58 >>>> PM >>>>>>>> Hey Mark, >>>>>>>> >>>>>>>> About the JSR proposal. I've >> actually >>>> been >>>>>> talking to some >>>>>>>> Oracle folks >>>>>>>> about this idea some (like 3?) >> years >>>> ago. They >>>>>> didn't >>>>>>>> really like it, since >>>>>>>> the classpath is only a VM >>>> implementation >>>>>> detail. >>>>>>>> I proposed it, because back then >> there >>>> were >>>>>> already rumours >>>>>>>> about module >>>>>>>> systems and writing a mechanism >> that >>>> relies on >>>>>> the >>>>>>>> classpath seemed like a >>>>>>>> bad idea at that time. A JSR (like >> 277 >>>> back then) >>>>>> could >>>>>>>> keep annotation >>>>>>>> scanning in mind while writing >> the >>>> spec. >>>>>>>> I pinged them again (I think it >> was >>>> last year) >>>>>> and they >>>>>>>> responded that they >>>>>>>> would think about adding an >> annotation >>>> scanner to >>>>>> Jigsaw, >>>>>>>> but a JSR was out >>>>>>>> of the question. >>>>>>>> >>>>>>>> I think mentioning their names >> here is >>>>>> inappropriate, but >>>>>>>> they're influential people in the >>>> Java/JCP >>>>>> world... >>>>>>>> >>>>>>>> This is not a reason to not write >> a >>>> framework or >>>>>> to not >>>>>>>> submit a JSR, but I >>>>>>>> thought I'd mention it... >>>>>>>> >>>>>>>> Ps. Maybe it's a good idea to >> "promote" >>>> XBean >>>>>> Finder and >>>>>>>> use it in >>>>>>>> MyFaces/OWB/etc...? >>>>>>>> Ps2. IIRC, we implemented our own >>>> scanner for >>>>>> MyFaces, for >>>>>>>> the simple reason >>>>>>>> that it removes an additional >>>> dependency. But, >>>>>> OTOH, using >>>>>>>> XBean Finder with >>>>>>>> the Maven Shade Plugin would also >>>> work... >>>>>>>> >>>>>>>> Regards, >>>>>>>> Jan-Kees >>>>>>>> >>>>>>>> >>>>>>>> 2011/2/27 Mark Struberg <[email protected]> >>>>>>>> >>>>>>>>> Hi Ivan! >>>>>>>>> >>>>>>>>> Yes, I already prepared for >> the >>>> addition of >>>>>> a >>>>>>>> xbean-finder based >>>>>>>>> ClassScanner implementation. >> But >>>> since I >>>>>> didn't reach >>>>>>>> David yesterday and I >>>>>>>>> personally don't know >> xbean-finder >>>> well >>>>>> enough, I just >>>>>>>> started hacking on a >>>>>>>>> scannotation based one >> (similar to >>>> the one >>>>>> we use in >>>>>>>> OpenWebBeans). >>>>>>>>> >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> --- On Sun, 2/27/11, Ivan >> <[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> From: Ivan <[email protected]> >>>>>>>>>> Subject: Re: Classpath >>>> Scanner >>>>>> proposal >>>>>>>>>> To: [email protected], >>>>>>>> [email protected] >>>>>>>>>> Date: Sunday, February >> 27, >>>> 2011, 12:01 >>>>>> PM >>>>>>>>>> Totally agree the idea, >> in >>>> Geronimo, >>>>>>>>>> it is definitely an issue, >> as >>>> many >>>>>>>>>> components need to scan >> the >>>> target >>>>>> application, >>>>>>>> and we are >>>>>>>>>> trying to improve >>>>>>>>>> this, e,g. In the >>>> xbean-finder, we use >>>>>> some >>>>>>>> filter to limit >>>>>>>>>> the scanning >>>>>>>>>> scope. Also, we hope to >> have >>>> a >>>>>> sharable >>>>>>>> annotation scanning >>>>>>>>>> tool, and open a >>>>>>>>>> JIRA to track this. >>>>>>>>>> >>>>>>>>>> [1] https://issues.apache.org/jira/browse/GERONIMO-5644 >>>>>>>>>> [2] >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-bundleutils/src/main/java/org/apache/xbean/osgi/bundle/util/ResourceDiscoveryFilter.java >>>>>>>>>> >>>>>>>>>> 2011/2/27 Mark Struberg >>>> <[email protected]> >>>>>>>>>> >>>>>>>>>>> hi folks! >>>>>>>>>>> >>>>>>>>>>> Since I'm tired of >>>> waiting for my >>>>>> EE stack >>>>>>>> to startup >>>>>>>>>> because each and >>>>>>>>>>> every library >> implements >>>> it's own >>>>>> classpath >>>>>>>> scanner >>>>>>>>>> over and over again, I >>>>>>>>>>> thought about >>>> introducing a >>>>>> proposal for a >>>>>>>> framework >>>>>>>>>> which allows to first >>>>>>>>>>> register 'ScanJobs' >> and >>>> then just >>>>>> does all >>>>>>>> the >>>>>>>>>> necessary classpath >> scanning >>>>>>>>>>> only once. >>>>>>>>>>> >>>>>>>>>>> If it turns out to >> work >>>> well, then >>>>>> I even >>>>>>>> consider >>>>>>>>>> this to get submitted as >>>>>>>>>>> JSR... >>>>>>>>>>> >>>>>>>>>>> But before this point >>>> gets >>>>>> reached, a lot of >>>>>>>> work is >>>>>>>>>> still waiting. >>>>>>>>>>> >>>>>>>>>>> I hope a few people >> are >>>> interested >>>>>> in this >>>>>>>> work and >>>>>>>>>> help me >>>>>>>>>>> specifying/testing >> the >>>> needs! >>>>>>>>>>> >>>>>>>>>>> The api and a bit of >>>> docs can be >>>>>> found at my >>>>>>>> github >>>>>>>>>> repo [1][2]. >>>>>>>>>>> >>>>>>>>>>> I'm currently working >>>> on >>>>>> 'scannizing' >>>>>>>> OpenWebBeans >>>>>>>>>> (and later MyFaces) as a >>>>>>>>>>> real world example. >>>>>>>>>>> >>>>>>>>>>> LieGrue, >>>>>>>>>>> strub >>>>>>>>>>> >>>>>>>>>>> [1] https://github.com/struberg/Apache-commons-classscanner/ >>>>>>>>>>> [2] >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> https://github.com/struberg/Apache-commons-classscanner/wiki/Apache-Commons-ClassScan-proposal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > >
