[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] Snipmatch GSOC

Hi Marcel,

Ok, i have create a temp google code project[1], and plan host my change in my local and this server. You know only local copy is not safe enough, if my hard disk crush one day, i have nothing to do except cry

After  Eclipse Legal team has approved the code, i will submit patches in Bugzilla, you guys can merge them for me.

BTW, i have transferred Doug's XML format 62 snippets to JSON format, in the attach file, you guys can use them as initial snippets file system.

[1]  http://code.google.com/p/snipmatch/ 

2012/2/21 Marcel Bruch <marcel.bruch@xxxxxxxxx>
Hi Chen,

you asked for version control access a few mails ago. The Eclipse Legal team is checking the code but I hope they will be done soon. When this happens, we'll import it into the central repository to its new location where we can work on.

But getting committer rights is not an straight forward thing at Eclipse as in a small open-source project. There is a formal committer election which finally gets approved by the Eclipse Technology PMC. In order to approve an election, the PMC needs some records that show your merits (read, you created several patches, show active email conversation etc.)

So my plan would be:
Keep your changes local until the Legal team has approved the code.
Then we commit the code into our main repository and final position.
Your can work on a local copy of this and send patches to Bugzilla (or even better Gerrit - I've to figure out). "Small" means less than 200, 250 lines of code. If this has been done several times, we can start the election.

Best,
Marcel

On 21.02.2012, at 07:11, chen cheng wrote:

Hi Marcel & Doug,

According to SnipMatch's Effect class define, snippet's JSON format should be like this:

{
   "effect":{
      "patterns":[
         {
            "string":"print $obj"
         }
      ],
      "params":[
         {
            "param":{
               "name":"obj",
               "majorType":"expr:",
               "minorType":""
            }
         }
      ],
      "envName":"javasnippet",
      "majorType":"stmt",
      "minorType":"",
      "code":"System.out.print(${obj});",
      "summary":"Print to standard output.",
      "id":""
   }
}

But there is still one point i am not very clear, in XML format:

<?xml version="1.0"?>
<effect env="javasnippet" type="stmt:">
<summary>Print to standard output.</summary>
<patterns>
<pattern>print $obj</pattern>
</patterns>
<params>
<param name="obj" type="expr:"/>
</params>
<code>System.out.print(${obj});</code>
</effect>

Param element and effect element has "type" attribute, but in Effect class and EffectParameter class, there
are attributes majorType and minorType, how does these "majorType" and "minorType" corresponds to the only 
one "type" attribute ?

Doug, you and Ye are the author of these classes, can you tell me what these two attributes mean? Thank you. 

2012/2/21 chen cheng <chengchendoc@xxxxxxxxx>
It seems that we have reached agreement in these respects:

1. Cheng be in charge of SnipMatch's client merge and improvement job
2. Doug be in charge of SnipMatch's server side job
3. Marcel supplies a Lucene and Git file system based snippets search engine both for server side and client side.

Then, we have to decide Snippet file's format:
1. Its file name does not make sense, just keep it unique
2. Use JSON or XML format, but we have almost agree with JSON. Marcel suggest we should use JSON, and i have read GsonUtil source code, and thought Recommenders have already some baisc JSON uitl tools, so use JSON can keep Recommenders' design consistency. So, i agree with JSON, what about you, Doug, can you finally confirm this point?
3.Snippets file's content details will corresponds to XML format elements in Doug's snippets attach file, if necessary, we can discuss add or remove some field.

Doug & Marcel, your advides ?


2012/2/21 Marcel Bruch <marcel.bruch@xxxxxxxxx>
Hi Doug,

On 20.02.2012, at 18:33, Doug Wightman wrote:

> GIT repositories is an awesome idea: sounds good to me!
>
> Yes, I'd be happy to be the primary mentor. I've contactes GSoC and
> will follow up.

Great!

> In terms of format, XML works for me - that's what we've used until
> now, but JSON is also fine. I'm not particular.

So, if both is fine for you I'd clearly vote for JSON for one primary reason:

All other server-side services are based on JAX-RS and JSON. IMHO, the server-side should use as few as possible different but similar technologies for storage, communication etc. as long as the existing tools make sense. In the case of XML vs. JSON there is IMHO no significant difference for our use case. Users that want to deploy recommenders' tool suite on their own servers should be able toto do so w/o the need to install a dozen different databases, and tools :)

For template storage I think GIT is the better choice (better than CouchDB) since update and synchronization is quite easy and with JGIT we have a simple library at hand to do it. In addition, there is no need complex setup required on server and client side to use these technologies. Thus, I'd vote for JAX/RS+JSON and GIT here.

Marcel
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev



--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]



--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]

Attachment: snippets json.7z
Description: Binary data