Doug Cutting wrote:
Henri Yandell wrote:
Your download page is already separate, you're using the global
closer.cgi file.
So we need to:
- rename Lucene Java's mailing lists, with forwards put into place.
- add a mailing list page to Lucene Java's website, modelled after
Doug Cutting wrote:
Garrett Rooney wrote:
Actually, currently we've got both lucene4c and java commits going to
[EMAIL PROTECTED], and there was some talk of just leaving it
that way, since it isn't that much traffic and it encourages people to
keep an eye on what's going on in other languages
Erik Hatcher wrote:
I'm not sure if this is the best way to do it (Garrett?), but I created
a /trunk top-level directory with svn:externals pointing to trunk of
both java and lucene4c. The drawback is that its https, which means
only committers would be able to use it. Is there a better
Thanks to Justin Erenkrantz's help getting us set up with Subversion,
Lucene4c has been imported into the ASF incubator repository. Get it
while it's hot at:
http://svn.apache.org/repos/asf/incubator/lucene4c/trunk/
Commit mails are currently going to [EMAIL PROTECTED] (although
the initial
Erik Hatcher wrote:
On Feb 26, 2005, at 11:56 AM, Garrett Rooney wrote:
Commit mails are currently going to [EMAIL PROTECTED]
(although the initial import mail bounced due to the size of the
mail), so we should decide if that's where they should stay (that's
what Justin recommends), or if we
I'm happy to announce the release of version 0.03 of Lucene4c, a port of
Lucene to the C language using the Apache Portable Runtime.
This release adds several APIs for running operations over an entire
index where previous versions only allowed you to do so with a single
segment, improves a
George Aroush wrote:
Proposal for new project Lucene.Net (aka dotLucene)
George Aroush -- [EMAIL PROTECTED]
(0) rationale
Lucene.Net (aka dotLucene) is a source code port of Jakarta Lucene from Java
to C#. The
George Aroush wrote:
Hi Garrett,
Thanks for your support.
No, the port of 1.4.0 and 1.4.3 of dotLucene is from the ground up and has
nothing to do with Lucene.Net 1.3. The logs on SourceForge.net shows this.
Excellent. I'm glad to hear it.
The conflicting question that I have is, Lucene.Net is a
Erik Hatcher wrote:
I encourage you to propose the codebase to the Incubator.
For the curious, the proposal has been sent. I hope to see you all
voicing your support on general@incubator.apache.org ;-)
-garrett
-
To
Erik Hatcher wrote:
I have checked out our current site to the lucene.apache.org area, and
I've also set up a redirect from the jakarta.apache.org/lucene area.
Things are redirecting fine for me. Let me know if you encounter any
issues, but also be patient in case the DNS updates for
Doug Cutting wrote:
Garrett Rooney wrote:
Additionally it would be good to work on updating the disk format
documentation, I've found several cases where the docs are quite out
of date compared to the current code. It's hard to expect the various
different ports to maintain compatibility when
Doug Cutting wrote:
Garrett Rooney wrote:
Agreed. Java Lucene is a subproject of the Lucene TLP, leaving the
existing Java Lucene site there for the time being seems ok, just so
we have something there, but we should endeavour to put up something
more permanent ASAP.
I think, for the present
Doug Cutting wrote:
Erik Hatcher wrote:
I've amended my request for e-mail lists here with Doug's preference:
http://issues.apache.org/jira/browse/INFRA-195
Do others agree this is the best approach? I don't mean to be
autocratic. Do we imagine different pools of users and developers for
I'm happy to announce the release of version 0.02 of Lucene4c, a port of
Lucene to the C language using the Apache Portable Runtime.
The primary new feature in this release is support for compressed file
stream directories, and along with that comes a directory abstraction
similar to that
Erik Hatcher wrote:
Garrett,
Now that we have Subversion, are you interested in us creating an area
for lucene4c at Apache?
I'd be happy to move lucene4c development to Apache, I'm getting to the
point where the project resembles something that could be useful, and
the ASF infrastructure would
Erik Hatcher wrote:
What is the procedure from here?
I encourage you to propose the codebase to the Incubator. I'd be happy
to be a sponsor of it, and I'm already tuning in to the incubator list.
The lack of community around this codebase will be an issue leaving the
incubator, but I think
Daniel Naber wrote:
On Wednesday 02 February 2005 21:20, Erik Hatcher wrote:
For committers, check out the repository using https and your Apache
username/password.
I guess this is the password one uses to log into cvs.apache.org with ssh?
Then it doesn't work for me, I can check out stuff but
I've seen other Lucene ports announce occasional releases here, so I
figured I'd drop you guys a line about lucene4c 0.01, which I just
released tonight.
Lucene4c is a port of Lucene to C, using the Apache Portable Runtime for
portability. Eventually I hope to build mod_lucene, an Apache
Doug Cutting wrote:
It would be useful to have a command-line utility (i.e., a static
main(String[]) method somewhere) that lists the files and sizes
contained inside a CFS file, and perhaps even an option to unpack it.
Anyone care to contribute this method?
Here's a diff to add this
Doug Cutting wrote:
It would be useful to have a command-line utility (i.e., a static
main(String[]) method somewhere) that lists the files and sizes
contained inside a CFS file, and perhaps even an option to unpack it.
Anyone care to contribute this method?
I may have a chance to look at that
Giulio Cesare Solaroli wrote:
I am not a commiter (just an happy user!), but I would suggest the
following layout:
asf-repo/
jakarta/
lucene/
trunk/
core/
sandbox/
branches/
tags/
This layout will allow tags and branches of both core and sandbox to
be kept
Otis Gospodnetic wrote:
I don't know how exactly SVN works, but one of the things we have
talked about in the past is that we currntly do not tag, branch, and
release sandbox components, and we all agree that we should.
Furthermore, because of API changes, keeping core and sandbox in sync
is
Doug Cutting wrote:
Garrett Rooney wrote:
The least effort way of doing that would be to include both the core
and sandbox under the same trunk, but again, that implies that you
ALWAYS tag and branch them together, and sometimes you may not want to
do that.
I think we should always branch
23 matches
Mail list logo
