As you can tell Richard and I have discussed this before ;-)
Without this capability in the framework there is no way to
support legacy code that has a default package that needs to
be used by other bundles. I agree with what Richard states
but this position can prohibit the adoption of OSGi in some
legacy scenarios.
John, if you cannot refactor the legacy code there is nothing you
can do using the standard OSGi R4 mechanisms :(
Tom.
[EMAIL PROTECTED] wrote on 09/14/2006 11:18:11 AM:
> Thomas Watson wrote:
> > As far as being able to distiguish between
> > the different default packages ... is this not the same issue
> > as having muliple versions of a normal package? You need to
> > use matching attributes to distinguish the different packages
>
> No, this is not the same at all. Different versions have some
> chronological relationship and are potentially substitutable for each
> other. This is not the case at all for the default package.
>
> However, I agree that you could concoct a scheme that forced people to
> use BSN and version with "." and that would probably work, but would be
> totally brittle and doesn't seem like a good reason to further bloat the
> framework.
>
> -> richard
> >
> > For example:
> >
> > Export-Package: .;legacy-lib-name="abc";version="1.0"
> >
> > Export-Package: .;legacy-lib-name="xyz";version="1.0"
> >
> > Import-Package: .;legacy-lib-name="abc";version="1.0"
> >
> > Import-Package: .;legacy-lib-name="xyz";version="1.0"
> >
> > This allows you to pick the default package from either the abc
> > or xyz legacy library.
> >
> > Tom
> >
> > > Can't do it.
> > >
> > > There is no way to express the default package in OSGi...the main
> > reason
> > > is there would be no way to distinguish one bundle's default package
> > > with another's. And you couldn't just combine them all, since this
> > would
> > > lead to naming conflicts.
> > >
> > > -> richard
> > >
> > > John Wells wrote:
> > > > How do I export the "root" package? In otherwords, a package with no
> > > > name. I know, I know, it isn't too smart... but I'm dealing with
> > legacy
> > > > code here...
> > > >
> > > > Any idea?
> > > >
> > > > John Wells (Aziz)
> > > > [EMAIL PROTECTED]
> > > >
> > > >>> Register now for BEA World 2006 --- See
> > http://www.bea.com/beaworld<<
> > > >>>
> > > >
> > _______________________________________________________________________
> > > > Notice: This email message, together with any attachments, may
> > contain
> > > > information of BEA Systems, Inc., its subsidiaries and
> > affiliated
> > > > entities, that may be confidential, proprietary, copyrighted
> > and/or
> > > > legally privileged, and is intended solely for the use of the
> > individual
> > > > or entity named in this message. If you are not the intended
> > recipient,
> > > > and have received this message in error, please immediately return
> > this
> > > > by email and then delete it.
> > > > _______________________________________________
> > > > osgi-dev mailing list
> > > > osgi-dev@bundles.osgi.org
> > > > http://bundles.osgi.org/mailman/listinfo/osgi-dev
> > > >
> > > _______________________________________________
> > > osgi-dev mailing list
> > > osgi-dev@bundles.osgi.org
> > > http://bundles.osgi.org/mailman/listinfo/osgi-dev
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > osgi-dev mailing list
> > osgi-dev@bundles.osgi.org
> > http://bundles.osgi.org/mailman/listinfo/osgi-dev
> >
> _______________________________________________
> osgi-dev mailing list
> osgi-dev@bundles.osgi.org
> http://bundles.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
