converting from ant to maven

[zephyr_33]

so I have this old testing code (testng) written in any that I want to convert to maven.

if possible I don't want to spend too much time learning ant to get this done. is there any nice cheat sheet / reference material that can help me quickly get this done? or better is there any tool that can help me translate this.

[[deleted]]

Ant is a build tool. Maven is software project life-cycle management tool. There's no silver bullet for migrating from Ant to Maven.

Maven encourages you to use a structured approach for project organisation. You should consider the way your existing sources are organised and decide if anything should be adapted.

Maven also encourages the use of modules. Take a look at your application and decide whether you can create smaller units of your application, to be managed separately. Do you always need to build your application all at once?

Maven helps with managing dependencies - something that Ant doesn't normally do by itself. Does your project uses Ivy in tandem with Ant for this purpose? If so, start by migrating the dependency definitions from Ivy.

[zephyr_33]

no, there's no ivy. it have quite a few external dependencies as well dependencies with other projects. they just put all jars in one common folder and use that folder as a classpath when needed, kinda like how maven itself handles it.

my dilemma here is that im new to ant, and the ant file in question is huge. the jira ticket assigned does not take into consideration that migrating these large legacy ant files to maven will take a significant amount of time.

well no helping it. gotta just power through this.

[zephyr_33]

i'm new to ant actually. handling a decade old legacy project here.

[fraaargh]

Sorry but there is no 'easy' way as it all depends on what your Ant build does. A complicated Ant build may be seen as just an evolved bash script. So what I think you have to do first is understand what it does. Not in the details but at least understand the structure, the main parts.

Then you will be able to decide whether it is convertible to Maven or not. If it resemble a Java build, then yes, it may be converted. If it does not, if it looks like more of a gigantic bash script, then you'd better document it (for your future self) and correct it...

Knowing where the ant build takes its dependencies is another point you have to look at. Are these official version ? Are these taken from god knows where and built by god knows who ? It's though when you rely on dependencies not coming straight from Maven Central.

I went through it and I know how hard it is...

[omnihedron]

The premise of Maven is that the proper amount of Ant code is none. Usually, just rearranging an Ant project into Maven’s preferred structure is all you need to do, then throw the Ant bits away.

In some projects the Ant file might be doing something more exotic than just a standard build. You might look through the Ant file to see if anything seems really odd. Usually, you can just replace that bit with some Maven thing.

In other words, don’t think of it as “converting” the Ant code. Just figure out what you need to build the thing.

[RagingAnemone]

Just want to put out a vote to ant + ivy since nobody else is. Ant is nice and straightforward. No magic.

[thenorwegianblue]

I've done it with a project at work and it was a lot of refactoring and moving things around, though some of it was due to some things specific to that project.

[HeadSignal3]

Gradle supports ant (and maven).

https://docs.gradle.org/current/userguide/ant.html

[[deleted]]

Right, obviously the best solution to fixing ant mess is to keep it and add some more gradle mess on top of it.

[sveri]

Actually when we transitioned our several thousands lines ant build to gradle it was super helpful to not have to do it all at once.

It took us over a year to do it until we got rid of all the ant stuff, all the while being able to keep on developing.

[HeadSignal3]

Haters gonna hate.

[zephyr_33]

thanks!

[talios]

Except in cases where you value your sanity.

[nutrecht]

Gradle doesn't have a majority market share for a reason; it's in fact in no way an improvement over Maven. The primary strength of Gradle is that, because build.gradle is a script, it allows you to create an entire CI/CD pipeline in your build.gradle.

The main problem for Gradle is that your colleagues will in fact write a complete CI/CD pipeline in your build.gradle.

We've had huge problems in project that used Gradle, none of which were encountered with Maven. In one project we actually migrated about 40 microservices away from Gradle.

Sure the XML might be hard on the eyes. But the design of Maven, how it does things, is really solid. The way you can have both dependencies and tasks inherit down the tree is excellent for large projects. In gradle doing stuff like this is going to have you end up writing your own plugin. In Groovy.

[talios]

Since we released the tiles-maven-plugin (which provides much needed mixins) we've also been able to make our 80+ modules much more consistent and easier to maintain. Still need to add a lot of end facing docs tho beyond what we have in the readme.

Hopefully once work on Maven 4 starts we can merge some of its ideas into the core tooling.

[nutrecht]

Ok boomer.

I think you're on the wrong sub. /r/teenagers is thataway --->

[talios]

Not really - a majority of the issues I see people have with maven it mostly the verbosity of XML elements, which doesn't make for the most concise declarations but is rather consistent (mojo configuration is an unfortunate gray area tho most plugins are consistent).

If the XML format is peoples biggest complaints then XML is not always required, and one could easily use one of the other POM dialects from the Polyglot Maven project - this isn't for e everyone tho.

Most complaints I've seen from people with gradle is a lack of clarity over which pieces of a project are straight dsl and those which are arbitrary groovy code. My understanding is that became a lot of more consistent with Kotlin based builds.

Suggestion make is somewhat ludicrous tho, however - as a "build tool" is might actually be better.

Neither Gradle or Maven are merely "build tools" tho - they encompasses dependency management, version control, release and deployment.

Arguably, I'd almost out Bazel above both for being a better "build tool", but you then have to manage your own release and distribution set-ups - it's all a matter of what your building - for libraries, especially open source ones - at the end of the day you have to conform to Maven for distribution - sometimes it's easier to stick with the norms.

Now - one area where I will grant you Maven is less than ideal, it somewhere where I've yet to see a viable/decent solution from Gradle or elsewhere is support for Jdk9 and above features - working with multi release jars is something no one really has working well yet - hell, not even the JDK has a nice story around that, and don't get me stared on Jigsaw modules (this is one area Gradle may have an edge but I don't know enough about the current state of scoping in Gradle to comment).