Right, well I think there are three reasonable positions to take: 1) Modularity is not important or useful. 2) Modularity IS important, but OSGi is not the best solution, and better solutions exist already or will exist in the future. 3) Modularity is important and OSGi is the best solution.
Rod does not appear to be arguing position 2, instead he seems to be arguing position 1, that modularity is not important or at least not important in most cases. I disagree, I think it is important in far more cases than Rod states... it's not just for infrastructural products like Eclipse or Glassfish, but those large internal corporate projects written by banks, insurance companies, retailers etc also stand to make big gains from modular techniques: enhanced productivity, reuse of components, more resilience to failure of components, easier division of labour between teams, etc. Position 2 is kind of what you said, that Jigsaw or something else may be better for modularity than OSGi. It's kind of difficult to assess this because Jigsaw is nothing more than a requirements document at this stage (and incidentally those requirements are well aligned with OSGi). Obviously I'm at position 3. I think that companies can gain a competitive advantage by using a module system that works now rather than waiting an unknown amount of time for a new module system that may or may not be better. Regarding your other point about multiple versions of the same library, I agree that it's undesirable, but it's necessary more often than you think. If some of the modules you are using come from third parties, then it really doesn't matter how actively you are maintaining your own modules, and you may be forced to fork them just to achieve single version compatibility. Anyway you have fallen into the fallacy of picking just one of the things OSGi offers and arguing against that as if it constituted an argument against the whole. Regards Neil On Jun 24, 5:25 pm, Jess Holle <[email protected]> wrote: > But that still leaves open the question as to whether the right solution > is to provide more tooling for OSGi or something simpler and possibly > better integrated with the language, e.g. Jigsaw. > > On one of the point items I have to agree with the Posse -- if you get > to the point where you want different versions of the same library being > loaded at the same time, then that's generally a sign that your overall > dependency management has gotten out of control or that some modules are > not being adequately maintained. Sure, in some rare cases such a need > will occur, I've seen it -- but I'd be loathe to add complexity to >98% > of development for the <2% problem. > > On 6/24/2011 9:44 AM, Neil Bartlett wrote: > > > > > Rod's message is a fair bit more nuanced than the headlines and > > soundbites would suggest. He said that OSGi productivity is low > > compared to "traditional" Java development, and it may surprise you to > > hear that I agree with him on that point... currently. > > > However I don't consider that a reason for giving up on the goal of > > building modular software. I and several others believe that OSGi can > > actually be made *MORE* productive than non-OSGi development, and we > > intend to prove it by building the tools that SpringSource failed to > > build. > > > I do think that SpringSource could have solved this problem as well, > > but they chose to focus on products like tcServer that were easier to > > sell and provided faster profits. Actually this created opportunities > > for smaller companies so ultimately I'm grateful to them. > > > Neil > > > On Jun 23, 9:22 pm, phil swenson<[email protected]> wrote: > >>http://www.theserverside.com/news/2240037102/OSGi-Not-Easy-Enough-to-... > > >> "We have changed our views on OSGi over the years, and one of the > >> reasons for that is that OSGi simply cannot be made as easy to use and > >> as productive as we feel is consistent with Spring values." > > >> "Niche" -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
