Support reading in the new liberty-plugin-config.xml format.

In the UtilitiesTestCase, after each package install test, the runtime should be removed so that the next package install test does not pass incorrectly.

Display the Gradle build folder in the Servers view for Gradle servers. Similar to the Maven target folder it should have its own icon and "(derived)" next to it.

Respond to configuration changes in the src folder:

• Invoke Gradle task to get the changes moved over to the build folder
• Notify the server of the changes

If an application which contains imports of any class under javax.faces.* is added to a Liberty server, <feature>jsf-2.2</feature> is automatically added to the feature list in server.xml. This is sensible when an application uses JSF but no feature which provides it is present in server.xml.

However, jsfContainer-2.2 is a feature which allows applications to provide their own implementation of the JSF specification while still using the specification interfaces. If jsfContainer-2.2 is already specified, It isn't ideal behavior to also enable jsf-2.2, since that would enable the implementation provided by the runtime, which I don't want. This is the current behavior.

If jsfContainer-2.2 is already specified, The jsfContainer implementers and I think the jsf-2.2 feature shouldn't be added automatically. Thoughts?

Create build script to allow local build and running personal build

The top level feature says "WebSphere Application Server Liberty Tools". Change it to "Open Liberty Tools" so that it's more clear when being installed alongside WDT.

[1] Steps to reproduce to follow, but deleting the server 'only' could result in stale target runtime information in the Maven/Gradle project. When you import the project again, the migration dialog appears and will be prompted to choose a compatible runtime.

[2] Also, another issue is that because the targeted runtime is burned into the faceted project XML metadata, the project isn't 'portable'. eg. if the user zips up the project for sharing, and if another user tries to import the project into their workspace, then that user will get the migration dialog. Perhaps, we need to see if we can extend the export wizard to remove this targeted runtime?

org.eclipse.wst.common.project.facet.core.xml

Update the plugin and feature versions

A number of classes in Open Liberty Tools need to be updated to add CDI 2.0 support and to accommodate CDI 2.0 support in the Open Liberty runtime.

A list of components (but not exhaustive) that have files that need to be updated are:

• com.ibm.ws.st.core
• com.ibm.ws.st.jee.core

The com.ibm.ws.st.liberty.tools.base feature has the following problems:

1. The version was downgraded to 0.0.1 instead of being upgraded to 1.0.2
2. A requires is missing for the common ui feature
3. For the requires the versions have .qualifier on the end which should not be there

BluemixLinkTest - The text in the web page has changed so update the test case
Docker external folder tests (JEEPublishWarNoDDExt, JEEPublishEarDDExt) the temp directory used to copy the projects into should be cleaned up

Update the server label to: Liberty Server
Update the runtime label to: Liberty Runtime

Support bootstrapProperties in the Gradle version of liberty-plugin-config.xml. These should be read in and added as bootstrap variables when processing the src server configuration.

Create a feature for Gradle support.

The maven-specific publishing code should be moved to the LibertyMavenJEEPublisher class in the com.ibm.etools.maven.liberty.integration plugin. Otherwise, it will be called 'twice' if another build plugin type is used.

After importing a Liberty Gradle project, the scan job is waiting a long time and appears to be unnecessarily excessive. User impact: this translates to a long delay before the prompt dialog appears.

If a Gradle project is imported make sure it is built and the liberty-plugin-config.xml file is generated if the project has Liberty integration.

-> This may not be needed if the ecosystem tools can do the build

The incorrect context root used to launch the browser when using Run on Server on a Servlet that is contained in a web module that is referenced in an EAR deployment assembly with the non default archive name.

Steps to reproduce:

Create a liberty server
Create a new web project that is added to an EAR
Open the EAR deployment assembly properties page and modify the Deploy Path for the web project so that it has a different name. Apply the change and close.
Create a servlet in the web project and do a Run on Server action on it.

Result:
Context root not found. Notice that in the server console log the web application is deployed and started and the context root matches the archive name in the deployment assembly. According to JEE spec this is the correct default context root.

From the JEE7 spec APPLICATION ASSEMBLY - 8.4.1 Assembling a Java EE Application section:
The context root is a relative name in the web namespace for the application. Each web module must be given a distinct and nonoverlapping name for its context root. The web modules will be assigned a complete name in the namespace of the web server at deployment time. If there is only one web module in the Java EE application, the context root may be the empty string. If no deployment descriptor is included in the application package, the context root of the web module will be the module name. See the Servlet specification for detailed requirements of context root naming.

Support multiple servers in build.gradle file

The Open Liberty Tools rely on a wlp/lib/version/WebSphereApplicationServer.properties file in order to tell that Liberty is installed. This file includes WebSphere branding information which isn't appropriate for Open Liberty so a new openliberty.properties file was added in its place. This means the tools can't detect Open Liberty though.

Raising the issue to facilitate discussion on how to fix. Issue was raised on groups.io

The following will be done for this issue:
- rename the docker feature to com.ibm.ws.st.docker.base
- create a new top level feature named com.ibm.ws.st.liberty.tools that pulls in:

•     com.ibm.ws.st.liberty.tools.base
  

•     com.ibm.ws.st.docker.base
  

There is inconsistent behaviour in OLT with how different types of error links handle selecting and highlighting the affected lines of code. If a link of the form: <ClassName>.<methodName>:<LineNumber> (e.g. TestServlet.doGet:31) is clicked, the cursor in the editor will move to the selected line, but will not highlight the line. However, if a link of the form <ClassName>.java:<LineNumber> (e.g. TestServlet.java:31) is clicked, the cursor moves to the affected line and the line is highlighted.

To Reproduce:

