Sometimes, I want to be away from keyboard for a while and before I go away I start my maven build, hoping that I can come back to see that the build has been successful.
But sometimes I come back and it says "build failed" then I build my project again and get "build successful", there are various reasons for this, maybe your antivirus was running and blocking access to a certain folder at the time of build or something like that.
Is it possible to make maven retry build command until you get "build successful"?
You can write your own script to launch the command for the build process but there are some considerations to do before doing it:
Does it makes sense to expect that a failed build may succed without a code modification?
How frequent the retry should be? If it is too much than you can potentially cause problems on the machine that you are running the script.
If you expect that 1) is possible than for 2) you can implement a non linear pollicy; for instance you can use exponential retry; similar to the policy done in Spring for the annotation #Retryable.
Related
I'm using Intellij IDEA, working on a Hybris project. We use ant for build, but the build takes too long (about 15 min), so when i start the build, I must stop coding, so i lose a lot of time.
My question is, can I keep coding while the build is running? Or will my uncomplete extra code make the build fail?
Thank you
can I keep coding while the build is running?
No, you should not change the code while the build is going on. Yes, you can keep changes unsaved :)
will my uncomplete extra code make the build fail?
Yes, it might.
I lose a lot of time.
Use code hot-swapping tools, like Jrebel(Licenced), DCEVM(opensource).
It is simply not possible to edit while building. You might end up with an inconsistent build. If you want to speed up development, try to set up something like jRebel.
you can just separate editing from building process by build on another computer device or try CI while you are using any CVS like GitLab, GitHub.
Our build takes a long time, even when nothing has changed. When I run mvn appengine:set_default_version it does a full build, which takes a few minutes.
Is there an easier way to call set_default_version, bypassing the build?
As requested by #Alex :)
I do believe you could build a custom flow to just to call set version. But seems like a complete overkill.
Since you should be changing the default version every once in a while and not on every build (I hope), would't the UI on the cloud Console suffice? You just go to Compute > App Engine > versions and setup the default.
Be advised some people reported issues with the new UI where default version was not changed, so if that fails you might need to use the old app engine console.
I have an Eclipse (4.4.1) working set consisting of ~60 projects (the number may be relevant, as it takes more time to refresh the workspace). Occasionally, I encounter build failures because Eclipse is unable to clean the output folder before build:
It turned out that the process which locks the file is Eclipse itself:
It also turned out that files being locked are always of XML content. Particularly, if I define resources with *.foo extension as XML files (via Preferences -> General -> Content Types), there's a good chance they will be locked, too, once they're copied to the output path.
I thought the problem was caused by all XML resources being validated automatically:
-- so I added exclusion filters 1st and even disabled XML/XSD validation entirely. The problem stopped occurring that often, but still emerges from time to time. Refreshing or closing-reopening a project isn't helpful.
The only remedy is restarting Eclipse or running Unlocker every 1/2 hour, which is not very convenient.
Any ideas how to solve or at least further diagnose this?
Just my 2 cents.
Perhaps you can fix this issue by following this steps:
Project -> Properties -> Builders -> New -> Program
Define a custom "Cleaner"-Program, for example Unlocker or your own Java- or CMD-script
Move your custom Builder-Program up. It should be the first Builder in the list
P.S. some times i have similar problems caused by Avira Antivirus Scanner...
Disable third-party version control daemons. (Like TGitCache).
They only lock resources for a short while and are not visible in Process Explorer, but are the most frequent cause of such failures.
Assuming that XML Validation is the main cause of your problem, I suggest you extend your search for validation points in your projects' configuration, to set off all of them:
General preferences/Validation
General preferences/XML/XML files/Validation (the "honour all schema locations" option might be causing delay at validating)
Project preferences/Validation (check them; might be overriding the general preferences)
Project preferences/Builders/Validator
Hope it helps.
I have experienced similar issues. Yes, the number of projects is probably the cause. Close the projects not in use. If that cleans things up moving groups of related project into separate work spaces should help you out.
i.e File-> Close project
I'm not familiar with the problem, but I would tackle the problem this way:
download File Leak Detector
add the agentpath to your eclipse.ini (e.g.,
-javaagent:path/to/file-leak-detector.jar=http=19999, see documentation of File Leak Detector)
when the problem happens again, see which (eclipse) class is responsible for holding a handle of the file
Find out what is the purpose of the class that holds the handle
This way, you are maybe able to pin down the Eclipse feature that causes your problem.
We are planning to automate the build system using Hudson. We are new to Hudson or it would be better to say this way that we are new to build automation process. Our application is on Java platform and the database is on MS SQL. This (automation) milestone is break down into different goals. The first step which we have is to automate database changes (DDL/DML) and during updating database if anything goes wrong it should be able to roll back the changes and send an e-mail to a group to notify the failure (with reasons). Otherwise, if succeed then allow to move on to the next step which is make the build and deploy with LiveRebel.
I think we should have a centric mechanism on build failure on any instance if a build fail it should be able roll back changes what it would have had done. For instance, if database changes failed as I said it should notified and don't proceed further. And, if database succeed and build making process failed (e.g because of Unit Tests) it should be able to roll-back the database changes. If notification can have failure details (like exception details with person responsible for this) it would be very helpful to diagnose and inquire appropriately. How can (should) I do this?
We are also interested to use LiquidBase with Hudson.
I would like to ask for your opinion and suggestions how should I plan this and what should be a good way to achieve this.
First of all you shouldn't mix up building and deploying. The database update would be part of your deploy process, not of your build process. Even if using continuous integration this should be kept separate. This means you do your database changes after the project was build and all your JUnit tests were run. If it fails before that it shouldn't perform the changes, so there would be no need for rollback.
As for your actual problem: I don't know any plugin that does what you want to do. In Hudson/Jenkins you always have the possibility to execute a batch/shell script. Write a script that performs your changes. The build should fail if your script exits with an error return code.
For sending notifications on build failure there are various plugins, including E-Mail.
Even I disabled the "Build Automatically", the realtime syntax checking still works, so seems the "Build Automatically" is useless?
Should I just turn it off?
Build automatically helps you know if there are any compile errors.
Its always a good practice to keep build automatically on as to ensure that you dont checkin any code that causes compile issues
Syntax checking isn't the same as building.
Do you really want to wait for the compilation cycle whenever you want to run your program after small changes? "Automatic build" does this compilation in the background and therefore saves your precious time when launching the application.
If you use maven and you edit some classes during mvn build and autobuild is on, it can break build and leave it in unexpected state (doesn't have to end with error). But i still have it turned on, just not changing code while mvn building.
It is a 'nice to have' feature because it gives you compile errors real-time. People also hate it because they complain it distracts them while they are typing out a lot of code and half way through typing the screen is filled with a bunch of red lines.
But this nice feature comes at the cost of your CPU. If I am on a slower machine or if I have other processes running that are CPU intensive then I turn off the auto-build feature. At that point you have to manually hit the shortcut key to build your code. Honestly you just get used to hitting the shortcut without even thinking after a while.