You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Grant Ingersoll (JIRA)" <ji...@apache.org> on 2007/02/15 17:06:05 UTC
[jira] Created: (LUCENE-805) New Lucene Demo
New Lucene Demo
---------------
Key: LUCENE-805
URL: https://issues.apache.org/jira/browse/LUCENE-805
Project: Lucene - Java
Issue Type: Improvement
Components: Examples
Reporter: Grant Ingersoll
Assigned To: Grant Ingersoll
Priority: Minor
The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one.
Ideas (not necessarily in order of importance):
1. More in-depth tutorial explaining indexing/searching
2. Multilingual support/demonstration
3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc.
4. Dealing with different content types and pointers to resources
5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs.
6. Demonstration of contrib packages, esp. Highlighter
7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices
Advanced tutorials:
1. Hadoop + Lucene
2. Writing custom analyzers/filters/tokenizers
3. Changing Scoring
4. Payloads (when they are committed)
Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-805) New Lucene Demo
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518567 ]
Grant Ingersoll commented on LUCENE-805:
----------------------------------------
Hmm, might be cool to make things real for the demo by using either the Wikipedia download or the Reuters download. Thus, we could make the demo a Best Practices place as well.
> New Lucene Demo
> ---------------
>
> Key: LUCENE-805
> URL: https://issues.apache.org/jira/browse/LUCENE-805
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Examples
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
>
> The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one.
> Ideas (not necessarily in order of importance):
> 1. More in-depth tutorial explaining indexing/searching
> 2. Multilingual support/demonstration
> 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc.
> 4. Dealing with different content types and pointers to resources
> 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs.
> 6. Demonstration of contrib packages, esp. Highlighter
> 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices
> Advanced tutorials:
> 1. Hadoop + Lucene
> 2. Writing custom analyzers/filters/tokenizers
> 3. Changing Scoring
> 4. Payloads (when they are committed)
> Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Assigned: (LUCENE-805) New Lucene Demo
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grant Ingersoll reassigned LUCENE-805:
--------------------------------------
Assignee: (was: Grant Ingersoll)
> New Lucene Demo
> ---------------
>
> Key: LUCENE-805
> URL: https://issues.apache.org/jira/browse/LUCENE-805
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Examples
> Reporter: Grant Ingersoll
> Priority: Minor
>
> The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one.
> Ideas (not necessarily in order of importance):
> 1. More in-depth tutorial explaining indexing/searching
> 2. Multilingual support/demonstration
> 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc.
> 4. Dealing with different content types and pointers to resources
> 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs.
> 6. Demonstration of contrib packages, esp. Highlighter
> 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices
> Advanced tutorials:
> 1. Hadoop + Lucene
> 2. Writing custom analyzers/filters/tokenizers
> 3. Changing Scoring
> 4. Payloads (when they are committed)
> Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-805) New Lucene Demo
Posted by "Grant Ingersoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473429 ]
Grant Ingersoll commented on LUCENE-805:
----------------------------------------
I'm all for that the examples from LIA, but I also think the key part
is the documentation that goes with it. I don't think it should be a
requirement to buy LIA (even though I think everyone should :-) )
in order to understand the demo. So, we would have to figure out
some way to get it documented w/o infringing on LIA, which may prove
difficult.
-Grant
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
> New Lucene Demo
> ---------------
>
> Key: LUCENE-805
> URL: https://issues.apache.org/jira/browse/LUCENE-805
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Examples
> Reporter: Grant Ingersoll
> Assigned To: Grant Ingersoll
> Priority: Minor
>
> The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one.
> Ideas (not necessarily in order of importance):
> 1. More in-depth tutorial explaining indexing/searching
> 2. Multilingual support/demonstration
> 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc.
> 4. Dealing with different content types and pointers to resources
> 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs.
> 6. Demonstration of contrib packages, esp. Highlighter
> 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices
> Advanced tutorials:
> 1. Hadoop + Lucene
> 2. Writing custom analyzers/filters/tokenizers
> 3. Changing Scoring
> 4. Payloads (when they are committed)
> Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805)
New Lucene Demo
Posted by Doug Cutting <cu...@apache.org>.
Chris Hostetter wrote:
> I kind of glossed over this when Nicolas first sent it -- but it makes
> total sense ... if a redaio button in Jira is legaly binding enough to
> allow someone with a signed CLA to commit into the repository and include
> in a release, then a checkbox on a "web form based document repository"
> (ie: cwiki) should be enough to allow someone with a signed CLA to export
> all the documentaiton and include it in a release.
I don't think the analogy is perfect. Exporting the wiki would be a
bulk, automatic process, while applying a patch is a manual and
incremental. Part of a committer's duty when considering a patch is to
determine whether the contributor likely had the right to contribute it.
Doing this on a patch-by-patch basis is not so bad: chances are you're
somewhat familiar with the contributor from the mailing list. A
substantial contribution from out-of-nowhere should cause you to raise
your eyebrows and learn a bit about the contributor before committing
it. But doing it on a wholesale export of a wiki is much harder, since
the wiki is constructed over years by a wide variety of contributors,
and thus committers might not examine every contribution to the wiki
they export.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805)
New Lucene Demo
Posted by Chris Hostetter <ho...@fucit.org>.
: I will ask on legal-discuss if click-agreement is sufficient.
: > I don't know how confluence works, but maybe it is possible to make
: > a "click-agreement" like the one there is in Jira while submitting
: > patches ?
I kind of glossed over this when Nicolas first sent it -- but it makes
total sense ... if a redaio button in Jira is legaly binding enough to
allow someone with a signed CLA to commit into the repository and include
in a release, then a checkbox on a "web form based document repository"
(ie: cwiki) should be enough to allow someone with a signed CLA to export
all the documentaiton and include it in a release.
we would probably want to have two seperate "web form based document
repository" areas ... one where you can only make edits if you check
the legal box which is archived and included in the releases by a commiter
(ie: socring docs, fileformat docs, tutorials, demos, etc...) and one that
is completley publicly accessible (ie: the FAQ, list of projects using
lucene, list of articles/books about lucene, whiteboard of ideas, tips and
tricks, etc...)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gr...@gmail.com>.
I will ask on legal-discuss if click-agreement is sufficient.
-Grant
On Feb 24, 2007, at 8:13 AM, Nicolas Lalevée wrote:
> Le samedi 24 février 2007 13:52, Grant Ingersoll a écrit :
>> Sigh.
>>
>> On http://cwiki.apache.org/confluence/display/CWIKI/Index
>>
>> Read the FAQ entry titled "But what if we would like the community at
>> large to help maintain the space?"
>> It seems if we want to bundle the docs w/ a release, then we would
>> need a CLA for people that contribute. At least that is my reading.
>
> I don't know how confluence works, but maybe it is possible to make
> a "click-agreement" like the one there is in Jira while submitting
> patches ?
>
> Nicolas
>
>>
>> On workaround that I _think_ would be satisfactory, though is to not
>> bundle that documentation, but just host it under our "Site Versions"
>> just like we always do. Then in the docs we do release, the links
>> would take the user to the appropriate site version. Then, we
>> wouldn't be bundling the wiki contents.
>>
>> This would take some ANT work to do string replacement on the URLs in
>> those docs.
>>
>> On Feb 24, 2007, at 1:24 AM, Chris Hostetter wrote:
>>> : think we could move more to the Wiki. One solution, would be to
>>>
>>> have
>>>
>>> : a simple script that calls wget (or some crawler) and downloads
>>> all
>>> : of the wiki. It would, however, be better if the wiki supported
>>>
>>> yeah .. that's a fairly crude approach that would result in a lot
>>> of the
>>> useless navigation links being left in place -- and we'd need
>>> soemthing
>>> somewaht custom to deal with changing the site links t opoint to
>>> the local
>>> files
>>>
>>> : tagging a snapshot. I've seen flashes of references on other
>>> : projects about the Confluence wiki from Atlassian. Is this
>>>
>>> available
>>>
>>> : for use at Apache and does it have the features we want?
>>>
>>> no idea if it has any features like this ... but it does appear
>>> to be
>>> available, geronimo and apache laps use it...
>>>
>>> http://cwiki.apache.org/geronimo/
>>> http://cwiki.apache.org/labs/home.html
>>>
>>> ....oooohhhhhhh.... this looks promising...
>>>
>>> http://cwiki.apache.org/confluence/spaces/exportspace.action?
>>> key=labs
>>>
>>>
>>>
>>>
>>> -Hoss
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>> --------------------------
>> Grant Ingersoll
>> Center for Natural Language Processing
>> http://www.cnlp.org
>>
>> Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
>> LuceneFAQ
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
------------------------------------------------------
Grant Ingersoll
http://www.grantingersoll.com/
http://lucene.grantingersoll.com
http://www.paperoftheweek.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Nicolas Lalevée <ni...@anyware-tech.com>.
Le samedi 24 février 2007 13:52, Grant Ingersoll a écrit :
> Sigh.
>
> On http://cwiki.apache.org/confluence/display/CWIKI/Index
>
> Read the FAQ entry titled "But what if we would like the community at
> large to help maintain the space?"
> It seems if we want to bundle the docs w/ a release, then we would
> need a CLA for people that contribute. At least that is my reading.
I don't know how confluence works, but maybe it is possible to make
a "click-agreement" like the one there is in Jira while submitting patches ?
Nicolas
>
> On workaround that I _think_ would be satisfactory, though is to not
> bundle that documentation, but just host it under our "Site Versions"
> just like we always do. Then in the docs we do release, the links
> would take the user to the appropriate site version. Then, we
> wouldn't be bundling the wiki contents.
>
> This would take some ANT work to do string replacement on the URLs in
> those docs.
>
> On Feb 24, 2007, at 1:24 AM, Chris Hostetter wrote:
> > : think we could move more to the Wiki. One solution, would be to
> >
> > have
> >
> > : a simple script that calls wget (or some crawler) and downloads all
> > : of the wiki. It would, however, be better if the wiki supported
> >
> > yeah .. that's a fairly crude approach that would result in a lot
> > of the
> > useless navigation links being left in place -- and we'd need
> > soemthing
> > somewaht custom to deal with changing the site links t opoint to
> > the local
> > files
> >
> > : tagging a snapshot. I've seen flashes of references on other
> > : projects about the Confluence wiki from Atlassian. Is this
> >
> > available
> >
> > : for use at Apache and does it have the features we want?
> >
> > no idea if it has any features like this ... but it does appear to be
> > available, geronimo and apache laps use it...
> >
> > http://cwiki.apache.org/geronimo/
> > http://cwiki.apache.org/labs/home.html
> >
> > ....oooohhhhhhh.... this looks promising...
> >
> > http://cwiki.apache.org/confluence/spaces/exportspace.action?key=labs
> >
> >
> >
> >
> > -Hoss
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
>
> --------------------------
> Grant Ingersoll
> Center for Natural Language Processing
> http://www.cnlp.org
>
> Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
> LuceneFAQ
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 24, 2007, at 1:24 AM, Chris Hostetter wrote:
>
> : think we could move more to the Wiki. One solution, would be to
> have
> : a simple script that calls wget (or some crawler) and downloads all
> : of the wiki. It would, however, be better if the wiki supported
>
> yeah .. that's a fairly crude approach that would result in a lot
> of the
> useless navigation links being left in place -- and we'd need
> soemthing
> somewaht custom to deal with changing the site links t opoint to
> the local
> files
wget can change links to point locally. For my upcoming Lucene/Solr
workshop next week, I include the entire Solr wiki in the .zip I make
available to the attendees. From my Rakefile:
task :fetch_wiki do
system("wget -P#{STAGE_DIR}/preconf -p --convert-links -r http://
wiki.apache.org/solr")
end
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gs...@apache.org>.
I should finish reading the thread before commenting... :-)
On Feb 24, 2007, at 2:07 AM, Chris Hostetter wrote:
>
> : ....oooohhhhhhh.... this looks promising...
> :
> : http://cwiki.apache.org/confluence/spaces/exportspace.action?
> key=labs
>
> Hmmm... i found a lot of interesting documentation directly on point
> here...
>
> http://cwiki.apache.org/confluence/display/CWIKI/Index
>
> in a nutshell:
>
> * cwiki has permissions schemes like jira, so you can have
> "official"
> documentation only editable by commiters and "community" documentation
> editable by anyone.
> * you can only use a cwiki as your main project site if you have the
> permsissions set so that only committers can edit it because of hte
> intelectual property issues with CLAs
> * for hte same reaosn, you can't bundle a snapshot of a cwiki with a
> release if it's publicly editable.
>
>
> ...these are policy issues, not techinical ones ... so it seems
> that any
> approach to archiving a wiki as part of a release is verboten in
> the ASF
> ... so i guess we can't completley abandon the notion of "formal"
> documentaion vs wiki docs.
>
> it really makes me wonder what the legal issues would be with
> trying to
> make an official site documentation page based on the contents of an
> existing wiki page.
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805)
New Lucene Demo
Posted by Chris Hostetter <ho...@fucit.org>.
: ....oooohhhhhhh.... this looks promising...
:
: http://cwiki.apache.org/confluence/spaces/exportspace.action?key=labs
Hmmm... i found a lot of interesting documentation directly on point
here...
http://cwiki.apache.org/confluence/display/CWIKI/Index
in a nutshell:
* cwiki has permissions schemes like jira, so you can have "official"
documentation only editable by commiters and "community" documentation
editable by anyone.
* you can only use a cwiki as your main project site if you have the
permsissions set so that only committers can edit it because of hte
intelectual property issues with CLAs
* for hte same reaosn, you can't bundle a snapshot of a cwiki with a
release if it's publicly editable.
...these are policy issues, not techinical ones ... so it seems that any
approach to archiving a wiki as part of a release is verboten in the ASF
... so i guess we can't completley abandon the notion of "formal"
documentaion vs wiki docs.
it really makes me wonder what the legal issues would be with trying to
make an official site documentation page based on the contents of an
existing wiki page.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gs...@apache.org>.
Sigh.
On http://cwiki.apache.org/confluence/display/CWIKI/Index
Read the FAQ entry titled "But what if we would like the community at
large to help maintain the space?"
It seems if we want to bundle the docs w/ a release, then we would
need a CLA for people that contribute. At least that is my reading.
On workaround that I _think_ would be satisfactory, though is to not
bundle that documentation, but just host it under our "Site Versions"
just like we always do. Then in the docs we do release, the links
would take the user to the appropriate site version. Then, we
wouldn't be bundling the wiki contents.
This would take some ANT work to do string replacement on the URLs in
those docs.
On Feb 24, 2007, at 1:24 AM, Chris Hostetter wrote:
>
> : think we could move more to the Wiki. One solution, would be to
> have
> : a simple script that calls wget (or some crawler) and downloads all
> : of the wiki. It would, however, be better if the wiki supported
>
> yeah .. that's a fairly crude approach that would result in a lot
> of the
> useless navigation links being left in place -- and we'd need
> soemthing
> somewaht custom to deal with changing the site links t opoint to
> the local
> files
>
> : tagging a snapshot. I've seen flashes of references on other
> : projects about the Confluence wiki from Atlassian. Is this
> available
> : for use at Apache and does it have the features we want?
>
> no idea if it has any features like this ... but it does appear to be
> available, geronimo and apache laps use it...
>
> http://cwiki.apache.org/geronimo/
> http://cwiki.apache.org/labs/home.html
>
> ....oooohhhhhhh.... this looks promising...
>
> http://cwiki.apache.org/confluence/spaces/exportspace.action?key=labs
>
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gs...@apache.org>.
Very cool.
Digging around leads to: http://cwiki.apache.org/confluence/display/
CWIKI/Index
On Feb 24, 2007, at 1:24 AM, Chris Hostetter wrote:
>
> : think we could move more to the Wiki. One solution, would be to
> have
> : a simple script that calls wget (or some crawler) and downloads all
> : of the wiki. It would, however, be better if the wiki supported
>
> yeah .. that's a fairly crude approach that would result in a lot
> of the
> useless navigation links being left in place -- and we'd need
> soemthing
> somewaht custom to deal with changing the site links t opoint to
> the local
> files
>
> : tagging a snapshot. I've seen flashes of references on other
> : projects about the Confluence wiki from Atlassian. Is this
> available
> : for use at Apache and does it have the features we want?
>
> no idea if it has any features like this ... but it does appear to be
> available, geronimo and apache laps use it...
>
> http://cwiki.apache.org/geronimo/
> http://cwiki.apache.org/labs/home.html
>
> ....oooohhhhhhh.... this looks promising...
>
> http://cwiki.apache.org/confluence/spaces/exportspace.action?key=labs
>
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805)
New Lucene Demo
Posted by Chris Hostetter <ho...@fucit.org>.
: think we could move more to the Wiki. One solution, would be to have
: a simple script that calls wget (or some crawler) and downloads all
: of the wiki. It would, however, be better if the wiki supported
yeah .. that's a fairly crude approach that would result in a lot of the
useless navigation links being left in place -- and we'd need soemthing
somewaht custom to deal with changing the site links t opoint to the local
files
: tagging a snapshot. I've seen flashes of references on other
: projects about the Confluence wiki from Atlassian. Is this available
: for use at Apache and does it have the features we want?
no idea if it has any features like this ... but it does appear to be
available, geronimo and apache laps use it...
http://cwiki.apache.org/geronimo/
http://cwiki.apache.org/labs/home.html
....oooohhhhhhh.... this looks promising...
http://cwiki.apache.org/confluence/spaces/exportspace.action?key=labs
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gs...@apache.org>.
Anyone know how we change this so that change notifications go to the
commits list? Perhaps whomever is responsible for the wiki??? could
update the committers section of the wiki with information about who
is responsible for the wiki and what that means? :-)
FYI: I haven't heard much back from legal-discuss on the wiki
exporting/click to agree thread.
-Grant
On Feb 23, 2007, at 8:42 PM, Steven Parkes wrote:
> All wiki changes.
>
> -----Original Message-----
> From: Grant Ingersoll [mailto:gsingers@apache.org]
> Sent: Friday, February 23, 2007 2:04 PM
> To: java-dev@lucene.apache.org
> Subject: Re: commited docs vs wiki -- was: Re: [jira] Commented:
> (LUCENE-805) New Lucene Demo
>
> I'll ask on infrastructure if there is a way to take a snapshot of
> the Wiki as HTML for release purposes. If we can do that, then I
> think we could move more to the Wiki. One solution, would be to have
> a simple script that calls wget (or some crawler) and downloads all
> of the wiki. It would, however, be better if the wiki supported
> tagging a snapshot. I've seen flashes of references on other
> projects about the Confluence wiki from Atlassian. Is this available
> for use at Apache and does it have the features we want?
>
> Also, FWIW, I just updated the release page on the Wiki and it said:
> ---
> Thank you for your changes. Your attention to detail is
> appreciated.
>
> Status of sending notification mails:
> [en] DanielNaber, StevenParkes, : Mail sent OK
> ---
> Do these two really receive all the wiki change notification emails
> or are they just subscribed to this particular page?
>
> -Grant
>
>
> On Feb 19, 2007, at 9:25 PM, Chris Hostetter wrote:
>
>>
>> : Yeah, query-syntax is pretty static, so that would be fine, but I
>> : sense a slippery slope here. Scoring is static, too, but I
>> think if
>> : people want to add to the scoring doc, that would be fine. Part of
>> : me feels like it should be all the docs, including the file
>> formats b/
>> : c we are trying to encourage people to document. On the other
>> hand,
>> : some parts of the docs, like the file formats and query-syntax,
>> feel
>> : more in stone to me and I can see a case that they should only be
>> : changed through a patch approach so that a committer is reviewing
>> the
>>
>> i'm with you all the way on that one ... it seems like every day i
>> change
>> my mind about how important it is to have "official" documentation
>> vs wiki
>> documentation.
>>
>> when solr first entered incubation, most of our stuff went in the
>> wiki
>> just because it seemed like the easiest way to get feedback,
>> improvements, and copy-editing from the widest audience ... we
>> discussed
>> migrating docs into subversion once they were more fleshed out, but
>> now
>> we're looking at migrating more docs from subversion to the wiki
>> then we
>> are the other direction.
>>
>> for Lucene-Java i'd be really leary of things like fileformats,
>> querystynax, and scoring just being wiki pages ... people still ask
>> questions about the fileformat from lucene 1.4.2, or how scoring
>> worked in
>> 1.2 ... if the only history of thta info was in a wiki where you
>> had to
>> figure out the right historic version that lined up with your code
>> based
>> on date stamps of commits (because we'd want to update the doc when
>> hte
>> change was commited, not when the release was made)
>>
>> the killer solution to a lot of problems would be a good utility for
>> slurping the whole wiki into html files, with all of hte wiki links
>> *and*
>> all of the links from the wiki to the "site" being translated into
>> relative file paths as an automated part of hte release.
>>
>> the only other anoyance i have about the wiki that wouldn't be
>> solved with
>> something like thta is the "javadoc annotation missing feature"
>> problem of
>> the wiki ... some things really belong in javadocs, but you still
>> want to
>> allow users to easily annoate those docs with their own tips/tricks
>> about
>> using it ... stuff that's deliniated as not being formal
>> documentation,
>> but still good to keep in mind, ie:
>> http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters
>>
>> PHP.net set the gold standard for this years ago...
>> http://www.php.net/manual/en/language.oop5.basic.php
>>
>> ...and Perl's CPAN is making progress...
>> http://www.annocpan.org/~AREIBENS/PDF-API2-0.57/lib/PDF/
>> API2.pm#note_1389
>>
>> ... but i've never seen a good Javadoc appraoch to this problem,
>> and none
>> of these solutions really address the issue of "releasing" baked
>> versions
>> of hte documentation that include the annotations/tips ... you'd
>> have to
>> commit them as part of the formal docs)
>>
>> : wiki policy to notify java-dev or java-commits when there are
>> : changes? I'm not sure how the wiki is administered or if I'm
>> missing
>> : the notifications already.
>>
>> i believe wiki edits already go to the commits list (that's how we
>> set
>> Solr up anyway)
>>
>>
>>
>>
>> -Hoss
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> --------------------------
> Grant Ingersoll
> Center for Natural Language Processing
> http://www.cnlp.org
>
> Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
> LuceneFAQ
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Steven Parkes <st...@esseff.org>.
All wiki changes.
-----Original Message-----
From: Grant Ingersoll [mailto:gsingers@apache.org]
Sent: Friday, February 23, 2007 2:04 PM
To: java-dev@lucene.apache.org
Subject: Re: commited docs vs wiki -- was: Re: [jira] Commented:
(LUCENE-805) New Lucene Demo
I'll ask on infrastructure if there is a way to take a snapshot of
the Wiki as HTML for release purposes. If we can do that, then I
think we could move more to the Wiki. One solution, would be to have
a simple script that calls wget (or some crawler) and downloads all
of the wiki. It would, however, be better if the wiki supported
tagging a snapshot. I've seen flashes of references on other
projects about the Confluence wiki from Atlassian. Is this available
for use at Apache and does it have the features we want?
Also, FWIW, I just updated the release page on the Wiki and it said:
---
Thank you for your changes. Your attention to detail is
appreciated.
Status of sending notification mails:
[en] DanielNaber, StevenParkes, : Mail sent OK
---
Do these two really receive all the wiki change notification emails
or are they just subscribed to this particular page?
-Grant
On Feb 19, 2007, at 9:25 PM, Chris Hostetter wrote:
>
> : Yeah, query-syntax is pretty static, so that would be fine, but I
> : sense a slippery slope here. Scoring is static, too, but I think if
> : people want to add to the scoring doc, that would be fine. Part of
> : me feels like it should be all the docs, including the file
> formats b/
> : c we are trying to encourage people to document. On the other hand,
> : some parts of the docs, like the file formats and query-syntax, feel
> : more in stone to me and I can see a case that they should only be
> : changed through a patch approach so that a committer is reviewing
> the
>
> i'm with you all the way on that one ... it seems like every day i
> change
> my mind about how important it is to have "official" documentation
> vs wiki
> documentation.
>
> when solr first entered incubation, most of our stuff went in the wiki
> just because it seemed like the easiest way to get feedback,
> improvements, and copy-editing from the widest audience ... we
> discussed
> migrating docs into subversion once they were more fleshed out, but
> now
> we're looking at migrating more docs from subversion to the wiki
> then we
> are the other direction.
>
> for Lucene-Java i'd be really leary of things like fileformats,
> querystynax, and scoring just being wiki pages ... people still ask
> questions about the fileformat from lucene 1.4.2, or how scoring
> worked in
> 1.2 ... if the only history of thta info was in a wiki where you
> had to
> figure out the right historic version that lined up with your code
> based
> on date stamps of commits (because we'd want to update the doc when
> hte
> change was commited, not when the release was made)
>
> the killer solution to a lot of problems would be a good utility for
> slurping the whole wiki into html files, with all of hte wiki links
> *and*
> all of the links from the wiki to the "site" being translated into
> relative file paths as an automated part of hte release.
>
> the only other anoyance i have about the wiki that wouldn't be
> solved with
> something like thta is the "javadoc annotation missing feature"
> problem of
> the wiki ... some things really belong in javadocs, but you still
> want to
> allow users to easily annoate those docs with their own tips/tricks
> about
> using it ... stuff that's deliniated as not being formal
> documentation,
> but still good to keep in mind, ie:
> http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters
>
> PHP.net set the gold standard for this years ago...
> http://www.php.net/manual/en/language.oop5.basic.php
>
> ...and Perl's CPAN is making progress...
> http://www.annocpan.org/~AREIBENS/PDF-API2-0.57/lib/PDF/
> API2.pm#note_1389
>
> ... but i've never seen a good Javadoc appraoch to this problem,
> and none
> of these solutions really address the issue of "releasing" baked
> versions
> of hte documentation that include the annotations/tips ... you'd
> have to
> commit them as part of the formal docs)
>
> : wiki policy to notify java-dev or java-commits when there are
> : changes? I'm not sure how the wiki is administered or if I'm
> missing
> : the notifications already.
>
> i believe wiki edits already go to the commits list (that's how we set
> Solr up anyway)
>
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gs...@apache.org>.
I'll ask on infrastructure if there is a way to take a snapshot of
the Wiki as HTML for release purposes. If we can do that, then I
think we could move more to the Wiki. One solution, would be to have
a simple script that calls wget (or some crawler) and downloads all
of the wiki. It would, however, be better if the wiki supported
tagging a snapshot. I've seen flashes of references on other
projects about the Confluence wiki from Atlassian. Is this available
for use at Apache and does it have the features we want?
Also, FWIW, I just updated the release page on the Wiki and it said:
---
Thank you for your changes. Your attention to detail is appreciated.
Status of sending notification mails:
[en] DanielNaber, StevenParkes, : Mail sent OK
---
Do these two really receive all the wiki change notification emails
or are they just subscribed to this particular page?
-Grant
On Feb 19, 2007, at 9:25 PM, Chris Hostetter wrote:
>
> : Yeah, query-syntax is pretty static, so that would be fine, but I
> : sense a slippery slope here. Scoring is static, too, but I think if
> : people want to add to the scoring doc, that would be fine. Part of
> : me feels like it should be all the docs, including the file
> formats b/
> : c we are trying to encourage people to document. On the other hand,
> : some parts of the docs, like the file formats and query-syntax, feel
> : more in stone to me and I can see a case that they should only be
> : changed through a patch approach so that a committer is reviewing
> the
>
> i'm with you all the way on that one ... it seems like every day i
> change
> my mind about how important it is to have "official" documentation
> vs wiki
> documentation.
>
> when solr first entered incubation, most of our stuff went in the wiki
> just because it seemed like the easiest way to get feedback,
> improvements, and copy-editing from the widest audience ... we
> discussed
> migrating docs into subversion once they were more fleshed out, but
> now
> we're looking at migrating more docs from subversion to the wiki
> then we
> are the other direction.
>
> for Lucene-Java i'd be really leary of things like fileformats,
> querystynax, and scoring just being wiki pages ... people still ask
> questions about the fileformat from lucene 1.4.2, or how scoring
> worked in
> 1.2 ... if the only history of thta info was in a wiki where you
> had to
> figure out the right historic version that lined up with your code
> based
> on date stamps of commits (because we'd want to update the doc when
> hte
> change was commited, not when the release was made)
>
> the killer solution to a lot of problems would be a good utility for
> slurping the whole wiki into html files, with all of hte wiki links
> *and*
> all of the links from the wiki to the "site" being translated into
> relative file paths as an automated part of hte release.
>
> the only other anoyance i have about the wiki that wouldn't be
> solved with
> something like thta is the "javadoc annotation missing feature"
> problem of
> the wiki ... some things really belong in javadocs, but you still
> want to
> allow users to easily annoate those docs with their own tips/tricks
> about
> using it ... stuff that's deliniated as not being formal
> documentation,
> but still good to keep in mind, ie:
> http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters
>
> PHP.net set the gold standard for this years ago...
> http://www.php.net/manual/en/language.oop5.basic.php
>
> ...and Perl's CPAN is making progress...
> http://www.annocpan.org/~AREIBENS/PDF-API2-0.57/lib/PDF/
> API2.pm#note_1389
>
> ... but i've never seen a good Javadoc appraoch to this problem,
> and none
> of these solutions really address the issue of "releasing" baked
> versions
> of hte documentation that include the annotations/tips ... you'd
> have to
> commit them as part of the formal docs)
>
> : wiki policy to notify java-dev or java-commits when there are
> : changes? I'm not sure how the wiki is administered or if I'm
> missing
> : the notifications already.
>
> i believe wiki edits already go to the commits list (that's how we set
> Solr up anyway)
>
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
commited docs vs wiki -- was: Re: [jira] Commented: (LUCENE-805)
New Lucene Demo
Posted by Chris Hostetter <ho...@fucit.org>.
: Yeah, query-syntax is pretty static, so that would be fine, but I
: sense a slippery slope here. Scoring is static, too, but I think if
: people want to add to the scoring doc, that would be fine. Part of
: me feels like it should be all the docs, including the file formats b/
: c we are trying to encourage people to document. On the other hand,
: some parts of the docs, like the file formats and query-syntax, feel
: more in stone to me and I can see a case that they should only be
: changed through a patch approach so that a committer is reviewing the
i'm with you all the way on that one ... it seems like every day i change
my mind about how important it is to have "official" documentation vs wiki
documentation.
when solr first entered incubation, most of our stuff went in the wiki
just because it seemed like the easiest way to get feedback,
improvements, and copy-editing from the widest audience ... we discussed
migrating docs into subversion once they were more fleshed out, but now
we're looking at migrating more docs from subversion to the wiki then we
are the other direction.
for Lucene-Java i'd be really leary of things like fileformats,
querystynax, and scoring just being wiki pages ... people still ask
questions about the fileformat from lucene 1.4.2, or how scoring worked in
1.2 ... if the only history of thta info was in a wiki where you had to
figure out the right historic version that lined up with your code based
on date stamps of commits (because we'd want to update the doc when hte
change was commited, not when the release was made)
the killer solution to a lot of problems would be a good utility for
slurping the whole wiki into html files, with all of hte wiki links *and*
all of the links from the wiki to the "site" being translated into
relative file paths as an automated part of hte release.
the only other anoyance i have about the wiki that wouldn't be solved with
something like thta is the "javadoc annotation missing feature" problem of
the wiki ... some things really belong in javadocs, but you still want to
allow users to easily annoate those docs with their own tips/tricks about
using it ... stuff that's deliniated as not being formal documentation,
but still good to keep in mind, ie:
http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters
PHP.net set the gold standard for this years ago...
http://www.php.net/manual/en/language.oop5.basic.php
...and Perl's CPAN is making progress...
http://www.annocpan.org/~AREIBENS/PDF-API2-0.57/lib/PDF/API2.pm#note_1389
... but i've never seen a good Javadoc appraoch to this problem, and none
of these solutions really address the issue of "releasing" baked versions
of hte documentation that include the annotations/tips ... you'd have to
commit them as part of the formal docs)
: wiki policy to notify java-dev or java-commits when there are
: changes? I'm not sure how the wiki is administered or if I'm missing
: the notifications already.
i believe wiki edits already go to the commits list (that's how we set
Solr up anyway)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gs...@apache.org>.
On Feb 19, 2007, at 1:17 PM, Doron Cohen wrote:
>
> So docs moved to wiki would be removed from svn, right?
>
Yes. To transition, the links would be changed to link into the Wiki.
> This also means that the recently added nice 'docs by release'
> views would only exist for Javadocs and FileFormats. Perhaps
> having query-syntax by release would also be helpful for users.
Yeah, query-syntax is pretty static, so that would be fine, but I
sense a slippery slope here. Scoring is static, too, but I think if
people want to add to the scoring doc, that would be fine. Part of
me feels like it should be all the docs, including the file formats b/
c we are trying to encourage people to document. On the other hand,
some parts of the docs, like the file formats and query-syntax, feel
more in stone to me and I can see a case that they should only be
changed through a patch approach so that a committer is reviewing the
changes. I guess the question is, if we switch to all wiki approach,
do people, especially committers, feel that changes that contain
errors will be caught and fixed. Perhaps we would want to change the
wiki policy to notify java-dev or java-commits when there are
changes? I'm not sure how the wiki is administered or if I'm missing
the notifications already.
Having spent some of the weekend looking through Solr's docs, I'm
quite impressed with what they have done through the wiki. It is
very well organized and seems to cover a lot of ground in a nice,
coherent manner, so that makes me in favor of putting all the files,
including File Formats into the wiki and setting it so that we are
some how notified of changes.
>
>>>
>>> -Grant
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Doron Cohen <DO...@il.ibm.com>.
Grant Ingersoll <gr...@gmail.com> wrote on 19/02/2007 04:36:08:
> To add to this, we could keep the same pointers for now, and just
> have them point into the Wiki so that people aren't completely lost
> by the changes.
>
> On Feb 18, 2007, at 7:46 AM, Grant Ingersoll wrote:
>
> > I'm all for the Wiki, just not sure how to get people to move to it.
> >
> > One idea is to move all of our main documentation there. That is,
> > move almost all of the content under "Documentation" to the wiki
> > and then update the wiki into a more coherent landing page.
> >
> > I would suggest we keep the following under the documentation link:
> > API Docs
> > File Formats
So docs moved to wiki would be removed from svn, right?
This also means that the recently added nice 'docs by release'
views would only exist for Javadocs and FileFormats. Perhaps
having query-syntax by release would also be helpful for users.
> >
> > -Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gr...@gmail.com>.
To add to this, we could keep the same pointers for now, and just
have them point into the Wiki so that people aren't completely lost
by the changes.
On Feb 18, 2007, at 7:46 AM, Grant Ingersoll wrote:
> I'm all for the Wiki, just not sure how to get people to move to it.
>
> One idea is to move all of our main documentation there. That is,
> move almost all of the content under "Documentation" to the wiki
> and then update the wiki into a more coherent landing page.
>
> I would suggest we keep the following under the documentation link:
> API Docs
> File Formats
>
> -Grant
>
>
> On Feb 15, 2007, at 7:20 PM, Erik Hatcher wrote:
>
>>
>> On Feb 15, 2007, at 2:33 PM, Grant Ingersoll wrote:
>>> I think that code is great and is often self-documenting, but it
>>> only represents the result of someone writing the code, it
>>> doesn't explain the why part of it. So, it would need English
>>> (and translations???) to explain why a particular approach was
>>> taken, along with possible alternatives.
>>
>> So how about following the Solr lead with incredible wiki
>> documentation and tutorial stuff. The code could be contributed
>> and then documented by the community.
>>
>> I'd have no problem copy/pasting sections of LIA that were
>> relevant and useful. Or writing some stuff from scratch on the
>> examples.
>>
>> Erik
>>
>>
>>>
>>>
>>> On Feb 15, 2007, at 2:25 PM, Erik Hatcher (JIRA) wrote:
>>>
>>>>
>>>> [ https://issues.apache.org/jira/browse/LUCENE-805?
>>>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>>> tabpanel#action_12473480 ]
>>>>
>>>> Erik Hatcher commented on LUCENE-805:
>>>> -------------------------------------
>>>>
>>>> That was my concern as well, Grant. At least the LIA code is
>>>> fairly well self documenting (we used JUnit for a reason :) and
>>>> the build file itself is a nice example of how to launch
>>>> applications and examples from a common starting point.
>>>>
>>>> What other documentation would be needed to make this a palatable?
>>>>
>>>>> New Lucene Demo
>>>>> ---------------
>>>>>
>>>>> Key: LUCENE-805
>>>>> URL: https://issues.apache.org/jira/browse/
>>>>> LUCENE-805
>>>>> Project: Lucene - Java
>>>>> Issue Type: Improvement
>>>>> Components: Examples
>>>>> Reporter: Grant Ingersoll
>>>>> Assigned To: Grant Ingersoll
>>>>> Priority: Minor
>>>>>
>>>>> The much maligned demo, while useful, could use a breath of
>>>>> fresh air. This issue is to start collecting requirements
>>>>> about what people would like to see in a demo and what they
>>>>> don't like in the current one.
>>>>> Ideas (not necessarily in order of importance):
>>>>> 1. More in-depth tutorial explaining indexing/searching
>>>>> 2. Multilingual support/demonstration
>>>>> 3. Better demonstration of querying capabilities: Spans,
>>>>> Phrases, Wildcards, Filters, sorting, etc.
>>>>> 4. Dealing with different content types and pointers to resources
>>>>> 5. Wiki use cases links -- I think it would be cool to solicit
>>>>> people to contribute use cases to the docs.
>>>>> 6. Demonstration of contrib packages, esp. Highlighter
>>>>> 7. Performance issues/factors/tradeoffs. Lucene lessons
>>>>> learned and best practices
>>>>> Advanced tutorials:
>>>>> 1. Hadoop + Lucene
>>>>> 2. Writing custom analyzers/filters/tokenizers
>>>>> 3. Changing Scoring
>>>>> 4. Payloads (when they are committed)
>>>>> Please contribute what else you would like to see. I may be
>>>>> able to address some of these issues for my ApacheCon talk, but
>>>>> not all of them.
>>>>
>>>> --
>>>> 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: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>
>>> ------------------------------------------------------
>>> Grant Ingersoll
>>> http://www.grantingersoll.com/
>>> http://www.paperoftheweek.com/
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> ------------------------------------------------------
> Grant Ingersoll
> http://www.grantingersoll.com/
> http://lucene.grantingersoll.com
> http://www.paperoftheweek.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
------------------------------------------------------
Grant Ingersoll
http://www.grantingersoll.com/
http://lucene.grantingersoll.com
http://www.paperoftheweek.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gr...@gmail.com>.
I'm all for the Wiki, just not sure how to get people to move to it.
One idea is to move all of our main documentation there. That is,
move almost all of the content under "Documentation" to the wiki and
then update the wiki into a more coherent landing page.
I would suggest we keep the following under the documentation link:
API Docs
File Formats
-Grant
On Feb 15, 2007, at 7:20 PM, Erik Hatcher wrote:
>
> On Feb 15, 2007, at 2:33 PM, Grant Ingersoll wrote:
>> I think that code is great and is often self-documenting, but it
>> only represents the result of someone writing the code, it doesn't
>> explain the why part of it. So, it would need English (and
>> translations???) to explain why a particular approach was taken,
>> along with possible alternatives.
>
> So how about following the Solr lead with incredible wiki
> documentation and tutorial stuff. The code could be contributed
> and then documented by the community.
>
> I'd have no problem copy/pasting sections of LIA that were relevant
> and useful. Or writing some stuff from scratch on the examples.
>
> Erik
>
>
>>
>>
>> On Feb 15, 2007, at 2:25 PM, Erik Hatcher (JIRA) wrote:
>>
>>>
>>> [ https://issues.apache.org/jira/browse/LUCENE-805?
>>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel#action_12473480 ]
>>>
>>> Erik Hatcher commented on LUCENE-805:
>>> -------------------------------------
>>>
>>> That was my concern as well, Grant. At least the LIA code is
>>> fairly well self documenting (we used JUnit for a reason :) and
>>> the build file itself is a nice example of how to launch
>>> applications and examples from a common starting point.
>>>
>>> What other documentation would be needed to make this a palatable?
>>>
>>>> New Lucene Demo
>>>> ---------------
>>>>
>>>> Key: LUCENE-805
>>>> URL: https://issues.apache.org/jira/browse/
>>>> LUCENE-805
>>>> Project: Lucene - Java
>>>> Issue Type: Improvement
>>>> Components: Examples
>>>> Reporter: Grant Ingersoll
>>>> Assigned To: Grant Ingersoll
>>>> Priority: Minor
>>>>
>>>> The much maligned demo, while useful, could use a breath of
>>>> fresh air. This issue is to start collecting requirements about
>>>> what people would like to see in a demo and what they don't like
>>>> in the current one.
>>>> Ideas (not necessarily in order of importance):
>>>> 1. More in-depth tutorial explaining indexing/searching
>>>> 2. Multilingual support/demonstration
>>>> 3. Better demonstration of querying capabilities: Spans,
>>>> Phrases, Wildcards, Filters, sorting, etc.
>>>> 4. Dealing with different content types and pointers to resources
>>>> 5. Wiki use cases links -- I think it would be cool to solicit
>>>> people to contribute use cases to the docs.
>>>> 6. Demonstration of contrib packages, esp. Highlighter
>>>> 7. Performance issues/factors/tradeoffs. Lucene lessons learned
>>>> and best practices
>>>> Advanced tutorials:
>>>> 1. Hadoop + Lucene
>>>> 2. Writing custom analyzers/filters/tokenizers
>>>> 3. Changing Scoring
>>>> 4. Payloads (when they are committed)
>>>> Please contribute what else you would like to see. I may be
>>>> able to address some of these issues for my ApacheCon talk, but
>>>> not all of them.
>>>
>>> --
>>> 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: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>> ------------------------------------------------------
>> Grant Ingersoll
>> http://www.grantingersoll.com/
>> http://www.paperoftheweek.com/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
------------------------------------------------------
Grant Ingersoll
http://www.grantingersoll.com/
http://lucene.grantingersoll.com
http://www.paperoftheweek.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 15, 2007, at 2:33 PM, Grant Ingersoll wrote:
> I think that code is great and is often self-documenting, but it
> only represents the result of someone writing the code, it doesn't
> explain the why part of it. So, it would need English (and
> translations???) to explain why a particular approach was taken,
> along with possible alternatives.
So how about following the Solr lead with incredible wiki
documentation and tutorial stuff. The code could be contributed and
then documented by the community.
I'd have no problem copy/pasting sections of LIA that were relevant
and useful. Or writing some stuff from scratch on the examples.
Erik
>
>
> On Feb 15, 2007, at 2:25 PM, Erik Hatcher (JIRA) wrote:
>
>>
>> [ https://issues.apache.org/jira/browse/LUCENE-805?
>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> tabpanel#action_12473480 ]
>>
>> Erik Hatcher commented on LUCENE-805:
>> -------------------------------------
>>
>> That was my concern as well, Grant. At least the LIA code is
>> fairly well self documenting (we used JUnit for a reason :) and
>> the build file itself is a nice example of how to launch
>> applications and examples from a common starting point.
>>
>> What other documentation would be needed to make this a palatable?
>>
>>> New Lucene Demo
>>> ---------------
>>>
>>> Key: LUCENE-805
>>> URL: https://issues.apache.org/jira/browse/
>>> LUCENE-805
>>> Project: Lucene - Java
>>> Issue Type: Improvement
>>> Components: Examples
>>> Reporter: Grant Ingersoll
>>> Assigned To: Grant Ingersoll
>>> Priority: Minor
>>>
>>> The much maligned demo, while useful, could use a breath of fresh
>>> air. This issue is to start collecting requirements about what
>>> people would like to see in a demo and what they don't like in
>>> the current one.
>>> Ideas (not necessarily in order of importance):
>>> 1. More in-depth tutorial explaining indexing/searching
>>> 2. Multilingual support/demonstration
>>> 3. Better demonstration of querying capabilities: Spans, Phrases,
>>> Wildcards, Filters, sorting, etc.
>>> 4. Dealing with different content types and pointers to resources
>>> 5. Wiki use cases links -- I think it would be cool to solicit
>>> people to contribute use cases to the docs.
>>> 6. Demonstration of contrib packages, esp. Highlighter
>>> 7. Performance issues/factors/tradeoffs. Lucene lessons learned
>>> and best practices
>>> Advanced tutorials:
>>> 1. Hadoop + Lucene
>>> 2. Writing custom analyzers/filters/tokenizers
>>> 3. Changing Scoring
>>> 4. Payloads (when they are committed)
>>> Please contribute what else you would like to see. I may be able
>>> to address some of these issues for my ApacheCon talk, but not
>>> all of them.
>>
>> --
>> 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: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> ------------------------------------------------------
> Grant Ingersoll
> http://www.grantingersoll.com/
> http://www.paperoftheweek.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [jira] Commented: (LUCENE-805) New Lucene Demo
Posted by Grant Ingersoll <gr...@gmail.com>.
I think that code is great and is often self-documenting, but it only
represents the result of someone writing the code, it doesn't explain
the why part of it. So, it would need English (and translations???)
to explain why a particular approach was taken, along with possible
alternatives.
On Feb 15, 2007, at 2:25 PM, Erik Hatcher (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/LUCENE-805?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#action_12473480 ]
>
> Erik Hatcher commented on LUCENE-805:
> -------------------------------------
>
> That was my concern as well, Grant. At least the LIA code is
> fairly well self documenting (we used JUnit for a reason :) and the
> build file itself is a nice example of how to launch applications
> and examples from a common starting point.
>
> What other documentation would be needed to make this a palatable?
>
>> New Lucene Demo
>> ---------------
>>
>> Key: LUCENE-805
>> URL: https://issues.apache.org/jira/browse/LUCENE-805
>> Project: Lucene - Java
>> Issue Type: Improvement
>> Components: Examples
>> Reporter: Grant Ingersoll
>> Assigned To: Grant Ingersoll
>> Priority: Minor
>>
>> The much maligned demo, while useful, could use a breath of fresh
>> air. This issue is to start collecting requirements about what
>> people would like to see in a demo and what they don't like in the
>> current one.
>> Ideas (not necessarily in order of importance):
>> 1. More in-depth tutorial explaining indexing/searching
>> 2. Multilingual support/demonstration
>> 3. Better demonstration of querying capabilities: Spans, Phrases,
>> Wildcards, Filters, sorting, etc.
>> 4. Dealing with different content types and pointers to resources
>> 5. Wiki use cases links -- I think it would be cool to solicit
>> people to contribute use cases to the docs.
>> 6. Demonstration of contrib packages, esp. Highlighter
>> 7. Performance issues/factors/tradeoffs. Lucene lessons learned
>> and best practices
>> Advanced tutorials:
>> 1. Hadoop + Lucene
>> 2. Writing custom analyzers/filters/tokenizers
>> 3. Changing Scoring
>> 4. Payloads (when they are committed)
>> Please contribute what else you would like to see. I may be able
>> to address some of these issues for my ApacheCon talk, but not all
>> of them.
>
> --
> 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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
------------------------------------------------------
Grant Ingersoll
http://www.grantingersoll.com/
http://www.paperoftheweek.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-805) New Lucene Demo
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473480 ]
Erik Hatcher commented on LUCENE-805:
-------------------------------------
That was my concern as well, Grant. At least the LIA code is fairly well self documenting (we used JUnit for a reason :) and the build file itself is a nice example of how to launch applications and examples from a common starting point.
What other documentation would be needed to make this a palatable?
> New Lucene Demo
> ---------------
>
> Key: LUCENE-805
> URL: https://issues.apache.org/jira/browse/LUCENE-805
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Examples
> Reporter: Grant Ingersoll
> Assigned To: Grant Ingersoll
> Priority: Minor
>
> The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one.
> Ideas (not necessarily in order of importance):
> 1. More in-depth tutorial explaining indexing/searching
> 2. Multilingual support/demonstration
> 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc.
> 4. Dealing with different content types and pointers to resources
> 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs.
> 6. Demonstration of contrib packages, esp. Highlighter
> 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices
> Advanced tutorials:
> 1. Hadoop + Lucene
> 2. Writing custom analyzers/filters/tokenizers
> 3. Changing Scoring
> 4. Payloads (when they are committed)
> Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-805) New Lucene Demo
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473419 ]
Erik Hatcher commented on LUCENE-805:
-------------------------------------
The examples from Lucene in Action are freely available and Otis and I are fine with assigning the ASL to them (its currently unspecified but implicitly ASLd). If these would be useful, at least the Indexer.java and Searcher.java which are better demos than current demo application, we're free to use that as a starter. All the code could be contributed if folks are ok with that.
In fact, maybe Otis and I should do the 2nd edition codebase within the Lucene svn somewhere so that it serves as a built-in example.
> New Lucene Demo
> ---------------
>
> Key: LUCENE-805
> URL: https://issues.apache.org/jira/browse/LUCENE-805
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Examples
> Reporter: Grant Ingersoll
> Assigned To: Grant Ingersoll
> Priority: Minor
>
> The much maligned demo, while useful, could use a breath of fresh air. This issue is to start collecting requirements about what people would like to see in a demo and what they don't like in the current one.
> Ideas (not necessarily in order of importance):
> 1. More in-depth tutorial explaining indexing/searching
> 2. Multilingual support/demonstration
> 3. Better demonstration of querying capabilities: Spans, Phrases, Wildcards, Filters, sorting, etc.
> 4. Dealing with different content types and pointers to resources
> 5. Wiki use cases links -- I think it would be cool to solicit people to contribute use cases to the docs.
> 6. Demonstration of contrib packages, esp. Highlighter
> 7. Performance issues/factors/tradeoffs. Lucene lessons learned and best practices
> Advanced tutorials:
> 1. Hadoop + Lucene
> 2. Writing custom analyzers/filters/tokenizers
> 3. Changing Scoring
> 4. Payloads (when they are committed)
> Please contribute what else you would like to see. I may be able to address some of these issues for my ApacheCon talk, but not all of them.
--
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org