Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Deployment Requirements

Revision as of 01:18, 17 October 2007 by Jimse.novell.com (Talk | contribs) (Deployers)

This page is a work in progress. It seeks to identify the needs of the different kinds of people consuming deployments listed on the Deployments page.

Deployers

These people would like the easiest method of downloading something, configuring it, and running it. Furthermore. they:

  1. would probably rather not deal with running a make.
  2. probably don't want to deal with searching the world for jar files.
  3. are not interested in source code or (re)building the project.
  4. may or may not have Eclipse installed

Ideal experience

Probably the most ideal experience here is that this person is able to work with a single installation file (this may be a WAR, some form or archive that simply needs to be exploded, or an install program. The form depends on the deployment and target platform/environment.

One would likely want to download this file, perform the "install" step, followed by whatever "configure" steps are necessary.

<todo: discuss the pros/cons of a script used to install (which would allow for the fetching of non-redistributable libraries)

WS servlet profile

When the deployment makes sense as a WAR file, this experience is typical:

  1. <todo>

Note that some post install steps such as fetching non-redistributable jar files may be necessary

WS or other web client profile

<todo>

BX profile

<todo: talk about different scenarios (standalone BX, BX + other processes, etc.), different browsers>

Standalone app profile

<todo: overview> <todo: when Java, this could be an archive containing all the jars/classes/config items needed> <todo: talk about non-redist libs>

Developers

These people are made up of developers and those who prefer to learn by digging into the code and perhaps tweaking it. Developers may want to change existing code or wish to write 'providers' or 'handlers' for some of the components that offer that ability. Furthermore, they:

  1. probably don't want to deal with searching the world for jar files.
  2. may have Eclipse installed and want to use the IDE. If so,
    1. probably want an easy way to get all dependency projects
  3. may not have Eclipse installed, and/or want to use some external way of developing. If so,
    1. may want to get dependency projects
      1. this should be fairly easy to do, not requiring them to hunt around for information
    2. may want to only get dependency binaries (no code for dependencies)

Dirty-handed Deployers

These are deployers who, before deploying prefer to learn about the workings of a deployment by getting their hands dirty. They essentially act like developers to a degree and at some point switch playing the role of a deployer.

Packagers

These are people who have probably become familiar with one or more deployments and wish to create their own custom deployment by packaging or repackaging existing Components and/or Deployments They likely share some of the attributes of deployers, but really they're more like developers in that they are seeking to package their own solution.

Back to the top