Farr, Aaron wrote:
-----Original Message----- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 4:48 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [RT] The Much-Needed Kitchen Sink Distribution
Hi gang,
an idea that first came into being in the Phoenix Development Kit (PDK) that we never quite finished. Lean and mean is a good idea in general, but as a demonstration of power, features, and an actual setup a "kitchen sink distro" can be very useful as well.
I've raised the idea several times before. Lets see if the spark can gather the critical mass required to start the lightning strike :D. I'm not going build this thing, but I can help to set some basic things up if there's enough interest. Responses to the development list please.
- Leo
+10000
Sounds similar to Enterprise Object Broker server (which is phoenix-based), but having something like this out of the box from Avalon would be cool. If nothing else, it would be a nice way to 'show off' Avalon.
More Random Thoughts:
- This somewhat flies in the face of the "The Avalon project is about the framework, not the applications" focus which I've seen. How big of an issue is that?
- There's lots of ways to do this with merlin. Various distributions could
just be various 'block.xml' files, plus perhaps some local config files. In
otherwords: 1. Download + Install Merlin
2. Download this small zip which defines Avalon Distribution flavor 'A'
3. run merlin.sh/bat on the included block.xml
4. Downloads resources from appropriate repositories.
Its easier than that!
$ merlin -install <your-block-url>
The url reference a deployment unit (in the merlin case its a bar file). Take for example something like James. It possible to package the core or james into a bar and with one command populate you local repository with everything required in accordance with the applicable licenses (and in the james case this includes bundled mail and activation jar files). Then execute:
$ merlin %MERLIN_HOME%\repository\james\xmls\block.xml -config %MERLIN_HOME%\repository\james\xmls\config.xml
bingo - your operational.
Advantages: We wouldn't have to host third party jars on avalon, just point to the third-party repository. This gets us around some licensing issues I would think.
Using references to third-party content partially addresses the issue but not completely (e.g. the James case where your required to bundle the mail and activation jar files from Sun). What this means is that as far as a bar file for james is concerned, the activation and mail file are installed into the users repository under the james group.
Alternatively, you could also create a 'pre-installed' merlin distribution
that already has all the resources loaded.
I think a better approach is to use jnlp to install a bootstrap system then simply parameterize the install with you application. The bootstrap install can check if merlin is installed, install if necessary, then proceed with installation of an app using bar urls. I'm already playing with some of these ideas and have established of experimental component repository that is basically aimed to be an intelligent front-end to the maven repository supporting component selection/installation/configuration/deployment based on *function* or *product*. For example, you could request an "instant messaging solution", or directly request the "OpenIM" product. Using the bar structural unit of deployment, jnlp for product deployment logic, product descriptors, block descriptors, and type descriptors - we have a total scenario. Add to this the ability to reference services in a block via urls that link back to the repository and bingo you have any kitchen sink you want.
;-)
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
