The process cannot access the file because it is being used by another process when running a multithreaded maven build - windows

I am having an issue when running a multithreaded maven build. The issue is simple, two threads are trying to access the same file to copy it, transfer it, etc. The issue is that I cannot find a way to tell maven to tell the threads to either wait till the file is accessible again or simply solve the problem.
Multithreaded builds are necessary for us so was wondering if this is possible to solve. Thanks in advance!

Drop the target folder manually as Windows might was not able to delete them on its own. Then try mvn clean install

Restart your system it will close all the processes and will resolve the issue.

Related

Thorntail run goal

I've seen command mvn thorntail:run in the documentation, but I cannot find this run goal specified in the pom files of provided examples.
Is there run goal at all?
Also I have a problem running my applications this way on Windows since java process is not shut down when I break execution in the console via Ctrl+C. I've read about this problem, but is there any solution to this?
I believe this is very similar to an existing question. This answer should be good for you: https://stackoverflow.com/a/53276378/742081

Is there a way to pause a maven multi-module build and resume later?

So this humungous package is trying to get installed on my VM for the past 5 hours. Its still going strong and looks like it has downloaded the entire Internet already. I need to shut my laptop down. Is there a command line tool to tell Maven to take a break, chill for some time, and resume from where it left later?
Edit: I see a very subtle difference between this and the existing question that has been pointed out. I have been using the -rf flag to recover from a failed build for some time now. But I am not aware of the intricacies of the workings of Maven so I wasn't sure if it would be able to recover if I killed the mvn process from the command line (or if my laptop ran out of battery and was forced to shut down), even if the build process was going on smooth. Here's an analogy - I like to think of Maven as someone managing a complex set of tasks. If some task fails, the manager keeps note of that, halts all the operations and reports to the seniors and waits till his issue is fixed. I believe that as soon as maven finds out something has broken, it saves the state of the build process to be able to resume later. But what happens if someone comes and kills the manager. Or in the case of what I did, if I kill -9 the maven process. Would maven be able to save a copy of the build state? I wasn't so sure. That's what I wanted to check
You can use -rf command line switch to restart the build from given package.
For example if your project consists of parent, child1, child2 builds, you can stop the build e.g. at child2 and restart it using (assuming you were doing clean install):
mvn clean install -rf :child2

Speed up Adobe CQ5 Maven build

I need solution to speed up maven build process.
The project is based on Adobe cq5 otherwise AEM and i have more than 10 modules in my project where the build happens in linear way.
Currently Build process takes more than 10 min to compile.
is any other specific tool available or other way to speed up the process?
Thanks
I have one suggestion,If you have 10 modules than make separate profile for each module,and build only that part in which you are changing and modifying,no need to deploy 10 modules each time unnecessarily.It will not speed up maven project build but can help you to save your time.It is a workaround but will be helpful .
Try mvn -T 4 clean install #Builds with 4 threads
Its a multi-threaded mode to run Maven and is faster. Apache documentation here.
To add to the other answers:
1) Give more memory resources to the server where the AEM instance is installed, content creation involves a lot of disk access so using SSD is a must.
2) Having a clean AEM instance helps to speed up the process. As you may know the AEM repository grows because of revisions so each time you deploy the repository size grows and it becomes slower. if it's a production environment use maintenance tools like revision clean up and compaction.
revision clean up
how to maintain repository
As per my knowledge there are no such mechanism to speed up.
better to make a build of particular module, it will deploy faster rather waiting for all 10 module to be happened.
Thanks
You can try using the suggested answers to build modules in parallel. It should speed up the build in theory.
But really there is no magic answer. You have to find the bottleneck in your build, it could be the number of dependencies, it could be a specific slow plugin, it could be hardware related, and it could be something else.
Try this: https://github.com/lptr/maven-time-tracker
It may help you find the bottleneck.
I would like to answer this question, knowing it was posted a really long time back.
Currently I am using AEM 6.3 and to recompile and deploy CORE module changes there is a simple maven trick -
This command tells us to -
run 1 thread/core
compile just the core module of the list of projects
and of course, zip package and send it to running AEM instance.
In my observation, this reduced the turnaround time by a huge margin.

Queue rather than run a TeamCity build while another build is running

Our busy enterprise server has 550 active build configurations running on 30 agents. We need a way to prevent some builds from running while other builds are running. I already understand artefact dependencies and this does not solve our problem as the builds do not depend on each other they just share some resources like server port numbers and database connections. Some build configurations conflict with each other when run simultaneously and we need to prevent this by having a way to queue a build (rather than run it) when one of a number of other builds are running.
We already use dumb tricks like restricting builds to specific agents, etc... I'm thinking about adding a first build step that checks for a flag in a db table or something but this would add lots of failed builds when what we really need is proper build queueing.
Am I missing something? Does this functionality already exist in TeamCity?
It looks like what you need is on its way in the form of TeamCity 8 Shared Resources. You can already get access to the EAP here.
My huge respect for 550 configurations and 30 agents.
I think you already found the solution:
Have one environment per agent
Assign configuration for specific agents
I could imagine how much it is work. But I think it's much cleaner and will work much faster than restriction to run several configurations at the same time.

Jenkins/Hudson Java.IO error Unable to clean workspace - Windows server

I have a Jenkins/Hudson CI server, hosted on a Dedicated server (Kindly hosted by someone else). We have come to a problem which we cannot solve, and need help from people who may know solutions:
When we try to run a build, we get a Build Failed, and
java.io.IOException: Unable to delete C:\Program Files (x86)\Jenkins\jobs\JumpPorts-2\workspace
Jenkins was able to create the files, so surely it can delete them? It is running as a service, and it is cloning the source (Maven - Java) from GitHub. This is on a windows server. I tested it on my VPS (Centos5) and it worked correctly, however due to it being a VPS, java does not run well with my other services, so i am unable to host it on there.
Full Error: http://pastebin.com/0tWVVdiH
Thanks in advance
Most likely you are using the Maven project type.
The Maven project type can parse the pom on disk before building and while accessing the GUI. As a result when building on Windows, there is the chance that window's strict version of file locking can get in the way, marking a file as in use until absolutely every file handle is released.
One way to reduce this issue is to have the windows builds run on a slave node rather than the master (note that the slave node can be the same physical machine, but because the remoting channel is required to see the slave's filesystem, the file handles may not be as big an issue)
Another way to reduce this issue is to switch to a FreeStyle project with a Maven build step. Note that my personal preference is to avoid the Maven project type on pain of death. ;-)

Resources