Should I add my Websphere Liberty Profile project to SCM?

4
votes

When using the Websphere Developer Tools for Eclipse, projects with names like 'WebSphere Application Server Liberty Profile' are added to the workspace. These contain the usr section of my Liberty installation, so contain things like extension ESAs, server.xml files, shared JARs, and so on.

It seems like it would be a good idea to have this project stored in SCM so that my team has exactly the same Liberty server.xml, extensions, and shared dependencies. Is this a good idea?

If it is a good idea, my further questions are:

  1. does the Liberty installation need changing to refer to what will be a new copy of the usr folder inside the workspace rather than inside the Liberty installation dir?
  2. what should be added to my SCM's ignore file for this project, or should everything be checked in?

If it's not a good idea, my further question is:

  1. how we should share this type of configuration within a team to avoid individual configuration? The goal is to be able to get the source from SCM and immediately have it in Eclipse, building, with no red X error markings.
1
eclipsewebsphere-liberty

1 Answers

2
votes

The user and product files in Liberty are designed to be separate, so a use case of the usr directory in SCM should be fine. The separation allows for things like sharing servers, configuration, and also easier migration, not only between servers of the same version but in future versions.

Here's a good set of information on the design, and some basic specifics, on user and runtime file design.

To answer specifically:

1) You can point Liberty to any usr directory location using the "WLP_USER_DIR" environment variable. See Customizing the Liberty Environment

2) I don't have 100% specifics on the ignore files. Startup liberty and check what is created and what is not touched. Generally this will be folders prepended with a dot, but some of this will be specific to your particular server and usage.

3) There is a wide range of ways you can share the user config, up to and including repackaging the entire server to remove the binaries that aren't used by your feature configuration. There is a decision to be made for sharing around where the application source lives and builds, and where the server lives and runs. Sharing "the configuration" can be as simple as a version controlled usr/servers/server.xml.