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

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} This page is a work in progress. It seeks to identify the needs of the different kinds of people consuming deployments listed on the Solutions 1.0 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)

Ideal experience

<todo: split this between Eclipse and non-Eclipse developers?> Due to the highly componentized nature of Higgins, it's preferable for the developer to be able to either:

  1. pull down a single project and use it's build script to fetch all dependencies, or
  2. use some master file (akin to an Eclipse .psf) to fetch the deployment project and all dependencies at once.

Once the dependency project and all dependencies have been fetched, the deployment and all dependencies can be built. Note that both steps could be accomplished at once if the build target which is responsible for building dependencies were smart enough to fetch those dependencies when they didn't already exist (i.e. ant has a useful cvs task that can be used to perform a cvs update within the ant script)

Note that a deployment will depend on a specific version (or specific versions) of Higgins components. While a "deployer's deployment" will/should already contain the appropriately versioned jar files, a buildable deployment must be able to fetch and build the correct version of each dependency project. This could be done by each project, as it is fetching it's dependencies, it specifies the correct version. In theory, a fetched version of a dependency project will in turn fetch the correct version(s) of sub-dependency projects it has listed.

After the build step is complete, ideally one would be left with a package similar to, or the same as that used by a deployer which can then be installed and configured as above.

<todo: copy profiles as above, or is it sufficient to say the build result should be the same as what a deployer gets?>

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.


Proposal

  • Convert “Components” page to an HTML page. (This will allow the nightly build (and soon the nightly test) LED indicators to be resurrected)
  • Rename the page “Downloads”. Get rid of the current Downloads page. Get rid of “Components” menu item from the left menu.
  • Add the missing content to make it a full downloads page. At present it is just a list of individual eclipse “projects” organized into what we call “Components” (still pretty low level). What’s missing are the top level “solution” level items and the mid level “sub-solution” items. These are currently BURRIED in the solutions description wiki pages. They need to be moved to the Downloads page and links put to them FROM the solution description wiki pages.
  • Top Level: Entire packaged solutions (e.g. Entire .zip file packages or installer executables)
  • Mid Level: For example, HBX-for-IE, AIR-Selector client, .WAR deployment files for STS or I-Card Service, etc.
  • Get rid of the text at the top of these intermediate pages (e.g. http://www.eclipse.org/higgins/ver2/downloadsnew.php?loc=downloads/saml2idp.server). The title is wrong “Higgins Downloads” <-- should be the name of the project. The text below that is wrong “Here you can find links...” <--no you can’t. This particular page has no builds on it too. Why is that? Are there no builds for this?
  • Need to go through every link in the Downloads column of the current “Components” page and fix the broken pages. Most are broken (i.e. They contain no “rows” in the table—that is below the words “Below are the recent builds for this item. “)
  • The following page is a high level (TOC style) overview of what content we want to see on this updated download page: New Higgins Download Page Proposal

See Also

Back to the top