I'm trying to associate information with projects (certain properties). I tried using the persistence store (getPersistentProperty() and setPersistentProperty()).
The problem with that is that when I export the project and re-import it in a different workspace, those properties are gone (since they are stored somewhere in the .metadata folder of the workspace).
So I was thinking that if there's a way to store the info in the .project file then this would solve my problem because this file is always included when projects are exported.
Is there an API to do that?
Any pointers would be appreciated! Thank you!
Regards,
T
You may need to consider using a configuration scope to store preferences across workspace.
See project scope preferences.
Using Store (as discussed in this thread), you also get some details on the nature of a configuration in this FAQ.
Related
I am using Eclipse in combination with the ABAP Development Tools (ADT) as main plugin for SAP-development.
Now I created some additional templates (View: Templates) and I just want to know where they are stored as I lost some of the templates and I want to check if I can find them in a backup somewhere (on file structure level).
Are the (additional created) templates as well stored in the workspace? Eclipse/ADT deliver also some basic templates, where are they stored?
Thank you for helping me to find the correct folder/file where this information is stored.
I have multiple maven projects that are related to each other in Eclipse.
Now I need to check the projects e.g. for cyclic dependencies. What I have is a folder that contains the constraints in every single project.
Is there a possibility to check the rules (constraints) with jqassistant without putting them into a folder in each project ?
Maybe there is a way to define the rules in a root project and let the tool know which projects it has to search for.
thanks for help
Tino
PS: Sorry for my bad english :)
there's currently only one way to share rules between projects by creating a plugin, i.e. a JAR file containing rules.
The documentation provides examples for
The structure of such a plugin
How a plugin is used with jQAssistant.
Would that solve your problem?
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.
When you change the classpath of an Eclipse project, the .classpath file changes so that if you send the project to someone else (including the .classpath file) they have the same classpath. But when you change a resource to "Derived", there is no change in either .project or .classpath. So where is Eclipse storing the information about which files and folders are derived?
Edit: I found this: "currently the derived state is stored in a single bit within a
flag integer associated with each resource in the workspace tree file" but if someone could explain more precisely where that flag integer is stored, and how to change it, that would be quite appreciated.
Long discussion on this eclipse bug which requests that derived state is persisted with the eclipse project settings (which can be shared), rather than in the workspace metadata (which can not). The bug is quite old, and remains unaddressed, but there is quite a lot of discussion.
My situation is that I'm generating a lot of java class files as part of an ant build in a workspace directory, and want to mark them as derived so they don't show up in searches. I think the option I will take is probably to adjust my automation so that it marks its generated resources as derived:
IResource.setDerived(true);
The OP's situation seems somewhat different. I'd probably try and base my project's build paths on a variable which each user can define independently, so your .classpath file is the same for all users.
This is not an answer to the question, but something that is directly related what I believe to be the issue at hand. That being the ability to share which files should be derived in a project with others.
Found this plugin to address that:
http://nodj.github.io/AutoDeriv/
For my current project, every time I set up a new workspace, I need to import hundreds of existing projects scattered in 20+ different directories. Is there a way to automate this step in Eclipse?
These projects are all checked into ClearCase.
This answer shows how to import an arbitrary set of projects into Eclipse using a custom plugin.
If I understand your question correctly, you would simply need to specify the paths of all the projects to import in the newprojects.txt file in the workspace root. You may want to remove the part that deletes existing projects though.
Could you import them all into a SCCS and then check them out all at once? You might try this as an experiment using cvs, not because you want to start using cvs in 2009, but because it has the best Eclipse support. If cvs can't do it, the others probably can't either.
For snapshot views, we have a "template" workspace which reference the .project and .classpath files in a "standard" way:
c:\ccviews\projectA\vob1\path\...
c:\ccviews\projectB\vob1\path\...
c:\ccviews\projectC\vob2\path\...
So by copying that workspace, we are able to quickly setup the projects for a new member of the team.
Each colleague will define their own snapshot views with:
a unique name (
colleague1_projectA_snap,
colleague1_projectB_snap,
...)
the same root directory for each view referring to a given project
(c:\ccviews\projectA for:
colleague1_projectA_snap or
colleague2_projectA_snap or
colleague3_projectA_snap...)
Since a snapshot view can be located anywhere you like on your disk, you can:
define a standard path
scale that to a large number of snapshot views.
Of course, that would not be possible with dynamic views, since their paths would by:
m:\aUniqueName\vob1\path
You could ask for each user to associate a view to a drive letter, but that do not scale for a large number of views.
Anyway, dynamic views are great for accessing and consulting data, not for compilation (the time needed to access any large jar or dll through the network is just too important)
Eclipse as the concept of project sets, but I'm pretty sure that's tied to using CVS. My team used this feature and it's how we shared the set of projects between us.
Another 2 alternatives I know of:
Buckminster
It's an Eclipse project which does component assembly, and one part of that is projects. Documentation was a bit crappy last time I played with it, but it does work. No idea if they have support for ClearCase, though it is extensible.
Jazz
Costs money and is also built on Eclipse. Covers similar ground to Buckminster but goes a whole lot further in team-orientated stuff.
I have created some scripts to do this for SVN. Currently, the scripts are run from Vagrant, but you could run them standalone. The process for clearcase should be similar.
See the answer here, which provides links to the source code: https://stackoverflow.com/a/21229397/1033422