←Older revision | Revision as of 21:23, 2 August 2010 | ||
Line 15: | Line 15: | ||
<comments/> | <comments/> | ||
+ | |||
+ | [[Category:Video]] |
←Older revision | Revision as of 21:23, 2 August 2010 | ||
Line 15: | Line 15: | ||
<comments/> | <comments/> | ||
+ | |||
+ | [[Category:Video]] |
Undo revision 3277 by 41.224.250.62 (Talk)
←Older revision | Revision as of 12:19, 1 December 2009 | ||
Line 8: | Line 8: | ||
[[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management of module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management of module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. | ||
- | + | === The need for Common Ground === | |
Do you wonder why certain people think [[Ruby]] is better than [[Java]]? Do you think it is due to [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|duck-typing]]? Due to having [[closures]]? Wrong, it is because [[Ruby]] has [[Gems]]. Listen to following screencast to get convinced that [[Java]] needs such [[Module system|common ground]] too. See it with your own eyes [[NetbinoxTutorial|in action]]. | Do you wonder why certain people think [[Ruby]] is better than [[Java]]? Do you think it is due to [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|duck-typing]]? Due to having [[closures]]? Wrong, it is because [[Ruby]] has [[Gems]]. Listen to following screencast to get convinced that [[Java]] needs such [[Module system|common ground]] too. See it with your own eyes [[NetbinoxTutorial|in action]]. |
The need for Common Ground
←Older revision | Revision as of 12:35, 30 November 2009 | ||
Line 8: | Line 8: | ||
[[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management of module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management of module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. | ||
- | === The need for Common Ground === | + | <=== The need for Common Ground ===> |
Do you wonder why certain people think [[Ruby]] is better than [[Java]]? Do you think it is due to [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|duck-typing]]? Due to having [[closures]]? Wrong, it is because [[Ruby]] has [[Gems]]. Listen to following screencast to get convinced that [[Java]] needs such [[Module system|common ground]] too. See it with your own eyes [[NetbinoxTutorial|in action]]. | Do you wonder why certain people think [[Ruby]] is better than [[Java]]? Do you think it is due to [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|duck-typing]]? Due to having [[closures]]? Wrong, it is because [[Ruby]] has [[Gems]]. Listen to following screencast to get convinced that [[Java]] needs such [[Module system|common ground]] too. See it with your own eyes [[NetbinoxTutorial|in action]]. |
←Older revision | Revision as of 15:28, 28 November 2009 | ||
Line 10: | Line 10: | ||
=== The need for Common Ground === | === The need for Common Ground === | ||
- | Do you wonder why certain people think [[Ruby]] is better than [[Java]]? Do you think it is due to [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|duck-typing]]? Due to having closures? Wrong, it is because [[Ruby]] has [[Gems]]. Listen to following screencast to get convinced that [[Java]] needs such [[Module system|common ground]] too. See it with your own eyes [[NetbinoxTutorial|in action]]. | + | Do you wonder why certain people think [[Ruby]] is better than [[Java]]? Do you think it is due to [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|duck-typing]]? Due to having [[closures]]? Wrong, it is because [[Ruby]] has [[Gems]]. Listen to following screencast to get convinced that [[Java]] needs such [[Module system|common ground]] too. See it with your own eyes [[NetbinoxTutorial|in action]]. |
{{#ev:bliptv|2790848}} | {{#ev:bliptv|2790848}} | ||
<comments/> | <comments/> |
A bit of math
←Older revision | Revision as of 09:12, 27 October 2009 | ||
Line 6: | Line 6: | ||
=== A bit of math === | === A bit of math === | ||
- | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management | + | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management of module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. |
=== The need for Common Ground === | === The need for Common Ground === |
←Older revision | Revision as of 08:53, 27 October 2009 | ||
Line 7: | Line 7: | ||
[[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management on module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management on module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. | ||
+ | |||
+ | === The need for Common Ground === | ||
+ | |||
+ | Do you wonder why certain people think [[Ruby]] is better than [[Java]]? Do you think it is due to [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|duck-typing]]? Due to having closures? Wrong, it is because [[Ruby]] has [[Gems]]. Listen to following screencast to get convinced that [[Java]] needs such [[Module system|common ground]] too. See it with your own eyes [[NetbinoxTutorial|in action]]. | ||
+ | |||
+ | {{#ev:bliptv|2790848}} | ||
+ | |||
+ | <comments/> |
←Older revision | Revision as of 19:02, 16 October 2009 | ||
Line 1: | Line 1: | ||
Specification and also an implementation for packaging, managing [[dependencies]], deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | Specification and also an implementation for packaging, managing [[dependencies]], deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | ||
- | In case one cares more about the build than execution, then have a look at [[Maven]]. | + | In case one cares more about the build than execution, then have a look at [[Maven]]. In case your primary domain is packaging, then you are probably seeking for [[RPM]] or [[Debian]] solutions. |
←Older revision | Revision as of 13:10, 16 October 2009 | ||
Line 1: | Line 1: | ||
- | Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | + | Specification and also an implementation for packaging, managing [[dependencies]], deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. |
In case one cares more about the build than execution, then have a look at [[Maven]]. | In case one cares more about the build than execution, then have a look at [[Maven]]. |
←Older revision | Revision as of 19:20, 13 September 2009 | ||
Line 1: | Line 1: | ||
Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | ||
+ | |||
+ | In case one cares more about the build than execution, then have a look at [[Maven]]. | ||
←Older revision | Revision as of 08:02, 2 September 2009 | ||
Line 1: | Line 1: | ||
Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | Specification and also an implementation for packaging, deploying and executing applications composed from pieces/modules. [[Java]] users can choose from [[OSGi]], [[NetBeans Runtime Container]] or possibly [[OSGiAndNetBeans|mix them]] together. | ||
+ | |||
+ | |||
+ | === A bit of math === | ||
+ | |||
+ | [[Module system]] design needs to face some tricky (e.g. [[NP-Complete]]) issues. Especially complex is management on module dependencies as described at [[LibraryReExportIsNPComplete]]. This can have various solutions (like [[LibraryWithoutImplicitExportIsPolynomial]]), but it also shows why good [[API]] design skills are needed and why [[BackwardCompatibility]] is important. |