I have a few utility functions, snippets and scratches that I want to be able to use in every project.
Currently I have the following setup for Clojure projects and Intellij IDEA/Cursive:
I have a user profile defined in .lein, where I have source-paths pointing to
when I sync and run REPL for project in IDEA/Cursive, I check that :user profile is selected (it is the default)
Cursive shows both project files and common files (i.e. scratches folder) in project pane
I can edit and eval in REPL real project files and my local helers/scratchpads seamlessly.
Is there a way to achieve this behaviour in VSCode?
Notes:
My clojure setup in Cursive is for illustration purposes only. I would like to find a way to get similar feature in other scripting languages (i.e. python, groovy). So ideally I don't want to use leiningen for that, but rather find a generic way to add common source folder to VS code Explorer pane.
I know that with multi-root workspaces I can achieve what I want, but it must be done manually per project. It would be much better if my folder with common utils was added to every workspace automatically. Something like a default workspace template would solve this, but I couldn't find anything similar. Am I missing something?
I have a plugin that adds arbitary information to resources of projects through the persistent property mechanism of eclipse. Now these projects are stored in version control systems like SVN and GIT.
The persistent properties will not get checked in because they are stored in the metadata of the workspace and not inside the project itsself.
%workspace%\.metadata\.plugins\org.eclipse.core.resources\.projects\%projectname%\.indexes
Is there a way to save these properties to the project and manage them via version control?
If not, does anyone have tried a custom solution for this?
There has been a question alike here:
Eclipse: Storing info in .project file
and the answer is useful if you want to store project scope information that does not refer to single resources. But i need to connect information to folders and files and store that information inside the projects filesystem location.
You could include the path of the resource in the 'key' part of the project scope preference value. So:
preferences.putString("/path/to/file/keyword", value);
I know this is a rather old question but it pops up as one of the top matches when searching for "Eclipse project scoped resource properties". (Having searched for this, it's obvious that I was looking for a solution myself.)
Eclipse provides project scoped preferences with the
ProjectScope. These preferences are stored in files in /<project>/.settings and can thus be added to version control easily. If you have e.g. set the encoding for a file in your project, you'll find org.eclipse.core.resources.prefs in this directory, and you can see how the resources plugin (which maintains this file) uses a specific scheme to combine a property name and a resource name in a preferences key.
Using this as a basis, I have implemented a custom solution for storing "persistent resource properties in Version Control" (a.k.a. "project scoped resource properties"). You can have a look at the solution here. Generating a key and storing the properties as preferences is straightforward and easy. In addition, my custom solution tracks deletions of files and removes properties to avoid having them "pop up" if you later create a file with the same name again. It also tracks moves/renames and keeps the properties associated with the moved/renamed file. Note that it deliberately doesn't copy the associated properties if a file is copied, because this is not the intended behavior for my use case.
It works, but as is usual with such a complex environment as the Eclipse platform, I have probably not considered every issue. When I have time, I'll dig in the source code of the resources plugin and have a look how to do it properly. Meanwhile, it works well enough for me.
I have seen, read and thought of different ways of using Workspaces (per project, per application (multi-asseted or not), per program language, per target (web-development, plugins,..), and so on) and I am still doubting what the best approach is.
Can anyone give a detailed, but not a page long insight into this?
This involves a lot of sub-questions, so to speak, and I don't know all the specific sub-questions I should ask, as I am sure I don't know all aspects of Eclipse (and Workspaces), but I'll try to give an example of what I am looking for:
What for?
What did the Eclipse development team expect it to be used for?
What do other/most people think?
What do you think?
... ?
Why?
Are there configuration conflicts vs. sharing merits?
Any filespace reasons?
Performance?
... ?
I am speaking of the minimum use-case for a developer that uses different languages and protocols, not necessarily all of them in one project (E.g. Php, Javascript and XML for some projects, C# for others, Java and SQL for still others, etc..)
Edit 2012-11-27: Don't get me wrong. I don't doubt the use of
Workspaces, I just want to use it as it is meant to be or otherwise if
anyone would think it better. So "what for?" means: What's the best use? And
"why?" actually targets on the "what for?", in other words: tell me the reasons
for your answer.
I'll provide you with my vision of somebody who feels very uncomfortable in the Java world, which I assume is also your case.
What it is
A workspace is a concept of grouping together:
a set of (somehow) related projects
some configuration pertaining to all these projects
some settings for Eclipse itself
This happens by creating a directory and putting inside it (you don't have to do it, it's done for you) files that manage to tell Eclipse these information. All you have to do explicitly is to select the folder where these files will be placed. And this folder doesn't need to be the same where you put your source code - preferentially it won't be.
Exploring each item above:
a set of (somehow) related projects
Eclipse seems to always be opened in association with a particular workspace, i.e., if you are in a workspace A and decide to switch to workspace B (File > Switch Workspaces), Eclipse will close itself and reopen. All projects that were associated with workspace A (and were appearing in the Project Explorer) won't appear anymore and projects associated with workspace B will now appear. So it seems that a project, to be open in Eclipse, MUST be associated to a workspace.
Notice that this doesn't mean that the project source code must be inside the workspace. The workspace will, somehow, have a relation to the physical path of your projects in your disk (anybody knows how? I've looked inside the workspace searching for some file pointing to the projects paths, without success).
This way, a project can be inside more than 1 workspace at a time. So it seems good to keep your workspace and your source code separated.
some configuration pertaining to all these projects
I heard that something, like the Java compiler version (like 1.7, e.g - I don't know if 'version' is the word here), is a workspace-level configuration. If you have several projects inside your workspace, and compile them inside of Eclipse, all of them will be compiled with the same Java compiler.
some settings for Eclipse itself
Some things like your key bindings are stored at a workspace-level, also. So, if you define that ctrl+tab will switch tabs in a smart way (not stacking them), this will only be bound to your current workspace. If you want to use the same key binding in another workspace (and I think you want!), it seems that you have to export/import them between workspaces (if that's true, this IDE was built over some really strange premises). Here is a link on this.
It also seems that workspaces are not necessarily compatible between different Eclipse versions. This article suggests that you name your workspaces containing the name of the Eclipse version.
And, more important, once you pick a folder to be your workspace, don't touch any file inside there or you are in for some trouble.
How I think is a good way to use it
(actually, as I'm writing this, I don't know how to use this in a good way, that's why I was looking for an answer – that I'm trying to assemble here)
Create a folder for your projects:
/projects
Create a folder for each project and group the projects' sub-projects inside of it:
/projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1
Create a separate folder for your workspaces:
/eclipse-workspaces
Create workspaces for your projects:
/eclipse-workspaces/proj1
/eclipse-workspaces/proj2
The whole point of a workspace is to group a set of related projects together that usually make up an application. The workspace framework comes down to the eclipse.core.resources plugin and it naturally by design makes sense.
Projects have natures, builders are attached to specific projects and as you change resources in one project you can see in real time compile or other issues in projects that are in the same workspace. So the strategy I suggest is have different workspaces for different projects you work on but without a workspace in eclipse there would be no concept of a collection of projects and configurations and after all it's an IDE tool.
If that does not make sense ask how Net Beans or Visual Studio addresses this? It's the same theme. Maven is a good example, checking out a group of related maven projects into a workspace lets you develop and see errors in real time. If not a workspace what else would you suggest? An RCP application can be a different beast depending on what its used for but in the true IDE sense I don't know what would be a better solution than a workspace or context of projects. Just my thoughts. - Duncan
Basically the scope of workspace(s) is divided in two points.
First point (and primary) is the eclipse it self and is related with the settings and metadata configurations (plugin ctr). Each time you create a project, eclipse collects all the configurations and stores them on that workspace and if somehow in the same workspace a conflicting project is present you might loose some functionality or even stability of eclipse it self.
And second (secondary) the point of development strategy one can adopt.
Once the primary scope is met (and mastered) and there's need for further adjustments regarding project relations (as libraries, perspectives ctr) then initiate separate workspace(s) could be appropriate based on development habits or possible language/frameworks "behaviors".
DLTK for examples is a beast that should be contained in a separate cage.
Lots of complains at forums for it stopped working (properly or not at all) and suggested solution was to clean the settings of the equivalent plugin from the current workspace.
Personally, I found myself lean more to language distinction when it comes to separate workspaces which is relevant to known issues that comes with the current state of the plugins are used. Preferably I keep them in the minimum numbers as this is leads to less frustration when the projects are become... plenty and version control is not the only version you keep your projects.
Finally, loading speed and performance is an issue that might come up if lots of (unnecessary) plugins are loaded due to presents of irrelevant projects.
Bottom line; there is no one solution to every one, no master blue print that solves the issue. It's something that grows with experience,
Less is more though!
Although I've used Eclipse for years, this "answer" is only conjecture (which I'm going to try tonight). If it gets down-voted out of existence, then obviously I'm wrong.
Oracle relies on CMake to generate a Visual Studio "Solution" for their MySQL Connector C source code. Within the Solution are "Projects" that can be compiled individually or collectively (by the Solution). Each Project has its own makefile, compiling its portion of the Solution with settings that are different than the other Projects.
Similarly, I'm hoping an Eclipse Workspace can hold my related makefile Projects (Eclipse), with a master Project whose dependencies compile the various unique-makefile Projects as pre-requesites to building its "Solution". (My folder structure would be as #Rafael describes).
So I'm hoping a good way to use Workspaces is to emulate Visual Studio's ability to combine dissimilar Projects into a Solution.
It's just a feature for structuring projects.
Obviously Eclipse designers tried to avoid having global settings for Eclipse and decided to put them into workspace.
Each Eclipse app depends on each workspace settings.
Is it a good decision? I think it's not so.
It lacks flexibility. It was naive to expect that global settings can be avoided.
It doesn't allow you to have single projects (it can be a surprise for Eclipse designers but it happens quite often).
But it still works.
Many people use it. Sometimes they suffer but more frequently everything is ok.
The problem we have are as follows:
We are using ANT to build our application. However, the application is built multiple times, once for each client (they have different skins / cms / i18n etc). Up to now, we had no need to compile them all at once (usually just work on one client at a time). Now, we want our build server to build all permutations for all clients in all languages. In other words, we need to create a war file for each client, each containing their own compilation.
At the moment, the client name is read in from the application's .properties file.
My question is this. Is there any way that the client.name property (from the application's .properties) be overridden in the build.xml used by ant? Or is the only way to create a different target for each client and hard-coding the name?
Thanks.
If you use Hudson to do your build, and have more than one parameter to change, you should be able to do a Matrix Build. There is more detail in this answer.
If it is just one parameter, you should be able to do a properties file and use Ant to read this properties file and iterate through it - I'm not sure precisely how, but you won't be the first person to have this problem, and if you are it wouldn't be difficult to create your own task. Or if not use Macros.
What is the difference between Java Build Path - Add External JARs Button and Add Variable Button Functionality,
Why its required. Please explain in detail.
Both can be used to achieve the same thing: add a JAR to your build path.
Suppose you have a project P1 that wants to use a JAR installed by supplier S1, which happens to be located at C:\S1\aproject\jars\Useful.jar
Client Add External JARs, navigate, select, and we're done.
But, consider these cases.
1). Suppose you have several projects that all want to use that same JAR? You end up repeating that for projects P1-PN. Gets dull. What's worse, suppose you install a new version of S1's stack, now you need to update all those project's build paths to reference
C:\S1\aproject-**v2**\jars\Useful.jar
And what's worse, if you miss one then you are running two versions of the JAR that may be really bad!
2). You share a project with a colleage who happens to have S1 product installed in a different location. They now need to amend the project to point to
E:\MyFavouriteThings\S1\aproject\jars\Useful.jar
And if you are using an SCM you may tread on each others toes.
So:
Instead Add Variable allows you to define a Workspace variable (ie. specific to your environment) which can then be used to reference that JAR
$(S1_JARS)\\Useful.jar
Now you a single place to update to a new version of S1, and each developer can set his own value for S1_JARs.
I would recommend using Variables for non-trivial development scenarios.