Mirko's note is helpful and I've appended it to the issue 277 for
consideration by the CPEG.
Glyn
"Richard S. Hall"
<[EMAIL PROTECTED]
.org> To
Sent by: OSGi Developer Mail List
osgi-dev-bounces@ <osgi-dev@bundles.osgi.org>
bundles.osgi.org cc
Subject
10/06/2006 09:24 Re: [osgi-dev] JSR 291 and
contributions to CLASSPATH from
outside the bundle
Please respond to
OSGi Developer
Mail List
<[EMAIL PROTECTED]
.osgi.org>
+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
_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
