10 responses

  1. Peter Kriens
    April 2, 2009

    Great article reflecting a lot of my thoughts about the subject. However, I do not think we should specify anything before we fully understand the issues. We need lots of people experimenting and finding solutions.

    We are working on tools in the OSGi and this is clearly one of the most important issues to address. As an organization, we’d love to foster the discussions around versioning and how to reduce brittleness and the maintenance nightmare.

    However, I do think your title is overly negative, Myths are stories that are not true. No sane person is promising reuse as we both seem to dream about today, but it is the primary reason for me to do OSGi. Therefore, I think the title of your post should have been better as “The Quest for Software Reuse” :-)

    Thanks! Kind regards,

    Peter Kriens

    P.S. The reasons why we are rather vague in the spec about the versioning scheme is that we did not want to restrict the required experimentation. If you do not understand something, I feel it is really bad to standardize it.

    P.S.S. You know about the bnd -versionpolicy?

  2. Brad Cox
    April 2, 2009

    To amplify on an observation that I actually picked up from Peter, we’re in that awkward stage between the reality of monolithic tools and libraries (jar-based) and the dream of a fully componetized (bundle-based) future. We desperately want components. But what we have to work with is jars artificially repackaged as bundles by various groups with ever-evolving understanding of what a truly competized world might look like.

    See http://bradjcox.blogspot.com for musings of how the construction industry bridged this gap in transitioning from monolithic (cave-man) to primitively componetized (mud brick) to modern (real brick) architecture. And how long that all took! ;)

  3. Mirko Jahn
    April 2, 2009

    @Peter:
    Thanks for the feedback! You might be right, that the headline is drawing too much negative attention, but I wanted to make a point. I see people violating even fundamental versioning rules for the sake of… I don’t know – dubious business reasons I guess, and at the same time praising their so greatly modular applications. Just because you use OSGi and a minimum of versioning you’re not automatically creating reusable artifacts. However for some reason this attitude is in people’s heads, not knowing what great responsibility comes with releasing software to the public. I think this is the important message: “Just because you made it a bundle it is not automatically a reusable artifact. It is hard work to make it so.”

    I am trying to foster this discussion for some time internally at work and it is conceptually well received so far and awareness is spreading. I think, we are at a critical point in the adoption phase of OSGi. People are now heavily investing in OSGi with the hope to (later) benefit from a great variety of reusable artifacts. When not adhering important, yet to define rules and providing tools helping you to version bundles, we might be facing a similar situation Microsoft witnessed with the DLL hell – having hundreds of bundles, all versioned inadequately (if at all), making it impossible to build a product on top of it without going through a serious evaluation and repackaging process. Something I certainly don’t wonna see… Learning from the past to conquer the future ;-)

    Your point that we need the experience and voice of many – I can’t agree more. I think this is the only way to come up with a ubiquitous scheme to versioning in the context of software reuse. The question remains what is the right process and environment for propelling these efforts so that lobbyism can be minimized, the “not developed here” attitudes doesn’t kill the process before it even started and the focus is on the important stuff – the technical (and partially social) problems?

    @Brad:
    Nice analogy. I heard similar ones when people where promoting software product lines. Unfortunately awareness doesn’t automatically translate to progress, we have to work on that by ourselves – but true, it certainly helps knowing ;-)

    Thanks,
    Mirko

  4. Richard S. Hall
    April 3, 2009

    While I agree with what you are saying, I think you are equating modularity with reusability. As is clear from the discussion, these two do not go hand in hand. There are still plenty of valuable reasons to create modular systems, even if the modules themselves are not reusable. So, it is still okay to praise our modular systems. However, I agree that making your modules reusable is the better way, although not necessarily the easier way to go. :-)

  5. Tony Morris
    April 3, 2009

    Get your head around pure lazy functional programming. Then we’ll have a talk about whether reuse is a myth. I’m confident you’ll change your mind. As a starter, ask yourself what property about a language subset that you consider “reusable”, since you’ll agree that it at least exists.

  6. Tom P
    April 4, 2009

    Interesting article, thanks.

    Note that your version schema link is broken – need to remove the trailing slash: http://wiki.eclipse.org/Version_Numbering

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

  7. Mirko Jahn
    April 6, 2009

    @Tom
    Thanks for the feedback. I updated the link…

    @Richard
    You’re right! I treated modularity and reusability synonymously, which is not true. I guess after working with OSGi for so long, I consider modularity as a given fact and don’t even think there is any not modular code out there any more – which is simply wrong. Thanks for clarifying and reminding me that we are still fighting the basic issues of our craft to a great extend. Maybe I am dreaming too much of a better world :-)

  8. shuron
    September 6, 2012

    This article is not new but hasn’t lost its relevance. I’m not new in OSGi, because of being ever on Eclipse IDE and sometimes doing Eclipse RCP development, but looking closer on OSGi in a last time.

    You describe here not only OSGi relevant topic. Versioning is big problem in a maven world. So my 5 cents are:
    The are two problems, first is to define what is the proper version strategy and who defines it and maintenance this rules.
    Second who and how controls the preservation of the rules.

    First is maybe simple. OSGi Alliance is encourage do define some kind of spec on this. But the control has to be done carefully. Thereby i think about a popular (has to be bright accepted ) OSGi Bundle repository (like maven has) which enables some contol function.

    Some simple control can be done e.g. during publishing and lead to refusing of deployment to Repo. Deeper and even semantic control could be done by human comunity. And there is a lot of opportunities how this could be relised, maybe it has to be not specified to detailed.
    What do you think?

Leave a Reply

 

 

 

Back to top
mobile desktop