Community
Participate
Working Groups
The Sudoku application is craving ECF support ;)
Created attachment 43427 [details] ECF Sudoku Patch The patch is ugly and somewhat broken (threading issues with drawing on display, and very simplistic support for sharing sudoku editors). Issues I noticed with your Sudoku API: 1) SudokuBoardStateListener method: public void cellChanged(Cell cell) {} doesn't work :) 2) Allow easier public access to create new Soduku boards (ie., createNewBoard) from stuff like a string or another board 3) Try to make model objects like Cell easily serializeable (keep things POJO) As to use this sample code, I'd first start an ECF server using the org.eclipse.ecf.server-feature (either do it command line or via the PDE launcher). Next, I would launch a new Eclipse instance using WorkspaceA, then another Eclipse instance using WorkspaceB. Click the little ECF icon in the sudoku view for the first workspace instance, then click it for the second workspace instance. Hopefully the boards should sync, and then you should be able to perform an action on one board and have it propogate to the other. Note, this is a very simplistic example and if it were to use ECF, it should follow the shared editor example of how to work with ECF datashare APIs. I'm out for vacation soon so anyone who wants to continue the spirit of Sudoku On A Plane, is more than welcome to. Given 90 minutes on a plane and your battery life dying, what can you hack out ;)?
btw, do you need an evangelism bugzie component ;)?
I've integrated your patch and will start looking at the issues you've raised. I decided refactor your ECF code into a separate plug-in to keep the ECF stuff optional. I added proper support to include ActionSets and refactored your action accordingly. The new project name is org.eclipse.sudoku.ecf.
Wayne, any plans to set a Bundle-RequiredExecutionEnvironment in these plug-ins' MANIFEST.MF files (since at the moment they need J2SE-1.5). How about bringing them down to a Foundation profile so that they can be run on embedded devices?
Yup. It's on my list. Relatively low priority right now, I afraid.
Created attachment 57203 [details] Patch to fix compiler errors and enforce an execution environment and Java 1.5 compliant JRE and compiler. All the unit tests pass except for project org.eclipse.sudoku.core.tests.factory's SudokuGameTests. Which, appears to me personally, to be a malformed assertion. I'm not seeing how a randomly hard coded sudoku board can equal one that's being randomly generated. In actuality, the test never occurs because it never gets to that assertion line because of SudokuGame's createNewBoard() method, which throws an SudokuBoardFactoryUnavailableException no matter what happens.
It would be great to have the sudoku example useable on many different platforms. The eRCP port is one example. One could also imagine someone doing a RAP port and /or sticking an AJAX front end or... to that end, making the code require only Foundation 1.0 (or 1.1 if you really must) would be great. BTW, where is the sudoku code in CVS?
(In reply to comment #7) > BTW, where is the sudoku code in CVS? Hi Jeff, the code is in /cvsroot/org.eclipse's www/evangelism/samples/sudoku/code module.
Jeff, I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=145258 for your interest.
(In reply to comment #6) > All the unit tests pass except for project > org.eclipse.sudoku.core.tests.factory's SudokuGameTests. Which, appears to me > personally, to be a malformed assertion. That's harsh. I kept the test in as a test to see if anybody was actually running them. Yes... that's it. More seriously, the test is poorly formed. It depends on a particular launch configuration which I never formalized. I'll see what I can do about that.
How do we feel about just moving the Sudoku implementation to a new Source Forge project? I'm not sure that the samples require the same rigor as an Eclipse Project. Putting it on Source Forge would allow us to more easily manage participation and accept contributions from others without having to add to the IP process backlog. Thoughts?
Gads! it seems something is badly broken if the Eclipse community cannot manage to have a set of examples hosted on eclipse.org. We should be showcasing what people can build with Eclipse technology and how. While I agree that not everything people want to use is compatible with EPL etc, our legal rigor does provide value. So supplying examples that people cannot safely reuse (because of legal concerns) is not a great service to the community.
(In reply to comment #11) -1, sudoku needs to stay at eclipse.org. This is the closest thing we have to a "game" at the moment and is a cool gimmick, per se. Thinking long term, when bug #184481 gets pulled through, it is only natural that we will want something of that scale to be featured on eclipse.org itself.
I agree, it should stay at eclipse.org. Also, it should be one of our premier examples to show that you can write something that will run on a device (eRCP), desktop and web (RAP). Do we need to create a component just for examples?
feels like an incubator of sorts...
Okay, you don't like the SF idea. Fine. I was just putting it out there. If it's forever a incubator the "safely reuse" argument may not apply. A "samples" project feels to me like something that can actually graduate. So where does this project align itself? A component of what project? I don't think we need more stuff in the Eclipse project. Also, in the broader picture, there will be other examples that will span projects. This one spans at least three. I was, at one point, thinking of a "Samples" Technology subproject. Do we want to explore something along these lines? Frankly, I'd love to put this project somewhere else so that collaboration is more possible.
Samples Technology project sounds fine. the main focus would be bringing together the wide range of technology available in Eclipse projects. I assume that each project itself would continue to create and maintain examples/samples are part of their project. This hypothetical project would do cross-project/cross-domain stuff. RCP, Sudoku-everywhere, using BIRT, DTP, WTP, ... together to solve X, etc. As for incubation, we would do well to declare the project as an incubator so that it can use the parallel IP process. The samples can graduate virtually by the committers declaring it "good" (code, IP, ...). Since the samples are not something that we would generally "ship" nor would, generally, someone directly/simply uses, it seems ok to me that the samples never formally graduate.
So what's the next step? Do we want to send a note to EMO announcing our intent to propose this project? Who all wants to be included in the proposal?
(In reply to comment #18) > So what's the next step? Do we want to send a note to EMO announcing our intent > to propose this project? This sounds good to me. > Who all wants to be included in the proposal? Count me in.
(In reply to comment #18) > So what's the next step? Do we want to send a note to EMO announcing our intent > to propose this project? Who all wants to be included in the proposal? > Count me in as well.
Three is a good start. Anybody else want in? What should we call this? Technically, a project's name isn't supposed to include the word "Eclipse", but... Relatively boring ideas: "Examples Built using Eclipse Technology" (EBUET) "Eclipse Sample Applications" (ESA) "Solstice" Weirder ideas: "Syzygy" - I just found this word on Google. - The alignment of three celestial objects within a solar system) "Harmonic Convergence" -The idea being that the project is an alignment of several different Eclipse projects Some set of words resulting in the acronym "FUDGE" (no particular reason)
(In reply to comment #21) Syzygy is certainly weird but makes sense. Harmoinc Convergence also makes sense. I think Solstice could work since it's when the Earth's axis is tilted most towards or away from the sun. My reasoning is that these examples are some of the most "far out" or "closest" things to an actual product that you can go without it being a truly shippable thing per Jeff's comment #17 about how these examples will probably never graduate.
Created attachment 71398 [details] Patch to org.eclipse.sudoku.ecf for 1.0.0 version of ECF Patch to fix obsolete code in org.eclipse.sudoku.ecf and allow it to run on ECF 1.0.0.
Created attachment 71417 [details] Patch to org.eclipse.sudoku.ecf for 1.0.0 version of ECF Update to communicate via server at ecftcp://ecf.eclipse.org:3282/server by default.
Created attachment 71565 [details] ECF 1.0.0 additions to support Sudoku-over-XMPP This attachment is a zip rather than patch because some icon/binary were added to the project. It is a zip of the entire project contents for the org.eclipse.sudoku.ecf project.
I've attached #71565 to this bug. This is a zip with the entire org.eclipse.sudoku.ecf contents, as binary content was added (icon) and so patch would not include. I don't have commit rights to project so please someone who does please make these changes and commit. Summary of changes 1) Removed toolbar button from UI for making connection 2) Added menuContribution for MultiRosterView (roster context menu) so that for containertypes that support the datashare adapter (i.e. XMPP/XMPPS, GT, Skype) a menu item will appear on the roster context menu: "Add Sudoku Listener". If this is selected then on the roster entry context menus a menu item will appear: "Start Sudoku Sharing". These are implemented via the menuContribution extensions and classes SudokuShareRosterContributionItem, and SudokuShareRosterEntryContributionItem. 3) Implemented 'SudokuShare' class which is responsible for the protocol for sharing the Sudoku state changes. Please add a public method on org.eclipse.sudoku.ui.SudokuView for changing the title of the view...so that the code in org.eclipse.sudoku.ecf can change the title to indicate that the puzzle is a remote user's (i.e. it's being shared).
I've applied the changes and committed them to CVS. I've been trying to run it against an RCP target and am finding that I have to add more and more bundles to my RCP target to make it work. The inclusion of org.eclipse.ecf.presence.ui requires that I pull in org.eclipse.ui.editors (it actually requires a package that I am pretty sure is only provided by this bundle) which in turn requires the inclusion of the resources bundle, file system APIs, and IDE UI. After some reflection, it's obvious that this provider is not intended for the RCP version of the game, but rather is intended for Sudoku as part of the development environment. Any thoughts about how we can ECF-enable the RCP version?
(In reply to comment #27) > I've applied the changes and committed them to CVS. > > I've been trying to run it against an RCP target and am finding that I have to > add more and more bundles to my RCP target to make it work. The inclusion of > org.eclipse.ecf.presence.ui requires that I pull in org.eclipse.ui.editors (it > actually requires a package that I am pretty sure is only provided by this > bundle) which in turn requires the inclusion of the resources bundle, file > system APIs, and IDE UI. The package is org.eclipse.ui.editors.text. We're using it for these two classes: import org.eclipse.ui.editors.text.EditorsUI; import org.eclipse.ui.editors.text.TextSourceViewerConfiguration; These let us use the platform hyperlink detection for text editors...which is a very nice feature and requested by community. It's indeed unfortunate that it pulls in so much. > > After some reflection, it's obvious that this provider is not intended for the > RCP version of the game, but rather is intended for Sudoku as part of the > development environment. > > Any thoughts about how we can ECF-enable the RCP version? We could easily create a version of org.eclipse.ecf.presence.ui that does not use/have hyperlink detection (or optionally does) and so would not pull in the editors.text package/bundle/dependencies. Then, I think o.e.e.p.ui would be completely appropriate for a small RCP app. The other bundles for ECF do not have nearly so many dependencies. I've created bug 194455 for ECF to track this.
(In reply to comment #27) > I've applied the changes and committed them to CVS. > > I've been trying to run it against an RCP target and am finding that I have to > add more and more bundles to my RCP target to make it work. The inclusion of > org.eclipse.ecf.presence.ui requires that I pull in org.eclipse.ui.editors (it > actually requires a package that I am pretty sure is only provided by this > bundle) which in turn requires the inclusion of the resources bundle, file > system APIs, and IDE UI. > > After some reflection, it's obvious that this provider is not intended for the > RCP version of the game, but rather is intended for Sudoku as part of the > development environment. > > Any thoughts about how we can ECF-enable the RCP version? > As per comment #28, I've made the ECF dependencies on org.eclipse.ui.editors.text *optional* in both org.eclipse.ecf.presence.ui and org.eclipse.ecf.ui. At classload time, if the package is available (Eclipse) the ECF views will have hyperlink detection...if the package is not available at runtime (RCP app) then a non-hyperlink enabled StyledText widget will be created and used. This will be in Europa/1.0.0 release of ECF, and is currently checked into org.eclipse.ecf.presence.ui and org.eclipse.ecf.ui.
Any other thoughts on the name front? I'm going to announce to emo next week our intent to propose an Eclipse Examples Project (EEP!) (with a proviso that better name may be forthcoming). I think it's best to keep the name non-weird so that its purpose for existing is as clear as possible (without having to spend a lot of effort developing mindshare). Also, can I get some +1 from whomever wants to be an initial committer on this project? Since this bug is totally the wrong place to have this discussion, I'd like to get this over with and close this bug. Thoughts, comments, concerns?
(In reply to comment #30) > Any other thoughts on the name front? No immediate help with names...sorry...I haven't had enough beer (today) to be useful here. > > I'm going to announce to emo next week our intent to propose an Eclipse > Examples Project (EEP!) (with a proviso that better name may be forthcoming). > > I think it's best to keep the name non-weird so that its purpose for existing > is as clear as possible (without having to spend a lot of effort developing > mindshare). > > Also, can I get some +1 from whomever wants to be an initial committer on this > project? +1 I will be an initial committer. > > Since this bug is totally the wrong place to have this discussion, I'd like to > get this over with and close this bug. +1 > > Thoughts, comments, concerns? >
(In reply to comment #30) > I think it's best to keep the name non-weird so that its purpose for existing > is as clear as possible (without having to spend a lot of effort developing > mindshare). That's understandable. There _are_ "weird" names like Buckminster, Higgins, and Maya which don't really mean anything at first glance. > Also, can I get some +1 from whomever wants to be an initial committer on this > project? Per comment #19, I'll join. I haven't yet heard anything from Mark about adding the eRCP Sudoku code to their CVS repository yet, unfortunately. Maybe we could move that code to EEP? > Since this bug is totally the wrong place to have this discussion, I'd like to > get this over with and close this bug. > > Thoughts, comments, concerns? Did the changes mentioned in comment #29 resolve the issue for you, Wayne? If yes I think we should close this.
(In reply to comment #32) > I haven't yet heard anything from Mark about adding > the eRCP Sudoku code to their CVS repository yet, unfortunately. Maybe we could > move that code to EEP? Ah, it's in now. :) http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ercp/?root=DSDP_Project The ECF bridge code isn't in ECF's CVS repository at the moment but I hope to get to it once we resolve bug 184491.
Not sure why this was assigned to webmaster. -M.
Moving to Examples
Will address this bug after Sudoku is moved from DSDP to Examples.
could someone tell me where to find this example in git repo?
(In reply to comment #37) > could someone tell me where to find this example in git repo? It's not in Git. We never did move it from DSDP. DSDP has since been terminated. I've put a copy of everything that I have from the original work on GitHub. https://github.com/waynebeaton/eclipseSudoku Note that I haven't looked at this code in at least four years.
Ok Wayne, thanks. I'm will play a bit with it in next weekend... If I could make it work with the actual Eclipse and ECF versions I will send a pull request... regards, Cristiano