1. Create an Eclipse workspace with Open Liberty Tools installed with an Open Liberty server configured
2. Create a Dynamic Web Project and add a servlet to it
3. In the servlet's java file, add the following:

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
     int i = 12;
     String s = "hello";
     response.getWriter().println(s + "" + i + k);
}

4. Deploy the project onto the server and navigate the Eclipse browser to the servlet's page
5. Error links should show up in both console and web browser. Try clicking both types of links (e.g TestServlet.doGet:31 and TestServlet.java:31) to see the difference between the two.

The ConsoleLineTracker.openJavaEditor() function in com.ibm.ws.st.ui is responsible for handling error links of the form <ClassName>.<methodName>:<LineNumber>, and it calls editor.selectAndReveal(start, 0), where the two parameters are the starting position and total length to highlight. It seems changing the 0 to the length of the line should fix this inconsistency, however I'm not sure of what other functionality it may break.

Currently if a module fails to publish on to a server, a NPE will be thrown without any further information as to which module failed to publish. A solution is to wrap the call to either publishDir in JEEPublisher.publishModule (or the call to publishSmart in ApplicationPublisher.publishDir) with a try/catch and print out an error message informing the user which module failed to publish.

Example Stack Trace:

java.lang.NullPointerException
at org.eclipse.wst.server.core.util.PublishHelper.publishSmart(PublishHelper.java:331)
at org.eclipse.wst.server.core.util.PublishHelper.publishSmart(PublishHelper.java:367)
at org.eclipse.wst.server.core.util.PublishHelper.publishSmart(PublishHelper.java:367)
at org.eclipse.wst.server.core.util.PublishHelper.publishSmart(PublishHelper.java:188)
at com.ibm.ws.st.core.internal.ApplicationPublisher.publishDir(ApplicationPublisher.java:886)
at com.ibm.ws.st.jee.core.internal.JEEPublisher.publishModule(JEEPublisher.java:170)
at com.ibm.ws.st.core.internal.ApplicationPublisher.publishModuleAndChildren(ApplicationPublisher.java:147)
at com.ibm.ws.st.core.internal.ApplicationPublisher.publishModuleAndChildren(ApplicationPublisher.java:153)
at com.ibm.ws.st.core.internal.ServerExtensionWrapper.publishModuleAndChildren(ServerExtensionWrapper.java:358)
at com.ibm.ws.st.core.internal.WebSphereServerBehaviour.publishApplication(WebSphereServerBehaviour.java:1195)
at com.ibm.ws.st.core.internal.WebSphereServerBehaviour.publishModules(WebSphereServerBehaviour.java:946)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:987)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)
at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3172)
at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:345)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

If the user selects not to create the runtime and server when they import a Gradle project that has Liberty integration then they should still have the opportunity to create it later. The same if they add the Liberty integration after importing the project. They should be able to do this by:

1. Right click on the project and select Gradle -> Create Liberty runtime and server
2. If the user selects no when asked to create a runtime and server on project import then a ghost runtime should be created and shown in the Runtime Explorer view. The user can later right click on this runtime and select Create runtime and server.

The DDE plugin and feature versions need updating as well.

Contribute plugins that will provide workbench integration to manage Liberty servers in a manner that supports the Continuous Integration workflow.

Support multiple applications in the build.gradle file.

The following message suggests starting the remote server in order to publish but remote start is not supported so remove the message. The server will be in republish state.

"The server needs to be started so that you can publish. Start the server and publish again."

Implement the code needed to run a Gradle task. See https://docs.gradle.org/current/javadoc/org/gradle/tooling/BuildLauncher.html for sample code.

Rename the com.ibm.ws.st.liberty.buildplugin.integration to com.ibm.ws.st.liberty.build.integration

The JEEContextRoot_EAR_NoDD_CRinWebXML is failing because of a commit for issue #18. The change will be reverted until the problem can be further investigated.

Looks like the Scan Job is scheduled on 'any' workspace resource change with project deltas.

However, we know that when the Create server and runtime action is selected on the build type (eg. Maven) then a new project folder is created, at least. If this is the only thing that results in a workspace resource change, then the LibertyManager could be more refined and not trigger another ScanJob.

This issue is opened to investigate whether LibertyManager can be made smarter and not start the scan job when our own runtime project is created. (eg. check the event source if it is 'us')

The action results in at least two resource deltas. One on the build plugin project and one on the new runtime project, and both resulted in new Scan Jobs.

Support non-loose configuration publishing for Gradle ear projects:

• Invoke minimal Gradle task to build the aggregate parent and get the application updated
• The server should be notified of the changes

Support loose configuration publishing for Gradle war projects:

• the server should be notified of changed application files

The problem is in the WebSphereServerBehaviour.checkModuleConfigOutOfSync method. If more than one ServerExtension supports the application type it does not keep checking for an out of sync situation.

Also, the OutOfSyncTest needs to be fixed up so that the imported modules compile properly.

Support loose configuration publishing for Gradle ear projects:

• The server should be notified of changed application files

The Gradle server and runtime associated with a Gradle project should be deleted if the project is deleted.

This feature will provide the same level of function as the existing Maven support for Open Liberty Tools

Improve the tracing in JMXConnection.notifyFileChanges to include the added/changed/removed files.

Add the icons for Liberty Gradle integration:

• one for the Gradle build folder
• one for the ghost runtime

Listen for changes to the liberty-plugin-config.xml file and respond appropiately.

When the user imports a Gradle project that has Liberty integration they should be prompted to create the runtime and server.

Support non-loose configuration publishing for Gradle war projects:

• The correct Gradle tasks should be invoked to rebuild and install the application without performing any other tasks that are not necessary (minimal tasks to get the application updated)
• The server should be notified of the changes