[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