I am working with a huge workspace (~1200 bundles/fragments) and a target platform (file) with about ~800 additional bundles. Settting up this workspace (switch branch, change target platform, etc.) and make it "green" takes a lot of time (20min-2hrs). During setting up this workspace I realized that some of the Eclipse internal tasks such as "Building" and "Loading Target PLatform" are executed in parallel.
But this doesn't make much sense to me, because I assume you cannot successfully build the workspace unless all required plug-in dependencies are resolved. This implies loading the target platform should be done in prior to building the actual workspace. The result is, that once "Building" and "Load TP" is finished, the workspace is a mess with >100000 errors and it requires some hardcore "Eclipse Dance"[tm] to make it "green".
My question is:
Could some sort of exclusion between those task solve this problem?
Is there a way to specify some sort of rules between those tasks from within the Eclipse IDE itself?
In case its only possible by manipulating the underlying Eclipse.org java classes, which one would that be and what would be a recommended way to do so?
The parallel building of projects can be enable in the preferences in General > Workspace > Build by setting Max simultaneous project builds to 2 or higher.
Please note that such slow building of projects as you describe is probably caused by something else:
Make sure your Eclipse (the platform and all plugins) is up to date. According to the screenshot, your Eclipse seems pretty old, so you will miss the numerous performance improvements that have been made in recent versions. For example, since EGit 5.6 only files actually modified instead of all files are refreshed when switching to a different branch.
Make sure it is not caused by a plugin you have installed. Some plugins can dramatically slow down building of projects, even when not used. So check it, whether you can reproduce it with an Eclipse without additional plugin.
Avoid circular dependencies since they can cause multiple build iteration (a project that has been changed triggers a build in the projects that depend on the project; which can result in a change that in turn can trigger the building of more projects; and so on): in Project > Properties: Java Compiler > Build set Circular dependencies to Error (which is the default).
Avoid project builder cycles. A project can have multiple builders (see Project > Properties: Builders). All builders will be executed until no file is changed. Touching a file without changing its contents is also a change. For Maven project, you can use the Maven Workspace Build view to debug this.
For large projects I disable "Build automatically" in the "Project" menu before updating from source code repository and building it with Gradle/Maven. After Gradle finished I enable "Build automatically" back.
Related
in Eclipse, when Maven is enabled, there is a pom.xml file to build with Maven. And also, Eclipse has a "build automatically" option in it's project menu.
Is the "build automatically" automatically build with Maven, or we need uncheck it, because when Maven is enabled, we don't need the Eclipse build in build system anymore?
Eclipse's m2e will run the plugin goals it has lifecycle bindings for. I don't know (and I'm unable to find) what specific phases are run, but from experience I know that:
for normal operation, at least compile gets executed.
for executing tests (e.g. JUnit test cases), at least test-compile gets executed.
Note that it doesn't have all possible bindings, and going around that problem is sometimes problematic. So, usually, having both should run fine, and in fact will avoid some incongruities due to the compiled state not updating while you code.
However if you have plugins that are ignored by m2e, you should actually shut down "Build Automatically" off when you need to be certain your build completes correctly.
For example, using the Maven Properties plugin, if you have not provided a binding and set m2e to ignore, you will have resources with out-of-whack property values. The problem can especially occur when you do a "Maven" build (from the right-click context menu for example), and then do a change in your code and save it.
You need both. Here is why:
Eclipse built-in compiler is used for incremental compilation - when you save your code, for example. But full build of the project is done using maven and project configuration in pom.xml.
Is the file .settings/org.eclipse.jdt.core.prefs part of the project or is it part of my personal eclipse configuration?
Should I add it to version control?
Yes, you should. If this file is not under version control, then you cannot create reproducable builds of the same project, because it is no longer self contained, but depends on your specific Eclipse installation and its settings.
If you import this project into another workspace (on your or any other machine), it may behave completely different, as the compiler compliance settings, the compiler warnings configuration and a lot of other stuff is suddenly missing or different. Chances are high that such a project suddenly shows warnings/errors in the new workspace, while it was completely fine before.
Note: This all also requires that you actually configure all Java related settings in the Project properties. Never use the Java compiler settings under Window -> Preferences if you want to have self contained projects.
Just to give a concrete example: If you have configured your projects compiler compliance level to Java 6, because you are using Java 6 specific features (like Override annotations on interfaces), then the project will create a lot of compile errors on other peoples machines. This is because the default compiler compliance level in every Eclipse workspace is Java 1.5, and in Java 1.5 that Override annotation is simply not allowed.
This doesn't have anything to do with whether you are developing closed source or open source, as indicated in the other answer.
Contrary to #nitind's opinion, no. You should not put any IDE-specific settings under version control. Except you are developing IDE features or plugins.
In case you really have mandatory team-wide IDE settings, putting them under version control would be a good idea, but IMO having mandatory team-wide settings is not a good idea in itself.
For all other cases, shared IDE settings are bad for portable builds, even with the same IDE, and useless at best for users of other IDEs.
EDIT: I should differentiate, depending on the target group of your project. If you are developing a closed source product in a team that works with eclipse, then keeping these preferences under version control is helpful and a good idea. If you are developing a library, closed or open source, or an open source project, I consider ignoring the preferences more appropriate and polite.
EDIT2: I'm afraid #Bananenweizen is misunderstanding what I am trying to say.
I know that these settings are the eclipse compiler settings. They are still IDE-specific in the sense that they won't have any effect in Netbeans or IntelliJ as they won't have any impact on ant or maven builds from the command line.
Yes, leaving these setting out of version control can bring you many red wavy lines in eclipse on a different machine. It won't, if it's a maven project with a set source level by the way, I'm not sure about ant.
Eclipse is not building the projects by itself - it builds them with ant if it's an eclispe or an ant project, or with maven if it's a maven project. Both ant and maven have specific settings for the source version that do not depend on IDEs.
And this is where these settings ought to be - in the build file. And the build file should be under source control. The exceptions I mentioned earlier still apply.
EDIT 2020.03.15 #howlger informed me that the usability of these formerly eclipse-exclusive files has improved. They can be used in VSCode and maybe IntelliJ. This improves their chances of being useful across IDEs and may change your decision towards sharing them.
IMO, the files are mixing concerns. While I support source level and code formatting as being part of the build, I consider issue highlighting rules, save actions and similar concerns to be out-of-scope. If possible, I separate those, sharing the former by putting them into the build definition, but not the latter.
Here is the problem with putting it under version control....
If you import and open a project, Eclipse insists when IProject.open(...) is called on touching the file in the .settings folder... and this is before you can register the team provider on the IProject object. That means validateEdit won't fire and you get annoying errors whether you click "yes" or "no" on the popup asking "do you want to make it writeable?" That's all well and good for optimistic file-locking providers, but no so great for the "pessimistic" ones. For us this is just been yet another eclipse annoyance.
If it's up to me, there is no way I'd put these in source control.
The answer is "yes" and here you find the motivation for it and the proper way to do it: watch the talk "Committing IDE meta files: misconceptions, misunderstandings, and solutions." or look at the corresponding slides from EclipseCon Europe 2015 by Aurélien Pupier #apupier (Senior Software Engineer, Eclipse specialist).
I'm currently working on multiple large webapps(each webapp when being run actually contains 3-7 eclipse projects) in Spring Tool Suite on a Mac. Every imported webapp has several errors after import and project validation complete. The maven builds will fail continually until I right click on every project associated with the given webapp and select Maven -> Disable Workspace Resolution. I can think run a maven clean, maven update, and maven build to clear out all the errors.
If there a way to disable Maven Workspace Revolution in my eclipse settings/preferences so that it's a global one time setting that tells every project in the eclipse workspace not to use Workspace Resolution?
Below are some screenshots I took to hopefully provide all the relevant details such as version numbers.
I just recently switched from using eclipse with add-ons to using the preconfigured Spring Tool Suite, so the install is only a few weeks old. It should be hopefully the most up to date versions of most plugins.
It can be achieved much faster by doing a Search (Ctrl-H) for resolveWorkspaceProjects=true for files of name org.eclipse.m2e.core.prefs, with the scope set to Workspace, and Replace set to resolveWorkspaceProjects=false.
I don't believe there is a global setting to do this automatically.
Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.
Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!
We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup
Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
(Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.
The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.
Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.
Hope this helps, and best of luck!
How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.
I have a workspace that contains many projects (CDT projects, to be specific). Each project has 4 configurations, but in the future they may have more.
Project B depends on Project A.
In some configurations, I need to prevent Project A from being built.
Is there a way to tell Eclipse not to build Project A for a particular configuration?
If Project B depends on Project A, and we are building Project B with configuration X, and I have used one of the answers to question #1 to prevent Project A from being built in configuration X, then will the whole build fail?
If the answer to #2 is "yes", can I make dependencies be per-configuration, so that in configuration X Project B will not depend upon Project A?
I'm not sure I really understand what you are trying to do, but perhaps you can configure the builders for your project under Project > Properties > Builders to do what you want (like changing order or disabling individual builders).
This is a great question Chris. Using CDT with references between project (or references between configurations) has never worked well. There simply isn't enough information in the platform for CDT to do the right amount of building -- the result is that often too much building occurs.
There's work happening place now to fix this. The concept of Build Configurations is being added to the platform for Eclipse 3.7: bug 325489
And in CDT we're working on doing a better job of building references: bug 309769.
It's not clear from your question whether you're using CDT's built-in Managed build, or whether you're running make on your own makefiles. Either way the situation will be better as you will be able to easily define references at the configuration level in Eclipse 3.7 with CDT 8.