“We have ideas for Maven 4 and even Maven 5” - an interview with Robert Scholte, a key member of the Maven project
Read more →
With the new release cycle, Java versions come out one after another, the eleventh one has already appeared, while many are sitting on the eighth. You will soon make a report on how Maven supports all this, and you do not want to spoil the report, but ask the question this way. What do you personally think about this new release cycle that adds work to you? Is this a change for the better or for the worse?
If you're talking about a 6-month release cycle, then for Maven it's a bit quick. Our team is quite small, we have about 5-10 active participants, and they are all volunteers, no company develops Maven. So, everyone should work on the project in his spare time. Changes in Java create a lot of work. Every time a new version comes out, we need to provide its support, which means that we don’t have time for Maven, plug-ins for it or anything else. It would be better for me if the cycle were a year or a year and a half long.
Do other people developing projects for the Java ecosystem have a similar feeling and also need to provide support for newer versions?
Judging by Twitter, then yes, most agree that 6 months is too fast.
Could you tell the story of the Maven? If I remember correctly, it was created a long time ago to make the Apache Turbine assembly less scary and painful. I, by the way, used Apache Turbine. Do you remember this time?
The Maven story began a long time ago. I joined the project about 8 years ago, that is, during version 3.0.3 or 3.0.4. And at this point, Maven existed for quite some time. As far as I know, he was part of the Turbine project. From the part of this project a separate instrument was made, which became Maven. I, like, probably, everything, then enjoyed Ant. I didn’t like that every time I started working on a new project, I had to copy all these Ant-files. I knew that there should be a better solution, I began to search for it on the Internet and found Maven. True, before I understood the main idea of Maven, a lot of time passed. However, when you understand it, it becomes convenient. All the problems I had with Ant disappeared. Ant is still an excellent tool, but if you are working on a project that combines multiple sources,
Maven is only about Java. I tried to use it for C ++, but it was not very nice. Will there be a time when Java will be no more, and what will we do then?
Of the existing popular object-oriented languages, Java seems to be one of the oldest, more than 20 years old. I did not watch the latest statistics, but I am sure that Java is still very widespread. I think it will exist for quite some time. At least, I hope so - this means that I will not be without work.
Will Maven live for a long time too?
But this is a difficult question. Until today, 65-80% of Java projects use Maven. Even for a product that is over 15 years old, that's a lot. Perhaps there is still much room for improvement in Maven. We have ideas for Maven 4 and even Maven 5. But they will take a long time to implement. I think Maven’s overall design will not become obsolete, but other assembly systems may well overtake it. Because they derive experience from both the mistakes we made at Maven and the decisions we made correctly, and based on this experience, we can start from scratch. One of the advantages of Maven is backward compatibility. Even a project written 10 or 15 years ago can be compiled with the latest version of Maven. But because of this, we have a lot of old code in Maven Core. It should be replaced, but this is not so easy to do.
As I recall, you can still now collect mods without annotations.
Yes it is possible.
Before the interview, I tried to find a tutorial about it, and did not find anything. As if the langolera are chasing us and eating up all the old documents on the Internet. But I remember that once a long time ago there were no annotations and special conventions were used. Well, let's move on to another question. Do you think Maven has real competition? Say gradle?
Gradle is a very strong competitor, and it has existed for quite some time. I believe that the presence of competition is good, because it keeps us in shape and makes us see some alternative solutions. They just have a different approach to how to build projects, there's nothing wrong with that. Everyone should choose what best suits their project. Perhaps I should also mention pro here.. This is a tool written by Remi Forax from the ASM (Bytecode Parser) command. He, like me, was a member of the Jigsaw expert group. He wanted to write a build tool that would best reflect the ideas of Java. When creating a pro, he borrowed the best aspects of Maven. Watching this was interesting. It was a demo created to show that you can use Java 9 modules and related benefits in the builder.
You said that you participated in the Jigsaw project - and you said it in the past tense. Has it ceased to exist? Does he still have the opportunity to develop?
This JSR is closed. True, there are some unresolved problems, but they are now engaged in the support team.
What caused the most difficulties when developing Maven? What were the most serious problems? Not in terms of Java 9, but in general, based on the entire development experience. Can you choose, say, the two most important problems?
The question is not easy, but let's try. The part where dependency resolution occurs is extremely complex. We are still trying to improve it. You may have noticed that there was no version of Maven 3.4, after version 3.3.9 there was immediately 3.5.0. The main reason for this is that there have been significant changes in dependency resolution. They were marked as bugfixes, but we noticed that a significant number of projects were suddenly broken - they depended on these strange changes. It was unacceptable. Therefore, we did what we would not have undertaken under any other circumstances — a hard-reset git repository, and in Maven 3.5.0 we began to select only external improvements. Well, and, of course, we made the console multi-colored - everyone liked it.
Well, now the turn of the second difficulty!
It was not easy for us to find a connection with the Maven community and teach them how to use the tool properly.
So everyone knows how to use Maven: copy a few XML spools from comments on Stack Overflow, and it will work. Is not it so?
Oh well. Not. I am sure that most often you will be advised to do a clean install, and this is incorrect. So, probably, it should have been done in Maven 2. Now you need to perform mvn verify. Because when you run clean, you delete everything, the whole result of the work. And if your files are being copied - these are I / O operations, they are performed slowly. In general, many things will be performed many extra times. Most plugins know when they need to perform their task. As a rule, there is no need for clean. As for install, this command only copies your JAR files to the local repository. This, again, is an unnecessary input / output operation. Moreover, your local repository may become dirty - that is, it may look different than your colleague's local repository. Sometimes this can lead to interesting results.
By the way, I have now opened maven.apache.org , and it says: "Apache Maven is a software project management and comprehension tool." But many believe that Maven is just another build tool. What is the difference between a build tool and a project management tool?
It’s probably better not to answer this question to me — I didn’t write it on the site. I think the author wanted to say that Maven is much more than just a project build. He also deals with dependency resolution, he provides the format of the configuration, he allows not to install too many things. In general, this is a huge set of everything.
What are the basic principles and beliefs of the Maven team? For example, do they consider that the declarative approach is better than the imperative one? Something like Python Zen. Do you have a similar set of rules?
I think no. In our opinion, the configuration of plug-ins should be made as simple as possible. If reasonable defaults exist, they should be specified. This makes life easier for the end user. For the first time in many years, we recently changed the default option for the source and target versions - it used to be 1.5, now it's 1.6. We wanted the default option to be present, because without it, the version used in the JDK is used. In this case, if I use Java 10, and someone else - Java 12, we will have different results. You should always specify source and target. But if you started using Java 9, you will not be able to create Hello World with a simple pom file and one class, since Java 9 requires at least Java 6 for the source and target values. Therefore, we decided to make the default version 1.6 and added a warning that
What difficulties do you see for Maven in the future? You said you tried not to change Maven too often. And yet, what awaits us in the future?
One of the most significant changes we want to make concerns the pom file. We found that in some sections — especially in a build — it would be nice to add some additional elements. But so far we can not do this. The same pom file that you use on your system is unloaded. If you add other elements to it, they break the XSD, and other tools cannot use it.
But you can change the XSD in the title?
Yes. But I don't think every tool checks for XSD. They just think they are dealing with version 4.0.0. So it will be very difficult to make changes. We decided to split the pom file into several parts, and start with Build POM. And the one that will be unloaded will be called Consumer POM. It will be generated based on the Build POM and no further action is required. And it will be fully compatible with Maven POM 4.0.0. Dividing the POM into two parts, we can finally improve it significantly and make Maven easier to use. This is a change in the Maven core, and we have been working on it for over a year, including the implementation in the IDE. It is not simple.
Some IDEs attempt to include parts of Maven in the IDE for reasons of integration, autocompletion, incremental compilation, and so on. How to do it right? As far as I remember, some parts of Maven were built into Eclipse a long time ago.
I think that such attempts are quite justified - this system turned out to be very user-friendly due to integration. This was possible thanks to one of the major changes implemented in Maven 3. In it, the architecture was redesigned to provide better support in the IDE. The authors of these changes worked closely with Eclipse, and this is where the decision came from. I think it is permissible. I know that NetBeans and InelliJ have a completely different approach, they just call Maven from the command line without any integration.
Another important topic is the speed of Maven. Can we somehow increase it? Dependency resolution and I / O operations are very slow. Even today on SSD.
Yes, something can be done. First you need to see how many cores are on your system, and run Maven in several threads. This is one of the solutions. In addition, you should take a look at Takari. This is a company created by Jason van Sile, one of the founders of Maven. He wrote some interesting extensions and significantly improved support for parallel builds, i.e. when you are building several projects. I hope that someday he will give these ideas to Maven, but for now you should look at his page.
You said you were working on Maven in your free time, right? Does the fact that you are one of the creators of Maven help you in your current job? Or is it just a hobby?
I work as a software architect in a government organization in Holland. With this I earn my living. Of course, they know that I also work on Maven, so they periodically contact me with questions about Maven. But overall, I'm just their architect. And in the evenings I work on Maven, trying to improve it, help people.
Do you work on other open source projects besides Maven?
I participate in two other projects. One is called MojoHaus, it has developed a significant portion of plug-ins for Maven. True, I’m doing little now in this project, but I still sometimes go there and edit various trifles. Another project is called QDox. It parses the source code. It is also associated with Maven, as it is used in some plugins for it. This experience helps me because, for example, in the case of the module descriptor, which appeared in Java 9, the experience allowed us to use the handle in Maven plugins.
By the way, what is your opinion on Java 9, 10, 11? Should I use them or better to stay on Java 8?
Should move to newer versions. Even if you don’t use all the features, go to Java 10, or wait a few weeks and go to Java 11. Just use the classpath. Java has become much faster thanks to modularity, but the classpath just works. I know that many still think that you need to add a module descriptor or use a system of modules, but this is not necessary. Just use the classpath.
By the way, are you familiar with the GraalVM project? How about using it to build Maven?
Last week I visited JavaZone and discussed this with Chris and Oleg. I think we will need to spend some time with this, see if it is possible to really improve the performance of Maven with the help of GraalVM. It may be interesting.
You are the creator of Maven, a project that is very important to Java developers. What are your feelings about this?
I am not the founder of the project, I support it. I began to study them when he had already walked a considerable path, and it seemed to me that this was acceptable. Ten years ago I would not have thought that I would end up at the top of the hierarchy, but this happened, and this is very cool. Everyone has an opinion about Maven, and I really like that when you come to conferences, people come up and say that they are delighted with Maven. It motivates me a lot, and gives me the strength to continue working on the project when I return home.
Many developers vehemently hate XML. I don’t belong to their number, but when it comes to build systems, this topic always comes up in connection with pom.xml in Maven. So I want to know: what is your opinion about XML?
In XML, it's good that it is clear to everyone, it is easy to parse, and for it you can provide very good support in the IDE. I'm quite normal with XML, and as far as I know, among Maven users, no more than 5% hate XML - but they shout about it all the way! And the other 95% you just never hear. Nevertheless, for these 5% there is a solution - here again I want to mention Takari. There is a polyglot project that allows you to choose a different syntax. So if you want to use Yaml and pom.yml, this is quite possible. You just need to add extensions to the project, and you can switch to another language.
And more about the mood of the developers: I remember the thread in the Maven mailing list, where the author of the SDKMAN tool! to the proposal to distribute the Maven community through it with phrases like “everything I see is a project with a stupid name” and “you could better sell your idea”. Then discussions arose: some thought that the community had reacted too aggressively, others that the original proposal “do additional actions in connection with my tool” was unreasonable. Anyway, many were unhappy with the situation, and in this regard, the question is: do you think that specifically Maven, or in general, does the open-source community have problems with communication?
Communication can be very, very difficult, that's for sure. Especially when it happens only through the text and you do not see the interlocutor in front of you - in this situation it becomes difficult to explain what you want to say. I think, before each open-source project there is this problem of correct communication with people. I fully understand why project participants sometimes get annoyed - they hear the same questions over and over. An example of such a question that I mentioned - “why can't mvn clean install be used”? I stopped explaining this, because otherwise I would have turned into a rude myself, but I do not want to. So I explain these things in other ways. So, on the one hand, it can be very difficult to communicate. On the other hand, although Maven is inflexible, it is part of his success. When people come up with offers, which are incompatible with our concept of Maven, we just say: sorry, but this does not suit us for such and such reasons. I fully understand that this can be frustrating. But in general, this approach is only for the best.
Could you at the end say a few words to our readers, suggest how they come to a bright future?
As I said before, a small team is working on Maven, this is an open-source project in which everyone can participate. It is not so difficult. We created a new label called up for grabs. These are problems that should not be too difficult to fix. Thus, it is quite possible to get acquainted with how Maven works. If you want to join our team, then the example of your fixes will show us the quality of your code - if you want to be noticed by us, then I recommend trying it. I would very much like our team to grow in the future.
Thanks for answers. See you on Joker 2018!
Minute advertising. On October 19-20, the Joker 2018 conference will take place, at which Robert will deliver a presentation on “Apache Maven supports ALL Java” . In general, there will be many more interesting and worthy of attention reports on Joker . Tickets can be purchased on the official conference website .