First of all let me say thank you to all the hard-working developers of the Buildship plugin.
I’m suspecting there is an easy answer to this that I’m just not seeing.
We have a multi-project setup that builds EAR archives for deployment on a WebSphere server, as well as a JAR for deployment on a different server.
We recently stood up a Jenkins server that builds this project using gradle scripts and it is a huge help.
However, the developers on the team use Eclipse for their work on their local development machine, and this is leading to some inconsistencies. For example:
The developers workflow is to make changes to their code, then do a Run As > Run on Server or a Republish to deploy their changes to their local WebSphere instance. Now we have been running into issues where a developer will use this workflow, their feature will work correctly, but when Jenkins picks it up the build either fails or (worse) we experience runtime errors because the developers are unable to use gradle to build and deploy the project - the only alternative we have seen so far is to go from:
Right click the server in the Servers view and click “Republish”
to
Run the gradle build task
Go to the gradle build output folder to retrieve the EAR file
Open the local WebSphere administration console
Upload the EAR file to update the application
Do this two more times for the other EARs in our project.
As you can see, we’re anxious to find a solution.
We are also having issues related to runtime dependencies because a developer will run e.g. methods on a JAR project via Eclipse, everything works fine, but then when it is built using gradle on the Jenkins server, it is discovered that that dependency was not included.
Is there an easy way to run our WebSphere EAR projects and our JAR projects via Eclipse using the gradle scripts? Or does our workflow need to change to “only edit in Eclipse, and run via the command line/deploy EARs manually to test the actual build.gradle output?”
have you tried Gradle 2.14.1 and Buildship 1.0.17? Buildship now correctly filters the classpath entries for war/ear projects to only include those that should be deployed to the server, so your classpath in Eclipse and in Gradle should match.
As for Java applications, there is still more work to do to get the test dependencies out of the runtime classpath. We don’t have a clear timeline for this at the moment. If a community member would like to step up, I’d be happy to guide them through the design and review process. Alternatively, it is also possible to develop this as an open source partnership.
Assuming websphere has a command line/REST API to upload the EAR then the second set of steps wouldn’t be difficult to automate in a single gradle task
I looked into those briefly, but I was hoping there would be a solution where our devs would still be able to utilize some of the tools Eclipse has to offer, like debugging on the local WAS server.
From everything I’m reading both on this thread and the Greater Internet, it looks like there is no way to tell Eclipse “Do everything the same way you were doing it, but when you want the JARs and EARs for this project, get them from gradle”
This would indeed be a much better solution, but is not supported by Eclipse
The closest you can get is always using the latest Gradle/Buildship versions. We are constantly improving how the Eclipse configuration matches the Gradle configuration.
Thanks! I was hoping at least for such a confirmation that there was no way to get that setup going.
In that case it looks like we’re going to have to move to a command-line based gradle installation then to keep Eclipse and Gradle essentially separate…working with the plugin for a few weeks, we’re not sure exactly what it would buy us over a command-line gradle client, and (in the case of RAD at least) it seems to necessitate quite a few workarounds for developers to get their projects to be deployable to the local WAS server, etc.
Buildship still gives you the convenience of synchronizing your Gradle settings with Eclipse and launchning tasks. So instead of working on the command line you can write a deployment task like @Lance_Java recommended and then connect to the server via Eclipse’s remote debugging.
