Thomas Hallgren wrote on 11/02/2007 10:55:00 AM:
> John Arthorne wrote:
> >
> > Having said that, altering the runtime structure of plugins to
> > workaround development time limitations seems to be a poor reason for
> > not doing this valuable optimization.
> I agree that having jar'ed plug-ins is of great value but is nested
jars
> really an optimization? I might be wrong (haven't tested) but I doubt
> that any gain in performance, memory consumption, or even significant
> size on disk can be proven.
Well, it really depends on the situation. If a plugin contains a
nested jar, plus thousands of other files, there is certainly
performance gain in install time, disk space, etc, from jarring. The
benefit of jarring tends to accumulate over a large body of plugins -
it might be a small gain for a single plugin, but for an application
with a 1000 plugins, it adds up.
>
> > It's certainly not the case that all plugins that contain nested jars
> > cannot be jarred.
> Of course not. My point is that the since the compiler fails to
> recognize nested jars, any downstream project depending on such
plug-ins
> have to go through the hassle that I described earlier. I'm questioning
> why that is recommended and why it's considered good citizenship.
I think the problem is that it's hard to come up with a simple
recommendation that applies in all cases. Plugins with nested jars
would probably need to be evaluated on a case by case basis to see
what the best solution is. Sometimes a nested jar is fine (such as the
common ant task case). Sometimes the right answer is to split the
nested jars out into separate plugins. Perhaps as with the "should do"
for ICU4J, it should instead say "Projects should have jarred plugins
where appropriate", with a link to a document with more details on
what "appropriate" is.
John