Coexist with Maven? Looking for a strategy

Help/Discuss Buildship
1

Here is my situation. I’ve spent the past three months primarily engaged in two efforts:

  1. Getting up to speed on gradle
  2. Developing plugins for building rpm files, our team’s chosen deployment mode

Now this is being rolled out to the wider team. Although I do some web development, it’s not a major use of time for me, it is quite sufficient to make a tweak here, a tweak there commit it to source control, build my war-containing rpm on the server and deploy it and test.

Others on my team do much more web development. I am starting to get complaints because they miss the level of Eclipse tooling support they are used to having with Maven. They are used to deploying a Maven project onto a local Tomcat server within Eclipse.

It is not clear how you do all of this with Buildship. The apps won’t deploy. Maybe once it does, once it doesn’t. If things go bad, and they sometimes do, you might have to blow away your Eclipse project, and then reimport a gradle project from a git repo. And deal once again with all the .project .classpath, .settings, etc.

I’ve raised a number of issues about them:

multiproject imports

build path output

deploy to server in Eclipse

These issues are costing lots of their time and also mine as I’m being looked at to help solve them.

As one of my colleagues put it:

with Maven projects, it all just worked beautifully, didn’t need to be an Eclipse guru … I’m so far behind the expected delivery schedule, and it’s mostly due to this stuff

And I can’t argue with him.

The point of this is not to whine. I understand where gradle is coming from, and the prodigious efforts that have gone into it thus far, and I find it amazingly good. Maven has a big head start, and I’m fully confident that in a couple years, if not a few months, things will be much better than they are now, good enough to satisfy my colleagues. I am not underestimating the difficulty of collaborating within Eclipse, with Eclipse bugs, etc.

But it’s still an objective fact that in May, 2016 gradle-eclipse integration is not where it needs to be.

And so, I’m looking for a temporary way of having the best of both worlds:

Has anyone tried having projects with BOTH a pom.xml and build.gradle in them? They could be loaded into Eclipse as Maven projects, developed within Eclipse, code checked in, and built with gradle on a server.

2 Likes
2

I have had both Gradle + Maven and Gradle+Ant/Ivy projects. It makes perfect sense to use what already works for integrating with other systems, while migrating to Gradle. The pain point of having two builds provides a nice incentive to actually finish the migration.

I am not familiar with Eclipse, but with the versions of IDEA at the time we had better luck generating the IDEA projects from Gradle (and customizing them with extra settings), rather than using the IDE import feature. Then as the IDEA import improved, we switched to the IDE importer, which streamlined our dev process.

3

I currently have a project with parallel maven and gradle builds. Our delivery pipeline is tightly coupled to maven, but developers want the speed and convenience of gradle for development and testing. I wrote a simple gradle plugin to help with this, it reads the pom.xml files of a multi-module build, and constructs a similar gradle project, importing dependencies from pom.xml files. The plugin is available at https://github.com/wfhartford/gradle-maven-thief.

1 Like
4

Converting Maven projects to Gradle is also provided by the built-in Gradle Init plugin:
https://docs.gradle.org/current/userguide/build_init_plugin.html

5

Now that I look at it, my description of the plugin really wasn’t very clear. The import of dependencies from pom.xml file is done at build time. My understanding of the init plugin is that it is a good way to migrate from maven to gradle. My thief plugin is intended for ongoing interoperability.

All that is required for a parallel gradle build is a settings.gradle file that includes all the projects, and a build.gradle file which applies the thief plugin to each sub-project.

6

yes, this simply is true. In my environment we have Jav projects which build an Eclipse RCP based client, and this is simply not supported with Buildship. Sadly, the Gradle team had no interests in what Wuff plugin tried to realize. For my team, this simply means: our Eclipse build and our build server still differ much. Okay, I understand, with what we need we sure do not meet the interests of most Gradle users.

Anyway, with Gradle’s coup in the Android landscape, I got the impression that the Gradle road changed somehow it’s direction. Don’t get me wrong. I still think Gradle is a big thing. But I also remember the promises Hans Dockter made for Gradle on IDEs.

7

We’re getting offtopic for this particular post, but I wanted to make sure people heard a measured opinion from someone not from Gradle.Com.

I also agree with Steve (sc1478) that IDE integration could be better, and it really needs to be in the long term.

Let’s remember that Gradle.Com is a commercial, for-profit, company, and they are producing a free product that is effectively open-source. IDE integration will move forward as fast as it can be funded by Gradle.Com, or perhaps along with contributions from other people with the ability to commit time and resources to move this forward.

Concerning the Wuff plugin, I wasn’t part of a conversation you might have had with Gradle.Com about that, but I would sincerely doubt you were told that they “had no interest” in this. Building Eclipse applications is extremely non-trivial. It takes people with experience and resources to maintain something like that. It should also be noted that the Wuff plugin itself is hardly in a state of active support anyway.

8

I just wanted to raise another “me too” hand over here. I work for a large corporation with many software modules, many of them still handled by Maven. We use Gradle. Most developers face the need to work on both kinds of projects at the same time (say make changes to a Maven-built dependency and it debug it within a Gradle-based dependent project). This is a pain in the rear. We hand-coded some scripts that intentionally “forget” to declare some dependencies to Gradle when generating Eclipse classpaths, dependent of what is stated to be in the workspace (we don’t check, we just trust the developer) and mess around with classpath file generation to add references to those Eclipse projects not in Gradle. This is complex and, thus finicky and keeps causing trouble.

Specifically, if anyone interested (and, really, you should NOT be), this is what we do:

eclipse {
  classpath {
    if (thoseOtherProjectaFromEclipse) { // repeated as necessary
      file {
        whenMerged { cp ->
          [otherProject1, otherProject2, ...].each { otherProjectName ->
            org.gradle.plugins.ide.eclipse.model.ProjectDependency otherProject = new org.gradle.plugins.ide.eclipse.model.ProjectDependency("/${otherProjectName}", null)
            otherProject.exported = true
            cp.entries << otherProject
          }
        }
      }
    }
  }
}

Not nice at all.

9

This use case is something that will eventually be covered by composite builds (allowing Maven projects to serve as a participant in the composite).

Until then your workaround honestly doesn’t look so bad. Maybe you could enhance it to automatically look for other projects checked out next to the current one, so the user doesn’t have to manually list what is in the workspace.