> -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > The location of block.xml is not important. It can be anywhere. > Copy it to a local place if you think you will have network problems. > JARs will be cached locally automatically.
Yes, this I know. My point is, the advantage of JNLP and similar systems is that you can have one point of deployment and automatically update all your clients. You can also still run the apps (pointing to the same link) in online or offline modes. This is a critical feature to me. Let me lay out an example: You're developing a set of applications for company internal use. The applications include NT services which run 24/7 on the client machines in the background and a couple of GUI Swing apps which can be launched from the users desktops. You have more than 50 clients and you need to be able to push updates to all clients without requiring anything other than restarting the application or perhaps their PC (in the case of the NT services). Some applications require network access, while others must run in online or offline modes. Solution? Well, there are lots. But Avalon (and Merlin specifically) solves most of these problems. You can install one instance of the Merlin platform and run all of these applications from that. You can use the service wrapper for the NT services and create batch files or shortcuts which use Merlin to launch the Swing apps. It all works pretty easily this way and you get the luxury of using a single consistent application framework. The trick is the auto-updates and online/offline capabilities. By having the applications launch via a remote URL (as your example showed), you can easily update _everything_ just by updating the application's block.xml on your intranet server. As long as Merlin has fairly robust network download capabilities (which could be improved), this solves your auto-update. Moreover, with Merlin's configuration override feature, you can have global configuration information in the blocks, but local configuration files that are client specific. Very nice. The trick is the online/offline system. If you're block.xml files are local, well, there goes your auto-updates. If they're remote, well then when you're in offline mode, you can't launch the application. Luckily there are a couple of simple solutions for Merlin. One is to introduce a new online/offline parameter (or cache) parameter, in which Merlin treats the URL like any other sort of resource. If it can't find the remote one, it goes looking into the local repository for the one it downloaded last time. Taking this to the next step, if the repositories are set up such that blocks (or whatever we call them) are included in the repository like so: /repository/projectName/blocks/block-2.3.xml or something like that. Then you should be able to launch the app by just saying: merlin.sh -execute projectName-2.3 and then Merlin goes looking for the app in remote or local repositories. Since we want Merlin to launch the latest and greatest from the remote repository each time, we can take advantage of the SNAPSHOT feature and say: merlin.sh -execute projectName-SNAPSHOT and that should do it. I'd like to add that you can ALMOST do this now, but it requires a local block.xml file which imports the other blocks as SNAPSHOTS and thus requires downloading of each of these blocks (as jars) from the repository each time the application is launched. If we could just download the block.xml file that would save on a lot of network traffic and improve startup times. So this rather long response brings me to the conclusion that just about everything should be in place. I didn't completely follow the updates to the repository package, nor am I completely up to date on all of the options for launching merlin (once there was something about .bar files, is that still there?), so perhaps this is all implemented and I'm just behind. But even in that case, I think my little example points out some of the possibilities with Merlin. > > Sounds like we're redoing a lot of JNLP. > > Yes, BUT... > 1. JNLP requires explicit declaration of JARs to download. Merlin can > derive > that information. > 2. JNLP requires explicit declaration of where to download from, no notion > of > repository. Merlin knows layout of Repositories (Maven type only at the > moment) and will pick up the JARs from there. So if you change the > repository > location, you have a single line to change. Certainly. There are a number of advantages of the Merlin block.xml system compared to JNLP. My point is that we're getting close to completely replicating that technology. And if that is the case, then there's still more we can learn from it. J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
