What is the purpose of Build Automatically option in Eclipse (Project-->Build Automatically)? Mine will always be checked. But when ever I have some java code changes I still have to do a full build. I was told that it should always be checked. I don't see any benefit in doing so. Please somebody explain.
Eclipse has a good answer on their website:
You have two modes of working: auto-build mode and manual build mode. By default, you are in auto-build mode and Eclipse takes care of compiling source files automatically. Builds occur automatically in the background every time you change files in the workspace (for example saving an editor). Auto-build is convenient because it means problems view, binaries, etc. are are up-to-date at all times. The downside is that in large workspaces auto-builds can be time-consuming if you are changing files in projects with lots of downstream dependent projects.
If auto-build is taking too long and is interfering with ongoing development, it can be turned off. Once in manual build mode, the user is in complete control over when builds occur and what gets built. Project > Build All (Ctrl+B) can be invoked at any time to trigger what auto-build was doing automatically. This allows you to build up a larger set of changes before invoking a build (Eclipse remembers which files have changed so that it does not have to do more work than required when you do ask for a build.
Note that when they say "auto-build mode" they mean if you have checked "Build Automatically", when they say "manual build mode" they mean you do not have "Build Automatically" checked.
Yes, you still have to do a build - but it's done automatically when you save (not an external build like an Ant build, but the "internal" build). If you didn't want to build on save, you'd uncheck the box. Having it build automatically makes some people nervous, I believe.
NOTE
For C/C++ users it's told (from help.eclipse.org):
By default, the Eclipse workbench is configured to build projects automatically. However, for C/C++ development you should disable this option, otherwise your entire project will be rebuilt whenever, for example, you save a change to your makefile or source files. Click Project > Build Automatically and ensure there is no checkmark beside the Build Automatically menu item.
Project - Disable Autobuild option does not always mean autobuild is off. For example "Makegood" test automation plugin will trigger autobuild when Preferences - Run/Debug - launching - (General opt) Build before launch is ON. So turn it off if manual build needed.
One thing that people didn't mention here (and it took a while for me to figure this out too) is that eclipse build (either automatic or manual) would basically follow what you have outlined in the project's "Java Build Path" source tab. So when a file is covered in that build source tab, when you change the file, it gets copied/compiled to the output folder that was specified for that directory/file.
One more difference is:
Most of the time while working on JSPs it helps me when checking "Build Automatically". It automatically picks up the changes in JSPs.
But if you make changes in your java classes/XMLs you need a manual build.
Since I'm using resin server which is run outside eclipse via command prompt, i prefer checking the option.
When i have my server setup in eclipse, i turn it off and use Publish on server.
This is the way i use and the answer is based on my experience.
If Build Automatically is checked, the IDE will automatically compile your Java code whenever you modify and save a file. This does not mean it will completely build and package your entire solution as if you were going to deploy it such as if you are working in a Web project on a WAR module. It basically really just compiles your code.
Related
I use Eclipse Luna 4.4.0. After I start Eclipse and haven't changed anything it sometimes rebuilds the whole workspace which is sort of annoying. It is not an incremental build, but a full rebuild (which includes cleaning output folders of all projects).
I use autobuild for projects (all java, using svn and git), but autobuild should not lead to this behaviour.
What triggers the complete workspace rebuild? The error log does not contain any hint.
Generally, the builder gets triggered as follows (from the Eclipse wiki).
JDT uses the autobuild facilities provided by the platform. If a resource changes, the platform checks the project description file (see .project in your projects). When the file contains a reference to the Java builder, the builder gets notified of the change and will then compile the Java source file and its dependents.
I don't know what exactly triggers the build on startup (I've always had the feeling that it somewhow "made sense" for Eclipse to do so when starting). Could it be that some of your resources are touched (if you're on a Linux system) during startup?
It also says there on the wiki how to switch off autobuilding (which I guess you're already fully aware of):
autobuild can be turned off through Window > Preferences > General > Workspace > Build automatically.
There are also related bugs on Eclipse's bugzilla, e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=73969, https://bugs.eclipse.org/bugs/show_bug.cgi?id=172444.
We are in the process of standardizing our default Eclipse configuration (styles, settings, dictionary, formatting, run configurations, etc.) for our developers.
However, for Java compiler errors and warnings preferences, there does not seem to be any way to export/import settings. Is there another way to do this?
Eclipse allow you to export your preferences via
File > Export > Preferences
You will see a list of exportable preferences, which contains Java Compiler Preference, you can even choose specified preference to export.
After that, you can import the preferences into a new workspace via
File > Import > Preferences
The ideal way to share settings within the team (for use within the IDE) is to use project specific settings. The project specific settings become part of the project and go into source control repository, hence every team member gets them for free.
Most of the settings you mention in the question can be configured per project.
I've developed a maven plugin (called codecleaner) that spread pre-configured eclipse settings for maven projects. It is very usefull wehn you dont want to put eclipse settings under version control, or when you want to save the time for manulay add the settings for each of the projects
https://github.com/yonatanm/codecleaner
currently The codecleaner plugin update the following types of eclipse settings:
Code Formatter
Save Actions
Clean up settings
Compiler Error/Warning level
JSP/XML/XSD/HTML Validation
In our team we use workspace mechanic to share the same workspace preferences by putting the preferences files on a shared drive. A small introduction can be read here.
Create a common build file (using Ant/Maven). If you use Maven, you can even ensure that the same jars are used by everyone while compiling.
This can be fixed outside of Eclipse, starting with standardizing the build process as Amit mentioned.
You might also want to consider a continuous integration system which builds every time someone commits code. This keeps everybody on their toes, preventing people from pushing broken code. Any compiler errors/warnings are visible to everyone.
I am developing for Android and use Eclipse to create an apk that also has a .so file with C++ code in it. My problem is that when I only change the C++ code and recompile that outside of Eclipse, Eclipse doesn't really always see that it's changed and I have to clean the project and rebuild it before I can reliably start it. This behaviour has cost me lots of time because Eclipse is not using the new .so file.
Is there a way to force Eclipse to always rebuild the project before its being run ?
In Project Options, go to "C/C++ Build.
Select "Builder Settings" tab.
Uncheck "Use default build command" and in the field Build command, just add the target "clean" as the first target.
E.g. assuming you have
> make -j2 settings
change it to
> make clean -j2 settings
I'm not sure how familiar you are with ant, but if you are compiling your c++ files through command line, one thought is to create an ant build script that will:
recompile your c++ files
clean and build your apk
install your apk onto your device
Then you can be sure the generated apk is always built using the latest compiled code.
As far as I know there is no way to force eclipse to always clean when you press the play button. You may consider a different IDE such as IntelliJ. You never have to 'clean' a project in that so I assume they re-build the project every time you press play...
We have a pretty big project. We use ant for setting the environment. One of the things that happens during the ant script is that a jar is copied to the lib folder of a project. Then, we use ant tasks: eclipse.refreshLocal and eclipse.incrementalBuild so that the jar now copied will resolve compilation problems in the project that refer to it.
Unfortunately, the projects seem unsynchronized with the filesystem. Project > properties > build path shows that the jar is present (probably information that is refresh while looking at the propertiesw) but the incrementalBuild didn't do what we expected it to do.
Also, sometimes a project that depends on this jar and we refreshed and built it (through ant) has a single compilation error: "The project cannot be resolved until build path errors are resolved". In other times, the are many compilation errors indicating the project hasn't noticed the new jar.
When I build it through eclipse, it is ok.
I was worried that maybe there are circular dependencies between the projects, but it appears the are no such dependencies (Build properties: the circular dependencies option is set to "Error", and the are no errors of this form in the projects).
Anybody is fimiliar with the problem?
What is the proper way to deal with this problem?
Thank you for your help.
If you right click on the build.xml and select Run as → Ant Build... you'll see a tab called Refresh. Just check the option Refresh resources upon completion.
(I use this myself when generating code in an ANT xslt target and it works like a charm.)
You may also want to check Refresh automatically under Window → Preferences → Workspace
Try Cleaning the entire workspace and refresh :)
One solution which might work for you is to modify the Eclipse launch config for the Ant build (Run -> External Tools -> External Tools Config), and explicitly configure it to refresh the workspace (or parts of it) when the Ant build finished. This removes the need to perform the refresh from within the Ant script itself, and it always triggers the correct build reaction when the script completes.
Eclipse does not generally like it very much if you change files in its workspace from outside. There is an option in the Eclipse Preferences to automatically sync with the filesystem, but that can be very intense with regards to IO.
And it will probably still not solve all your problems, esp. when you change library jars.
Even considering skaffman's suggestion with the Refresh on build completion, I am not sure this would really improve your situation, but give it a try.
From my experience, realistically I would have yet to see a solution in a big setup that really works and makes life easier instead of just creating a different set of problems.
I'm soon going to check in the very first commit of a new Java project. I work with Eclipse Ganymede and a bunch of plug ins are making things a little bit easier.
Previously I've been part of projects where the entire Eclipse project was checked in. It's quite convenient to get the project settings after a check out. However this approach still was not problem free:
I strongly suspect that some Eclipse configuration files would change without user interaction (from when I used Eclipse Europa), making them appear as changed (as they were changed, but not interactively) when it's time to do a commit.
There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard.
Sometime if the Eclipse version was different from others Eclipse would get angry and mess up the project configuration. Another case is that it change the format so it gets updated, and if commited messes up the configuration for others.
For this specific project I have another reason not to commit the project files:
There might be developers who prefer NetBeans which will join the project later. However they won't join within the coming months.
How do you organize this? What do you check into versioning control and what do you keep outside? What do you consider best practice in this kind of situation?
At a minimum you should be check-in the .project and .classpath files. If anybody on your team is hard-coding an external JAR location in the .classpath you should put them up against the wall and shoot them. I use Maven to manage my dependencies but if you are not using maven you should create user libraries for your external JARs with with a consistent naming convention.
After that you need to consider things on a plug-in by plug-in basis. For example I work with Spring so I always check-in the .springBeans and likewise for CheckStyle I always check-in the .checkstyle project.
It gets a bit trickier when it comes to the configuration in the .settings folder but I generally check-in the following if I change the default settings for my project and want them shared with the rest of the team:
.settings/org.eclipse.jdt.ui.prefs - it contains the settings for the import ordering
.settings/org.eclipse.jdt.core.prefs - it contains the settings for the compiler version
In general I haven't noticed Ganymede modifying files without me modifying the project preferences.
I recommend to use maven so that the entire life cycle is outside of any IDE. You can easily create an eclipse project with it on the command line and you can use whatever you want, if it's not eclipse. It has it's quirks but takes out a lot of bitterness when it comes to dependencies and build management.
In our world, we check in the entire Eclipse project and the entire parallel but separate Netbeans project. Our motivations for this were entirely focused on "when I do a checkout, I want a functional configuration immediately afterward." This means that we had to do some work:
Create runnable configurations for each primary IDE (people like what they like). This includes main class, working directory, VM parameters, etc.
Create useful start up scripts for all of our relevant scenarios.
Create edited datasets that don't cause the checkout to take too much longer (it's a big project).
This philosophy was worth cash money (or at least labor hours which are almost more valuable) when our new hire was able to check out the project from Subversion into Eclipse and immediately run a functional system with a (small) real data set without any fuss or bother on his part.
Follow up: this philosophy of "make the new guy's life easier" paid off again when he changed IDEs (he decided to try Netbeans after using Eclipse for quite a long time and decided to stick with it for a while). No configuration was required at all, he just opened the Netbeans project in the same directory that Eclipse had been pointing to. Elapsed switchover time: approximately 60 seconds.
I only ever check in things are done by humans, anything else that is generated (whether automaticly or not) should be easy to regenerate again and is liable to change (as you've stated). The only exeption to this is when the generated files are hard (requires alot of human intervention ;) ) to get it right. How ever things like this should really be automated some how.
Try to port your project to a build system like maven. It has everything you need to get the same experience of the project on every machine you use.
There are plugins for just everything. Like the eclipse plugin. You just type "mvn eclipse:eclipse" and the plugin generates your entire ready to work eclipse project.
To give the answer to your question. Never check in files that are not being used by your project at any time in the development cycle. That means that metadata files like eclipse properties etc. should never be checked in in a SCM.
I like checking in the .project, .classpath, and similar files only if they will be identical on any Eclipse user's machine anyway. (People using other IDEs should be able to check out and build your project regardless, but that issue is orthogonal to whether or not to check in Eclipse-only files.)
If different users working on the project will want to make changes or tweaks to their .project or .classpath or other files, I recommend that you do not check them into source control. It will only cause headaches in the long run.
I use IntelliJ, which has XML project files. I don't check those in, because they change frequently and are easy to recreate if I need to.
I don't check in JAR files. I keep those in a separate repository, a la Maven 2.
I don't check in WARs or JARs or javadocs or anything else that can be generated.
I do check in SQL and scripts and Java source and XML config.
I'd suggest having the actual project files ignored by the version control system due to the downsides you mentioned.
If there is enough consistent information in the project settings that there would be benefit from having it accessible, copy it to a location that Eclipse doesn't treat as special, and you'll have it available to work with on checkout (and copy back to where Eclipse will pay attention to it). There is a decent chance that keeping the actual project files separate from the controlled ones will result in loss of synch, so I'd only suggest this if there is clear benefit from having the settings available (or you're confident that you'll be able to keep them synchronised)
In our case, we used to check in the project files (.project and .classpath) to make it easy for all developers to create their project workspace. A common preferences file and team project set were located in source control as well, so creating your workspace was as simple as import preferences and import team project set. This worked very well, but does rely on everyone having a consistent environment, any customizations would have to be applied after the basic workspace is created.
We still do this for the most part, but Maven is now used so of course dependency management is handled via Maven instead. To avoid conflicting information, the .project and .classpath were removed from source control and are now generated via maven goals before we import the team project set. This would easily allow for different environments, as you would simply need scripts to generate the IDE specific portions based on the Maven configuration.
PS-For ease of maintenance though, I prefer having everyone use the same environment. Anything else inevitably becomes a full time maintenance job for someone.
Netbeans 6.5 has an improved Eclipse project import which is supposed to sync changes from Netbeans back to Eclipse: http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization
Don't. Only check in the source code of your projects.
As a response to:
"There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard."
Eclipse offers a number of ways to keep local settings manageable: Java Classpath Variables (Java > Build Path > Classpath Variables) are one, 'Linked Resources' (General > Workspace > Linked Resources) are another http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htm Creating a README that states which settings to set before building/running the project works pretty well in my opinion.
Now how to make sure your continuous build system understands the changes that were made to the eclipse settings, thats another issue... (I have a separate build.xml for ant that I keep up to date by hand)