lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Moving SweetSpotSimilarity out of contrib
Date Tue, 02 Sep 2008 18:16:00 GMT

: >From a legal standpoint, whenever we need to use open-source code, somebody
: has to inspect the code and 'approve' it. This inspection makes sure there's
: no use of 3rd party libraries, to which we'd need to get open-source
: clearance as well.
: 
: This process was done for Lucene core, but not for contrib, in my company.
: AFAIU, this process should be done by a company if it wants to (usually
: mandatory when you integrate open-source code in your products). Therefore I
: don't think the Lucene community should be concerned with this.

You should talk to whomever you need to talk to at your company about 
revising the appraoch you are taking -- the core vs contrib distinction in 
Lucene-Java is one of our own making that is completly artificial.  With 
Lucene 2.4 we could decide to split what is currently known as the "core" 
into 27 different directories, none of which are called core, and all of 
which have an interdependency on eachother.  We're not likely to, but we 
could -- and then where woud your company be?

What you should be concerned with is what gets released: a Lucene-Java 
release contains all of the Lucene-Java core code as well as the contrib 
code ... it should be considered one cohesive unit release by the Apache 
Lucene project.  Things like Solr, Nutch, Mahout on the other hand -- they 
are released seperately by the Apache Lucene project.

: The only thing that the community can do is to move as much as possible to
: the core, so that if a company inspects the code, it will cover as much as

Doing this would actually be a complete reversal of the goals discussed in 
the near past:  increasing our use of the contrib structure for new 
features that aren't inherently tied to the "guts" of Lucene.  The goal 
being to keep the "core" jar as small as possible for people who want to 
develop apps with a small foot print.

At one point there was even talk of refactoring additional code out of the 
core and into a contrib (this was already done with some analyzers when 
Lucene became a TLP)


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message