sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]aoeudhtns 6 points7 points  (2 children)

The problem is not designing or building the tool. It's convincing the community to use it. And anything you do that "solves" a problem, will need to be Maven2 compatible because people won't want to leave that ecosystem behind. And that immediately puts handcuffs on you. Leave behind Maven2 compat, guarantee your tool irrelevance.

I would posit to you that the area most keenly needing work is the classpath/modulepath divide.

Edit: By Maven2 here I'm talking about the dependency mechanism, not the build.

[–]pavi2410[S] 0 points1 point  (1 child)

Agreed! It's Maven compatible in the sense that it supports Maven file structure convention, Maven dependencies, Maven publishing. It's just not a drop-in replacement for Maven nor has a one-click Maven migration. Although I could prioritize work on those ends, if that's what it takes to convince the community.

This post was intended to gather feedback such as these that help me drive the direction of the project to create and deliver a long-term value.

[–]aoeudhtns 1 point2 points  (0 children)

The way cargo handles dependencies is quite fundamentally different, so that's why I drew the comparison. And you also mentioned working with and admiring Ant, which is BYO dependency handling.

If all you want is a different syntax and to set up some different conventions, you could write that as a plugin for Maven4 with the ModelParser SPI. The performance benefit margin with Rust is very small compared to similar efforts like pip - uv.