Dear receivers and Geronimo project members, Thank you very much for voting me as a committer. Once again, thank you very much for trust and big credit based on very few contributions made so far.
I am writing cause I would like to continue my struggles with XBean and I wanted to check with you which parts of XBean are actually in use across geronimo ecosystem. So far most of checks I made by using GitHub code search and mvnrepository.com <http://mvnrepository.com/> via dependency chains. Both are fine but not reliable. This allowed me to find major components which are being used and some which are not used at all. For example xbean-telnet is one of these. From history I know that major projects using XBean are Apache ActiveMQ, Apache OpenEJB and Apache TomEE. Most of xbean references inside Apache ServiceMix is gone since several years as xbean-server from 3.x line become a foundation for Karaf and other components around. I had a short chat with Romain on IRC before I got a committer badge and he asked me about keeping amount of changes low. Initially I really wanted to do that, but it turned out to be quite hard. Since David mentioned a possible XBean 5 release over a weeks ago I think it could be a good opportunity to drop code which is not used at all. From usage reported by mvnrepository seems that xbean-spring is most used module (216 usages) followed by reflect (66), finder (60), bundleutils (45) naming (24). A classloader (17) with blueprint (12) is the end. These seems to be most important modules which got certain adoption in community. I omitted maven plugin and asm modules as these are kind of helper/utility ones, but still gets referenced in multiple places. If you have a moment to review a codebase - please do this and take a look and report modules beside above which must stay from your point of view so we will be able to drop legacy by not porting these modules to next release. At current stage I managed to get most of schema related stuff work. Remaining tests failures come from incompatibility of schema generated before with present versions of Spring or schema processors. I wanted to enrich schema with elements representing maps, lists and so on, however this was difficult to go over. Because of that I started work on extraction of xbean-model module. This gonna occupy me for a while. Main goal behind is unification of source code annotation parsing (source -> qdox -> model), and namespace handler logic (model -> runtime) which now have a gap in middle. Annotations and structures representing these read via qdox are written to file and read from it later on using code which has nothing to do with annotations (or configuration model). This possibly was a fair take long time ago, however makes eventual extension (or reduction) of annotation model harder. More over many of people who was active in project before is gone now so no-one really knows what is file syntax. I am learning this by touching code which reads that. I would like to push this work forward to place where qdox could be substituted for example by java code annotations, simply javadoc can not be validated by compiler (at least not without additional code to maintain). A java annotation types could be then mapped to xbean-model and used by namespace parser without necessity to have a configuration file (keep in mind its just idea). From more interesting facts - blueprint tests are passing without issues because schema validation doesn’t fail for them. What currently blocks spring module is XSD validation - not our code directly. Kind regards, Łukasz — Proud yet fresh Geronimo committer :-) twitter @ldywicki http://dywicki.pl
