On Fri, Jan 27, 2012 at 9:37 AM, Toni Menzel <t...@okidokiteam.com> wrote:
> Hi Pete, > > Thanks for your insight! Thats exactly why i would be keen on not just > dump-bundle-izing dependencies but sort the apples and oranges that "are in > good shape in terms of modularity". This includes: > - proof of concept projects showing things actually work (and not just > resolve) > - repackage/fork libraries of interest and make them more modular > - encourage (by all means) authors to pull those changes back in. > (keyword: feedback pipe) -> this is far easier to do if you can showcase > scenarios why this is really useful and not just for the niche of > OSGi-Nerds. *Put Modularity on the Flag and OSGi in your toolbox. Not the > other way around.* > When I first got started it took me literally months to get around this issue. Ended up having to hire Neil Bartlett to come in and show me how to do some black belt kung-fu level bnd work to get around some problems from one of the many dependencies that I brought in from the spring repo, with a typical 1000+ entry manifest that conflicted with a package from another 1000+ manifest entry bundle. Thank god for Neil Bartlett, and for the "uses" directive. By the time I had that done, I had forgotten why I even cared about modularity in the first place. I felt pretty stupid doing something so hard with such a subtle benefit. Rod Johnson is going around saying that OSGi isn't what the market is interested in and citing it as one of his most expensive mistakes. He's right about the market, but really we all seem to be missing the point. The market has plenty of reason to be interested in modularity, OSGi is just the best shot at getting there, and even then it is only truly viable when common dependencies come in modular form. Back to the topic at hand, if we quit just blindly converting projects to OSGi with 1000+ entry manifests, or talking to providers in terms of OSGi, but instead talked up the benefits of modularity, it would probably be a much easier sales pitch, and a much better result too. It would take a lot of patience, but we'd eventually get there. The key metric is the size of the manifest. If it's a big manifest with quadzillion imports, it's not modular - right????. It may be theoretically usable in an OSGi environment, but it's existence may do more harm than good if coupled with the wrong bundle. My 2c > Toni > > On Fri, Jan 27, 2012 at 4:22 PM, Pete Carapetyan < > p...@datafundamentals.com> wrote: > >> Observation: [almost off topic] >> - I use OSGi because it supports modularity. In that, modularity is all >> I really care about. OSGi does this well for me, and pretty painlessly too, >> as it has for the last year. >> - This thread once again demonstrates that, as for me, 80% of the time >> seems to be spent jacking with dependencies that even when OSGi-ified would >> still never be modular in design. >> >> It just seems funny to me that such a large percentage of the effort >> required to work with OSGi is where almost none of the benefit is. Just a >> big up front requirement. >> >> Just saying :) I'd still never go back. >> >> _______________________________________________ >> general mailing list >> general@lists.ops4j.org >> http://lists.ops4j.org/mailman/listinfo/general >> >> > > > -- > Toni Menzel Source <http://tonimenzel.com> > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > >
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
