On Tuesday 13 January 2004 13:47, Farr, Aaron wrote: <snip reason="good stuff" future="wiki?" />
> 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. That makes a lot of sense, and sounds like it could be implemented in minutes... But only by the Wizard himself. > 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 "Or Something Like That". I think we should in that case follow the same notion as for other repository artifacts, i.e. a Group and ArtifactID, followed by an optional version argument. ArtifactID could also default to block.xml, and you would then have; merlin -launch myproject or merlin -launch myproject;main-server.xml or merlin -launch myproject;backup-server.xml;2.4.1 Yeah, it does sound right to me. Stephen?? (This belongs on dev list actually.) > 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. Sure. What I was trying out a few weeks ago was to use JNLP to download and start the Merlin bootstrap, which in turn launched the application. In this scenario, I have NOTHING installed on the local machine, not even the Merlin bootstrap or whatever, and could easily push everything except the JVM. Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
