[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] RequiresBundle, ImportPackage and virtual providers
- From: Niclas Hedhman <niclas@xxxxxxxxxxx>
- Date: Thu, 30 Mar 2006 23:41:44 +0800
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=UHgNedgayICgT94mQ7CzKAH6PacgP9dQ81WkO+8q0sMqYi4cfbl4lsnMESjmw+yrPRWnb8viOuIGBmXNdkhVYkwpA+sRJyp7wrznxWHnbFAkTmIiFfr3OWOlff7E9fDAmfEIT+ozRZG/bBlc+U7rZt9KKeEmHrJ8bDI85CazFAA=
- Organization: Independent
- User-agent: KMail/1.8
On Thursday 30 March 2006 21:55, Neil Bartlett wrote:
> Post-291, developers will still have to find a solution to the
> problem, and there is nothing to stop them using OSGi Service Layer.
> However this "lowest common denominator" approach is a little
You are right for the short-term, but once JSR291 has settled in and OSGi has
adjusted to it, we are then free to experiment with more than a single
approach to the Service layer on top of JSR-291. Perhaps the OSGi model does
not suit all needs, or perhaps it is too complex for some.
I am generally not in favour of large "all-or-nothing"/"kitchen sink" specs,
as they become monolithic, hard to use, inflexible and doesn't call for
innovation and evolution to the same degree as smaller ones.
So expect to see more JSRs on top of 291, but we need to start somewhere. ;o)