Hello Lukasz, This ringed this bell to me: http://apache-geronimo.328035.n3.nabble.com/XBean-cleanup-td3991305.html
An alternative proposal can be to explode xbean in (names are bad, takes them as scope please ;)): - geronimo-container (reflect, asm shade, finder, classloader, naming) - geronimo-osgi (spring/osgi utils/blueprint) Telnet can be in its own module or donated to chatterbox probably. An enable to do more long term work on osgi side without blocking the rest of the repo. Wdyt? Le lun. 20 août 2018 20:11, <[email protected]> a écrit : > 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 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 > >
