| Madhuranga, Stefan,
I discussed the with Andreas and Johannes how we could implement the first version of a shared repository. We came to the conclusion that, for the beginning, we don't want to build a complex system upfront. Instead we'd like to store our snippets in a separate GIT repository which will be checked out into a local workspace project called ".snipmatch".
The repo layout will be rather primitive. It will only contain a /snippets folder that contains all our snippets. The /index/ folder will be created in the same project but under an ignored folder "index/". Any temporary files (like your csnip files) can be stored in some other folder.
Developers who want to share new snippets, may add new ones or edit existing ones via the snippets view and the snipmatch editor. To upload a new or edited snippet we'll tell developers how to use EGIT to push their change to Gerrit review system at Eclipse.org. If someone submits a new snippet, we'll review and edit it (if needed) via Gerrit web frontend until we think it's good to go.
What do you think about this (rather simple) approach (for now)?
Best, Marcel
Hi Marcel, There are some problems here. Some of this snippets use swt elements. In order to support this, swt should be on the build-path of the project, and at the moment only the standard java build path is added to the project. I could simply add it in the path when the project is created, but I was thinking to implement some sort of build path set-up mechanism in the snipmatch preference page where the user will set the jars available on the buildpath for the External Snippets project. Something similar to the dependencies section from MANIFEST.MF. There are some other issues as well of which I will try to take care this week. I managed to separate the project in the o.e.r.snipmatch.rcp and o.e.r.templates.rcp modules. The contents are the following: - o.e.r.snipmatch.rcp contains the snipmatch plug-in elements (preference page, multi page editor, etc).
- o.e.r.templates.rcp contains the Xtext grammar core elements(compiler, type computer, formatter, the grammar itself etc). This also contains an out-of-the-box editor for .cSnip files.
This can be found here[1]. A Readme will be available soon 😊 The update site [2] contains only the o.e.r.snipmatch.rcp plugin installable unit, which means that only the multi-page editor and its requirements from the templates.rcp will be installed. Best Regards,
Stefan. From: Marcel Bruch
Sent: ‎Sunday‎, ‎September‎ ‎8‎, ‎2013 ‎2‎:‎06‎ ‎AM
To: Recommenders developer discussions Hi Stefan,
Note that the snippet format changed a bit: You may consider using /snipmatch-org.eclipse.recommenders.snipmatch.rcp/src/org/eclipse/recommenders/snipmatch/Snippet.java for deserializing the snippets instead of using the old Effect class.
Best, Marcel Hi, This is the weekly report for the snipeditor: What was planned: -> implement type computation for the other template variables and continue implementing the remaining syntax -> add functionality to the metadata page of the snipeditor (allow user to edit the fields) -> test the syntax with java templates to ensure it works. What was accomplished: ->all of the syntax is supported; The expressions can be found here [1]. -> most of these expressions should be resolved to the correct type. There still are some that do not work properly in certain situations, e.g. ${cursor} is only treated as an object, so the following will produce an "Unable to cast Object to boolean" error : if(${cursor}){}. I tried to set the type to void but in this case the error would change to "Unable to cast Void to boolean". -> I’ve added a small (nasty looking) pop-up that allows the search phrases to be edited and the types used in the snippet are available. Note that at the moment it displays all types that were computed (including the code snippet itself) and sometimes does not work. The interface can be seen here [2]. What the plan for the next week is: -> try to compute types for elements like ${cursor} based on the context. e.g.: for the _expression_ if(${cursor}){}, ${cursor} should be treated as a Boolean. -> try to add content assist to jFace variables like ${array}. -> make the type section of the metadata page work properly and set up a nicer dialog to edit the fields in search patterns. Best Regards,
Stefan. [2]: <Image931.png> _______________________________________________ recommenders-dev mailing list recommenders-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/recommenders-dev
_______________________________________________ recommenders-dev mailing list recommenders-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/recommenders-dev
|
