lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (LUCENENET-565) Port Lucene.Net.Replicator
Date Wed, 09 Aug 2017 19:05:02 GMT


ASF GitHub Bot commented on LUCENENET-565:

Github user NightOwl888 commented on the issue:
    > Holy crap... I am glad I am not under that umbrella, in an age of continuous delivery
and continuous deployment that sounds like poison... o.O...
    It's both a blessing and a curse. For example, we would never be able to pull this off
without the resources of the CI account (TeamCity) that we have setup. It takes at least an
hour to run the tests on each platform, so we need something we can run them in parallel on
for at least that long. I tried this with MyGet and it turns out there is a limit to 15 minutes
per build. So, having a full CI server with huge amounts of storage and RAM is a good thing.
I also got some help from the team setting it up.
    Also, Apache requires that all code must be testable before being released (implying there
must be tests), and ensure that the licensing is all legal, all code files have license headers,
    But not being able to setup your own repo (because they are hosted by Apache) and having
to deal with JIRA instead of just using GitHub's issue tracker causes some friction.
    Could there be Lucene.Net without Apache? I don't know. There must be some reason why
no developer before me went off on their own and decided to pull it out from under Apache
(and I don't think there is anything in the licensing preventing it). 
    But we do what we can. Recently, there have been more contributions than since I started
working on this a year ago. I am not sure if that is because we are now so close to the finish
line, or my efforts of updating documentation, getting a release on NuGet, etc are starting
to pay off.
    But I think that to help combat this we really need to update the documentation, website,
simplify deployment, etc. and generally make Lucene.Net a good place to work. Key among these
things is to lower the bar for how difficult it is to add search to an application, and that
is what I am hoping to achieve with these integration packages (which in turn should increase
both downloads and contributions). But of course, if you would rather use the low-level APIs
directly they are not going anywhere.
    > So what your talking about is having a registry of indexes (with writers and readers)...
That registry could be registered as a singleton... (Sounds much like my LuceneIndexContext
on a different project >.<)
    Yes, it is probably similar. Although it will probably end up being an `IIndexAccessor`
or something along those lines.
    It sounds like you are not too familiar with dependency injection (which is why I am following
this approach), and although you can certainly get by without it, it is definitely something
every developer should know going forward. I was reluctant to read up on DI at first and wasn't
sure that doing so would be worth the time, but ever since I read [Dependency Injection in
.NET](, it has forever changed
the way I write code. And out of dozens of books that I have read there are very few I can
say have accomplished that. But as they say, you can lead a horse to water, but you can't
make them drink - do as you will :).
    > Anyways, this is derailing things a bit, it was just some input for you going forward.
So we should probably get back to focusing on the actual Lucene.Net.Replicator, and comments
in there >.<...
    > Ill see if I can find a suitable place for that little demo app.
    Thanks again. Replicate away! And if you can, find a way to replicate contributors :).

> Port Lucene.Net.Replicator
> --------------------------
>                 Key: LUCENENET-565
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Task
>          Components: Lucene.Net.Replicator
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Shad Storhaug
>            Priority: Minor
>              Labels: features

This message was sent by Atlassian JIRA

View raw message