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 <[email protected]> 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 >
