When I create a Gradle project in Eclipse via the Buildship plugin I end up with two projects: one of them is called "lib". There is apparently no option to prevent this or even to rename the lib project to anything more meaningful.
A bug has been filed here but it's been closed because this is how the Gradle developers want our projects to be structured regardless of size or complexity.
The only workaround I know involves manual tweaking of the generated files.
Is there any way to make the Buildship plugin behave like it used to do in the past, with only a single maven-structured project?
I'm currently using JUnit 5.1, but I want to switch to JUnit 5.5 (at least 5.4) to use new features of that version (mainly the #Order annotation), but I'm really struggling to properly set it up.
Unfortunately I cannot simply switch to a newer eclipse version, because I'm tied a specific version we use at my workplace.
As there is no JAR-download, i've tried to build it from source. The only guidelines concerning this are saying to build it with Gradle, but I don't understand how to do this.
What I tried so far:
- downloaded the repository as an archive (zip) and imported it to eclipse, which resulted in multiple projects and <1.000 errors
- imported the repository into eclipse (via import wizard), but failed to find a way to make a build from it
I was able to run some test with JUnit 5.4 features, but i achieved this by downloading different modules as JARs from some maven-repository I found in a JUnit issue on github and including them as external JARs into the classpath. This was very tedious because of the number of different JARs & the way they were organized in the repository folders.
To me this feels like a workaround, as I still have no idea how to solve the initial problem of building JUnit from source.
I'm quite new to eclipse and have a basic understanding of what Gradle is, but I've never used it so far.
I don't expect a detailed step-by-step guide on how to achieve this (although I wouldn't complain ;) ), but I'd really appreciate it, if you could give me an outline of how building from source is done in general and maybe additional references for me to read about certain steps (e.g. setting up gradle).
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 think it is quite normal to have more than one binary in a project. However, with Eclipse CDT I don't know how to set up the IDE to get things done.
I know I can create several projects - one per binary. And I know I can set the dependencies per project. However, I cannot regard them as one project in Eclipse. If I'd like to share the code with a version control system (like svn), each developer has to import the projects separately.
What I miss is something like the Solution (sln file) in Visual Studio. Should I create a single project and create the make files by myself?
I haven't tried it out yet, but there is this 'project set' which can be ex- and imported. Is this the solution? Can this be put into version control?
My goal it to put everything under version control, not only subprojects. I cannot imagine that CDT makes only sense for single-binary applications.
How can I work properly?
I am quite sure CDT doesn't support sub-projects, which leaves you pretty much with:
one workspace per "set of projects"
one project per binary (like you mention in your question)
project dependencies (like you mention in your question)
In term of version control, that means:
submodules (Git),
subrepos (Mercurial) or
external (SVN)
for each project needing a shared library project.
In short, that means putting under version control various components (set of files), with one referencing specific version of others (that list of specific versions of other components is called a "configuration", based on a component-based approach development)
In Netbeans 6.5, I've got two different C++ application projects - my application and the unit tests. I want to set it up so that if my main application is rebuilt, the unit tests are rebuilt as well (and vice versa).
Netbeans is good at resolving the dependencies for library projects, and rebuilding them if necessary, but I can't see any way of making one application project depend upon another.
I could do this by editing the .build-post rule in the Makefile by hand, but that's a bit ugly.
I suspect adding some magic macros to the Project Properties -> Build -> Debug -> Additional Dependencies dialogue would do what I want, but I can't find any docs for this.
I suppose this is probably a sign that I should switch to Cruise Control to automate the process of building and running my tests...
Support for this was added in Netbeans 6.7.
Project Properties -> Required Projects -> Select the project and tick "Build".
Note that it won't let you create a cyclic dependency by having two projects Require each other, but you can work around this by creating a dummy Main project that Requires all the projects that you want to build together.