I tweet technical content that I consider interesting, but the funny tweets are the ones that get the most engagement. I attended the JavaLand conf...
For further actions, you may consider blocking this person and/or reporting abuse
I took a similar road. First Ant, then Ivy and then Maven.
At some point, I was fed up with XML not really understanding the benefits so I started looking into Gradle, being envious not being able to use it.
Then, we needed an Android App so I was happy to start with the (mandatory) Gradle build.
First, there were all kinds of plugins missing we needed. So I hacked them into the build script. I ended up, using printf debugging to find bugs in my build script. Something that would never be required or even possible with Maven.
One thing I found particular weird was the mix-up of declarative and imperative code that got me confused more than once.
I also thought that this flexibility is great but it isn’t. You have enough work to fix your code (and potentially pipeline code) that you surely don’t wan to fix build script bugs…
Exactly my thoughts. Thanks, I will also point to your article from now on when needed 🥰
I'm very happy that I'm not alone in my thinking's.
Standardization is key and I think it's main key for open-source, where you can "feel at home" as much as possible on every project that uses Maven. This helps reduce time to contribute, witch I think is the main metric for open source community.
Also, if some day Apache move main maven repo to modern host e.g. GitHub it will increase the love. NOT MIRROR
What do you mean here? The Maven repos for Apache Maven itself and for all plugins and components are available on Github ....they accept PR etc.
for example:
github.com/apache/maven
github.com/apache/maven-install-pl...
etc.
GitHub is a pretty crappy UX. Partly the fault of Git being crappy UX, but GiHub could be so much better.
Use of Maven certainly doesn't make me "feel at home", the first thing I do when encountering a Maven project is convert it to Gradle so I can breath a sigh of relief.
About GitHub:
My point was that GitHub is better comparing to what they use now link 1, link 2. This is very old approach. I believe they also use mailing lists for discussion, this is very old style and it will not get new contributors.
Even Gnome right now switched to GitLab and feels good there:
About "feel at home":
With Maven you will have more probability that next project will have same structure and flow and not fall in "The snowflake syndrome" like described in article.
What do you mean? We, the Apache Maven team (including myself) is using GitHub for a long time ...
one exmaple: github.com/apache/maven
maven.apache.org/plugins/
maven.apache.org/shared/
maven.apache.org/pom/index.html
maven.apache.org/extensions/index....
This list all plugins etc. incl. links to GitHub etc. incl. link to JIRA ticket system.. you can offer pull requests via Github... for a long time.
My path to Maven was similar, but started a bit earlier. I went from: make (in the '90s) to Ant to Maven. There wasn't really anything good pre-Ant. Make isn't really suitable for Java but nothing particularly better at the time, and you can make make work if you need to. I stuck with Ant probably longer than I should have before going to Maven. I haven't used Gradle at all.
Indeed! That is an exciting conclusion.
My final thought why I like Maven it's just because I am old school guy, but now, I have a better way to justify it.
I am in the opposite camp. While I do recognize Maven's legacy and all the good that it brought, I would choose Gradle any day. This probably primarily comes from my internal burning hate for everything XML, but I also find that Gradle runs a lot faster. I don't have any other objective arguments, and I haven't written plugins for either tool, but I gotta say, I have a lot more will to live after migrating my projects to Gradle 4 years ago.
I had a similar journey. First Ant, then Maven, then Gradle. Gradle is by far better for how I work. Maven offered roadblocks all the time. Maven POM files are horrendously verbose and awkward to deal with.
Oh? Which of the "standard" projects do you mean?
mvn archetype:generatelists over 3000 project types. Good luck.Gradle is built on the premise that flexibility is required, as demonstrated by the over 3000 Maven archetypes and pretty much the experience of every developer that has done something more than "Hello World". I don't consider Gradle the last word in build tools, it certainly has it's rough spots, but it works for me. I'll always choose flexibility over Maven's handcuffs. I'm not going back to that hell.
I think point in article and I'm agree with it, that flexibility creates another hell.
So you on the road to the hell too with your flexibility.
More on that, by being loud - you are pushing young people to that hell too.
Try to think broadly and analyse historical consequences of some directions and to what they lead in long term run.
Author where did great job neutrally describing things.
Gradle brings nice features into Maven and this is good in scope of progress, so Gradle did good job here, but what is question mark here, after so many years is this tool that we need to follow?
I will be as loud as possible to save people from Maven hell. They can thank me later. There is an article out there on the internet "Why everyone eventually hates Maven" - it's still relevant.
I don't disagree that the flexibility can create another hell. I just don't see it happening very often in practice. With Maven the hell is enforced. With Gradle you have enough flexibility to cause problems if you aren't careful, but in most cases you simply have the tools you need to get things done.
If you are a beginner, follow the conventions strictly. Don't roll your own solutions until you have a thorough understanding. Both Maven and Gradle prefer convention over configuration. Gradle just does it in a way that is easier to read, far less to write, and leaves you an escape hatch if you find that you need it in the future.
The build output from Maven is overly verbose too the point that it makes it difficult to find crucial information when things go wrong. Gradle does a better job.
The author doesn't appear neutral to me, there is an anti-Gradle bias in the article that IMO is not justified. Maven works in simple cases and when you realize that you need something more, trying to accomplish it with Maven is often painful. I was there. I tried. I evolved the same project through Ant, Maven, and Gradle. With Gradle it was simply far less painful. Of those three options I consider only Gradle when starting a project. I know the other two will let me down. Not that Gradle hasn't let me down at times as well. I admit it can be complex, but it isn't always complex. Gradle projects can be simple and straightforward, and usually they are.
Over 3000 archetypes for Maven projects... that's basically demonstrating the flaw in that approach.
First I'm completely biased for Maven...
That is a contradiction in it self, because not everyone hates it..
The flexibility is a thing I'm always reading.. but do you really need that (apart from that you can write plugins etc.)..
The output of Maven can be reduced if you like?
And Maven works for a lot of cases .. not only simple case I'm doing builds for companies with builds with over 3000+ modules etc. (Is that simple?).. complex setups etc. and yes written a number of plugins for such things which integrates very well in the overall build process. This integration makes it easy for other devs to understand the whole build process... In general the default plugins should do the job ... my experience if you need to outside most of the time you should reconsider that...
I don't say Maven is perfect... it can be improved in many ways ...
3000 archetypes is not related to Maven itself. Many people/orgs offer archteypes...
thanks for the article !, I am currently considering also sbt