There's an incubating feature in gradle for comparing builds (documentation here). The documentation states it can compare:
A Gradle build with a build executed by another tool such as Apache Ant, Apache Maven or something else (i.e. migrating to Gradle).
I'd like to use this feature but the documentation doesn't outline how to do it. I'd like to build the same source code twice, once with maven then with gradle and compare the built artifact (a jar).
I've generated a build.gradle using gradle-init --type pom now i'd like to
Run the gradle build (build.gradle)
Run the maven build (pom.xml)
Compare the jars built by both
I don't mind if I need two duplicate copies of the source code to achieve this. I'd like to automate the process so that it's repeatable as I migrate my build from maven to gradle.
Related
What is the difference between IntelliJ, Maven and Gradle build system in IntelliJ IDEA?
Has IntelliJ IDEA its own build system?
In addition, what is the difference between run in IntelliJ and Gradle bootRun?
Build project is IntelliJ's own build-in build mechanism, it simply compiles all modified and dependent files in the project.
However, it's a "plain vanilla" build. It doesnt do fancy things like creating artifacts, deploying to repositories, codegen from a wsdl - etc. That's what we use build automation tools for, and there are 2 of them (maven and gradle) in widsepread use.
Maven and gradle allow developers to set up a custom (and more complex) build configuration.
The maven pom.xml defines lifecycle goals and the gradle build.gradle defines tasks.
Via a plugin architecture, maven / gradle can accomplish almost anything in a build process. Whilst the maven / gradle "run" task can operate similarly to IntelliJ "Build Project", it's not the same thing - in this case the build is instrumented by the build tool (maven or gradle) and can be configured differently, and be part of a more complicated build process.
What is difference build project in IntelliJ and gradle build?
IntelliJ build uses IDE's own jps project model and builder for compiling the java-based projects. Including incremental build support.
With Gradle build it actually uses Gradle to build the project (think Gradle build task).
In addition, What is difference run in IntelliJ and gradle bootRun?
Basically same as above: IntelliJ runner - uses build results of IDE's builder and IDE's own Run/Debug Configuration to launch the application ant tests. With Gradle runner - IDE delegates this to corresponding (bootRun) Gradle task.
See also Configure the build and run actions for additional details.
I tested this locally in my project, using two builds: one using IntelliJ IDEA's "build project" and the second using Gradle's own build command.
Then I checked the contents of the .build directory in my project and found that the former (IntelliJ IDEA's build) produced less files than the latter (Gradle). I think Gradle's build system is more powerful than IntelliJ IDEA's, which is why I prefer to use Gradle in my projects.
I've had a java maven project, and now I converted to gradle because I have to write some cutom build script.
I'm wondering if I still need to keep pom.xml. Do I need to add my dependencies to pom.xml, or I should get rid of pom.xml and add them to build.gradle ? Does gradle replace maven ?
Gradle and Maven are two different build systems. They are quite the same but have some differences. But if you convert your maven project to gradle, then your pom.xml is useless from now on. You can easily convert your maven project to gradle using gradle's incubating feature with this command gradle init --type pom. Then your scripts will be added to build.gradle file. This is still an incubating feature though. You can also do it from stract. I suggest you to read the following document.
I went through this link to import a gradle project as dependency into another gradle project. Is there a way to include a maven project as dependency into a gradle project?
If that Maven project is built somewhere else and deployed to a Maven repository, you can specify the artifact it produces as a simple compile dependency. If this Maven project is somehow a subproject of a Gradle multi-project build, I suppose you could hack it to work by simply ignoring the Maven POM file and perhaps adding a build.gradle to that project.
To use the solution described on the link that you provided - both projects must be gradle and included in gradle settings. Therefore you can use project closure to compile and depend on the project without building it explicitly.
I am not aware of any way to do this with maven project. I understand you use some maven plugins that you dont want to rewrite in gradle as simply can not find any equivalents etc. Often had that problem.
In this scenario I would suggest to build maven project and depend on a built jar in your gradle project.
Otherwise you could probably amend sourcesets in your gradle project to include maven classes. But I think it would be to complicated.
If I would be you I would turn it into gradle and try to replicate what you had using maven or just build the artifact and depend on it in dependencies closure.
Gradle is not that new anymore and there are many plugins that are superseding old good maven stuff.
I have written a spring boot application, based on a few maven startup POM entries.
Now, this application is being merged into a larger code base, which uses gradle to do builds.
Is there a way to convert a maven based project to gradle without any major disruptions?
https://gradle.org/migrating-a-maven-build-to-gradle/ is a good starting point
Gradle init task will automatically convert an existing Maven one to Gradle in addition to create a new skeleton project. Try running gradle init from the root project directory and see whether gradle is able to convert automatically. This command parses the existing POMs and generate corresponding Gradle build files plus a settings.gradle file if it’s a multi-project build. If you’re lucky and don’t have many plugins or much in the way of customization in your Maven build then gradle init will do the trick.
Here’s a list of Maven features that may make the process more difficult:
Bills of Material (BOMs)
“import” and “provided” scopes
Optional dependencies
Integration tests
Custom configurations
Less common Maven plugins
Custom plugins
In a nutshell, Yes automatic conversion is possible, but there are lot of catches.
I wrote a project which use maven. It's good for me.
But, some other people don't have maven, so I am trying to write an ant build.xml for them.
My question is:
Inside "javac" -> "classpath" tag, how could ant get the libs I used in the project from maven? So that could compile & pack all the 3rd-party libs into release via ant.
Is this possible or there are better solution for maven & ant exists in same project.
Ant combined with Ivy is your answer. Ant can use a Maven repository to pull in jars, and can even be made to output a pom.xml, so the jar can be deployed back to a Maven repository.
I have an ivy.dir project on Github that I use to help integrate Ivy into already existing Ant tasks -- especially if they use Subversion as a version control system. You can create a ivy.dir subproject, and make that an external on the Ant project.
Have a look at ivy. Use it to download your dependencies for ant from a maven repository.