You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
then I build with maven, it's repeat again:
mvn clean package -X
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
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
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.
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#
The text was updated successfully, but these errors were encountered:
@chwod That sounds like an interesting problem. Can you please share a minimal Maven project that reproduces the behaviour that you have described? You can do so by zipping up the project and attaching it to this issue or by pushing it to a separate repository on GitHub.
and I run it in a mac pc(before it's win10), it's repeat again!
by the way, how to debug the spring-boot-maven-plugin? if you tell me or give me where to find, it is a good sound, maybe I can fix it by myself, and may give it a pull request.
wilkinsona
changed the title
build with deep package file in a long time
Maven repackaging of a jar with a deeply nested package is prohibitively slow
Jan 5, 2022
Question or improve
Description
For some reason, there will be many files with deeper paths in my project. like this:
when I build with maven:
there will be keeped in here:

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:
public class FilePathToolLang {}
the project looks like this:

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.
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#
The text was updated successfully, but these errors were encountered: