+1 -> richard
Jahn Mirko wrote: > 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 > _______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
