Hi, Alin Dreghiciu schrieb: > 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.
The maven project has a description of the process to follow to upload artifacts to central [1]. Alternatively, it might be conceivable, that we try to use the nexus repository at repository.a.o to upload them on behalf of the OSGi. We would have to ask infra@ on whether this would be an option. WDYT ? On a side track: Have you considered syncing the ops4j release repository with the cetral repository as described on the same page. Regards Felix [1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html > > 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 >> > > >
