I would like to know if there is a way to organize multiple DSLs inside a single Eclipse project. More specifically, I would like to organize all five Xtext projects of a DSL in some top-level "project folder".
The background is that we manage complexity and enable reuse by making smaller reusable DSLs, e.g. one reusable for expressions and other one for more domain-specific or application-specific aspects. However, each Xtext DSL results in 5 projects, causing a lot of clutter in the Package Explorer when multiple DSLs are involved. A strongly related question has been asked before:
Xtext: define 2 DSL's in one project
The answer there is that multiple DSLs are not needed inside the project for that specific use-case. My use-case is different because I want to be able to easily view the different DSLs and potentially co-develop them.
We are using Xtext in an environment managed by Gradle. We are using the Gradle Eclipse plugin, which creates a lot of Eclipse project files everywhere. As a result, when choosing to "Open Project from File System" in Eclipse, I not only get the option to import the five projects related to the DSL, but also the option of opening the parent folder as a project. This means I can have each DSL (all its five projects) organized neatly in a "project folder". This is exactly what I want! ...
BUT ...
it does not actually work. The figure below shows my package explorer with the five projects of my ExperimentDSL included in the bottom. This DSL works. On top, it shows the folder structure I get when including the project file generated by Gradle, resulting in a "project folder" that can potentially contain multiple DSLs.
As you can see, GenerateExperimentDSL is flagged red and refuses to run. It seems Eclipse somehow treats it as a Java project, but I do not know how to change this or and if this would help solve my problem. Secondly, I would not know how to set up such a project by hand, since the project file in this failing case was generated by Gradle.
Long story short, does anyone know how to get this kind of folder structure to work so that I can keep all my DSLs in the workspace without clutter?
What you try to do is currently not possible. Have a look at the concept of WorkingSets in Eclipse that let you achieve something similar
Related
Personally, I am a very visual-oriented sort of person. A long list of classes, especially with similar names, in one package in Eclipse can be a pain to stare at. Is there an Eclipse plugin or a way to annotate classes in the Package Explorer with colors?
I am aware of and currently use Eclipse working sets, but I would like to furtherly color-label the classes themselves in the package explorer list.
Seems like a pretty far-fetched request, but is it possible?
Yes there is an plugin call Resource Decorator Check this blog for more details.
Check the motivation section:
While working with mylyn and working sets helps to organize the workspace, I was always missing some visual distinction between different project types. Like having different colors for plug-ins and features or highlight important files.
You can use regular expression to decorate a set similar resources.
I work for a big company that has standards on Java project names. Long standards:
com.company.department.subdepartment.stream.project
Rather than let the package explorer take up a sizable portion of my screen, I'm looking for a way to shorten the project names. Mousing over project names shows the full name, but it's still very slow to determine which project I want to look at next with the incredibly long names. As has been answered before, package names can be shortened. I've got a rule set up, but it only works for packages:
com.company.department.subdepartment={department}
Is there a way to do an analogous thing for project names in Eclipse?
Package explorer uses the org.eclipse.jdt.internal.ui.packageview.PackageExplorerLabelProvider class to provide the view labels. Going through the source of this I don't see any support for shortening the project names.
The following ideas depend on how your eclipse workspaces are setup. If you're lucky and you just import project from your VCS, these could work for you.
If you're using maven, Eclipse project names are usually derived from your GAV. The Import as Maven project wizard has options for what pattern to use for the project name based on your maven GAV.
Otherwise, you can sometimes just right click the project -> rename. YMMV if you have any scripts or such that have the project name hardcoded. If you have these constraints, find those scripts and use variables rather than hardcoding.
I have a lot of projects in Eclipse and I'm trying to tidy it up with something simple like a folder. Is there any way to do this so i can have, for example all projects for a particular client in one collapsable folder?
You can achieve this organization within eclipse without actually changing the filesystem structure of your projects. The feature, to cut to the chase, is called Eclipse Working Sets.
The gist is working sets are groups of projects or resources, and most of the eclipse views (package view, enterprise explorer, navigator, etc) can honor and switch between working sets.
Create a working set of type Resource, select the projects you want, then in the package explorer carat drop down (I'm looking at eclipse Kepler) you can either have the top-level elements be the working sets (e.g. a folder-like view per client) or you can filter out stuff one working set at a time.
Some other uses for working sets might be projects of certain types, Java vs. C++ projects, etc. as outlined in this older tutorial.
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.
Background
I'm a developer of the Vrapper project.
Vrapper contains of 2 major parts
Vim-emulation library (vrapper.core)
Eclipse part that makes a good use of it
We want vrapper.core to be Eclipse-unaware, so it's reusable
outside of the Eclipse. Currently, we can "vrap" all sorts of Eclipse
text editors and our little mock text editor that we use for unit testing.
vrapper.core implements all sorts of Vim commands, modes, etc.
Those all communicate with Platform - an interface that abstracts out
underlying stuff (text editor, clipboards, settings system, etc.).
When mode is created for an editor it asks platform if there are extra
commands that are approperiate for underlying editor, currently edited file type, etc.
EclipsePlatform provides those commands using Eclipse extension points mechanism.
So, let's consider the following projects (there are more):
vrapper.core - Eclipse-independent code for Vrapper
vrapper.eclipse - Eclipse plug-in that depends on vrapper.core
surround.core - Eclipse-independent code that emulates surround.vim (Vim plug-in)
surround.eclipse - Eclipse fragment for vrapper.eclipse
that makes it provide commands form surround.core.
There are two ways we can deal with those:
One plug-in to rule them all
This is how it should look like from Eclipse's perspective.
There is one plug-in that contains code from vrapper.eclipse and vrapper.core,
and one fragment that contains code from surround.core and surround.eclipse.
Many plug-ins
There are 3 plug-ins
two OSGified libraries vrapper.core, surround.core
vrapper.eclipse
surround.eclipse fragment depends on vrapper.core in this case
Problems
Many plug-ins solution have some issues with lazy class loading that I don't understand.
It's beacause when instances of modes from vrapper.core are created they need
classes from surround.core to be created (via vrapper.eclipse -> surround.eclipse).
This works if you run stuff from Eclipse and select all plug-ins from run configuration,
but if one deploys features & plugins and run eclipse normally an exception is thrown
because classes from surround.core cannot be found.
It's something in the spirit of surround.core asking for extra commands from
dependent plug-ins creates implicit circular dependencies.
What I mean by implicit dependencies is that no core class depends on eclipse-specific classes in compile time.
Modes (like vim normal mode) are core classes. They contain commands. There are some commands specific for particular Eclipse editors (like run this JDT-specific refactoring). Those commands implement core interfaces, but their code (obviously) lives in eclipse-specific projects. When mode is created it asks underlying platform for some extra commands - those extra commands are implemented in eclipse plug-ins. This is when lazy class loading in eclipse make everything blow up in runtime - classes for extra commands are referenced by extension points, but they are not yet loaded. Boom, exception.
I tried to work this around by using "one plug-in to rule them all" approach.
Having just one plug-in seems to be much better solution to me, but I couldn't make it work cleanly.
Only thing that succeeded for me was quite an ugly hack.
All .core projects had an Ant task that created .jar file with their classes
and dropped it into corresponding *.eclipse project
*.eclipse projects included that jars and had them enlisted in MANIFEST files.
The problem with this ugly hack approach (besides of it being ugly hack) is
that development becomes quite painful. Eclipse code navigation, code coverage
and few other things in Eclipse stops working.
Summary
We have eclipse independent library + eclipse specific stuff architecture,
but we really need all of this to live in one plug-in (because there are some dependencies in both directions).
How do I make code from few projects live into one plug-in/fragment?
It turned out that adding Eclipse-BuddyPolicy: dependent to MANIFEST.MF files, reexporting some dependencies and turning one fragment into plugin (so there is plug-in dependency for BuddyPolicy to track) was the right solution.
Problem solved :-)
From reading this it sounds as if the actual problem is the fact that there are dependencies in both directions. Can't you refactor your projects to make only the Eclipse-spcific proejcts depend on the core projects, and not the other way around?