lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Miller <>
Subject Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
Date Wed, 21 Sep 2011 12:15:10 GMT
The granular approach can cause dependency issues as well. FubuMVC is
running into this with their granularity had to invent their own build chain
for "ripples" of changes.

I would say do two packages Lucene and Contrib and when one of the pieces of
Contrib gets awesome enough to warrant it's own package.

I look forward to official Lucene.Net packages.

On Tue, Sep 20, 2011 at 10:56 PM, Michael Herndon <> wrote:

> We're taking a quick poll over the next few days to see how people would
> like use Lucene.Net through Nuget on the developers mailing list**
> Currently version 2.9.2 is hosted on, but that package was not
> create by the project maintainers, thus nuget is not currently set up in
> source.  Going forward, we would like to continue what someone else started
> by creating nuget packages for Lucene.Net.
> Right now there are two packages: Lucene & Lucene.Contrib.  My question to
> the community is do you wish to finer grain packages, i.e. a package for
> each contrib project or continue to keep it simple.
> The granular approach will let you use only what you need. We can also
> create additional higher level packages which have dependencies on the
> other
> ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full.
> Or we can keep it simple and continue with only two packages.
> My concerns are that the granular approach might overwhelm people with
> choice. The simple choice might be considered bloat for importing and then
> installing assemblies that you might never use.
> Another topic to converse about is would you like to see an out-of-band
> project nuget feed for  nightly builds, branches with new or experimental
> features, or stable code snapshots for a projected release?
> ** when you post, please respond to
>  This
> was posted to both lists to make sure everyone subscribed to both lists has
> a chance to voice their use cases or concerns.

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