Hi Karl Thank you very much for your quick reply. I was able to get it working by adding the jars to the felix.auto.start.1 property in the config file. I have no patch right now, but maybe at another time :-)
Best regards Rasmus Med venlig hilsen / Best regards Rasmus Nørby Jakobsen Software Engineer, MSc R&D Department Universal Robots A/S Energivej 25 5260 Odense S Denmark Phone: +45 89 93 89 89 Cell: +45 28 49 24 95 [email protected] www.universal-robots.com Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message. ________________________________________ Fra: Karl Pauls [[email protected]] Sendt: 25. april 2016 12:00 Til: [email protected] Emne: Re: Space issues with Felix Hi Rasmus, as long as you don't specify the "uninstall" action to felix.auto.deploy you should be able to delete the bundles from the bundle folder after they have been installed into the felix cache. The felix cache shouldn't be invalidated (unless you specific to clean it on framework start or delete it yourself). However, this is obviously a little tricky as you can't update the bundles easily anymore after you remove them from the bundle folder. Alternatively, you can use the "reference:" protocol to install your bundles. If you install a bundle with a url of "reference:file:..." it will not copy the bundle jar into the cache but keep referencing it from its original location (this is not spec but iirc, supported by Felix, Equinox, and KF). Unfortunately, there is no way to have felix do that automagically together with the felix.auto.deploy - hence, you'd either have to list the urls yourself in the config or you'd have to write your own / patch our AutoProcessor ( https://svn.apache.org/repos/asf/felix/trunk/main/src/main/java/org/apache/felix/main/AutoProcessor.java). I guess you could easily add a property to tell felix to install all bundles using the reference: protocol (patches are welcome :-). regards, Karl On Mon, Apr 25, 2016 at 10:48 AM, Rasmus Nørby Jakobsen < [email protected]> wrote: > Hi Felix Users > > We have a setup using felix.auto.deploy.dir with the Install and Start > actions enabled. We use the default setup of keeping original bundles in > the bundle folder and the installed version in felix-cache. We are > approaching disk space issues due to having every jar twice and would like > some feedback on what is the best practice here. Is it possible to remove > the original jars after running the application once? Or will the > felix-cache ever be invalidated for some reason (causing the need to have > the originals)? > > If you need further details on the setup/configuration please let me know. > > Best regards > Rasmus Jakobsen > > Med venlig hilsen / Best regards > > *Rasmus Nørby Jakobsen* > *Software Engineer, MSc* > > *R&D Department * > *Universal Robots A/S* > Energivej 25 > 5260 Odense S > Denmark > > Phone: +45 89 93 89 89 > Cell: +45 28 49 24 95 > > [email protected] > www.universal-robots.com > <http://www.linkedin.com/company/universal-robots-a-s> > <https://www.facebook.com/UniversalRobots> > <https://twitter.com/Universal_Robot> > <https://plus.google.com/100123388801849599660/posts> > <http://www.youtube.com/user/UniversalRobotsVideo/videos> > > Please note that this message may contain confidential information. If you > have received this message by mistake, please inform the sender of the > mistake, then delete the message from your system without making, > distributing or retaining any copies of it. Although we believe that the > message and any attachments are free from viruses and other errors that > might affect the computer or IT system where it is received and read, the > recipient opens the message at his or her own risk. We assume no > responsibility for any loss or damage arising from the receipt or use of > this message. > > -- Karl Pauls [email protected] http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
