-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Evgeni,
On 6/14/12 3:11 PM, [email protected] wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've some >> questions about the (non) sharing options of bundles in the >> deployment admin that is not clearly described in [1]: Suppose a >> bundle is already installed on the system, but not as part of a >> deployment package, e.g., MyLogService v1.0. If we would install >> a deployment package containing another version of MyLogService, >> say, v1.1, is this considered valid? If so, then the text of step >> 6 on page 334 of [1] should be changed as it suggests that *any* >> installed bundle should be upgraded, regardless whether it is >> part of the source package or not. > That bundle is so called "externally" (outside DeploymentAdmin) > installed. Why do you think that it should be upgraded? If you read the spec carefully, you can interpret it saying this. To quote: "If the bundle symbolic name already exists in the system with a different version number, update that bundle with the resource stream." (step 6; section 114.8, page 334). Here the word "system" suggests that all bundles should be regarded as potential upgrade candidate, not only those in the (target) deployment package. Hence my question. >> If not, then the text of the first bullet of step 3 on page 333 >> of [1] should be changed as it suggests that source packages can >> *only* contain bundles that are either not present at all or >> present in the target package, missing the scenario where a >> bundle is present in the system, but not part of *any* deployment >> package. >> Another question is the (non) sharing of resources; section >> 114.2.2 of [1] clearly suggests that no sharing is allowed >> between deployment packages for *any* resource. For bundles we >> should check for symbolic name and version, but for any other >> resource this is up to the implementation of the customizer, or >> not? > Yes, but the resource processor, not the customizer, because of: " > A sharing violation must be considered an error. The install or > update of the offending Deployment Package must fail if a resource > would be affected by another Deployment Package. The verification > of this rule is delegated to the Resource Processor services, or > the Deployment Admin service in case of bundles. " Ok, if the resource processor is responsible of doing this, when should this verification take place? Should this be implicitly part of step 11 (section 114.8, page 334)? - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is:/ Luminis Technologies B.V. IJsselburcht 3 6825 BS Arnhem +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP2ekWAAoJEKF/mP2eHDc4W38QAI1JVBnqh4JgaVYJJspOKLnM 26CQ+BmGOzNg/YKnTJ1bsxW+JjrkvILCy8apl9eHPPjm6L7F40FoBhkol2OxEQcq zK5WthAQW1VCZcK1a+4lNh0TvitwJxXdEHbK8R6QUDF3Ve6Q7HQQt60vz0jDHRnl jsG8mDgRd4UfoBNZgF48ql1WS6FWEBzJ2iIz58jvnMmSFAVr1A1Tpcek4tH08aDq P4NP7qQq6ZiaAsS8NbASVE/WR1Ka1NKoYZJA6vWlHo/Rmrgedf7gKdeh+YDnTNa6 JNax22m1qsfchfO+XWd6lRUDaCfO/SFl8/os+miGU+AZjYosaMzQSs0VARhDN4uq 5y1TODj0cCeGE0Mw+aBicpzy9AYJb43a4+UJp9PNvW82VLlCRJ5yAD9+NlQiSL5G unE0O+0uvs4XF3juITcXobH5JmTv1QGa7HG0rVS5s+mMqgJQel0uNtjJnthNhUJP 9kLdcm2fD2wmIS9xZbsj2ZzylXah8vrA7vPenIS8IjiLhxdogiEI/af3ZjA4QBnw j75oLR19CBpBA8oSnZdelJFz/wtUrqpXAYOLrDam7vXB8tEzardBbIIvSn1AOTm6 f/vwiEyyyHvhBPz5s2c++8KJU1/yjtlOrzxkC5UNkWt7Sr5IEfAmzDAuMm4pT73d xCxdqLem3cnFtrkiYIuq =u5wA -----END PGP SIGNATURE----- _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
