[
https://issues.apache.org/jira/browse/LUCENE-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903985#action_12903985
]
Chris A. Mattmann edited comment on LUCENE-2628 at 8/29/10 12:47 PM:
---------------------------------------------------------------------
*puts on ASF member hat*
Unless the Lucene folks want to champion moving over the OpenBitSet class into
commons, then this discussion is really moot. The reporter of this issue (Stu)
is free to create a patch for commons that duplicates this class, and if the
commons folks are willing to manage it over there, then that's on them. If the
Lucene folks at some point down the road then decide to take Stu's commons
contribution, and update their internal Lucene code to use the commons
versions, then more power to them. If the opposite is true, that's fine as
well. This is all ASLv2 licensed stuff in the end, and folks are free to fork.
That said, it's on the maintainers of libraries in *both* communities to decide
if things are worth the reorganization in the end. For the commons side, it
seems like an easier job (accept patch, find someone to maintain it, e.g.,
Stu). On the Lucene side, depending on how much or how little reuse you want to
do (reuse entirely, remove class in Lucene, to subclassing an internal Lucene
class that depends on the new commons one, and/or overrides it, all the way to
keeping a copy of the commons class in Lucene-ville), you guys can choose where
to go from there.
was (Author: chrismattmann):
*puts on ASF member hat*
Unless the Lucene folks want to champion moving over the OpenBitSet class into
commons, then this discussion is really moot. The reporter of this issue (Stu)
is free to create a patch for commons that duplicates this class, and if the
commons folks are willing to manage it over there, then that's on them. If the
Lucene folks at some point down the road then decide to take Stu's commons
contribution, and update their internal Lucene code to use the commons
versions, then more power to them. If the opposite is true, that's fine as
well. This is all ASLv2 licensed stuff in the end, and folks are free to fork.
That said, it's on the maintainers of libraries in *both* communities to decide
if things are worth the reorganization in the end. For the commons side, it
seems like an easier job (accept patch, find someone to maintain it, e.g.,
Stu). On the Lucene side, depending on how or how little reuse you want to do
(reuse entirely, remove class in Lucene, to subclassing an internal Lucene
class that depends on the new commons one, and/or overrides it, all the way to
keeping a copy of the commons class in Lucene-ville).
> Extract OpenBitSet to Apache Commons
> ------------------------------------
>
> Key: LUCENE-2628
> URL: https://issues.apache.org/jira/browse/LUCENE-2628
> Project: Lucene - Java
> Issue Type: Wish
> Reporter: Stu Hood
>
> o.a.l.util.OpenBitSet is a great alternative to java.util.BitSet, and it is
> generally useful outside of the search field. It would be great if OpenBitSet
> were available outside of Lucene proper, perhaps as part of Apache Commons.
> Aside from the communication required to accomplish this, there is the small
> issue of OpenBitSet extending o.a.l.search.DocIdSet in Lucene 3.0. There is
> very little logic contained in DocIdSet, so it could probably become an
> interface: Lucene proper could then extend the extract version of OpenBitSet
> to implement DocIdSet.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
