1) agree on package format - zip is easiest with Java because it's built-in .. I'd need to look for a tar/gz library otherwise

2) agree on manifest format - i recommend inside the ZIP is a file called manifest.emp that is something like:

<empeg-app>

  <!-- metadata about the app -->

  <uid>org.jempeg.Application1</uid>

  <name>My Application</name>

  <version>1.0</version>

  <author>Mike Schrag</author>

  <email>[email protected]</author>

  <description>A Sample Application</description>

  <homepage>http://www.jempeg.org</homepage>

  <license>This is the text of my license.  Don't steal my code</license>



  <!-- defines requirements -->

  <requires>

    <!-- a required package -->

    <package>

      <uid>org.jempeg.Application0</uid>

      <version>1.0</version>

    </package>



    <!-- required empeg version -->

    <!-- one of min or max is required -->

    <empeg min = "2.0b10" max = "2.0b12"/>



    <!-- one of min or max is required -->

    <hijack min = "242" />

  </requires>



  <!-- config-ini defines values that are to be set in config.ini -->

  <config-ini>

    <!-- "set" values will automatically be set, description is optional -->

    <set name = "key1" description = "Key #1" value = "value1"/>

    <set name = "key2" description = "Key #2" value = "value2"/>

    <set name = "key3" description = "Key #3" value = "value3"/>



    <!-- "ask" values will be asked to the user.  "enum" would be a drop-down box -->

    <ask name = "color" description = "Your favorite color" type = "enum">

      <valid-response value = "red"/>

      <valid-response value = "blue"/>

      <valid-response value = "yellow"/>

    </ask>



    <!-- "ask" values will be asked to the user.  "text" would be a text field -->

    <ask name = "yourname" description = "Your name" type = "text"/>

  </config-ini>



  <app-ini>

    <!-- same as config-ini but would go into the app.ini file in the package directory -->

  </app-ini>



  <!-- files defines the set of files to be installed -->

  <files>

    <!-- target of "relative" would install this file (w/ full directory) relative to the user's install dir -->

    <file src = "/file/inside/of/zip/1.file" target = "relative"/>



    <!-- target of "absolute" would install this file (w/ full directory) to absolute path (like /etc/whatever) -->

    <file src = "/file/inside/of/zip/1.file" target = "absolute"/>

  

    <file ...... >

    .

    .

    .

  </files>

</empeg-app>

3) decide where manifests are stored after install
(so jEmplode can introspect your Empeg for installed apps to determine version dependencies). Probably shuuld be renamed to /somewhere/packages/{uid}.emp where uid is the UID from the manifest file.

4) Add it to jEmplode

What do you guys think? No promises on delivery time of something like this, but it's very doable.

Mike

Yep sounds good...

a couple of things:

<set name = "key1" description = "Key #1" value = "value1"/>

this should have a section= attribute as well to say which section the key should be added to (ie [hijack] or [irconfig])

How should <ask>ed values be referred to in setting config.ini keys...?

Cheers

Kim

Hi.

This looks very good and promising. However, the package description lacks a few features.

1. default installation directory
2. optional installation of specific files (like language dependend(sp?) files)
3. variable substitution in config.ini writing and file placement
4. execution of an installed file during/after the install process
5. uninstall information (files to delete, cleanup program to run,...)
6. dependence upon one package out of a list of many (like a naviagtion system needs at least one of the accompanying map packages).
   

The default installation directory might be something like /opt/<uid>/ generally, but I think it should be possible to override that default if the programmer wants that.
Optional installation of specific files might be combined with variable substitution, and isn't really necessary, but would be a nice plus if we ever get larger volume packages (like language dependent voice output with a navigation system).
Variable substitution would be usefull in various circumstances, but I think it would be most useful in the config.ini/app.ini sections.
Command execution would be useful to do additional manipulations the installer doesn't support on its own, like making symlinks (I don't think that is possible via FTP, is it), or (in the case of deinstallation) cleanup of application databases etc.
Finally, if we can install a package, we might also want to uninstall it at a time, so we need to have info for that as well, e.g. the names of files the application generates while running, or other files that don't exist and are not created by the install, but need to be removed on uninstall.

cu,
sven

Just thought I'd pop this back up to the top 'cause it'd be great to have this functionality in JEmplode. I'd lead to more exposure of the things that are out now, such yn0t's programs, as well as encourage and and make easier to install future projects.

This JEmplode functionality should go hand in hand with the functionality siberia37 was describing earlier that lets you selectively start and stop programs from the hijack menu so that they're not taking up memory all the times when you don't need them.

With these two parts we'd be well on our way to having easily usable programs For the Masses (tm). So count me in as another person who'd like to see this happen.

John

Hell yeah. I don't have the time to do an installer, but I would gladly use one for my programs if it were available. There's a lot of issues to be worked out, I think, as has been mentioned before, getting a "standard environment" on the Empeg (with alternate root partition, etc.) is a prerequisite of such an installer. Not that it couldn't be done without, but it would be pointless to install apps and have them overwritten by an upgrade.