Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Little on Jul 13, 2007
Sun and the members of the JCP are making a huge effort to ensure that it is compatible with OSGi, OSGi will support 277 (after all, 277 has 2 OSGi people on it). But it would be quite wrong for Sun to favour one vednor solution (OSGi) over all the others (Maven, Ivy, etc).
JSR-277 is a good thing for OSGi. It makes life easier from a JDK perspective for it and the other competing solutions. Bundles/modules become first class citizens on the JVM level. Beyond that, it’s up to the framework (OSGi or whatever else) to provide any value-add stuff they want to. 277 does not limit that. OSGi will offer proprietary extensions on top of the basic spec just like everything else in vendor land. So why do the OSGi people jump up and down all the time.
It would be rather like if the JBOSS folks were constantly attacking JPA because it didn't solely support hibernate.
They attack JSR 277 not because it's coming from a JCP, but rather because the spec group blatantly ignored an 8-year experience OSGi brought us, and naively approached the problem with a "don't tell us how to do it, we know better" approach.
Isn't it the core idea of JCP to embrace industry experience and not reinvent a squared wheel?
I still don't get what the issue is.
Members of the JSR-277 expert group include two .NET experts, two OSGi experts who co-authored the R4 modularity spec, Maven's creator and Ivy's creator. Sonds like "embracing industry experience" to me, and exactly what the JCP is supposed to do.
William,
Take a look at the expert group mailing list for JSR 277, which is now open to the public (albeit read-only). Having done so, it's really hard to see that the two OSGi experts (Glyn Normington and Richard Hall) are being listened to. It's certainly not from a lack of effort on their behalf. There are numerous areas in the JSR 277 draft spec and the current strawman which are irreconcilable with OSGi: Sun is willfully refusing to learn any lessons from the experiences of OSGi/JSR 291.
OSGi people are not simply complaining because our favourite module system has not been chosen. That would be childish. The principle reason that we are making so much noise is that JSR 277 is heading towards failure as a module system! It will be hugely damaging to the entire Java community to have a broken module system baked into the JVM.
I would really like JSR 277 to be a success, but I believe that it should build on OSGi rather than compete with it. Competing APIs are great in some areas (e.g. GUI libraries or XML parsers) but the module system of the platform is not one of those areas. Can you think any other language or platform that has multiple competing module systems?
Neil.
By this logic OSGi should be encouraged to recruit JEE experts and define a better alternative to EJB.
Plus it's wrong to say that "... t would be quite wrong for Sun to favour one vednor solution ..." Have you looked at who's involved with OSGi? Last time I looked it was more than a single vendor! With the exception of Sun, I think all of the usual major JEE suspects are there.
That's right! Without wanting to oversimplify the issue here. It seems like yet another round of Sun playing the "not invented here" game. Ever since I got acquainted with OSGi it seemed to me like it had solved so many questions of component models, component dependency checking, deployment and upgradeability that most appserver vendors have not yet solved properly and that the official jee standards are not even touching at all.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
7 comments
Watch Thread Reply