Community
Participate
Working Groups
Created attachment 186541 [details] source code and screenshots Hi All, At the last EclipseCon 2010 we (Ericsson) and some Eclipse.org committers had discussion around code that we would like to contribute to Eclipse.org as the committers had interest in the source code. We have received approval from Ericsson Corporate and the Patent agencies that we can contribute the code to open source. As for the details on the code, we have developed a plug-in which allows users to share and set preferences via a shared file and/or URL via the Eclipse Preferences (see screen_shot_1.jpg). You can set your preferences to be of type init or force. The type init set the preferences but allows you to change them. As for the type force, they cannot be changed. If you do change them, we have a GUI under the preferences that shows you how you differ from the group (see screen_shot_2.jpg). You can also use the Eclipse export to export parts of the preference setting as well (see screen_shot_3.jpg). We have attached the plug-in, feature, and screen shots in the preferences.zip. Feel free to arrange a meeting with all CCd parties and more if need at your convenience. BR, Emilio & Domenic
Please note that this plug-in has been tested on Windows, Linux 32 and 64 bit GTK, and Sun OS.
Created attachment 189318 [details] Updated source code for html files Please disregard the previous source code. We have updated the help section in the plug-in in this new version.
Answering questions for CQ 1. He/She authored 100% of the content they are contributing Yes 2. He/She has the rights to donate the content to Eclipse Yes 3. He/She contributes the content under the project license (in this case, the EPL). Yes
Hi, Pascal Rapicault started the CQ process at EclipseCon. This is a first for me. What is the next thing we should see in this process? Thanks, Dom
(In reply to comment #4) > Hi, > > Pascal Rapicault started the CQ process at EclipseCon. This is a first for me. > What is the next thing we should see in this process? > > Thanks, > Dom What is the CQ number? The next steps after the CQ is approved is to: 1) Get an existing committer to review the contribution. I hope we can have someone do a quick check on the overall direction soon (in the coming week or so) 2) Determine a release where we would want to include this enhancement (it is too late for 3.7) 3) Determine if Equinox the correct place for this mechanism, seems this is a layer on top with UI involved and could easily be pushed up to the eclipse project (Platform->UI?)
Hi Thomas, Thanks for the quick reply :) Pascal, Do you have the CQ number? Thanks, Dom
It also looks like a google summer of code is proposing yet another preferences model for eclipse that addresses some of the import/export issues: http://code.google.com/a/eclipselabs.org/p/e4preferences/ It would be good to collaborate on one approach, we already have a convoluted preferences story in eclipse.
See message http://dev.eclipse.org/mhonarc/lists/e4-dev/msg05071.html on the e4 mailing list where they want to contribute the google summer of code project to eclipse.
Hi Thomas, I totally agree with collaborating. I think if we can marry the different solutions we can get a more complete solution the first time around. BR, Dom
IPZilla dev.eclipse.org/ipzilla/show_bug.cgi?id=5053
It would be helpful if you were able to list out the specific problems that you are trying to solve. I've taken a look at the contribution and have a couple of questions/comments. - I was unable to run the current code as-is because of multiple NPEs. After some hacking I was able to get it to work. - the general feel of the code is that, if contributed, it belongs not in Equinox but more likely in a component higher up like Platform UI. - Export: the overhead of adding a new preference import/export mechanism seems high. I believe the current mechanism can be modified/expanded to handle some of the use cases which you are trying to address. - Compare: the Compare view doesn't seem like a generally applicable mechanism, it is more like a debugging tool that developers would use in specific cases where they have problems. (or a customized Compare view for these files) The 99% case is that the typical user doesn't care where preference values are stored, how they compare to values in other locations, etc. They just want the values stored and retrieved correctly. - Configure: if my interpretation of the "force" and "init" are correct, then I believe this behaviour can either be done with the current preference import/export and customization mechanisms or with some tweaking. Like I mentioned, perhaps explaining more about your use cases would better help my understanding of what you're trying to accomplish and how it can fit in with what Eclipse already offers. Thanks.
Hi DJ, What is an NPE? To address your comments and questions: - Does this belong to Equinox or Platform UI? When I originally spoke to some Eclipse.org members they felt this would be the best place to put it in the event that we missed the 3.7 deadline and get it into a 3.7 incubation. I really have no preference, I just followed their recommendation. - For the export we added the functionality to only export certain preferences as per the user's choice. I agree, this can be extended as part of the existing UI instead of an additional one -The compare feature. Reason for this is that sometimes some people muck around with preferences and break their environment. The diff was an easy way to compare between the user and the team pref. It was easier than a text diff because you don't need to have line alignment to have an easy diff view -Force vs Init If a pref file is set to force than even if you change your preferences, the next time you restart your IDE they will be forced back to the tam pref. Whereas the Init type sets it on Workspace creation, but can be changed by the user has he/she pleases. Overall, I have to say that highest priority use case here is that instead of forcing export and import of preferences, a user can point to a manage network or http file. Within Ericsson we host the epfs on a server and the team leads usually ask us to update them every now and then to re-align preferences based on new releases. In summary, the plugin today is written as a plugin, but I do agree that we should have this embedded directly into the existing plug-ins and just enhance them. Comments on my feedback is welcome and how to proceed as well. My first time on this and pretty open to your WoW. BR, Dom
Nevermind with the NPE (Null Pointer exception)... :)
Dropping milestone. This is not a reflection of the contribution. Just reflecting reality that this is not going into any 3.7 deliverable.
The problem which this contribution is trying to address is in my opinion no1 of all requests in Eclipse-based IDEs. Enterprises workaround current preferences limitations by using headless preferences imports or ant workspace setup. The functionality delivered in the patch is in huge demand. The contribution addresses this issue in probably the best way given current constraints of the preferences mechanism. On the other hand, the second most common request is an Eclipse ability to create a set of preferences that can be distributed across the company. Manually creating a file with preferences to share is as difficult as distributing them. Exporting all preferences does not mean that all significant preferences are exported(only the initialized ones), and even if they are, they can overwrite preferences that should not be overwritten (like local paths). Manual modifications of epf files also may fail due to implicit dependencies between them. This is the first and the biggest issue that we tried to address in contribution bug 341891. It is important to say that the newly proposed preferences model came under fire for introducing totally new API. Given that the preferences contribution (not this one) will be reworked during GSoC, and it should not be considered as an alternative to Ericsson's contribution.
Hi Christopher, Thanks for your comments. I would just like to add, that the code prodived is not intended as a replacement. Really in the end, I think that Eclipse Preferences need some added functionality that not only our plug-in provides but other contributions in this area have also provided. Right now it has been written as a separate plug-in, but as mentioend earlier, I think we agree that this should be in the platform. As for manually creating EPF files. Typically what I have done is sanitized them manually after and export because I have had some experience in the area. Having said this, I would really like the opportunity to discuss with other contributors in this area so that we can define use cases and perhaps marry a few solutions to make this right the first time. Eclipse Committers, woudl it be possible to arrange a meeting with Eclipse members, Ericsson, and other contributors in this area to further discuss this? I can say that from our corporate needs, my user community has been more than pleased and I have also seen some interest from people at EclipseCon in our plug-in as well. BR, Dom
Emiliom, Domenic, after some screw up on my part with the CQ, I finally heard back from the legal team and they mention that the files don't have any license headers. Could you please fix those and reattach a new version of the code. The eclipse releng tool (available from the I or M build repos for the SDK has some code to help with this). Here is the message from the legal team: =========== The content attached does not contain any copyright or license notice. Please have the contributors amend accordingly and reattach. Please see http://www.eclipse.org/legal/copyrightandlicensenotice.php for templates. Triage cannot begin until this is place. ===========
Hi, Sory about that. Emilio is working on it and will get back to you asap with the new build. BR, Dom
Created attachment 195153 [details] Updated code with copyright information. Reattaching a new version of the code. Files have been updated with appropriate copyright information and namespace has been changed to org.eclipse.common_prefs. The version has also been changed to beta version 0.1.0.
I have attached the new code to the IPzilla
Congrats! The contribution has been approved for use at Eclipse. The review came back with the following comments that will have to be addressed before we can check in. But more importantly, we will have how this can be best integrated with the rest of eclipse. Subject to the following changes being made prior to checkin, this submission is approved: 1. TabFolderLayout.java includes a comment, "* Copied class from package org.eclipse.compare.internal". The file is a copy of the IBM file. The original IBM header should be reverted with any changes made by the contributor noted in Contributor Section of the header... 2. feature.xml - contains: <copyright url="http://www.example.com/copyright"> and <copyright url="http://www.example.com/license">
Created attachment 196866 [details] Updated with comments from Eclipse review Attached version 0.1.1 of the code. Changes made based on comments received from the review at Eclipse.
> Attached version 0.1.1 of the code. Reporting 2 small issues of the attached version 0.1.1: --- 1) org.eclipse.common_prefs.core.CommonPrefResource.init(boolean) line#116 changed exists = (lastModified > 0); into exists = false; Rationale: I use an svn server as http source. But at least old versions of SVN lack on the last-modified header. In this case the plugin refuses to accept the url as source. --- 2) org.eclipse.common_prefs.core.CommonPrefsHelper.addNetworkNode(String[], Preferences) line#1081 and #1090 nodePref.put(NetworkPrefResources.HOST, networkResource.getHost()); Causes an NPE if getHost() returns null. The common-prefs exporter stops working because of that. My current workaround is skipping such an entry.
> into > exists = false; Shame on me, it should be: exists = true;
Has this been included in 4.2?
For anyone wanting to use this, I've made a bugfixed version or the 0.1.1 version here: https://github.com/fredrikattebrant/common_preferences.git Fixed what's discussed in comment #23 part 2.
Since workspace mechanic seems more than dead (download url 404) and developer seems no longer responsive I feal like lost in dark again. Can we commit this, please? I need the enforcement feature and like to migrate our developers to this.
Oomph is taking care of resolving this problem and much more: https://projects.eclipse.org/projects/tools.oomph You should definitely take a look at that. This is what Ericsson is now using internally. Otherwise, you can always you the attached code internally.
