Would this mean that people checking out Lucene source (especially the
core) could possibly need 2 or more JDKs on their machines in order to
do a build? I know it is would be automated through the build scripts,
but it seems like _it could_ degenerate into a management nightmare.
What if peo
I use 1.5 JVM since 1.5 years building 1.4 and 1.5 projects which
works perfect. But if you are afraid of the management you could still
modify your local build process to set JAVA_HOME variables during
build.
Multiple JVM on a system should not be a problem AFAIK.
Won't that solve the problem?!
We are actually using 1.5 too. My concern is that when someone makes
changes to the core, they have to make sure they didn't break the code,
this includes all of the contrib modules, which _could_ mean that I need
more than just 1.4 and 1.5 to build and test the core and contrib
areas. I just
On 5/30/06, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
We are actually using 1.5 too. My concern is that when someone makes
changes to the core, they have to make sure they didn't break the code,
this includes all of the contrib modules, which _could_ mean that I need
more than just 1.4 and 1.5
Please don't move to Java 5.
My reasons are simple (and some perhaps stem out of old information or
misinformation):
MacOS 9 does not run Java 1.5, which is one of my target platforms.
Has Java 5 been ported to all target platforms?
Java 5 has nice syntax sugar but no real substance other
If you need to run on OS9 then run Lucene 1.9 (or it seems 2.0, just not
2.1).
You have a working, stable release that runs under 1.4. There are MANY
applications that don't run under OS9 now (they require OSX). Why should
Lucene be any different? I am fairly certain you cannot even purchase OS9
f
Just use 2.0.* for GCJ.
New Lucene releases are made every half a year at best. It will be a while
before we have 2.1. By that time GCJ may be up to speed.
Otis
- Original Message
From: Bill Janssen <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Cc: Otis Gospodnetic <[EMAIL PROTEC
Here we go, monster thread. Some responses inline.
- Original Message
From: DM Smith <[EMAIL PROTECTED]>
Please don't move to Java 5.
My reasons are simple (and some perhaps stem out of old information or
misinformation):
MacOS 9 does not run Java 1.5, which is one of my target pl
Robert Engels wrote:
If you need to run on OS9 then run Lucene 1.9 (or it seems 2.0, just not
2.1).
You have a working, stable release that runs under 1.4. There are MANY
applications that don't run under OS9 now (they require OSX). Why should
Lucene be any different? I am fairly certain you can
By stating that I needed to run on Mac OS 9, this also implies that I
need to run on OSX prior to Tiger (10.4) which does not have Java 5 and
according to everything that I read, won't. OSX 10.3 does not seem like
an unreasonable target platform for Lucene applications.
Robert Engels wrote:
I
Nobody replies... hmm I assume that this would be ok. Mentors? Doug, Yonik, Ian?
simon
On 5/29/06, Simon Willnauer <[EMAIL PROTECTED]> wrote:
Hello everyone,
today I reconsidered the internal representation of the feed /
entries. I had a closer look at the Google Data Client Api which is
supp
If you can control them to run 1.4, you can probably control them to run
1.5.
Any performance gains offered by 2.1 would pale in comparison to your user's
upgrading their machines. If not, they stick with 2.0 based Lucene, and run
it under 1.4
Why don't your users run MS-DOS? It would be the fas
Robert Engels wrote:
If you can control them to run 1.4, you can probably control them to run
1.5.
I cannot control my application's users to run Java 1.4. We moved from
Java 1.3 to Java 1.4 only after all platforms our users were running had
a Java 1.4 jvm available. We did make a conscio
Simon,
I just don't quite understand how you are going to use the Google
Client API in the GData server.
On 5/30/06, Simon Willnauer <[EMAIL PROTECTED]> wrote:
Nobody replies... hmm I assume that this would be ok. Mentors? Doug, Yonik, Ian?
simon
On 5/29/06, Simon Willnauer <[EMAIL PROTECTED]>
On May 30, 2006, at 11:45 AM, DM Smith wrote:
By stating that I needed to run on Mac OS 9, this also implies that
I need to run on OSX prior to Tiger (10.4) which does not have Java
5 and according to everything that I read, won't. OSX 10.3 does not
seem like an unreasonable target platform
I think the code "cleanliness" of 1.5 and the better concurrent classes are
a huge benefit.
I know in our project we developed many similar classes, and these can no be
replaced by core JDK classes. I also find 1.5 code far easier to read and
work with.
I just don't understand why a "few' voices
What features should be encouraged? discouraged? not allowed?
For example, should annotations be used where possible? or is it purely
optional?
What about "static import"? I find that DoHicky.WHATS_IT a bit more
revealing than WHATS_IT, as it tells me its origin.
Should enhanced for loops b
Erik Hatcher wrote:
On May 30, 2006, at 11:45 AM, DM Smith wrote:
By stating that I needed to run on Mac OS 9, this also implies that I
need to run on OSX prior to Tiger (10.4) which does not have Java 5
and according to everything that I read, won't. OSX 10.3 does not
seem like an unreasonabl
See, I have to build an internal representation for an entry or a feed
inside the server. I have to build these from the incoming entries and
from the storage to send them back to the client. I also have to
provide transformation from Atom to RSS. Additionaly Atom allows
extensions like the google
Robert Engels wrote:
I think the code "cleanliness" of 1.5
Perhaps, but only if it is retro-actively applied to the entire code
base. It creates confusion when there is a blend of coding styles. Some
enhanced for loops, some old fashioned iterators; some new collections,
some old.
Some of th
: Agreed. But, I have not heard one compelling argument for the JDK 5 for
: core. (JVM certainly)
Off the top of my head...
* Generics for cleaner more type safe APIs
* Varargs for cleaner APIs
* Concurrency Libraries, in particular the new j.u.concurrent.locks package
...someone also men
The ThreadLocal is a class library change, so no it would not apply here.
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 12:51 PM
To: java-dev@lucene.apache.org
Subject: Re: Lucene and Java 1.5
: Agreed. But, I have not heard one compelli
While the technical benefits remain a bit fuzzy (for me), there is no
reason you wouldn't be able to use them if you needed to since you say
they have an Apache license. Do their client libraries have any other
dependencies?
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene se
Robert Engels wrote:
I just don't understand why a "few' voices can hold back progress. These
"few" can just run older versions of Lucene. 1.5 has been released for
almost 4 years on most major platforms. Not using 1.5 for such a high
profile project is absurd.
The fact that this has generated
On Tuesday 23 May 2006 20:05, Chris Hostetter wrote:
>
> : I'll repeat the DocIterator from that thread:
> :
> : public interface DocIterator {
> : public int doc();
> : public boolean next();
> : public boolean skipTo(int target);
> : }
> :
> : to come to my q
Chris Hostetter wrote:
: Agreed. But, I have not heard one compelling argument for the JDK 5 for
: core. (JVM certainly)
Off the top of my head...
* Generics for cleaner more type safe APIs
* Varargs for cleaner APIs
* Concurrency Libraries, in particular the new j.u.concurrent.locks pack
No the client lib has no dependency. Using this api will make 5 jars I
wanted to use obsolet.
I don't need any XML Api anymore. working with the feed (parsing and
generating) will be done by the client library. I already started to
use it and it fits in perfectly. I will upload a new patch today o
Doug Cutting wrote on 05/30/2006 08:51 AM:
> Chris Hostetter wrote:
>> : Agreed. But, I have not heard one compelling argument for the JDK 5
>> for
>> : core. (JVM certainly)
>>
>> Off the top of my head...
>>
>> * Generics for cleaner more type safe APIs
>> * Varargs for cleaner APIs
>> * C
: Since we don't know the timeframe of these releases, it's hard to be
: sure what this really means. The rubber will really only hit the road
: when we schedule a 2.1 release. In effect, this punts the issue to 2.1
: release planning, which is fine by me.
I don't follow .. won't the rubber wil
Chuck Williams wrote:
I still don't understand why environments that are years behind in java
and most other apps should expect to be on the latest and greatest lucene.
Yes, it is clear to me that you don't. The key thing is these people
are fellow members of the Lucene community and we shoul
Chris Hostetter wrote:
I don't follow .. won't the rubber will hit the road the first time a
committer debates committing a patch to the trunk of the core that
requires 1.5 language features? ... that could be tomorow.
Indeed. Tomorrow is another day.
Is there anyway to keyword tag issues i
Simon Willnauer wrote:
I think it's quiet a good idea to reuse the data model of the client
lib on the server.
+1
If the license is compatible, and it is, there's no reason we should
re-invent this.
Doug
-
To unsubscribe,
Doug Cutting wrote:
Chuck Williams wrote:
I still don't understand why environments that are years behind in java
and most other apps should expect to be on the latest and greatest
lucene.
Yes, it is clear to me that you don't. The key thing is these people
are fellow members of the Lucene
For reference, it appears that Ant encourages Java *1.2* compatibility.
Tomcat 5.5 does not yet support Java 1.5 language features in jsp
pages, but is now using Java 1.5 features internally. Jakarta Commons
Logging's current release is still compatible with Java 1.2. From what
I can tell, J
Using Gdata client libs in the server for XML->Java object sounds good. It
looks like they use Java 5's XML parser, so you don't need external XML parsers.
Otis
- Original Message
From: Simon Willnauer <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, May 30, 2006 3:07:
1.5 has built in Logging support - eliminating the need for Jakarta logging.
That is like saying Jarkarta Collections does not use JDK 1.5. No one that
develops NEW software uses Jakarta Collections - they use the Collections
support in the JDK.
-Original Message-
From: Doug Cutting [ma
Right, they use the build in SAX parser which offers quiet a good
performance as well. I agree with you that it is quiet a good idea not
to reinvent the whole abstraction.
simon
On 5/30/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Using Gdata client libs in the server for XML->Java object so
Huh... hadn't realized that the client libraries also do XML parsing
(but I guess they need to do a certain amount to parse responses from
the server). Lucky for you!
Will you need to add some more parsing code to handle client-to-server
requests, or do the client libs even handle that?
On 5/30
HA! :) :) It does!!
In a great way. you just say feed.generateAtom(writer) /
generateRss(writer) and there you go!
Sounds great doesn't it?!
simon
On 5/30/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
Huh... hadn't realized that the client libraries also do XML parsing
(but I guess they need to d
Robert Engels wrote:
1.5 has built in Logging support - eliminating the need for Jakarta logging.
Logging was first added in Java 1.4.
That is like saying Jarkarta Collections does not use JDK 1.5. No one that
develops NEW software uses Jakarta Collections - they use the Collections
support i
Besides what has already been covered:
Lucene Query and Filter objects are marked as Serializable so a remote
client can serialize a request to a server which then rewrites and
executes the request. This allows for a Webstart or applet-based
architecture where the client can construct and send
Hello All,
I am new to Java Lucene Api. I am writing a heavy test for lucene java
api. The test is to write text data to disk and also create a lucene
index for it. Everytime, I write index file, I do the following:
org.apache.lucene.index.IndexWriter writer = new
org.apache.lucene.index.IndexW
Doug Cutting wrote on 05/30/2006 10:29 AM:
> Tomcat 5.5 does not yet support Java 1.5 language features in jsp pages,
This is not true -- I use them all the time. 1.5 features are not
supported by default, but can be enabled easily by adding this to your
jsp servlet:
compiler
Chuck Williams wrote:
Storing content in a Lucene index is a common approach and works well.
I agree that this is the best approach to use initially.
You might also make the API for storing entries pluggable. This is hard
to do well when you only have a single implementation, so at first you
Hello,
I'm trying to write a MultiSearcher/ParallelMultiSearcher variation that uses
JMS to talk to its subordinate Searchers. While running through MultiSearcher
to see where I can save some cycles or network hops, I came across
Query.combine(). It's called from MultiSearcher.rewrite() (as you
LinkedHashMap for LRUs, StringBuilder...
- Original Message
From: Chris Hostetter <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Tuesday, 30 May, 2006 7:51:23 PM
Subject: Re: Lucene and Java 1.5
: Agreed. But, I have not heard one compelling argument for the JDK 5 for
: core.
eks dev wrote:
LinkedHashMap for LRUs, StringBuilder...
LinkedHashMap is a Java 1.4 feature. StringBuilder is indeed 1.5.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Log4j can be configured to use delegate to the standard 1.5 logging. In fact
this is preferred so you have STANDARDIZED logging support (and not a
different logger for every library).
All NEW code should use the 1.5 logging for simplicity of configuration and
for future ease of integration.
On 31/05/2006, at 7:45 AM, Robert Engels wrote:
Log4j can be configured to use delegate to the standard 1.5
logging. In fact
this is preferred so you have STANDARDIZED logging support (and not a
different logger for every library).
All NEW code should use the 1.5 logging for simplicity of
If I understand what you are saying, unfortunately it will not work.
The issue is that rewrite() needs to access the index. E.g., a* or [a
TO d] rewrite to disjunctions of all terms that exist in the index that
match, respectively, the prefix or range. To determine this set of
terms it is necess
Well, the point is that commons-logging is not a Logging-API. It is
rather an abstraction layer on top of several Logging-API's like the
1.5 logging and Log4j. I would always go for an abstraction layer than
for some delegate mechanism between implementations.
Simon
On 5/30/06, Robert Engels <[E
Java's logging is an API, not an implementation, and allows nearly unlimited
control.
-Original Message-
From: Paul Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 4:52 PM
To: java-dev@lucene.apache.org
Subject: Re: Lucene and Java 1.5
On 31/05/2006, at 7:45 AM, Robert Engel
Oh, yeah -- wildcard and range queries. That's an even better reason for this
method than the one I guessed (and the hunt for an optimization that nobody has
thought of continues on...) If I understand correctly, I can still do the
combine() once on the JMS MultiSearcher if the query doesn't con
Joe R wrote on 05/30/2006 12:37 PM:
> If I understand correctly, I can still do the
> combine() once on the JMS MultiSearcher if the query doesn't contain any
> wildcard or range terms.
>
>
In general, you cannot rely on this. Any app may define any subtype of
Query and give it a rewrite() met
54 matches
Mail list logo
