| Hi, I am following the discussion in the JSR mailing list and I have some questions concerning the request 277 form Bea. Perhaps some of you can make things a bit clearer for me. I totally understand the problem with third party jars, which can not be changed. I ran into similar problems in my project. As far as I understand, this is a development problem, because the spec explicitly allows nested jar files. Concerning this, there already exists a bug report for the Eclipse IDE (of course not everyone is using eclipse, but for my case I'll stick to this IDE for explanations). The bug 103136 indicates the nested jars problem (https://bugs.eclipse.org/bugs/show_bug.cgi?id=103136) and therefore I think it is a IDE issue. In Eclipse you can use a folder instead of a jar to contain your bundle during development time (like having it in the workspace). Of course, this is no standard, but this solution is for me good enough. Is there something I missed so far? On the other side, if external contributions to the CLASSPATH are allowed, I am a bit afraid of opening the box of pandora. I mean, in OSGi the smallest deployment unit is a bundle. The bundle defines all dependencies in terms of requirements related to the OS, JVM or contributions by other bundles. If we skip difficult things like arbitrary files and focus on dependancies on standardized jar files there are a lot of problems coming into my mind, like versioning, changes of the file name, resolving of the host bundle (how is this dependency expressed, can it be checked by the framework) and of course the deployment in other environments like mobile devices. For me, somehow it looks like the break of the component idea, which is in OSGi combined with the smallest deployable unit. In cases of jar files, what has to be done to create a bundle? In general, if it is just a library, a manifest file must be added. Often it is very easy to make a bundle out of this jar file. If you do the work for a third party library, often they welcome this effort by including it in their product, because the drawbacks are very little and in the same time, they win a lot. My experiences showed me, that this can work. At least it is worth a try in many cases. To sum up my points. I don't really see the necessity of having this in the spec. I couldn't find a proper usecase which is worth the drawbacks. Perhaps some of you can enlighten me. Greetz, Mirko |
_______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
