Module system
From APIDesign
| 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. |
Revision as of 19:02, 16 October 2009
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 mix them together.
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.
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.
Follow
