lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <geo...@aroush.net>
Subject RE: Lucene.Net project involvement
Date Thu, 29 Mar 2007 00:46:59 GMT
Those obsolete warnings are because the current release is .NET 1.1 based.
With Lucene.Net 2.1, they will be taken care off once we are on .NET 2.0.
The other warnings, we can address them once we get the port working and
have free cycles to do clean up.

-- George Aroush 

-----Original Message-----
From: Michael Mitiaguin [mailto:mitiaguinm@optusnet.com.au] 
Sent: Wednesday, March 28, 2007 12:35 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: Lucene.Net project involvement

George ,

As for warnings about obsolete and deprecate (see below).  Perhaps JLCA may
be targeted at Net2 ( I don't know ) and they will go away.

Warning    3    'System.Threading.Thread.Resume()' is obsolete: 
'Thread.Resume has been deprecated.  Please use other classes in
System.Threading, such as Monitor, Mutex, Event, and Semaphore, to
synchronize Threads or protect resources.  
http://go.microsoft.com/fwlink/?linkid=14202'    
C:\tariffwise\Lucene\Lucene.Net\SupportClass.cs    218    13    
Lucene.Net-2.0.0
Warning    4    'System.Threading.Thread.Suspend()' is obsolete: 
'Thread.Suspend has been deprecated.  Please use other classes in
System.Threading, such as Monitor, Mutex, Event, and Semaphore, to
synchronize Threads or protect resources.  
http://go.microsoft.com/fwlink/?linkid=14202'    
C:\tariffwise\Lucene\Lucene.Net\SupportClass.cs    251    13    
Lucene.Net-2.0.0
Warning    5    'System.Configuration.ConfigurationSettings.AppSettings' 
is obsolete: 'This method is obsolete, it has been replaced by 
System.Configuration!System.Configuration.ConfigurationManager.AppSettings'

C:\tariffwise\Lucene\Lucene.Net\SupportClass.cs    619    38    
Lucene.Net-2.0.0

Warning    66    
'System.Runtime.Remoting.RemotingConfiguration.Configure(string)' is
obsolete: 'Use
System.Runtime.Remoting.RemotingConfiguration.Configure(string fileName, 
bool ensureSecurity) instead.'    
C:\tariffwise\Lucene\Lucene.Net\Search\RemoteSearchable.cs    100    
4    Lucene.Net-2.0.0
Warning    67    
'System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel(System.Run
time.Remoting.Channels.IChannel)' 
is obsolete: 'Use
System.Runtime.Remoting.ChannelServices.RegisterChannel(IChannel chnl, 
bool ensureSecurity) instead.'    
C:\tariffwise\Lucene\Lucene.Net\Search\RemoteSearchable.cs    101    
4    Lucene.Net-2.0.0


As for this group of warnings  probaly nothing can be done as they are
output of JavaCC .

Warning    14    The variable 'nextStates' is declared but never used    
C:\tariffwise\Lucene\Lucene.Net\QueryParser\QueryParserTokenManager.cs    
630    10    Lucene.Net-2.0.0
...
Warning    71    The private field 
'Lucene.Net.QueryParsers.QueryParser.jj_semLA' is never used    
C:\tariffwise\Lucene\Lucene.Net\QueryParser\QueryParser.cs    1319    
16    Lucene.Net-2.0.0

Regards,
Michael

George Aroush wrote:

