lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <>
Subject Re: Offer of help vis Lucere project
Date Mon, 01 Oct 2012 20:35:22 GMT
My thoughts exactly - either a search server on top of Lucene.NET
(I'd recommend looking at ElasticSearch as a role-model, not SOLR) ,  a
Java porting aid (a handy R# plugin would worth tons more in terms of
productivity than a tool that just translates code, as a dev should do a
pass on the code anyway) , Luke.NET (WPF or Web-ish), or thinking of an
idea to a new missing contrib (Azure directory?)

On Mon, Oct 1, 2012 at 10:03 PM, Troy Howard <> wrote:

> All,
> You may recall a project I started called Lucere before getting directly
> involved with Lucene.Net. At that time I was planning to fork Lucene.Net,
> but since getting involved here that project has died off. I still get
> occasional inquiries about the project via Codeproject, and I generally
> point them to the Lucene.Net mailing lists.
> I just got an interesting email via that project, with an significant offer
> for development help. See below:
> Dear Lucere team,
> I am writing on behalf 12 students of AGH University of Science and
> Technology in Cracow, Poland. In starting fall semester we have project in
> our objective technologies course. This course is concentrated mainly on
> analysis and design of models (UMLs, objective principles and so on), but
> also on producing very high quality of code and using most common approach
> to development nowadays (design patterns, ORMs, unit testing, IoC and so
> on). We are looking for open source project to contribute. We think that we
> could desing and develop one or two specific parts of open project like
> this as a part of our university project. Our team is full of very
> ambitious and very skilled people. Twelve people should be enough to build
> something great. Moreover we have support of our PhDs leading this course.
> They will validate all our ideas and will help us to design everything in
> best way.
> As I said before we want to create rather entire module than fixing some
> bugs. Due to our course objectives we are interested only in highly
> objective modules. It would be great if you allow us free rein in designing
> such module. Maybe you have in your roadmap some features we can build in
> that way.
> Your project seems very interesting for us and we would be delighted to
> contribute. We are waiting eagerly for your response.
> Best regards,
> Bartlomiej Szczepanik
> Faculty of Computer Science, Electronics and Telecommunication
> AGH Univerity of Science and Technology, Cracow, Poland
> ---
> If this is interesting to us, I will coordinate with Bartlomeij and see if
> we can bring these developers into Lucene.Net. If we do suddenly have 12
> new developers that want to work on the project... What should they do, and
> how will we coordinate their work?
> His stated goals are to create not to bug fix... and porting doesn't really
> fall under the fold of "create and design".
> We have always tossed around the idea of creating a layer on top of the
> existing API that would be more .NET idiomatic, or incorporating some new
> .NET specific features into the library *in addition* to the baseline
> functionality that we port directly. Perhaps this could be the group to do
> that work?
> We've also talked about trying to get some improvement with an automated
> porting process, and how that would require significant coding work to
> bring a project like Sharpen up to our needs. Perhaps they could focus on
> that?
> Maybe they could work on the distributed/federated search application that
> was brought up a while back? a SOLR-like project, that is unique to
> Lucene.Net (as opposed to porting SOLR or just bringing back the .NET
> remoteing model that was removed)?
> Perhaps they could design a new tool like Luke, that is more maintainable
> (have you seen that code? eek)...
> There are a lot of options here. Thoughts?
> Thanks,
> Troy

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message