Github user jeme commented on the issue:
https://github.com/apache/lucenenet/pull/209
Ok so I think I will give up on commenting on all of the above because
there is to much. I will as a general note say be careful that you don't get
ahead of your self.
I personally think it would be a bad idea to put to much of all that
AspNetCore, Owin etc. into this particular project (project as Lucene in a
whole, not each csproj file)...
Instead I would separate them out and give them meaningful project names...
and give them their own release cycle... (Actually I think the
Lucene.Net.Replicator.AspNetCore project would belong in one of those "child
projects", but that is a bit complicated as it's currently needed for tests, it
might be possible to write the tests differently without it or add a
minimalistic implementation into test instead)
They could still be under "Lucene.Net" organisation wise, but I think there
would be many advantages in allowing them to have their own repo and life...
This would focus this repository on the port of lucene (as direct as
possible, but also to support these projects) and each project could have it's
individual focus... (Lucene on AspNetCore for all AspNetCore integration on
different levels, Lucene on Nancy for that etc.)...
Also, your already on the edge of making some decisions that would be bad
for larger scale projects... E.g. making a Singleton LuceneWriter (registered
in a IoC Container or not) wouldn't that limit you to only having a single
index?... that would seem like an odd direction to consider within this context
as the Replicator directly supports shards... (aka multiple indexes?)
It also seems that as things are right now you can't release each
individual csproject on it's own from here?... (E.g. releasing just the
Lucene.Net package and not the rest?)... If that is the case then I think that
speaks even more for putting these more "platform" specific integrations into
their own project/repo/release cycle so they are not bound by each other... So
that these packages could be release on a much more rapid cycle than Lucene.Net
it self.
There is ofc. many considerations around such "branching out", but from
having done so quite a few time my self on our own projects, I can say that it
is so much more convenient in the long run...
As a final note, I won't be able to find time to take the
Lucene.Net.Replicator.AspNetCore project much further, my goal was to focus on
Lucene.Net.Replicator it self and provide a meaningful port of that that could
be integrated into AspNetCore (which we haven't even adopted yet), AspNet4x,
Nancy or similar frameworks with relative ease...
Which path you take with Lucene.Net.Replicator.AspNetCore is up to you...
But I don't feel right about building anything two involved for a
framework/platform I don't even use and therefore don't know all the ins and
outs of...
To me it was an example integration that could help me find points in the
Lucene.Net.Replicator which might cause difficulty when integrating or straight
out felt wrong and there are a few things about the ReplicatorService that
annoys me in that regard, but there is a broader picture as the HttpReplicator
aligns to that same theme and then there is your desire to stay compatible with
Java versions, which is questionably because they choose to actually serialize
Exception objects, if java clients expect any meaning of that then we are not
compatible at all as all Exceptions would end up as "Unknown Exceptions" in a
Java client... and that goes for the other way around as well...
I do have a small super simplistic and extremely crude DEMO AspNetCore app
that indexes and publishes data and then a Console client that pulls the
replicas which works. I am trying to use this to weed out annoyances.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