>Hi Michael, Ciaran and all,
>
>Ciaran: welcome aboard to the mailing list and I am glad to see your 
>email generated some interest; I welcome any help you or anyone can 
>offer working on Lucene.Net.
>
>My goal of Lucene.Net are to meet the followings:
>1) Index is cross compatible with Java's Lucene such that you can 
>read/write to the same index concurrently using C# of Java Lucene.
>2) The APIs are consistent between C# and Java Lucene.  This is why I 
>use "GetXYZ()" instead of C# prosperities.
>
>Up to release 2.0, I kept Lucene.Net on .NET 1.1 because I wanted to 
>support more .NET installation as possible.  With Lucene.Net 2.1 
>release it's time to move to .NET 2.0 -- I don't think anyone has any 
>objection to this, but Mono may have some issues.
>
>As for the code clean up, this maybe difficult and it depends on what 
>clean up you mean.  Take a look at open JIRA issues against Lucene.Net 
>and you will see few about over using "throw".  Those, unfortunately, we
can't fix.
>Why?  Because those "throw" are also present in Java Lucene and trying 
>to 'fix' them in Lucene.Net may in effect alter the behavior of Lucene.Net.
>This said, any extra code or "throw" introduced into Lucene.Net due to 
>conversion mistakes should be fixed.
>
>As for the warnings, I don't have direct experience looking at them 
>using VS.NET 2005 (I still use VS.NET 2003)  But in VS.NET 2003, most 
>of those warnings are from comments -- i.e.: the class and API XML 
>documentation that don't get converted correctly from Java to C#.  If 
>you can think of a tool to clean them up, please let me know.  If it's 
>something else you are talking about, please let me know.
>
>Finally, making the Lucene.Net code more compliant to .NET / C# 
>standard would be, in my opinion, a nice thing to have.  But before we 
>can do so, we must get the port working and keep in mind my goal #2 above.
>
>Lets discuss this topic further.  Next week, I expect to release an 
>early release of Lucene.Net 2.1.  If folks can help to finish off the 
>conversion, then we can get this out much sooner then previous release.
>
>Regards,
>
>-- George Aroush
>
>
>-----Original Message-----
>From: Michael Mitiaguin [mailto:mitiaguinm@optusnet.com.au]
>Sent: Tuesday, March 27, 2007 9:19 PM
>To: lucene-net-dev@incubator.apache.org
>Subject: Re: Lucene.Net project involvement
>
>Ciaran,
>
>What I can't understand if core of synchronising versions with Java 
>Lucene is   Java Language Conversion Assistant, how all this cleaning 
>up/revising  is going to work.
>Would it be  possible to build automated procedure which preserve all 
>.Net improvements after conversion from major upgrade from Java ?  I  
>am not sure.
>Even if to track somehow  only changed/added Java classes still for 
>each such class merging new/revised Java  functionality with previous 
>manual changes to utilise  .Net capabalities is required.
>You used term component , but Lucene is rather API with fine grained 
>classes and a simple change may propagate into  several  classes  ( 
>files  in  Java
>) .
>I don't know how George is coping with that and what would be the plan 
>if say tomorrow Lucene Java 3 will be realeased.
>
>Michael
>
>Ciaran Roarty wrote:
>
>  
>
>>Michael
>>
>>I've been in touch with George about getting involved and he said to 
>>post to the mailing list.
>>
>>I reckon there's a fair amount of work could be done in changing the 
>>codebase without affecting the published interface and I reckon that's 
>>where the bulk of the initial work would take place; as we know, the 
>>code is not yet optimised for .NET.
>>
>>Now, balanced against that, in my opinion are the following factors:
>>
>>- The code currently compiles against 1.1 and 2.0 (albeit with some 
>>obsolence); any change to move Lucene.Net to 2.0 would leave the 
>>1.1codebase behind.
>>- There are different types of contribution to the codebase: cleaning 
>>up code; revising methods and classes to benefit .NET standards and 
>>capabilities is a good thing. However, Lucene is a powerful IR 
>>component and if the core development of those capabilities happens in 
>>the Java version then we will need to follow that.
>>
>>That's my thoughts for the moment. Maybe we could take a specific part 
>>of the component and revise that. Learning lessons about the process 
>>and the codebase from that exercise, we can move into the guts of the 
>>component......
>>
>>Any thoughts?
>>
>>Ciaran
>>
>>On 27/03/07, Michael Mitiaguin <mitiaguinm@optusnet.com.au> wrote:
>>
>>    
>>
>>>Ciaran,
>>>
>>>The only active contributor to the project is George Aroush and 
>>>perhaps he is the only person who will give you the most definite answer.
>>>I am also interested only in  Net2/3 codebase . Currently vesion 
>>>2.0.4 still uses VS 2003 projects and my main concern are warning 
>>>messages about deprecated and obsolete methods when compiled under Net2.
>>>Supposedly it 'll be fixed in 2.1
>>>Also Java Lucene is more mature project with a lot of people involved 
>>>and it would be safer to crosstranslate new things from there taking 
>>>into consideration  .Net specifics.
>>>>From other hand in my case if Lucene will be part of a  project where 
>>>all warning messages considered to be the errors which must be 
>>>eliminated , it it beyond my competency what can be done to achieve 
>>>that. ( JavaCC generated code crosstranslation creates a lot of them 
>>>)
>>>
>>>Michael
>>>
>>>Ciaran Roarty wrote:
>>>
>>>      
>>>
>>>>Anthony
>>>>
>>>>I too have used Lucene.Net with C# 2.0 to great effect. However, I 
>>>>am discussing the use of .Net 2.0 in the codebase itself; and, if 
>>>>not,
>>>>        
>>>>
>>>the
>>>      
>>>
>>>>optimisation of the codebase for .Net in general.
>>>>
>>>>Ciaran
>>>>
>>>>
>>>>On 26/03/07, tony njedeh <njedeh@yahoo.com> wrote:
>>>>
>>>>        
>>>>
>>>>>I set up my lucene to a .net 2.0 framework, using VB and it works 
>>>>>well in that environment.
>>>>>
>>>>>Anthony
>>>>>
>>>>>Ciaran Roarty <ciaran.roarty@gmail.com> wrote:
>>>>>George et al
>>>>>
>>>>>I have been using Lucene.Net in a proof-of-concept environment for
>>>>>          
>>>>>
>>>the
>>>      
>>>
>>>>>last
>>>>>couple of months - with my colleague Guy Steel - and we wanted to 
>>>>>get involved in its development.
>>>>>
>>>>>I am a .NET developer for a large consultancy company and would
>>>>>          
>>>>>
>>>like to
>>>      
>>>
>>>>>get
>>>>>involved in making Lucene.Net more aligned to .NET and .NET 2/3 in 
>>>>>particular. However, I am not sure if that is something which is 
>>>>>initially planned for Lucene.Net. As I understand it, the majority 
>>>>>of the conversion has been done, initially, using the Java Language 
>>>>>Conversion
>>>>>          
>>>>>
>>>Assistant.
>>>      
>>>
>>>>>Some
>>>>>of the Java codebase uses patterns that are not best practice for
>>>>>          
>>>>>
>>>.NET
>>>-
>>>      
>>>
>>>>>such as using Exceptions for non-exceptional circumstances. This is 
>>>>>not to denigrate Lucene.Net, it is one of the best pieces of 
>>>>>software I have used.
>>>>>
>>>>>So, this email should be considered an introduction and a request
>>>>>          
>>>>>
>>>to be
>>>      
>>>
>>>>>allowed to get involved. I have never worked on an Open Source
>>>>>          
>>>>>
>>>project
>>>      
>>>
>>>>>before so I'll need some guidance but I am willing to learn. I do
>>>>>          
>>>>>
>>>have
>>>a
>>>      
>>>
>>>>>couple of questions to start with:
>>>>>
>>>>>- Is there a roadmap for the product? Is there a roadmap for Lucene
>>>>>          
>>>>>
>>>that
>>>      
>>>
>>>>>we
>>>>>will try and follow?
>>>>>- Is there a preferred version of the .NET Framework that it is 
>>>>>planned to support?
>>>>>
>>>>>Enough for now, just wanted to introduce myself and get involved.
>>>>>
>>>>>Cheers,
>>>>>Ciaran
>>>>>
>>>>>
>>>>>          
>>>>>
>>>      
>>>
>
>
>  
>


Mime
View raw message