The pom just copies files, it's system.properties that controls what gets loaded. So you can copy whatever files you like into lib, using any mechanism you like, and just reference the ones you wan to deploy in system.properties.
Typed on a tiny keyboard... Apologies for the typos. On Sep 19, 2011, at 8:59, Greg Logan <[email protected]> wrote: > On 11-09-19 08:02 AM, Josh Holtzman wrote: >> Upgrading 3rd party bundles, unfortunately, requires changing two files: >> matterhorn-runtime-dependencies/pom.xml and system.properties. There >> are many options for improving this, but my goal wasn't an overhaul, it >> was to fix the short term problem of runtime dependencies on a remote >> http server. > > What happens when those files are updated? Does it auto-flush the lib > directory? Does this present an issue when there are multiple version > of the dep in the lib directory? This is very similar to my solution, > except that when something changed in system.properties I would get an > SVN conflict and know it was time to redownload all my deps :) > > G > >> If you just want to upgrade the 3rd party jars, you can either manually >> copy the new jar into lib or change the pom and rebuild >> matterhorn-runtime-dependencies. You'll always need to up update >> system.properties. >> >> Does that make sense? >> >> In the future, I could envision a mechanism to auto-load everything in >> lib, but we'd need to be careful to deal properly with start levels. >> >> Hope that helps, >> Josh >> >> On Sep 19, 2011, at 2:00 AM, Rubén Pérez wrote: >> >>> Hi Josh, >>> >>> >>> Does this mean that, should we change those 3rd party bundles (for >>> instance to upgrade versions), they will be updated as soon as we >>> rebuild? BTW, what if we *just* wanted to update those 3rd party jars >>> and we do not "deploy" the jars? Would the /lib contents be updated >>> anyway or is deploying required? >>> >>> Not trying to be critic here, just to understand well the new mechanism. >>> >>> Thanks >>> Rubén >>> >>> 2011/9/18 Josh Holtzman <[email protected] >>> <mailto:[email protected]>> >>> >>> I've committed r10974 as part of MH-8161. This changes the way we >>> load 3rd party OSGI bundles on startup. Now, when you build >>> Matterhorn with -DdeployTo=$FELIX/matterhorn, the 3rd party jars >>> will be deployed to $FELIX/lib. Once you rebuild your code and >>> update your config.properties and system.properties files, you'll >>> be able to remove $FELIX/felix-cache at will, without fear of >>> requiring another long download from nexus. >>> >>> Let me know if you run into any problems with the new approach. >>> >>> Thanks, >>> Josh >>> >>> On Sep 14, 2011, at 7:52 AM, Josh Holtzman wrote: >>> >>>> Shouldn't be difficult at all. I can probably do it this weekend. >>>> >>>> Josh >>>> >>>> On Sep 14, 2011, at 7:44 AM, Rubén Pérez wrote: >>>> >>>>> Josh, >>>>> >>>>> Is it too difficult to get rid of those http dependencies? Does >>>>> not seem logical that all the Matterhorns around the world stop >>>>> working just because a server is down... >>>>> >>>>> Regards >>>>> >>>>> 2011/9/14 Greg Logan <[email protected] >>>>> <mailto:[email protected]>> >>>>> >>>>> Remember to also grab the ones from the bottom of >>>>> config.properties. That's what got me, I had them all >>>>> except for the two security related ones from the other file :( >>>>> >>>>> Is there a ticket related to this? Seems like an easy >>>>> enough fix (we have a script to do this locally) that we >>>>> might be able to push it into 1.3... >>>>> >>>>> G >>>>> >>>>> Josh Holtzman <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>>> The solution is simple: replace every reference to a >>>>> dependency starting with http:// with file://, and of course >>>>> ensure that you've got the dependencies locally. I've been >>>>> advocating both on and off list to change >>>>> config/system.properties to remove all dependencies >>>>> delivered via http for what seems like a year now. We can >>>>> even deliver all of the dependencies in a zip, and have >>>>> maven unpack them for us. >>>>>> >>>>>> Josh >>>>>> >>>>>> On Sep 13, 2011, at 7:56 AM, Rubén Pérez wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> It's nice to know that felix won't work if the repository >>>>> is down, EVEN IF YOU HAVEN'T RECOMPILED. >>>>>>> >>>>>>> I have just wiped out the contents in our development >>>>> installation, and erased the logs and the felix-cache, as >>>>> always. Now felix won't work, even though I didn't compile >>>>> anything. The system is just as it was before, I just >>>>> deleted the cached data. Still, it requires the repository >>>>> to be up, so it can download who-knows-what. Really? >>>>> Seriously *every* single Matterhorn installation in the >>>>> world depends on a simple repository being reachable? You >>>>> have to be kidding me... >>>>>>> >>>>>>> >>>>>>> 2011/9/12 Adam Hochman <[email protected] >>>>> <mailto:[email protected]>> >>>>>>> thanks. I missed Greg's original email. >>>>>>> >>>>>>> >>>>>>> On 9/12/11 2:28 PM, Schulte Olaf A. wrote: >>>>>>> Tobias is offline Monday evening, but we'll take a look >>>>> first thing tomorrow morning; sorry for the inconveniences >>>>> caused. >>>>>>> >>>>>>> O >>>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: [email protected] >>>>> <mailto:[email protected]> >>>>> [mailto:matterhorn- <mailto:matterhorn-> >>>>>>> [email protected] >>>>> <mailto:[email protected]>] Im Auftrag von Adam >>>>> Hochman >>>>>>> Gesendet: Montag, 12. September 2011 23:22 >>>>>>> An: infra; Opencast Matterhorn >>>>>>> Betreff: [Opencast Matterhorn] nexus is down<IMPORTANT> >>>>>>> >>>>>>> I don't have access to this host so there's not much I >>>>> can do. According >>>>>>> opencastproject.org <http://opencastproject.org/>'s cname >>>>> records, it looks like repository.opencastproject.org >>>>> <http://repository.opencastproject.org/> >>>>>>> points to opencast01.opencastproject.org >>>>> <http://opencast01.opencastproject.org/> which resides at >>>>> ETH Zurich. Our list >>>>>>> server and download area also reside on that server but >>>>> they appear to be working. >>>>>>> Walt is trying to find his ssh keys, but in the interim >>>>> it would be great if someone >>>>>>> from Zurich could take a peek. >>>>>>> >>>>>>> Thanks, >>>>>>> Adam >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Matterhorn mailing list >>>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>>>>> >>>>>>> >>>>>>> To unsubscribe please email >>>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Matterhorn mailing list >>>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>>>>> >>>>>>> >>>>>>> To unsubscribe please email >>>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Matterhorn mailing list >>>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>>>>> >>>>>>> >>>>>>> To unsubscribe please email >>>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Matterhorn mailing list >>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>>>> >>>>>> >>>>>> To unsubscribe please email >>>>>> [email protected] >>>>> <mailto:[email protected]> >>>>>> _______________________________________________ >>>>> _______________________________________________ >>>>> Matterhorn mailing list >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>>> >>>>> >>>>> To unsubscribe please email >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> _______________________________________________ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Matterhorn mailing list >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>>>> >>>>> >>>>> To unsubscribe please email >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> _______________________________________________ >>>> >>> >>> >>> _______________________________________________ >>> Matterhorn mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please email >>> [email protected] >>> <mailto:[email protected]> >>> _______________________________________________ >>> >>> >>> _______________________________________________ >>> Matterhorn mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please email >>> [email protected] >>> _______________________________________________ >> >> >> >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
