[
https://issues.apache.org/jira/browse/LUCENE-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067432#comment-13067432
]
Lance Norskog commented on LUCENE-3151:
---------------------------------------
_*Architects remove dependencies*_
For external use, this locksteps the external user (Mahout for example) to
changes in these data structures. It's a direct coupling. This is how you get
conflicting dependencies, what the Linux people call "RPM Hell".
If you can make a minimal class for export, then have Lucene use a larger
class, that might work. Here is a _semi-coupled_ design:
h5. public class ITerm
* A really minimal API that will never be changed, only added onto.
* Code that uses this API will always work- that is the contract.
** clone() is banned (via UnsupportedOperationException).
** If a class implements clone(), all subclasses must also implement it.
* I would also ban equals & hashCode- if you want these, make your own subclass
that delegates to a real Term subclass.
h5. public class Term extends ITerm
* This is what Lucene uses.
* It can be versioned.
* If you code to this, you lock your binaries to Lucene release jars.
Here is a _fully-decoupled_ design:
* Separate suite of main Lucene objects, with minimal features as above.
* Separate Lucene library that xlates/wraps/etc. between this parallel suite
and the Lucene versions. Lucene exports this jar and works very hard to avoid
version changes.
It's a hard problem all around, and different solutions have failed in their
own ways. Error-handling is a particularly big problem. Using these objects in
parallel brings its own funkiness.
> Make all of Analysis completely independent from Lucene Core
> ------------------------------------------------------------
>
> Key: LUCENE-3151
> URL: https://issues.apache.org/jira/browse/LUCENE-3151
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 4.0
> Reporter: Grant Ingersoll
> Fix For: 4.0
>
> Attachments: LUCENE-3151.patch
>
>
> Lucene's analysis package, including the definitions of Attribute,
> TokenStream, etc. are quite useful outside of Lucene (for instance, Mahout
> uses them) for text processing. I'd like to move the definitions, or at
> least their packaging, to a separate JAR file so that one can consume them
> w/o needing Lucene core. My draft idea is to have a definition area that
> Lucene core is dependent on and the rest of the analysis package can then be
> dependent on the definition area. (I'm open to other ideas as well)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
