[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Incubator commit rights for Kim Horne
|
The only sharing you would get in such a customization scenario is the
bits of the JAR files on disk since the "in memory" bundles has been
transformed. It seems to me that computers have pretty big hard disks
these days and can support multiple transformed versions of a JAR file.
The transformation could even be done at product install time if you want
to avoid "shipping" the transformed versions of the JAR.
In any case, we probably do not need to do it at runtime with the
associated performance/caching issues.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
office: +1 407 849 9117
mobile: +1 386 848 3788
Kimberly Horne <kim@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
10/27/2006 01:05 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] Incubator commit rights for Kim Horne
I am now doubting myself. I really like the feel of this solution.
Augmenting the builder to process bundle resources seems so much more
elegant than inserting transformation points at N levels of the
runtime. Other than the loss of transformations based on runtime
state (a dubious asset at best) the main drawback I can see is how it
would affect the shell sharing scenario. If multiple logical
products use the same bundles it'd be impossible to have product-
level customizations.
On Oct 25, 2006, at 4:28 PM, BJ Hargrave wrote:
>
> Also, does the transformation need to be done at runtime? It seems
> the use
> cases are all packaging issues in assembling an RCP based product.
> Why not
> just have support for transformation at packaging time instead of
> runtime.
> This will then remove the runtime variability which can cause
> stability/debugging issues.
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
