Home

News: SpringSource to move dmServer to Eclipse – OSGi not ready for mainstream?

  1. Adrian Colyer posts that SpringSource has submitted a proposal at Eclipse.org to continue development of the dm Server as part of the Eclipse. The Eclipse nickname for the project is Virgo. As part of the post Colyer remarks that OSGi is not ready for the mainstream. Colyer writes that :"There is a great deal of interest and innovation around enterprise OSGi and the dm Server. This interest is strongest amongst early adopters, and projects with requirements that match closely the dynamically modular nature of the OSGi Service Platform. For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits. This situation needs to be addressed before enterprise OSGi can become the de-facto approach for mainstream enterprise application development. " [his italics] http://blog.springsource.com/2010/01/12/dm-server-project-moves-to-eclipse-org/

    Threaded Messages (51)

  2. This and more...[ Go to top ]

    I think it's that and more... Spring is now part of the bigger organization and has much wider horizons. Recent acquisitions should also point to the direction they, and the rest of the industry, are heading. I think it's a right move and the fair one. They are giving millions of dollars in R&D back to the community - the place that helped grow to where they are now. My $0.02. -- Nikita Ivanov. GridGain - Cloud Computing Platform
  3. Re: This and more...[ Go to top ]

    They are giving millions of dollars in R&D back to the community
    What R&D? Since when implementing OSGi is R&D?
  4. OSGi not ready[ Go to top ]

    I've never used OSGi on my projects because it is too complex to use and configure. Many people thought that EJB 2.1 were too complex, and decided to migrate to the Spring approach. Now, OSGi could die for the same reason. Up to now it is relegated to the "Eclipse World", and cannot go out there.
  5. Re: OSGi not ready[ Go to top ]

    I've never used OSGi on my projects because it is too complex to use and configure.
    I wonder of what nature the problems were for which you considered OSGi as a possible solution. OSGi is a powerful hammer, and not well suited for small nails.
    Up to now it is relegated to the "Eclipse World", and cannot go out there.
    GlassFish 3 is a major (and rock-solid) project that relies on OSGi in a very fundamental way.
  6. Re: OSGi not ready[ Go to top ]

    It all boils down to the hard fact; "You must know what you are doing". I've seen a lot of nagging about different "new" technologies Corba is bad, J2EE sucks, Springsource is evil, Maven is cancer for your projects blabla I've used most of them and alot is hard to get right the first time, especially when you don't take the time to LEARN: how do I use this framwork right? Every framework enforces a architecture, and if you try to force Your square shaped architecture onto a round shaped framework. It will hurt you. Spring won't do anything good to your project until you LEARN how to use it right. JavaEE6 will probably hurt your feelings to and so will OSGi.. Know your framework/tool and use it right!
  7. OSGi not ready, is it?[ Go to top ]

    I've never used OSGi on my projects because it is too complex to use and configure.
    Many people thought that EJB 2.1 were too complex, and decided to migrate to the Spring approach.
    Now, OSGi could die for the same reason.

    OSGi is not complex. The only thing is that, it has a longer learning curve. Once you are familiar with it, you will understand the power of OSGi.

    OSGi is not suitable for all the java projects, but if you need true modularity in your systems, OSGi is the way to go.

    I have been using OSGi for more than one year now, and it is working perfectly for us. We've developed a complete enterprise SOA platform based on OSGi. Check out WSO2 Carbon project and the related products in wso2.com/products

  8. Re: OSGi not ready, is it?[ Go to top ]

    We've developed a complete enterprise SOA platform based on OSGi. Check out WSO2 Carbon project and the related products in wso2.com/products

    Ok, I'll check it! I think OSGi is very elegant, and it really addresses the modularity problem. But now I cannot understand the trade-off between what we loose in OSGi complexity (configuration, find/create/install OSGi modules) with what we gain in project modularity.
  9. Re: This and more...[ Go to top ]

    http://williamlouth.wordpress.com/2009/07/03/jazoon-‘09-the-conference/ "...This last item seems foreign to many OSGi disciples who apparently do not understand one of the main reasons why operations stop and restart processes in applying a managed change – to be sure the process can indeed be restarted when something goes terribly amiss in production outside of the container (hardware). It is much easier rolling back at the time the change is applied."
  10. Re: This and more...[ Go to top ]

    http://williamlouth.wordpress.com/2009/07/03/jazoon-‘09-the-conference/
    Maybe I'm just stupid but I think I've looked at that a number of times and I don't get the italics. Are those quotes? What's the difference between what's in italics and what's not?
  11. Re: This and more...[ Go to top ]

    William,
    Maybe I'm just stupid but I think I've looked at that a number of times and I don't get the italics. Are those quotes? What's the difference between what's in italics and what's not?
    The blog post is very valuable and the kind of thoughts we need on modularity and OSGi. However, I do have to agree the italics make the post very difficult to read. Cheers, Reza
  12. Re: This and more...[ Go to top ]

    Sorry guys a WP formatting error/editor within the HTML itself. Will correct it now.
  13. OSGi not ready for mainstream?
    Is this really meant to be a serious question? What rock have you been hiding under? Tom
  14. I agree that OSGi is still years away from becoming mainstream, so this is probably a good move on part of both SpringSource and wider acceptance of dmServer if it is really to become something developers adopt in significant numbers. Personally, I think OSGi as it stands today is more applicable in its embedded systems roots than it is in the enterprise, so an Eclipse project is a much better fit in the scheme of things. Cheers, Reza
  15. I've tried to start usig OSGi for new project at spring. It doesn't seems ready for mainstream. You have to do a lot of low level programming while thinking about you software modularization. There are some frameworks simplifing OSGi usage (iPOJO, OPS4J) but they have really strong learning curve and so require much efforts to be introduced into project.
  16. A simple to use OSGi programming model for the enterprise is a lot closer than most realize. We (IBM) are working hard to bring the benefits of OSGi to mainstream WebSphere customers. Get a glimpse of where we’re going in our OSGi Applications open alpha, which is available now. https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/iwsasosgia/ Erik Kristiansen IBM WebSphere
  17. A simple to use OSGi programming model for the enterprise is a lot closer than most realize.
    The programming model is only part of the problem, I think (and that alone is a big one right now). If OSGi is to succeed, it needs to be as non-invasive as possible so it isn't "in the way" of developers if/when they actually need OSGi-like features and can "graduate" applications seamlessly into the model as the needs of the application/organization evolve. If this is pushed to the market too aggressively before it is really ready, the results could be just as counter-productive as CORBA, EJB 1.x and EJB 2.x. I do hope someone is thinking this through carefully before getting on the marketing bandwagon too quickly. In a way, I think open source/early-adopters is a much better mechanism for fully hashing out the OSGi story than more traditional mechanisms. Cheers, Reza
  18. Funny how this has become OSGI thread although its just one vendor Spring who chaged their direction on OSGI. anyway .. OSGI the way it is - its very complex for sure. we used it for a pilot project involving about a 1 million trx per day project. too much training , overhead and dependency understanding. The benefits didnt really pay off that much. On the other hand - I felt that if we change the way class loaders behave in general in JVM itself, it may be easier. OSGI does have other benefits, but the main problem still boils down to getting around lot of class loading behaviours. If we can have better control over that - we can take J2EE deployments, dependency management to the next level.
  19. A simple to use OSGi programming model for the enterprise is a lot closer than most realize. We (IBM) are working hard to bring the benefits of OSGi to mainstream WebSphere customers. Get a glimpse of where we’re going in our OSGi Applications open alpha, which is available now.

    https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/iwsasosgia/

    Erik Kristiansen
    IBM WebSphere
    It will be great if IBM can fix issues in webspehere as is first and make it easy to manage and run cheap. I cznt imagine the mess it will be when IBM gets into OSGI .. The harshness comes from lot of bad experiences with IBM websphere... nothing personal Eric.
  20. It will be great if IBM can fix issues in webspehere as is first and make it easy to manage and run cheap.
    I cznt imagine the mess it will be when IBM gets into OSGI ..
    The harshness comes from lot of bad experiences with IBM websphere... nothing personal Eric.
    Or at least stop pretending that all the unnecessary nonsense that IBM adds to J2EE helps people when it really just exists to trap customers in a web of proprietary extensions.
  21. I have used OSGi through our adoption of the FUSE ESB (think ServiceMix 4) and it was a bit daunting to adopt at first. After reading enough about it and actually developing a production ready product, I believe that OSGi is the way to go. We used Spring's OSGi support and the maven's bundler plugin and it made things really simple. Yes, you do need to start thinking about modularizing your applications and how things inter-relate. Glassfish v3 also uses OSGi now, so it's really becoming more mainstream than people think. I do believe that there should be better tooling created and OPSJ is doing a great job at that. The Spring's dm server seems like a push in the right direction and maybe they should have a bigger involvement in the development of the OSGi spec.
  22. I spent couple of days to get a webapp working with Spring DM-Server and it was not a good experience to scratch head on manipulating manifest files. I think the problem is any realistic web application requires OSGI compliant open source jar files. The challenge is to find all those jar files with right versions in Spring EBR repository. If you don't find the library you are looking for in EBR, you end-up spending lot of time in creating an OSGi bundle for it. For OSGi to be practically usable, first thing is all open source libraries should make their jar files OSGi compliant and make it available in maven public repos. I think SpringSource tried to take an approach "they are not doing it, but we will do it and publish in EBR". It is too much to chew for one organisation to manage all versions of all open source libraries to be OSGi compliant. It requires entire Java open source community , tool/product vendors to adopt OSGi before applications can be migrated to OSGi compliant servers.
  23. It will be great if IBM can fix issues in webspehere as is first and make it easy to manage and run cheap.
    I cznt imagine the mess it will be when IBM gets into OSGI ..
    The harshness comes from lot of bad experiences with IBM websphere... nothing personal Eric.


    Or at least stop pretending that all the unnecessary nonsense that IBM adds to J2EE helps people when it really just exists to trap customers in a web of proprietary extensions.
    +1. I don't think any devs buy this nonsense any more. managers seem to lap it up in spades, then inflict it upon devs, who do nothing to deserve it. Give me Tomcat/Jetty any day. For my 2c, Maven gives 99% of the benefits of OSGi. I don't really need to stop/start components, or hot deploy that much. I value the design time benefits of a component approach a lot more than the runtime (hotdeploy) benefits. I also think one problem with OSGi adoption is that in the average enterprise there are a mix of contractors and permies, of varying coding and tetris-playing skill levels. It's difficult enough to drive Maven adoption and thinking about components without the extra technical complexity of OSGi.
  24. For my 2c, Maven gives 99% of the benefits of OSGi. I don't really need to stop/start components, or hot deploy that much. I value the design time benefits of a component approach a lot more than the runtime (hotdeploy) benefits.
    Interesting perspective. OSGi and Maven do have very little in common but for both having "dependency management" written somewhere in there documentation (if there is decent documentation at all but that is an entirely different matter). Maven's dependency management runs into big problems once it really starts to manage complex dependencies with multiple versions on the same libraries in different parts of the dependency tree. It is one of the tools that makes simple things possible and hard things hard. OSGi's benefits on the other hand would be very interesting for a lot of scenarios but "OSGi" is an awful abstraction. What one needs in the real enterprise world are beans and modules, much like, say *.jar, *.war and *.ear files that you drop into your systems and that are resolved, managed and restarted correctly as per their dependencies. For what it's worth there should not be *any* "programming model" as such associated with this but it should simply work by configuration, for each and every class within the respective modules. Thinking "OSGi" and "Enterprise" is about good a match as thinking "Socket Programming" and "HTML Pages".
  25. OSGi's benefits on the other hand would be very interesting for a lot of scenarios but "OSGi" is an awful abstraction.

    What one needs in the real enterprise world are beans and modules, much like, say *.jar, *.war and *.ear files that you drop into your systems and that are resolved, managed and restarted correctly as per their dependencies.
    Ironically this is a very good description of how an OSGi bundle should behave! Core OSGi is meant to provide a firm foundation on which you can build abstractions, such as the OSGi Bundle Repository or Declarative Services, that manage and process dependencies exactly as you suggest above. But to do this we need quality dependency information in our JARs that tools can process - for me this is OSGi metadata, for others maybe Maven or JSR294. We need to know how two modules relate to one another in order to manage them properly.
  26. OSGi's benefits on the other hand would be very interesting for a lot of scenarios but "OSGi" is an awful abstraction.

    What one needs in the real enterprise world are beans and modules, much like, say *.jar, *.war and *.ear files that you drop into your systems and that are resolved, managed and restarted correctly as per their dependencies.

    Ironically this is a very good description of how an OSGi bundle should behave!
    Karl, are you talking about the 'service' abstraction in OSGi? My understanding is that you do not have to use that feature. What you have described here (I don't care about whether hot deploys work or not) is already part of OSGi and implemented using the existing features of the JVM. You can get dependency management through OSGi without changing your code. It's definitely possible that OSGi can be improved upon but it seems like there is a lot of confusion about what it does today. It may be the case that it's too hard to use or whatever but I think we should all understand what it provides before getting into whether it's a good option.
  27. The responses suggest that many people don't consider OSGi a trivial concept. And at first it isn't, but after reading a bit about it, it actually makes a lot of sense. The primary issue that enterprise (as opposed to embedded) OSGi tries to solve is the JVM class loading issues. Secondly, it is the separation of concerns. As far as the JVM class-loading issue is concerned, I'm sure everyone that has worked with Java to a degree has run into JVM classpath issues, whether its related to having the same package class names, or having multiple jars with slight version variations loaded into the JVM memory. OSGi allows the developer to specify which exact packages should be loaded into the JVM and even allows multiple JARs with let's say different versions to be loaded at the same time. However, when you import you are given the option to specify which version of the package that you want to import. This provides much more granularity than just specifying the versions of the JAR files themselves. When you create a jar, it is good practice to specify the versions of all of the packages that you are exporting as well. As far as the second issue (separation of concerns), OSGi makes you start thinking about your code in terms of modules. A module should do something very specific. As an example, you may have one module that has a specific JDBC driver for your database. Another one that deals with DAO layer. Another module that deals with exposing your business logic via REST or SOAP. Furthermore, a good practice is to split each of your modules into an all interface bundle and one that is all implementation. That way you can swap out your implementation at any time with another bundle at runtime, without compromising your contracts defined in the interface bundle. As far as the complexity of dealing with the Manifest file, that isn't the case. You actually don't need to change your manifest file directly. As Stuart mentioned, if you use maven, the felix's maven bundler plugin will help you to manage your relationships of the bundles and packages for you. You still need to provide which packages you want to import and export. And another great feature of OSGi is that it allows you to swap out a piece of your functionality without bringing down the server. In conventional containers the entire web application has to be restarted. With OSGi, nothing is down and only a piece of your code is actually refreshed with newer code.
  28. Wow, people seem to have very strong feelings about this. Just to add a little bit of pro-OSGi feedback here. I personally have used the modularity/dependency management aspects of OSGi in a few projects. After a bit of learning I got used to the export, import and extension-point mechanisms there and I have to say I still like the way it is done in. Particularly when developing from Eclipse, configuration of the bundles is very straightforward. And if you have an external jar file for which you need an OSGi bundle, creating one is a matter of minutes, a very simple thing to do. Should hot-redeployment not be wished for, then just go and restart the whole thing. Developing an OSGi based application from within Eclipse give you excellent debugging and testing facilities also.
  29. We need objects, components versioning ? Not .jar versioning ? I'm not sure. This is what we usually hear from SOA guys. But in a application, services have inputs & outputs data and when you talk about a "version" you've to take into account all the layers of your application, up to the database. So a "version" is more than a version of one service/class/component/object. This is why packaging is really important and why OSGI is "package oriented" because beeing "object" oriented cannot solve the "versioning problem"
  30. ... Give me Tomcat/Jetty any day.

    For my 2c, Maven gives 99% of the benefits of OSGi. I don't really need to stop/start components, or hot deploy that much.
    +1 One would think that the RoR experience would have shocked the Java community into rethinking the embrace of complexity (e.g. "hot swap") but we still don't get it. Maven itself is not a simple tool, but at least it is non-invasive (at the code level).
  31. OSGI will never be mainstream, it will forever belong to people who thought DCE was the answer, then CORBA was the answer and then though WS-* was the answer. No one needs that complexity except for a huge consulting organization like IBM that makes it money off enterprises being locked in to their solutions and their services. Ignore it and it will go away. See #dce, #corba and #ws*. Use Maven, write modular code and deploy on a simple server like Tomcat or Jetty and you'll be much better off in the long run.
  32. OSGI will never be mainstream, it will forever belong to people who thought DCE was the answer, then CORBA was the answer and then though WS-* was the answer. No one needs that complexity except for a huge consulting organization like IBM that makes it money off enterprises being locked in to their solutions and their services. Ignore it and it will go away. See #dce, #corba and #ws*.

    Use Maven, write modular code and deploy on a simple server like Tomcat or Jetty and you'll be much better off in the long run.
    If you're using Maven you might want to try the following:
    mvn archetype:create "-DgroupId=org.examples" "-DartifactId=foo"
    Go to the pom, change packaging from "jar" to "bundle" and add the following build section:
    org.apache.felix maven-bundle-plugin true 2.0.1
    Build as usual:
    mvn clean install
    And bingo, you have an OSGi bundle. If you're feeling adventurous try this:
    mvn install org.ops4j:maven-pax-plugin:1.4:provision
    Which automatically deploys your bundle onto an OSGi framework (by default Felix but you can choose Equinox or Knopflerfish, etc.) If you have suggestions to make this simpler or less intrusive, please let us know at Apache Felix or OPS4J. Personally I'm not overly fussed if OSGi is "mainstream" or not - but I do think it's a good solution to modularity and the pot-luck process of throwing JARs onto a single classpath. Just look at how many libraries these days use maven-shade-plugin / proguard / jarjar to hide dependencies under different packages to avoid conflicts and version issues. So if I can help make OSGi more accessible with tooling and extensions then I'm happy. Of course the more libraries that add OSGi metadata to their distributions, the easier it will be for everyone else - no more hunting around or rolling-your-own bundle.
  33. >I cznt imagine the mess it will be when IBM gets into OSGI ..
    The harshness comes from lot of bad experiences with IBM websphere... nothing personal Eric.
    IBM moved WAS to an OSGi kernel for a few releases ago. The knock they've been taking since that time is that application developers don't have access to the OSGi layer. This package they're working on addresses that.
  34. Re: OSGi not ready for mainstream?[ Go to top ]

    The title of this thread is misleading - somehow it went from "enterprise OSGi not ready for mainstream" to "OSGi not ready for mainstream", which surely means something different, even though it's not clear what differentiates enterprise OSGi from non-enterprise OSGi.
    For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits.
    Assuming that "enterprise XYZ" means something large in scale, possibly distributed, many users, many applications etc. then I'm left to wonder for which "XYZ" short-term benefits can be had at all. I doubt that OSGi -like any architectural choice for complex projects- can deliver short-term benefits for such projects no matter how easy it is to use. That's simply a reflection of the complexity and timeline of such projects, not of OSGi itself. (And I don't even want to think about what shortcuts might be taken to deliver an enterprise application "as quickly as possible".) Or maybe -just maybe- dm server isn't the way to accomplish that.
  35. Re: OSGi not ready for mainstream?[ Go to top ]

    For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits.


    Assuming that "enterprise XYZ" means something large in scale, possibly distributed, many users, many applications etc. then I'm left to wonder for which "XYZ" short-term benefits can be had at all. I doubt that OSGi -like any architectural choice for complex projects- can deliver short-term benefits for such projects no matter how easy it is to use. That's simply a reflection of the complexity and timeline of such projects, not of OSGi itself. (And I don't even want to think about what shortcuts might be taken to deliver an enterprise application "as quickly as possible".)
    This is a really good point and highlights a major misconception. A lot of people think that 'enterprise software' means low quality code with little concern for correctness and performance. Frankly I have no idea where people get this idea. Yes, enterprises are looking to reduce their costs and time to delivery but that doesn't mean that they value these over correctness and performance. The cost of incorrect or poorly performing code is much higher than the cost of developing it correctly in the first place. Only a small fraction of the cost of enterprise software is in the development of it (if the developers know what they are doing.) This is a something I deal with frequently. We get these contractors that take a big steaming dump on us and seem completely bewildered when I tell them that the code isn't good enough as if it doesn't matter that it doesn't work or is unreliable or unsupportable. Hell, even off-the-shelf software vendors call their tools 'enterprise' when there is no automated deployment model or even something that can be put into source control.
  36. Reuse Is the Dream Dead again[ Go to top ]

    Reuse Is the Dream Dead again http://techdistrict.kirkk.com/2009/07/08/reuse-is-the-dream-dead/ OO passed , SOA passed, OSGI passed again chinese discussion about Reuse: http://www.jdon.com/jivejdon/thread/37994
  37. Modularization is difficult[ Go to top ]

    I think the question not whether OSGI is ready for the enterprise, but rather whether modularization is really necessary for 95-99% of projects. My answer to this is a resounding NO. However if you are at a point in a project where you realize that you have a growing set of components, that are expanding in their interconnectedness, and that different clients need to be supported at different versions of those components, and you do not have the money to expand your developer-base, you have a couple of options. 1. Get a REALLY great build tool(MAVEN or IVY) and understand it THOROUGHLY. 2. Use spring or any other DI framework(Guice?) to the nth degree to make those components configurable, this obviously in combination with point #1 3. USE OSGI (the learning curve is high, but OSGI has very specific advantages when it comes to efficiently dealing with modularization)..... this also in combination with point #1 So, dont cause yourself pain (MODULARIZATION), if you dont need it...if you do need it OSGI is a good fit My 2c Ivanhoe
  38. Re: Modularization is difficult[ Go to top ]

    I think the question not whether OSGI is ready for the enterprise, but rather whether modularization is really necessary for 95-99% of projects.
    Curious what people believe the definition of "modularity" is? I have a feeling I'll get 20 answers and 20 different responses.. Thanks
  39. Re: Modularization is difficult[ Go to top ]

    I think the question not whether OSGI is ready for the enterprise, but rather whether modularization is really necessary for 95-99% of projects.


    Curious what people believe the definition of "modularity" is? I have a feeling I'll get 20 answers and 20 different responses..
    You are probably right. I'll take a 30 second crack at it. Modularity (in this context) is the property of a software component to be used in combination with other components without being designed specifically for each possible combination. With regard to that, I don't think OSGi provides modularity as much as it provides a mechanism that helps enforce it.
  40. Re: Modularization is difficult[ Go to top ]

    With regard to that, I don't think OSGi provides modularity as much as it provides a mechanism that helps enforce it.
    how so? Thru the export/import tags in the manifest?
  41. Re: Modularization is difficult[ Go to top ]

    With regard to that, I don't think OSGi provides modularity as much as it provides a mechanism that helps enforce it.


    how so? Thru the export/import tags in the manifest?
    Mainly the export. By implicitly hiding what isn't exported you can prevent packages that are not part of the public API from being accessed. This has a side benefit of determining structuring package easier. You can have public classes without exposing them. There's a cost to this. If you have a inadequate public API, this will make your jar less useful. Frankly, I guess a lot of people who bitch about OSGi are realizing that their APIs are inadequate for the needs of the users. But if things outside of your public API are being used, your code is very unlikely to be modular. Those hidden dependencies are what makes it difficult to use code in different contexts. The imports are helpful in managing dependencies. They don't do anything to eliminate them but they make them explicit. Anyone who wants to use your jar won't be surprised about what else they need to use it. And explicitly stating your dependencies makes it obvious if you have many dependencies i.e. your code is less modular. From a technical perspective it make it easier to use your code in an environment with other modules with their own dependencies. You can have different versions of those dependencies in the same scope. I'm sure there are limits to how well that works in practice, though.
  42. Re: Modularization is difficult[ Go to top ]

    Mainly the export. By implicitly hiding what isn't exported you can prevent packages that are not part of the public API from being accessed. This has a side benefit of determining structuring package easier. You can have public classes without exposing them.

    There's a cost to this. If you have a inadequate public API, this will make your jar less useful.
    That seems great when building a public product like an eclipse plugin.. Not as complete a solution when you have an inhouse developed web application where everyone has access to everyone's code.. A developer can just as easily change the export to fix the "inadequate" public api.. This causes me to build in other means to govern this. The same governance I use without OSGi..
  43. Re: Modularization is difficult[ Go to top ]

    Mainly the export. By implicitly hiding what isn't exported you can prevent packages that are not part of the public API from being accessed. This has a side benefit of determining structuring package easier. You can have public classes without exposing them.

    There's a cost to this. If you have a inadequate public API, this will make your jar less useful.


    That seems great when building a public product like an eclipse plugin.. Not as complete a solution when you have an inhouse developed web application where everyone has access to everyone's code.. A developer can just as easily change the export to fix the "inadequate" public api.. This causes me to build in other means to govern this. The same governance I use without OSGi..
    You can change the manifests on 3rd party jars too. I don't really see what difference it makes. You don't need the source to modify exports in the manifest. The point of OSGi is not to force people to use shitty APIs. The point is that explicitly stating what the public API is gives it more value. It's true that OSGi is not magical. If your reason for rejecting OSGi is because it doesn't magically fix all your problems, then I guess your logic holds. OSGi containers provide capabilities that are not present in standard java. I support these can be approximated in JEE. If you don't need those capabilities, or you are fine with dealing with the JEE classloader hierarchy mess, don't use OSGi. There's nothing about an OSGi enabled bundle that prevents it from being used in a non-OSGi environment. I don't understand why people adamantly oppose things that don't affect them.
  44. Re: Modularization is difficult[ Go to top ]

    You can change the manifests on 3rd party jars too. I don't really see what difference it makes. You don't need the source to modify exports in the manifest. The point of OSGi is not to force people to use shitty APIs. The point is that explicitly stating what the public API is gives it more value.

    It's true that OSGi is not magical. If your reason for rejecting OSGi is because it doesn't magically fix all your problems, then I guess your logic holds.

    OSGi containers provide capabilities that are not present in standard java. I support these can be approximated in JEE. If you don't need those capabilities, or you are fine with dealing with the JEE classloader hierarchy mess, don't use OSGi. There's nothing about an OSGi enabled bundle that prevents it from being used in a non-OSGi environment. I don't understand why people adamantly oppose things that don't affect them.
    I never claimed it did magic (though having read the spec some of it does seem magical! :-)) Not sure why fans of a particular technology have to be so insulting when people ask honest questions.. I actually like OSGi quite a bit.. But people do tend to sell it as a magic bullet.. My point above is you still need solid programming practices like code reviews and governance to save you from poor practices even in an OSGi environment. It by itself doesn't solve the problem.
  45. Re: Modularization is difficult[ Go to top ]

    I never claimed it did magic (though having read the spec some of it does seem magical! :-)) Not sure why fans of a particular technology have to be so insulting when people ask honest questions..
    I'm not insulted and I'm not really an OSGi fan. I'm an interested onlooker at best. But when people imply that you need to modify code to use OSGI, I feel compelled to point out that this is factually incorrect.
    I actually like OSGi quite a bit.. But people do tend to sell it as a magic bullet.. My point above is you still need solid programming practices like code reviews and governance to save you from poor practices even in an OSGi environment. It by itself doesn't solve the problem.
    I never said that OSGi solves any problems. In fact, I stated quite clearly that it does not, by itself, solve anything. When you start talking about how OSGi won't fix governance issues or a broken deployment process, it appears that you are employing a rhetorical technique. If you want to challenge the claim that I did make: that OSGi provides tools that can be used to enforce modularity, I am happy to debate that point. If what you meant was that OSGi provides nothing more than what you can get through a governance process, then I think you are wrong. OSGi is a technology that is orthogonal to governance, in my opinion. If you have no control over what's deployed, no technology solve that.
  46. Re: Modularization is difficult[ Go to top ]

    Seems we're saying the same things.. So not sure why the disagreement. If you thought I meant OSGI was a silver bullet I didn't mean too (others have tried to sell it to me that way).. I also didn't meant to imply that OSGi is completely useless.. As I said I actually think it's a great fit for some use cases (especially embedded).. OSGi is a just a tool, not a silver bullet.
  47. Dependency Hell[ Go to top ]

    As we use more 3rd party jars, their dependencies become more likely to conflict. We teeter across this high-wire pretty well because we have been doing it for a long time. That doesn't mean its the right way to do it. And it is only going to get worse the more we build our apps by cementing other people's work together. Someone blamed Maven for dependency mismatch issues. Maven just cleans up the mess enough that you find out you have the dependency mismatches that you always had without knowing. They are in there waiting to bite you one day when someone finally tests that bit of unused code that exercizes the dependency spawned bug. What I see as particularly helpful in OSGi is a way that the producers of jars that are designed to be used by others can encapsulate their dependencies with versions tightly enough to avoid dependency hell. It's the ability to run two versions of the same jar without untoward results that is needed. It particularly applies to the jars we use in our applications but don't write ourselves. (Oh yes, how is this fundamentally different than the old DLL hell we endured in early versions of Windows--or made fun of.) So just give me that advantage without making me do so much work to get my own jars running. I'm free to pick whatever versions I want for the jars I use in my app. I don't really need all that attention to OSGi details.
  48. Re: Dependency Hell[ Go to top ]

    So just give me that advantage without making me do so much work to get my own jars running. I'm free to pick whatever versions I want for the jars I use in my app. I don't really need all that attention to OSGi details.
    Can you elaborate on what it takes? This might be what is holding OSGi back.
  49. Good and bad...[ Go to top ]

    I think it's good that Spring will hand this code over to Eclipse, if Eclipse accepts it. Which they shouldn't. As someone who watched the development of Spring's OSGI offerings from day one, I was exceptionally disappointed with how they went about their implementation. Much like one would expect Microsoft to do, after several months of development, they began to ignore the standard, add their own extensions, and basically create vendor locking for those looking at using dmServer. Personally I'd like to see Eclipse reject this project so they can continue to focus on standards based OSGI, and not end up being part of the Spring eco-system. Great promotional tool for Spring/VMWare if dmServer ships by default with WTP. And horrific for the industry as a whole.
  50. Very interesting ... from Adrian's blog:
    "For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits."
    I very much agree with this - it is exactly because of this that I started working on Impala, which gives you the most important benefits of modularity (declarative dynamic services, dynamic reloading of parts of an application, etc.), without all the complexity of OSGi. For all it's strong points I've never believed that OSGi in its current form was ever going to become mainstream for enterprise Java. On the strength of Adrian's comments it now appears to me that in spite of all their efforts and innovation in this area, SpringSource don't believe this will happen either (at least not for the foreseeable future and not without real simplifications). This is an positive development, because it will bring SpringSource back to their roots based around simplicity and ease of use. That being said, the ideas of modularity are still crucially important, particularly for the health of applications. In my view, it is extremely difficult to develop a large Java application efficiently without some form of dynamic modularity. What is needed, however, are simple solutions to the problem which co-exist more easily within the enterprise Java world. Phil Zoio Impala - simple dynamic modules for Spring http://www.impalaframework.org/ http://impalablog.blogspot.com/
  51. Happy Admiran has come this far in his career. I am hoping to ge my hands my server so i can upgrade to Eclipse
  52. After reading all the responses here I can only come to the conclusion that the Enterprise Java people are not ready for OSGi, not the other way around. They want to keep their flat, monolithic classpath and cruel API designs. They want complex build processes, that need complex build tools (maven). OSGi forces you by strict package separation to think about your API before hacking it. It provides a rock solid service oriented infrastructure which enforces further de-coupling of components. Unfortunately, most programmers are not able nor willing to spend time on good API design which should be the basis of every project, especially in the so called "Enterprise Market". It's the same market that promises the customer unlimited features and processing speed combined with tight schedules which defeats thinking before doing effectively. Then there are the middleware products like JPA that were clearly not designed for modularity. And when you wanted to run JPA inside OSGi you had always trouble getting the classes visible to the EntityManager. Ever tried to add an Entity to a running JPA EntityManager?. Not possible. Is that a fault of OSGi. Certainly not. If the JPA specs would have accounted for adding and removing Entities during runtime we could already build very flexible OSGi applications today. Of course it would have made the already very complex caching mechanism in JPA even more complex. I always looked at Spring with mixed feelings. It dragged a lot of configuration data with it and adopted OSGi very late in the process. Let's see what the dmServer can offer, that I cannot get with a plain vanilla OSGi system and remote-services. And by the way: I for one, would never try to build a web application using Java. Its just the wrong tool for the job. Most so called "Enterprise" developers would be surprised how easy webapps are developed outside their world. Keep your eyes open and use the technology that you think fits your project best. And don't stick to JEE closely minded. To the poster that offered an alternative component system based on spring. Looking at the website it seemed like an overly complex system (build process alone) and does not solve the main problem of Java (classpath, versioning).