FWIW, in some other instances such as ejb-container module dependency on corba we were solving similar problem not by using DynamicImport-Package but by specifying Import-Package with optional resolution flag. I am not completely sure about pros and cons of each approach so while this change looks fine to get past immediate problem it would be good idea to get Sahoo's or Richard's blessing...
Thanks,
Snjezana
----- Original Message -----
From: tim.quinn_at_oracle.com
To: snjezana.sevozenzerovic_at_oracle.com, jane.young_at_oracle.com
Cc: dev_at_glassfish.java.net
Sent: Wednesday, December 15, 2010 3:59:34 PM GMT -08:00 US/Canada Pacific
Subject: admin/util/osgi.bundle change review request - for 3.1 ms 8
Hi.
The proposed change fixes the current problem reported in JIRA 15192.
admin/util has a "provided" dependency on security/core..."provided"
was suggested IIRC to keep the security module and its downstream
dependencies out of the nucleus distribution. At the time, though, I
neglected to make sure the dependency would be resolved dynamically,
since the code that actually requires the dependency should not
execute in the nucleus - only in the glassfish distribution.
This change makes the dependency dynamic instead. With this change in
my workspace the nucleus start-up no longer fails trying to locate the
security module (which is not present).
Thanks.
- Tim
Index: admin/util/osgi.bundle
===================================================================
--- admin/util/osgi.bundle (revision 43878)
+++ admin/util/osgi.bundle (working copy)
@@ -45,3 +45,5 @@
com.sun.enterprise.admin.util.jmx; \
com.sun.enterprise.admin.util.proxy; \
com.sun.enterprise.admin.util.test; version=$
{project.osgi.version}
+DynamicImport-Package: \
+ com.sun.enterprise.security.ssl