FYI A while ago I searched for a repository that contains the core and/or compendium jars but could not find one. So, at that moment I uploaded them to OPS4J repository: http://repository.ops4j.org/maven2/org/osgi/org.osgi.core/ http://repository.ops4j.org/maven2/org/osgi/org.osgi.compendium/
I guess that best will be to have them in Maven central repository and I recall posting a message on this list related to this subject as Peter K. told me that he does not know how to do so, so maybe someone from Felix could take that job. On Fri, May 15, 2009 at 7:31 PM, Richard S. Hall <[email protected]>wrote: > For those not following the users@ discussion, here is a link: > > > http://www.nabble.com/-karaf--Equinox-integration-problem---and-possible-solution-to23559788.html > > The above thread discusses an issue with using our compendium bundle. This > is not the first time this issue has been raised. The summary is our > compendium bundle results in odd class loading errors in some cases. My > conclusion is that this is because we dynamically import *, so dependent > bundles are using the compendium packages even though the compendium > dependencies are not actually satisfied. > > We dynamically import * to avoid forcing all users of compendium to satisfy > all dependencies to use it, because most of the time they are not needed for > the contained service interfaces. However, in the cases where they are > needed, it is problematic. > > Why do we provide these bundles at all? Originally, the OSGi JAR files were > not bundles, so we needed something and did it ourselves. Now this is no > longer the case, I believe. > > It seems we need to figure out what we should do to address such issues in > the future. I think there are three options: > > 1. Stop providing these bundles altogether and just rely on the > official artifacts from the OSGi Alliance (I believe they are in a > maven repo somewhere). > 2. Provide them with their full explicit dependencies (i.e., static > Import-Package declarations). > 3. Divide them up into more reasonable chunks, since they lack > cohesion as bundles which makes managing their dependencies more > unreasonable (e.g., it sucks having to deploy a provider of > javax.microedition.io for org.osgi.service.io when you just want > to use logging). > > At this point, I think the order of the options listed here is the order of > my preference. > > I talked to Tom Watson about this and he agrees, saying he thinks their > bundles are a mistake and doesn't plan on updating them. His recommended > approach for the future is to bundle the API with the implementations. > > Sounds good to me, since that's what we do too. What do you guys think? > > -> richard > -- Alin Dreghiciu Software Developer - Looking for new projects! My profile: http://www.linkedin.com/in/alindreghiciu My blog: http://adreghiciu.blogspot.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development.
