Community
Participate
Working Groups
Users that work in a team environment often need to distribute Eclipse preferences to the whole team and to each user's workspace. Currently the only option is to import and export an .epf file from the Eclipse user interface. A possible way of making this administrative task less time consuming consists of providing a plug-in that contains two ANT tasks, to import/export the Eclipse preferences to/from a given workspace. It will then be possible for users or system administrators to simply run a batch file that will update each user's workspace by running Eclipse in headless mode.
Reassigning to Platform
Is this task already scheduled ? do you have resources to write the code ? if not maybe it is good idea to mark this extension as "bugday" for this month ?
this is not scheduled and is unlikely to happen without community involvement.
I have already written and I could provide some sample plug-in code and descriptions of how to use it. I would just need indications concerning the preferred naming conventions.
Lara could you provide this example as attachment to this enhancement?
Sample code and instructions for how to run it has been provided at this URL, for the convenience of users who requested it for products based on Eclipse 3.2. http://www-1.ibm.com/support/docview.wss?uid=swg21273017 Expect this URL to go live by Dec 14. I expect that you will have to rename the packages to match the platform's conventions and perhaps decide whether similar code must be inserted in an existing plug-in.
Created attachment 86213 [details] Patch This patch adds both tasks to org.eclipse.ide. I know this may be a little bit controversial but I am open for any suggestions. I am also afraid that this patch may not work because of bug 108337 - I will work on it on Monday.
Situation with bug 108337 is clear (see comments there). The only thing to do is figuring out where those scripts should be placed.
For these tasks to be added to the org.eclipse.ui.ide this will have to be addressed by the platform ui team and not the Ant team.
As this adds Ant dependencies to the ide this would be a major change for what could be just a standalone feature so I can't see us wanting to put this in the platform. I think this one is best suited as a community contribution outside of the platform in it's own standalone plug-in.
Removing the 3.4 as we won't be changing our dependencies for this issue.
(In reply to comment #11) > Removing the 3.4 as we won't be changing our dependencies for this issue. Tod, It's really important enhancement for large teams from enterprise environments. They need a way to automatically setup workspaces using scripts without user interaction. If there's any better solution than ant task, I'd love to hear about it.
There is no reason that you couldn't take the WizardPreferencesPages and make import and export operations for them like we did for ArchiveFileExportOperation and just use the operations. Note that the API freeze for 3.4 has passed and the feature freeze is M7 (mid May 2008).
(In reply to comment #13) > There is no reason that you couldn't take the WizardPreferencesPages and make > import and export operations for them like we did for > ArchiveFileExportOperation and just use the operations. ok, that sounds simple :) But how can I make use of operations from outside of Eclipse? e.g. from shell script or ant task?
Ok now you have me confused. Why did you want to add ant to the ide at all then if you don't want Eclipse? The purpose of the UI preference support is to filter out what the user has set themselves from what is in the preference store in a way they can understand in the UI but it is backed the Core preference API. If you want to run without the UI at all you could just write a headless application that talks to the Core API only .
(In reply to comment #15) As you're able to configure your workspace with UI, it'd be useful to allow to do this from outside, e.g. Company prepares developer-ready environments for it's 350 devs - if they tell them all to import appropriate preferences from location X - there'll be for sure at least one who won't do that :) I'm not sticking to IDE. This feature can live in some other plugin. Why I believe it should stay in SDK and not in some external plugin is because: - there's already all preferences import/export stuff ready - it just needs a batch interface; - enterprise users are asking for it. Consider a number of already existing ANT tasks contributed by Eclipse plugins: - pde has tasks to export products, features, plugins - emf has tasks to import/export Ecore, XSD, etc. - IDE(?) could have tasks to import/export preferences
(In reply to comment #12) > > If there's any better solution than ant task, I'd love to hear about it. > I've thought about this problem myself. I would prefer some sort of hierarchical preference store: someone defines the preferences for the company, another person for the project and a developer for his environment (or any other hierachy you want to use). The preference stores are linked and the last defined value overwrites the others (unless prohibited on a higher level). I've looked very briefly in the code and it seems that the preferences are actually read by Equinox (correct me if I'm wrong). If there is a chance that this will be accepted as a contribution my company is willing to work on this (we have done this on bug #201052).
It seems like a pretty straigtforward core / ui split. You should write one headless plug-in and then one with a UI if you think you need it. As far as the UI goes it sounds like what we already have does what you want though - point to a location and then import. I don't see what else you would want to add unless it was to change the workspace switching somehow. And you are right - it is the Equinox preference store that we use. Some warning though - preferences are currently full of extra information you don't want the whole company to use as much of it is local to your install. Export all of your preferences now to see what we mean. I wouldn't expect any of this to make it into 3.4 as it is very late in the cycle.
(In reply to comment #18) Importing preferences won't reflect changes made afterwards higher up the chain. This is something which is not necessarily connected to developers who are able and willing to work with exported preferences, we are doing RCP based applications for non-IT customers. In this domain it would be a lot easier to use a hierarchical approach. Since all possible solution I've thought about would require some changes to the API there is no need to rush it since the 3.4 API is frozen by now. But there is a life after 3.4.
(In reply to comment #17) > I've thought about this problem myself. I would prefer some sort of > hierarchical preference store: someone defines the preferences for the company, > another person for the project and a developer for his environment (or any > other hierachy you want to use). The preference stores are linked and the last > defined value overwrites the others (unless prohibited on a higher level). > I've looked very briefly in the code and it seems that the preferences are > actually read by Equinox (correct me if I'm wrong). If there is a chance that > this will be accepted as a contribution my company is willing to work on this > (we have done this on bug #201052). thanks Achim, it sounds pretty cool. do you have any idea how to apply these preferences without user interaction? Also it may happen that company preferences have changed and it's necessary to update them silently.
I work for a large IT shop supporting multiple users using an eclipse based product. We use Ant to assemble a set of projects, source code resource etc. Without a mechanism that is callable from ant, we cannot completely configure the eclipse workspace. Each user must import preferences after launching a freshly build workspace and then compile the workspace. This causes users, especially, new user to have problems that this mechanism would resolve. Having the ability to import preferences from ant would allow us to configure and then compile the workspace, which we cannot do today. We also use ant and cruise control to do nightly builds. Because import preferences are not available from ant, we must make sure all projects are committed with the correct configuration I.E JRE version etc. Import preferences sets all values correctly for an IDE workspace has no errors. However, when we execute a rolling build it fails sometimes because say for example an incorrect JRE entry for a project that would be fixed by importing preferences. This is another source of grief. Silly question, if this functionality does not belong to the IDE and does not belong to ant should a new area, responsible for automation, be created to add valuable automation like this to Eclipse?
Maybe it would be good to add this functionality to ant plugins, not to platform? Reassigning component for Ant team attention.
This bug is open for almost 3 years. Platform is not interested (because it would introduce additional dependency). And what about ANT team? Could you please comment this bug?
(In reply to comment #23) > This bug is open for almost 3 years. Platform is not interested (because it > would introduce additional dependency). And what about ANT team? Could you > please comment this bug? The Ant team is in minimal maintenance mode currently - i.e. no one is working on it full or part time - only when something critical comes up.
As Tod already said, a Preferences export contains a lot of local data that won't apply or even work correctly to other workspaces. Remember preferences are part of the workspace and workspaces are definitely NOT intended to be shared. Reading the intended use cases her, it seems like they could be met by using project-specific settings which are checked into source control so that every workspace that checks out the project automatically uses those settings. AM I missing something?
So why it is possible to import/export them? It may be possible some day to export only particular preferences group (validation, compiler settings, CVS repositories (this is possible now) and similar). But import will work correctly only on clear workspace. You cannot say: this is company policy right now. all new projects must follow it. apply this preferences.
(In reply to comment #26) > So why it is possible to import/export them? > > It may be possible some day to export only particular preferences group > (validation, compiler settings, CVS repositories (this is possible now) and > similar). If the preferences extension providers (the plug-ins that contribute preferences) would do a better job of assigning categories, then that selective export/import would indeed be more useful). I'd encourage everyone to file bugs where they see a plug-ins preferences not assigned to a category for export/import. > But import will work correctly only on clear workspace. You cannot say: this is > company policy right now. all new projects must follow it. apply this > preferences. Why can't you say that? In fact, using project-specific settings is the best way to enforce such things; if you set up a developer's workspace with certain settings, he can easily change them later and there is no way to detect or block that. Project-specific settings, when checked in, provide a lot more "protection" and enforcement, and are more flexible. Of course a determined user can change them locally if he is really determined to undermine the policy, but check-in of them can be restricted and/or easily detected. Besides, that's a personnel problem not a technology one.
I have to agree with Eric, using project specific settings is much preferable to an Ant task. This feature would be better served as its own bundle and not part of of the SDK. Marking as WONTFIX
Some things to consider we have 29 + projects in a small workspace. We maintain upwards of 300+ projects. We are moving away from project setting because maintenance is a nightmare. Consider upgrading the JDK from 1.5 to 1.6 and having 300+ java projects to update in the simple case. In this example where is the best place, in your opinion to store the JDK settings at the 300 times, once for each project or once at the workspace level? How do you I achieve the following configuration with project settings: set the default JRE/JDK for new projects? set the JDK compiler rules in a consistent manner across all project in the workspace. set the default user capabilities set the internet proxy? set the CVS timeout? set the label decorations IE turn on CVS viewing?
Almost every month somebody request this feature from Eclipse Support. There is a lot of settings that cannot be configured on project level, and Jim pointed to some of them. Also, I believe that it is design issue that preferences are used to store Eclipse state, and not actually user settings. Examples: WTP Validation stores the list of scanned projects. Mylyn stores editors related to tasks. Finer grained preferences hierarchy is in (slow) progress (bug 208564). This feature may wait for better time but I strongly disagree with closing it as WONTFIX. There is a lot of work in many plug-ins that needs to be done to solve this issue correctly and completely but we have to try at least.
I am re-closing this as wontfix. There are no plans or resources in the Ant team to fix this bug.
