This question already has answers here:
In Maven, Why Run 'mvn clean'?
(4 answers)
Closed 4 years ago.
If I want to re-compile the project, should I execute mvn clean first?
In most of the cases you can skip clean. However you should keep in mind possible side effects can be caused by "dirty" target directory. E.g.
You completely removed some class/file, compiled version gonna live in target
In real life project it is quite often to use external plugins during the build, which can also generate some files/reports/etc. From my experience plugin developers don't care a lot to handle situations with "dirty" target folder (I would do the same :)), so you can get tricky errors during the build.
So I would highly recommend to always use clean:
Before publishing the artifacts
When you get some unexpected behavior/errors during compile/package
Most of the time yes,
When deleting resources, classes or anything which lead to something created in the target directory then a clean is necessary because the item won't be deleted until then.
If not, the generated artifacts may contain those deleted items.
If you only updated existing items then most of the time you can bypass the clean
EDIT:
Be extra careful with my last statement. Even updates can lead to side effects without clean. What if a plugin generates items with hash in their names ?
#See In Maven, Why Run 'mvn clean'? for more issues than can arise without clean
Related
The feature build automatically under the eclipse is much faster than the ./gradlew build.
My findings after some research is that it compiles and builds only the changed file and replaces it in build folder.
So why can't ./gradlew build command compiles and builds files that have changed and replace it in build folder and make the whole building process faster.
I have recently started using build automatically feature with hotswap agent + DCEVM.
Why can't gradlew build command compile and build only the things that have changed and make the process faster?
There's no dependable way how to determine what needs to be recompiled. For example, compile-time constants get inlined and there's no trace of where they come from in the class files (it can be found in the source files, that implies parsing them and losing time; it can be stored in some auxiliary files and some tools do it).
See the "Limitations" section of this for details.
The reason maybe is that they don't go through configure step of gradle.
Sure, but the configure step doesn't usually take that long.
Eclipse knows which files have changed
Good point (in a comment by holwgler).
Some time ago I spent some time trying to make my gradle compilation faster and I gave up. Eclipse is damn fast for many reasons:
incremental compilation
multithreading using all cores
knowing all changed files
having the whole compiler code optimized by the JIT
probably caching file dependencies
ugly highly optimized code
My "solution" is ignoring the problem. I do everything in Eclipse, except for integration tests (which take way longer than the compilation) and production builds (which are rare enough so I don't care).
You may want to read these performance tips.
To find out where the time gets spent, use
./gradlew clean; ./gradlew --profile jar
For me, 90% of the time is just :compileJava.
Over the last couple of months I have restructured (renamed) my Maven modules of my project. I discovered some unexpected behavior with respect to how Jenkins treats outdated Maven modules (i.e., they no longer exist in pom.xml files) produced by the build job.
This is depicted in the following screenshot:
As can be seen several modules are skipped (= grey bubble). Sadly, however from the UI, I have no chance to delete them by any means. Deleting the workspace does not help either. Actually, the problem exists in other build jobs as well in case a renaming of one ore more modules was conducted in the pom structures.
The next screenshot shows a German version of the menu options.
Despite I used the latest Jenkins version (2.23), there seems to be no possibility to clean up the ui / modules from this project.
Does anybody have an idea how I can achieve removing this obsolete artifacts without a fresh setup of the whole project or even the complete build server installation.
EDIT-1:
There is an offical issue for that at the Jenkins Project, which seems to be unresolved up to day.
EDIT-2:
I've tried the work arround mentioned in the issue using http://hudson-installation/job/the-project/deleteAllDisabledModules in order to obtain the delete view. However, this page does not exist.
I think this answer from Amedee Van Gasse provides at least a workaround to your problem.
He suggests removing the modules marked as "(übersprungen)" by hand using a Groovy script. His solution also implies why the use of http://hudson-installation/job/the-project/doDeleteAllDisabledModules won't work: The property disabled isn't properly set for the respective modules.
Goto:
http://jenkins-ci/job/<projectname>/<package>$<modulename>/
and click delete.
look at:
http://jenkins-ci/job/<projectname>/modules
It looks like you are in the menu of a build. You first have to go back to the project "Zurück zum Projekt". Afterward you can delete the project (Assuming you have the necessary permissions).
Some things you could try as a last resort:
Delete the job, and then recreate it.
Reinstall Jenkins.
Create a new FreeStyle job and use the same command as you expect developers to use:
mvn clean install
This behaviour is an outstanding bug in the Jenkins Maven Plugin
https://issues.jenkins-ci.org/browse/JENKINS-4561
For me it raises a deeper question of why would you ever want to use a plugin for this functionality. It is a DevOps principle to ensure that the developers use and understand the same techniques as are used to build for release.
So my issue is the same as the title. I have TeamCity v. 8.0.3 (build 27540), and have several test packs set in place. The issue is that I wrote a test in Eclipse, moved it to another package, and now every time that the test build kicks off in TC it runs that test two times, once for the original package(even though it's not there anymore), and once for the new package.
I haven't seen this happening for any test before, and would like to know if anyone encountered this situation and if they have a solution.
Any help is much appreciated.
Most likely files left from the previous build. If you enable Swabra it will clean such files automatically.
You probably need to clean your project - the old .class files are likely to be hanging around. If you're using maven, change the invocation to include the clean phase. Make sure you didn't accidentally check in the .class files, too.
After several late-night debugging nightmares, I've somehow fallen into the paranoid habit of clicking 'Project -> Clean...' in Eclipse every time I'm about to export a signed/unsigned .APK for upload to an App Store. I can only assume that, some time in the distant past, it seemed to be a necessary safeguard when debugging some external JAR or otherwise.
This adds several tedious minutes to the overall export process, particularly with multiple builds and/or apps.
Is this ever a necessary step, or just paranoia?
Cleaning the project recompile all of your classes and it may fix some problems that R.java class cause when resource id's have changed but already compiled classes that refrenced to those id's no longer exist or changed.
I would consider a build system using Maven, Ant or the upcoming Gradle. This avoids problems with corrupt workspaces and lets you integrate automated testing easily; e.g. UnitTests or the simple question "Does it run on Android Version X.Y?"
I prefer Jenkins/Hudson as build server.
Especially when you have several apps for different targets, it can be cumbersome to run all the exports manually.
Ant based build system using Jenkins: this and this
New Gradle based build system: this
I accidentally deleted a .class (Java bytecode) file in my project (on the filesystem, not using Eclipse itself). Easy to fix, right? Just re-build it. But that doesn't work! Even if I select "Build Project" or "Build All" or "Build Automatically" from the "Project" menu, nothing actually happens on the file system, and I still get:
Exception in thread "main" java.lang.NoClassDefFoundError
I just want to re-compile this from the source code I already have!
By the way, when I choose "Clean..." from the "Project" menu, Eclipse doesn't delete any files either. I have also tried re-importing the project into a different folder, but Eclipse just copies all the .class files and the problem persists.
The OP answered his own question in the comments (2 and a half years ago):
Found the solution: another project on which that project depended could not be compiled, because it could not be cleaned, because Eclipse wanted to delete the .svn directories throughout that project (I have no idea why), and it could not because some of the files didn't have write permission. I was happy to wipe out all the .svn data just to get this working! Thanks for the hint. – user690075 Sep 7 '11 at 1:25
In regards to the bounty
This question has not received enough attention.
This problem keeps wasting hours of my time.
IF the OP's answer didn't resolve your issue, you should ask a more specific question on a new post, describing what you've attempted and how the OP's solution didn't resolve your specific issue.
That being said, assuming you did try the solution the OP posted, it is possible a different issue (that wasn't caused by deleting a class file) is causing the same error. Because you started a bounty on someone else's question and you can't get your prestige back I thought it would be appropriate to mention it might be worth your time to make sure your JDK version(s) are compatible between old or external source code used in your project. You'll get the same error NoClassDefFoundError when the compiler reaches a point in your code that references an object/class that's defined in a library that was developed on an incompatible JDK, it's missing key internal dependencies that are not found within your JDK version.
I would go into more detail, but since this question is specifically about an error that came about from deleting a class file I don't feel it's right to do so.
Do a complete clean
1) Find and delete the .eclipse folder (you may back them up first)
2) Delete related .class files
3) If there are any .svn folders, delete them either manually or via your svn client
4) Do not use auto build for this, but manually select only the broken project and do a clean (in case there are dependencies)
If that fails, probably a good idea to package your source codes and re-import as a new project. That can avoid wasting time on a probable IDE bug
In more traditional languages, programs are loaded all at once as part of the startup process. Java doesn’t have this problem because it takes a different approach to loading. This is one of the activities that become easier, because everything in Java is an object. Remember that the compiled code for each class exists in its own separate file. That file isn’t loaded until the code is needed. In general, you can say that “class code is loaded at the point of first use.” This is usually when the first object of that class is constructed, but loading also occurs when a static field or static method is accessed.
If You can't restore from local history. Then you are out of Luck. Use Source Control Management Tools like SVN or Git to avoid such surprises next time.
If you are having source file try to compile file along with dependencies alone in console or other IDE and copy that class file let the errors be errors now edit source file in eclipse try to build again. Hopefully this will not work because even eclipse will neglect Re-compiling some files while building Project. Better Give a Try.
You sure this source file is in your project's source set? Because Eclipse will only compile and put it in your classpath in that case. Right click the project in Package Explorer, Properties -> Java Build Path -> Source. The enclosing folder should be there or Eclipse won't compile it.
In case, say, this source file of yours was once in source set and was compiled that could explain why it was working up until you removed the binary.
In order for this problem not to happen I suggest having Scrub output folders when cleaning projects being selected in Java -> Compiler -> Building and Build automatically... on in Project menu.
Also make sure your project compilation/build succeeds, otherwise Eclipse may not compile all the classes.
If it still doesn't help it could be important what type of project you are having problems with: Java Project, Maven Project, Gradle Project, etc.
To the person that put the bount out, maybe you could just commit all your changes to what ever code repository you have, after exiting eclispe just delete the whole workspace, then create a new workspace and re import all the files into the new workspace from your code repository.