Another reason  is that in general you need to handle optional dependencies. 

I feel that this list of -runbundles is a primary design artifact of my system, 
on par with source code, and not a consequence of the initial requirements. For 
this reason I never enable autosave since it changes the bundles that end up in 
my end-result without me being aware of it; it keeps on working (and growing). 

I find it much better to get an unresolved error in my running framework when I 
make a save so I can consider the consequence of that change. After 10+ changes 
it becomes a lot harder to figure out the cause and then generally people let 
their dependencies go for it is too hard to figure out where each one came from.

In a maven world where a popular project like like ActiveMQ has almost 300 
dependencies with a mish-mash of versions I guess I am the odd one out :-(

Kind regards,

        Peter Kriens


> On 2 jun. 2016, at 07:59, Tim Ward <[email protected]> wrote:
> 
> Hopefully the upsides are obvious. There are a few potential downsides:
> 
> 1) You may have added extra runbundles which will be lost
> 2) If the resolve operation is large (particularly if it uses big 
> repositories) then it can take a long time.
> 3) Resolution is a destructive operation (it changes the file) which doesn't 
> fit the normal model for a save.
> 
> Best Regards,
> 
> Tim
> 
> Sent from my iPhone
> 
>> On 2 Jun 2016, at 05:00, Paul F Fraser <[email protected]> wrote:
>> 
>> Hi,
>> 
>> Is there any downside to selecting Auto Resolve on Save in Enroute?
>> 
>> Paul Fraser
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to