4 ms·

When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libra

by dkarl 2y ago

When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libraries, because the extension had to be loaded before Maven read the file where our private repo was configured. Whereas a Gradle build can read Groovy files straight from disk.

cyberax 2y ago
> When I used Maven, extensions had to be published to and pulled from a public repo. You can just `mvn install` them locally into your local repository.
- lihaoyi 2y ago
  You can, but why should you need to? Why can't the build tool take the plugin code directly off of disk, build it, and use it? This kind of orchestration of manual steps is what build tools are meant to be good at
  - cyberax 2y ago
    Sure. But adding ability to self-modify the build drastically increases the complexity of a build tool. Maven developers decided that they want to avoid that.
  - beeboobaa3 2y ago
    It can, for plugins. GP is talking about extensions which you typically don't need.
- dkarl 2y ago
  Then you don't have a standard build, you have a build with multiple steps that needs to be documented and/or scripted. In an organization where every other project builds in a single step with "mvn package", and people can check out a repo and fire up their IDE and stuff just works, people are going to get bent out of shape because from their perspective, things aren't working out of the box. A slightly more powerful build tool that supports custom code in the build doesn't force users to script around it. You can create an arbitrarily customized build that builds with the same commands as a Hello World project. (It's a double-edged sword, to be sure, because people don't try as hard to avoid customization as they would with Maven.)
mdaniel 2y ago
As the most extreme counterexample of your ... experience[1], someone made a plugin that allowed writing pom files in languages other than XML: https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2#usage https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2... With an especial nod to https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2#scala https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2... given this submission 1: I believe that you encountered errors, programming is packed to the gills with them, but correlation is not causation in that just because it did not immediately work in your setup does not mean it's impossible or forbidden
beeboobaa3 2y ago
I'm using several maven plugins (not extensions) that are defined within the reactor project itself. It works well. You do need to split your build into multiple projects governed by a reactor but you'll have that anyway as soon as you have more than 1 module. Then you just always build the reactor. Pretty much the same idea as gradle.

by dkarl 2y ago

cyberax 2y ago

> When I used Maven, extensions had to be published to and pulled from a public repo. You can just `mvn install` them locally into your local repository.

lihaoyi 2y ago
You can, but why should you need to? Why can't the build tool take the plugin code directly off of disk, build it, and use it? This kind of orchestration of manual steps is what build tools are meant to be good at
- cyberax 2y ago
  Sure. But adding ability to self-modify the build drastically increases the complexity of a build tool. Maven developers decided that they want to avoid that.
- beeboobaa3 2y ago
  It can, for plugins. GP is talking about extensions which you typically don't need.
dkarl 2y ago
Then you don't have a standard build, you have a build with multiple steps that needs to be documented and/or scripted. In an organization where every other project builds in a single step with "mvn package", and people can check out a repo and fire up their IDE and stuff just works, people are going to get bent out of shape because from their perspective, things aren't working out of the box. A slightly more powerful build tool that supports custom code in the build doesn't force users to script around it. You can create an arbitrarily customized build that builds with the same commands as a Hello World project. (It's a double-edged sword, to be sure, because people don't try as hard to avoid customization as they would with Maven.)

mdaniel 2y ago

As the most extreme counterexample of your ... experience[1], someone made a plugin that allowed writing pom files in languages other than XML: https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2#usage https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2... With an especial nod to https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2#scala https://github.com/takari/polyglot-maven/tree/polyglot-0.7.2... given this submission 1: I believe that you encountered errors, programming is packed to the gills with them, but correlation is not causation in that just because it did not immediately work in your setup does not mean it's impossible or forbidden

beeboobaa3 2y ago

I'm using several maven plugins (not extensions) that are defined within the reactor project itself. It works well. You do need to split your build into multiple projects governed by a reactor but you'll have that anyway as soon as you have more than 1 module. Then you just always build the reactor. Pretty much the same idea as gradle.