Skip to content

Maven repackaging of a jar with a deeply nested package is prohibitively slow #29175

@chwod

Description

@chwod
  • spring-boot 2.6.2
  • jdk8
  • win10
  • sts-4.13.0.RELEASE
  • maven 3.5

Question or improve

add support for deep files build or improve performance or show detailed information to let anybody to know the process

Description

For some reason, there will be many files with deeper paths in my project. like this:

com.java.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.any.java

when I build with maven:

mvn clean package -X

there will be keeped in here:
image

then it is nothing to show, no errors, no timeout, no more info, but it is in running status(The cursor will still keep blinking and run it in eclipse, it's also always in a running status). and then I waited for a whole day and it was still not complete, no errors, no timeout, no more messages, and still running

so, I will find the reason:

  1. I create a new project with spring-starter-project(to save time, the test was removed), and with a main java in root package, then add an other file with a deeper path, the file contents is empty class(no method) :
    public class FilePathToolLang {}

the project looks like this:
image

  1. then I build with maven, it's repeat again:

mvn clean package -X

  1. when I replace the deep package file with long path or long file name in long package name(see picture above), it's not repeat, so , may only be related to depth
  2. back to the first step, use the deep package file, and remove spring-boot-maven-plugin from pom.xml, then build with maven, it's not repeat, and can be complete. so, ruled out the problem of maven
  3. back to the first step again, we use the deeper file and remove the class:
    public class FilePathToolLang {}
    leave only package information:
    package a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.a.b.c.a.a.a.a.a.a.a.a;
    then, it's complete, as if there is no such file. so, may only be related with class file.
  4. Go one step further, now we need to find out what is the maximum depth that can be tolerated. Step by step verification, When the depth exceeds 20 levels, the time spent will double

conclusion

In most cases, we do not need too many depths to have a good management of source code files. But the code is open, and we do not rule out the need for in-depth management. There are also many long-path problems and corresponding solutions on the Internet. Therefore, I suggest that optimization for this should be necessary.
In the course of the experiment, we found that the deep path file has almost no effect on maven itself, So, can we also have a way to deal with this kind of problem?
Take a step back,It may be related to other situations such as the system, even if it does not have to be solved, can you provide a process information that can let the user know what is happening in the middle,like maven, every time a file is added to the compressed package, a corresponding information is also displayed. so, If we can display a corresponding message every time a file is processed, telling the user what they are doing, then once such a problem is encountered, the user will also know which file has the problem, at least not far away. Instead of endless waiting

#Thanks All#

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions