Yes, I also suggest using optional import.
Thanks,
Sahoo
On Thursday 16 December 2010 05:40 AM, Snjezana Sevo-Zenzerovic wrote:
> 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
>
>