I cannot distribute the jar files for WebSphere on the internet. I'm sure it would cause all kinds of legal issues. You'll have to import the missing jar file from WAS full profile.

Since this plugin packages 2 plugins together (Liberty and Full Profile), you'll need each dependency to build it.

You'll need import the admin jar from the full profile using the following:

mvn install:install-file -DgroupId=com.ibm.ws -DartifactId=admin -Dversion=8.5.0 -Dpackaging=jar -Dfile=<path to the admin jar for websphere full profile>

Hope this helps

@Julie, Are you looking for a SysOps solution where a Jenkins Job will merely update a remote Liberty instance's configuration without deploying an application? Give me the requirements and I'll plug it into the roadmap to create a separate plugin if this is the case. Please advise.

I would like a Jenkins Job to deploy a war file to a remote Liberty instance as well AND set the configuration.

Although, I don't have a use case currently for changing the configuration without deploying an application, it might be handy.

Thanks for clarifying the use case.

Here are the steps I see.

1) User must manually setup connectivity in server.xml for the remote WLP instance (required in order to connect to WLP remotely)
2) A new field will be added to the plugin configuration (Inject server.xml: ________________) where a local file path (to a new server.xml) will be required.
3) The new server.xml must not override the security configurations or you won't be able to redeploy to it. (i'll put checks in place to prevent that)

If you agree with the above, let me know. I'll have development done in a few hours if this will work.

So it will merge the provided server.xml with the one on the remote server? So if I have 3 wars, and I'm deploying a 4th, does the provided server.xml have to contain the definitions for all 4, or just the new one?

Shoot me a list of configuration elements you need initially and I'll make a UI for just those elements in the plugin. I'll ultimately have to merge the configurations together. Give me the baseline elements you want to manage in server.xml and we'll go from there.

Here is a sample:
<application type="war" id="manda-brand-service" name="manda-brand-service" location="${server.config.dir}/apps/manda-brand-service.war">
<application-bnd>
<security-role name="manda">
<special-subject type="ALL_AUTHENTICATED_USERS" />
</security-role>
</application-bnd>
</application>

Hello Gregg,

We are facing a similar problem where we are unable to deploy the files using the plugin to apps directory.

Here is our use case.

1. We would want to deploy the WAR files to apps directory instead of dropins directory. Jenkins WebSphere Deployer plugin by default is picking up dropins directory and nothing else.
2. As per the documentation we tried changing server.xml as below and did not work.

<remoteFileAccess>
<readDir>${server.output.dir}/apps</readDir>
<writeDir>${server.output.dir}/apps</writeDir>
</remoteFileAccess>

3. Another observation is, in the help section, as per this URL we need to update server.xml as. Even if we do not specify dropins, by default files are getting deployed to dropins directory.

<remoteFileAccess>
<readDir>${server.output.dir}/dropins</readDir>
<writeDir>${server.output.dir}/dropins</writeDir>
</remoteFileAccess>