I have a solution with many projects and I would like to disable Postsharp for debug builds to reduce local developer build times. Is there any way to do this without editing each project file?
I know this may sound like a bad idea, but we are only using Postsharp for exception logging and our builds go through several environments for automated/manual testing (which would use a release build), so we would pick up on any potential issues at this point.
If it helps, Postsharp was added to the projects via nuget.
You can define the compilation symbol (constant) "SkipPostSharp" for Debug mode only.
I don't know how to do it for the entire solution, but it can be done easily
per project.
Project > Setting > PostSharp
Choose Yes for Disable PostSharp for this configuration
Related
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.
I am using the free edition of PostSharp extensively in a project. I would like to use the PropertyChanged.Fody addin to handle all the PropertyChanged Notifications automatically.
(I know that PostSharp offers a library for this, but it is not free, thus I would like to use Fody)
It appears that when I use both PostSharp and Fody in a project, the debug symbol files goes out of sync with the source code. When I debug a project I can no longer properly step through code. It looks similar to when you attach a debugger in VS to a process where the source code is different than that of the executing binary.
If I disable either PostSharp or Fody, then debugging works immediately again.
Is it possible to use both PostSharp and Fody in the same project? Does this require special / extra configuration?
Is their a way to prevent Eclipse from building or compiling a project if unsolved warnings exist? I'm very lazy and know I am likely to ignore feedback from tools like checkstyle, so I was thinking it could be useful to force correct code before compiling.
Do you think this is a good idea? Do you know how I might do this in eclipse?
Thanks.
Eclipse
In the Preferences window, under Java|Compiler|Errors/Warnings, each of the various types of problems can be set to Ignore, Warning, or Error. You can change any or all of them to Error.
At the bottom of the page is a checkbox for:
Treat above errors like fatal compile errors (make compiled code not executable).
So, decide what messages you want to fail your build, and check that last checkbox.
Non-Eclipse Use
If you want to use checkstyle, findbugs, or pmd and have them fail your build, you will have to depend on an external build tool like Ant, Maven, or Gradle. You can create <checkstyle>, <findbugs> or <pmd> tasks, and have your real <package> target depend on them; that way if the audit task requires compilation, the target allows it, but you'll never get a [ejw]ar file out of it.
It's actually a good idea to have a build system that does not depend on the IDE. You may want to use a CI system, for example.
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 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.