Plan of action

[Hakeem]

So folks, what is our plan of action on getting started. Are we
considering Lucene.NET as our - I don't know whats the word here
(source base?) - and then embark on .Netification or we start this
from scratch as if Lucene.NET didnt even exist. If its the latter then
I guess we need to start defining what we are trying to accomplish and
plan for incremental releases

I thought I read Troy Howard or someone comment somewhere that the
goal of this project is not .NETifying Lucene.NET in its current form

Thanks!
Hakeem

[Sergey Mirvoda]

I think we need to "upgrade" Lucene.Net.
Replace all static class with enums.
Change method casing, introduuce properties instead of mutators,
intruduce delegates where appropriate.
Because now Lucene.NET is not a .net project it is a port of java
project with all java good or bad traditions.
But I think we should be as close to Lucene API as possible, to reuse
Lucene Documents, Test cases etc.

As for me the first step is to extract all public API from
Lucene(.NET) via reflection and start conversion.
After that we need to resurrect test cases (integration and feature)
etc.

[Troy Howard]

All,

I spent some time working with the code this weekend and I have come
to a few conclusions. I apologize upfront that I'm going to be
contradicting things I said just a few days ago regarding which
version of Lucene to work from, how to do it and the .NET framework.
That said, I think the following plan will be the most effective way
to move forward and keep a reasonable schedule.

I spent a few hours this weekend working on porting 3.0.2 a little
just to see how difficult this would be. Honestly, it's fairly
straightforward when working directly from the Java code.

I tried converting using three different methods and found that in all
cases, each method actually required more work than just copying and
pasting the Java code into my C# editor and cleaning it up manually.
The two languages are so similar, it seems to be to be much easier to
do by hand... Specifically, the converters tend to miss the meaning of
the code and create a seemingly functional conversion, which is
confused, convoluted, and often doesn't actually work as expected.
Converting manually seems to be a more reliable and simpler process.
The only limiting issue is the quantity of code to convert.

Having the existing Lucene.Net code as a reference was helpful. There
were a few instances where the conversion from Java to .NET was not
completely obvious. In those cases, I referenced the existing
Lucene.Net code and was able to either reuse or upgrade that code to
work.

That said, we have a lot of people on the commit list for the project
(9 people not including myself). It seems like with 10 developers
working together, this wouldn't take very long at all.

Regarding the .NET framework version to target, I think we should
focus on 3.5 SP1 for the initial release. The primary reason for that
is that 4.0 is not installed by default anywhere, so any use of the
library would require an end user to install 4.0 as well. This creates
an additional dependency. There are many things 4.0 provides that
could be useful but nothing so essential as to outweigh the cost of
requiring the additional dependency.

Nonetheless, the useful things could be great and planning for the
future is always a good idea... So, I think having two versions of the
code, one targeted at 3.5 and one targeted at 4.0 would be completely
reasonable. This is an approach that many projects take, and I think
it's a wise way to deal with the platform question. I think this
should be done as part of our second phase of implementation
(description of phases follows).

So, with those opinions set in place, here's the proposed workflow/roadmap:

The project will have two phases, one which is closely adherent to the
Java API and structure and a later one which diverges more
significantly. For each phase, for each stage, we will complete each
layer until all layers and stages are complete.

When I refer to "working in layers" the layers are:
- Layer 1 - Disk Access (Directory, File, Lock, etc..)
- Layer 2 - Streamable Read and Write ( Various readers/writers )
- Layer 3 - Persistable Domain Objects (Document, Field, Term, etc)
- Layer 4 - Logical Domain Objects (Querys, Scorers, Searchers, Analyzers, etc)

Phase One - 3.0.2 Implementation:

The primary goal of this phase is just to get a working build of 3.0.2
in .NET. This will be done by hand, and we will do basic conversions
to ".NETify" the API during this process, in a minimal manner.
getXX/setXX accessors converted to properties, enums used, case
updated, etc.

Stage One - Contracts and Tests:

Each layer will need to be worked on in series:
- Starting with the 3.0.2 Java code base, read the Java code and
create the appropriate .NET interfaces, enums, etc.
- Update existing test cases to use the new interfaces and to use
MbUnit framework
- Create new unit tests where needed (see Java code for new ones for
3.0.2, or just create them if you notice they are lacking coverage)

Stage Two - Implementation:

Each layer can be worked on in parallel:
Since there is a complete abstraction or all layers, we can work in
parallel to implement the interfaces and prove the unit tests. By
creating the interfaces first, we do not need to wait until a
dependency layer is implemented, merely use it's interface and assume
it will be implemented in the future. Create mocks where needed to
prove unit tests for the part you are working on.

This stage of implementation will mirror existing 3.0.2 code's API and
internal structure. We will create a functioning 3.0.2 compatible
build which passes all tests. This can be compared to the existing
Java 3.0.2 release for performance and when Lucene.Net 3.0.2 is
released we can further compare against that library.

Phase Two - Refactoring and Reimplementation:

During this phase, we will redesign the API, integrating whatever
awesome new ideas we have for the library, possibly changing how it
works internally, possibly keeping it the same. This design will be
the result of community input and discussion. The work in this phase
will follow the same pattern as the previous phase, in which we work
through the layers in order in Stage One to redefine the interfaces
and update the tests, and in Stage Two, we update those changes in the
implementation.

Roadmap and Schedule

It's my hope that we can complete the first phase quickly (four
weeks). This would mean that we'd be ready to start phase two by
mid-Decemeber. It also means, that if, for some reason, Lucene.Net is
unable to complete their 3.0.2 port by that time, we can give them
ours and prevent any ASF status problems. This would ultimately be a
compromise for Lucene.Net as the API wouldn't be line-by-line due to
our minor .NET style refactoring in phase one. Since this refactoring
would be minor, it may be an acceptable level of deviation for the
Lucene.Net project.

Assuming Lucene.Net does complete their port on schedule, then it
means that as soon as we finish our build, we will have a functioning
version of 3.0.2 from them to benchmark our build against.

So the roadmap, milestones and schedule, starting today, would be as follows:

Phase One - 3.0.2 Implementation: (11/15 - 12/12, four weeks)
- Stage One - Contracts and Tests: (11/15 - 11/28, two weeks)
-- Layer 1 & 2 (11/15 - 11/21)
-- Layer 2 & 3 (11/22 - 11/28)
- Stage Two - Implementation: (11/29- 12/12, two weeks)
-- All Layers in Parallel (no specific milestone dates within this stage)

Phase Two - Refactoring and Reimplementation: (12/13 - 1/2/2011, three weeks)

Initial Release: 1/3/2011

I realize that this schedule is aggressive in general and specifically
unlikely to be met in a timely fashion due to the holidays (in the US,
we have Thanksgiving on 11/25, then Christmas 12/25, then New Years
1/1)... This will likely delay our schedule somewhat and may mean that
we don't start the second phase until much later.

Either way I'd like to try to complete the first phase before the new year.

I realize this plan involves a number of compromises but I believe it
to be a reasonable set of compromises and a reasonable schedule which
we can commit to and release on time.

I'll get this put in the issue tracker creating tasks for each part of
the process and scheduling them. Could someone please write this
roadmap and schedule up and put it in the wiki? I'm thinking Kyle, as
he said he'd be most helpful initially doing documentation and tests.

Thanks,
Troy

> --
> You received this message because you are subscribed to the Google Groups "Lucere Development" group.
> To post to this group, send email to lucer...@googlegroups.com.
> To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.
>
>

[Troy Howard]

Apologies, I just realized that I listed the layers out of order.

Layers 2/3 should be swapped, as the streamable read/write layer
depends on the existence of the persistable objects.

Correct layers are:

- Layer 1 - Disk Access (Directory, File, Lock, etc..)

- Layer 2 - Persistable Domain Objects (Document, Field, Term, etc)
- Layer 3 - Streamable Read and Write ( Various readers/writers )

- Layer 4 - Logical Domain Objects (Querys, Scorers, Searchers, Analyzers, etc)

Thanks,
Troy

[Ciaran Roarty]

Troy

I am happy to follow that roadmap.

Ciaran

[Ciaran Roarty]

I also like the aggressive timescales but think we'll struggle. I have
no mercurial experience, for example.

C

On 15 Nov 2010, at 01:19, Troy Howard <thow...@gmail.com> wrote:

[Mark Perry]

Would like to start taking a crack at the C# port tonight if that's
not too short notice.

Is the "lucene-3.0.2-src.zip" source the correct version to use from
the following URL?
http://mirror.ox.ac.uk/sites/rsync.apache.org//lucene/java/

Just a few questions as I haven't worked in an open source team before:

- How do we ensure that we do not duplicate "work being done"?
- For a mercurial newbie what's the process we are using?
-- Do we commit up to the CodePlex repo?
-- Do we commit locally and issue patches?

Any pointers would be great.

Thanks, Mark

[Sergey Mirvoda]

Roadmap is fine to me.

Can start right now.

--
--Regards, Sergey Mirvoda

[Troy Howard]

Mark,

Excellent questions.

"Is the "lucene-3.0.2-src.zip" source the correct version to use from
the following URL?
http://mirror.ox.ac.uk/sites/rsync.apache.org//lucene/java/"

Yes. That's the correct source set.

If you'd like to get started today, here are a few initial guidelines:

- The lucere.definition project is intended to hold the interfaces,
enums, exceptions and constants and nothing else
- The first area to start defining interfaces for is the Disk I/O
Layer, which for all intents and purposes is entirely contained in in
the Lucene.Store namespace.

Naming and Namespace notes:
- Interfaces should be prefixed by an uppercase "I" but otherwise
match the implementation type name
- Enums should not use plural form (in fact never use plural form for
anything other than collections)
- Exceptions should be placed in their own namespace not the namespace
of the classes/scope they are related to (ie:
lucere.exception.DirectoryNotFoundException NOT
lucere.io.DirectoryNotFoundException)
- Tests go in the lucere.test project.
- Test case class names should match the associated class, but be
suffixed by "Test" and the namespace should also be suffixed with
".test": Example: (in lucere.definition project) lucere.io.IDirectory
-> (in test project) lucere.io.test.IDirectoryTest
- Mocks should follow a similar convention, and should live in the
lucere.test project: Example: (in lucere.definition project)
lucere.io.IDirectory -> (in test project)
lucere.io.mock.IDirectoryMock
- Namespaces should be lower case, but
classes/interfaces/methods/properties/etc should be PascalCase
- Camel case for parameters and private fields. Private fields should
be prefixed with a underscore.
- We're only working on interfaces here, but for implementations,
unless ther'es a very good reason all concrete classes should be
public, not sealed, and have a empty constructor. We don't need to
protect people from themselves...

I've laid out some of the classes to the namespaces I'd like them to
be (I'll complete this list tomorrow). Please place the
classes/interfaces in the following namespaces:

Disk Layer

lucere.io
- Directory
- IndexInput
- IndexOutput
- BufferedIndexInput
- BufferedIndexOutput
- ChecksumIndexInput
- ChecksumIndexOutput
- FileSwitchDirectory
- FSDirectory
- FSLockFactory
- MMapDirectory
- NIOFSDirectory
- RAMDirectory
- RAMFile
- RAMInputStream
- RAMOutputStream
- SimpleFSDirectory

lucere.io.lock
- Lock
- LockFactory
- NoLock
- NoLockFactory
- LockStressTest
- LockVerifyServer
- NativeFSLockFactory
- SimpleFSLockFactory
- SingleInstanceLockFactory
- VerifyingLockFactory

Persistable Domain Object Layer

lucere.entity
- AbstractField
- Document
- Field
- Fieldable
- NumericField

Exceptions Layer (this is a cross cutting layer)
lucere.exception
- AlreadyClosedException
- LockObtainFailedException
- LockReleaseFailedException
- NoSuchDirectoryException

When the time comes for implementation, separate projects will need to
be made for each layer (yes this means multiple DLLs, sorry I'm anal
about this because I feel everything that can be reused as a separate
piece should be in it's own DLL to maximize code reuse).

In the end I forsee that we'll have something like this project list:

lucere.defintion - interfaces/enums/exceptions
lucere.io - Disk layer (mostly whats in Lucene.Store)
lucere.entity - domain object layer (mostly what's in Lucene.Document)
lucere.stream - reader/writer layer (mostly what's in Lucene.Index)
lucere.analysis - analyzers/queries/parsers/filters/collectors/scorers
etc (Lucene.Analysis, some of Lucene.Search)
lucere.service - searcher classes (and whatever top level APIs we
write that don't already exist for searching)
lucere.toolkit - utility classes (mostly what's in Lucene.Util)
lucere.test - test cases for everything else

With regard to non-duplication of work, in this case, it's easy --
Mark, you'll be responsible for completing everything in the
Lucene.Store namespace and no one else will do that. ;)

When I get all the rest of this broken up and put in the issue
tracker, we'll just assign segments of work there, which should
resolve any confusion.

As for Mercurial, the procedure is as follows:

- Make a local clone of the repository at https://hg01.codeplex.com/lucere
- Commit to your local repository as often as possible
- Share and merge with other developers as needed by either mailing
patches/zipped repos/using "hg serve", etc.
- When you are ready to submit your changes to the central repository,
you have three options:
- - Just do a push. If there are issues I can unravel them later.
- - If you prefer a review cycle before committing (many people do),
feel free to just zip up your local repository and if it will fit (4MB
or less), upload it as an attachment to the issue which you are
working on.
- - If the entire repo zipped gets to be too big (it will), you can
create patches... Patches in Mercurial are a bit annoying, because
they only cover a single revision, and if you are committing often to
your local repo you may have several revisions to commit at once..
This means exporting a bunch of patches, zipping up those patches and
uploading or attaching all of them together. This is a much smaller
amount of stuff to attach, but more troublesome because each patch
must be applied in order.

I prefer to keep this process somewhat informal because I don't want
to be forced to review every patch before it gets committed. I want
you to feel confident enough about your code that you can simply
commit and feel good about it. Peer review will happen anyway, since
this is open source and since we'll all be working on the same code
base at the same time... So it's just a matter of whether you prefer
to let the peer review happen before or after a commit. Either way, if
there's something problematic, I can fix it, or ask you to fix it, and
keep it in a branch until issues are resolved then merge into tip
later.

Many people are scared to perform merges, for good reasons. Merging
can be confusing and it's hard to know how to correctly merge if
you're unfamiliar with what someone else's code was intended to be and
yours happens to unexpectedly conflict with it. I'm not afraid of
merging and will gladly do it for you if your commit requires it and
you don't want to do it, just ask.

Also, if you're working on a project with another developer, feel free
to share code privately via email exchanges, ftp, setting up a web
server with "hg serve", or what have you... Merge and commit against
each other's local repos until you're ready to push to the primary
branch. This can be a great way for two or three developers to work
together, sharing code and changesets without interacting with the
trunk in the central repo until they are finished.

For example... As I'm typing this I got the email from Sergey, saying
he would like to start tonight as well. I think a good division of
work would be to have Mark get started on the interfaces for the disk
layer and Sergey to work on the unit tests. You two can share your
local repositories with one another until your work is correctly
integrated and ready for commit to the central repo.

DVCS can be a bit confusing and chaotic at first compared to CVS/SVN
but in the end it ends up being very flexible for this kind of working
scenario.

Feel free to ask stupid questions unashamedly. We should all be
learning all the time and never be afraid to ask for knowledge from
our peers.

I probably left a lot out so fire away if there are unresolved questions.

Thanks,
Troy

[Ciaran Roarty]

Troy

 

A comprehensive post to move us forward. Really happy to see some traction.

 

Is there a particular Mocking framework you had in mind?

 

Ciaran

[Troy Howard]

Ciaran,

Nope... I prefer to just write mocks without a framework (mostly
because I don't like adding any more dependencies than necessary).

Feel free to use any framework you'd like if you think it will benefit
the unit tests. I've used Rhino Mocks in the past with great success
(BTW: Thanks Ayende, if you're still paying attention!).

Thanks,
Troy

[Hakeem Mohammed]

Excellent starting point Troy et al. I think we are rolling ;)

I'd like to get a few items clarified in the guidelines Troy posted above and add some suggestions

Do we want the namespaces in lowercase for compatibility reasons with Lucene? Since VS follows the convention of having Project\folder names for namespaces, I'd rather that we go by convention and keep the Pascal casing but if there is a compelling reason not to follow it, that's OK too

I too haven't use mercurial before. have had too much of the Git kool-aid ;) So I was wondering if we can have Git as our SCS instead. One advantage I could think of with Git is that we could configure TeamCity and have continuous integration and nightly builds. Maybe this could be done from Mercurial too. I don't know

As for mocking, Moq is an excellent framework as well. In addition, I'd recommend the following frameworks for various other tasks

StructureMap for DI\IOC. It has a very fluent API and all configuration is in code
log4net for all logging related activity
Memcached for caching (though I'm not sure if that is being done in Lucene)

Thanks!

On Mon, Nov 15, 2010 at 6:19 AM, Troy Howard <thow...@gmail.com> wrote:

[Ciaran Roarty]

Codeplex supports Mercurial or TFS so I think we need to stick with Mercurial.

[Gaurave Sehgal]

Great just checked stack of lucere group emails today morning and its really exciting that we are starting this soon. 

I have a suggestion for coding conventions mentioned here. I don't know if any of you have used Resharper tool. I have been using it for my official project and it is an awesome tool. All conventions we are talking about it takes care of them and also suggests code optimizations etc etc. The good news is that tool is FREE for an open source project. I think the project coordinator has to just apply for a license from Jetbrain's website. 

If we all use the same tool it will make sure that all of us are using the same conventions.

Thanks

Gaurave

[Ciaran Roarty]

+1 for Moq

On 15 November 2010 13:35, Hakeem Mohammed <hakee...@gmail.com> wrote:

[Hakeem Mohammed]

R# is an awesome tool and I'm hooked on it too. But, its something that we use to get to our goal and will not be part of the final product. So it would be up to each contributor to decide which tool he/she wants. I know some people use CodeRush

:d

[Sergey Mirvoda]

just for clarification

why lowercasing namespaces?

All .NET projects and BCL use pascal cased namespaces.

PS

tabs or spaces?

Regards,

Sergey

--Regards, Sergey Mirvoda

[Sergey Mirvoda]

FYI

just started with tests.

--
--Regards, Sergey Mirvoda

[Troy Howard]

Resharper - This is a great idea, but the project must have been
active for at least 3 months to apply for this. I will definitely
apply at that time.

Moq - This looks cool. I haven't used it before. Would love to see it in action.

StructureMap/log4net - These are both excellent libraries and may be
useful in the second phase.

Memcached - I love memcached, but this is unlikely to be relevant
unless we really develop the service layer (approaching something like
SOLR).

Git vs Mercurial - Ciaran's answer is correct. Git is not supported by
Codeplex.. Only TFS/SVN or Mercurial. Git is great though.

Namespaces - Lowercase namespaces are my personal convention. They are
also the coding standard at my company (but I built that coding
standard... soo). The main reason I prefer them is that it provides
some contrast to the method names and I find it easier to read in
code. For example, if there is a nested class it's quite obvious, or
if there is a namespace element that matches a class name, it's also
obvious... Consider:

Lucere.IO.Directory <-> lucere.io.Directory
Lucere.IO.Lock.Lock <-> lucere.io.lock.Lock
Lucere.IO.Lock.Lock.LockNested <-> lucere.io.lock.Lock.LockNested

It makes it easy to see where the namespace stops and the class names
begin and prevents conflicts with the Pascal cased elements.

That said, this book (Framework Design Guidelines: Conventions,
Idioms, and Patterns for Reusable .NET Libraries,
http://amzn.to/qwtfK) says namespaces should be Pascal cased and at
one time I followed that entire book quite strictly. Maybe I've just
gotten too lazy to keep hitting [shift] all the time. ;)

Regarding sub-folders and namespaces, yes, we should use that
structure. Where a project contains more than one namespace, use
sub-folders to contain those sub-namespaces (also makes it easier
since you don't have to specify the namespace, it just makes the right
one for you automatically).

FYI: Looks like Kyle is working on the documentation and Christopher
(ccurrens) is working on the lucere.entity namespace
(Lucene.Documents)..

Thanks,
Troy

[Troy Howard]

All,

I almost forgot to mention.. If you do decide to include additional
dependencies on third-party libraries (such as Moq or the like) please
update compilation-notes.txt with the appropriate information.

Specifically these details:
- Where to download the package and what version is expected
- Where to install the package files relative to the lucere solution
files so that relative pathing will work correctly.
- Any other relevant setup details (local app.config settings, etc)

Thanks,
Troy

[Sergey Mirvoda]

Mark and I working on IO and Tests

--Regards, Sergey Mirvoda

[Hakeem Mohammed]

Excellent. So did we finalize on the version of Lucene that we wanted to use as a base 2.9.2 or 3.0.2? I know there was some discussion in another thread but didn't know what the outcome was. I had pulled the 3.0.2 version a week or so before this project was started. What I see in there is 3 different solution files having one project each. I'm working on having a single solution file with all the projects in there

Thanks!

[Hakeem Mohammed]

One more thing, I see the Target framework for the definition and test projects set to 4.0. I thought we were targeting this for 3.5

Unrelated, I find IM as an effective means for collaborating with remote groups. I know members of this group are in different time zones. I'm on US Eastern time and mostly plan to work week nights and some day hours over the weekend. If anyone is interested, my Skype Id is hsmohd

[Troy Howard]

Hi Mark/Peter,

Glad to have you both aboard.

Here's a quick run down of the current assignment break down:

- Documentation/Wiki: Kyle Jones/Prescott Nasser
- Define IO Layer interfaces: Mark Perry
- Port IO Layer unit tests: Sergey Mirvoda
- Define Entity Layer interfaces: Christopher Currens
- Port Entity Layer unit tests: Christopher Currens
- Define Streaming Layer interfaces: Troy Howard
- Port Streaming Layer unit tests: <unassigned>
- Define Service Layer interfaces: <unassigned>
- Port Service Layer unit tests: <unassigned>

Depending on where you feel the most comfortable, you could either
grab one of the unassigned tasks and get started on it, or help out
one of the other devs with their task. Chris could probably use help
with the unit tests for the Entity Layer and Mark P./Sergey could
probably hand off some of the I/O layer work as well.

Order of operations will become a bit of an issue at this stage, as
it's the very beginning... You can't write a unit test until the
interfaces have been defined and you can't define a higher layer until
the lower layer that it depends on is complete... Well that last
statement isn't true exactly.. For example, I'm working on the
streaming layer even though neither the I/O Layer or Entity Layer are
committed yet.. When ever I need to reference the one of those types,
I just stub out the interface as a empty interface in the correct
namespace/file location, with the assumption that someone will be
committing a fully defined version in the near future and it will just
merge in.

With that in mind, someone could start working with on "service" layer
interfaces at this point as well.

I haven't gotten all the details into the issue tracker yet (because I
was itching to get to the code) but I think the work that's there to
be done should be fairly straightforward. Feel free to ask for
clarification or assistance as needed.

Thanks,
Troy

On Tue, Nov 16, 2010 at 1:09 AM, harrisonm <harriso...@gmail.com> wrote:
> Hi Troy
>
> Just got the codeplex invite.
>
> Can you let me know if you have any particular part of Lucene you want
> me to work on to Lucere?
>
> Thanks, Mark H.

>
> On Nov 15, 11:19 am, Troy Howard <thowar...@gmail.com> wrote:
>> Ciaran,
>>
>> Nope... I prefer to just write mocks without a framework (mostly
>> because I don't like adding any more dependencies than necessary).
>>
>> Feel free to use any framework you'd like if you think it will benefit
>> the unit tests. I've used Rhino Mocks in the past with great success
>> (BTW: Thanks Ayende, if you're still paying attention!).
>>
>> Thanks,
>> Troy
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 15, 2010 at 3:15 AM, Ciaran Roarty <ciaran.roa...@gmail.com> wrote:
>> > Troy
>>
>> > A comprehensive post to move us forward. Really happy to see some traction.
>>
>> > Is there a particular Mocking framework you had in mind?
>>
>> > Ciaran

>> >> - Make a local clone of the repository athttps://hg01.codeplex.com/lucere

>> >> > On 15 November 2010 06:40, Ciaran Roarty <ciaran.roa...@gmail.com>

>> >> > wrote:
>> >> >> I also like the aggressive timescales but think we'll struggle. I have
>> >> >> no mercurial experience, for example.
>>
>> >> >> C
>>

>> >> >> On 15 Nov 2010, at 01:19, Troy Howard <thowar...@gmail.com> wrote:
>>
>> >> >>> Apologies, I just realized that I listed the layers out of order.
>>
>> >> >>> Layers 2/3 should be swapped, as the streamable read/write layer
>>

>> ...
>>
>> read more »
>
> --
> You received this message because you are subscribed to the Google Groups "Lucere" group.
> To post to this group, send email to luc...@googlegroups.com.
> To unsubscribe from this group, send email to lucere+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lucere?hl=en.
>
>

[Troy Howard]

Hakeem,

I went ahead and updated the project files to reflect the 3.5 framework target.

Some of the devs are using Google Talk to collaborate. We've also
discussed setting up a IRC channel for the same purpose or some
similar topic based group chat room.

That said, Ayende has a good point that IM is not always available and
it is also transient, so the group as a whole may not get the benefit
of the conversations.

I would say both are useful -- real-time collaboration via IM for
quick help and working through the details of specific issues and
following up with email/wiki docs whenever anything of significance
emerges (or anything turns up repetitively). Email and this mailing
list are always available as a backup for when IM doesn't work out.

Thanks,
Troy

[Troy Howard]

Hakeem,

Regarding the Lucene version to work from, the current methodology is
as follows:

1. Working from the Java Lucene 3.0.2 build, create interfaces in the
lucere.defintion project that match the Java classes.
2. Port the Java Lucene unit tests to .NET and have them work against
the interfaces defined in the first step.
3. Implement the classes in .NET by either porting the Java manually,
or using code from either Lucene.Net's upcoming 3.0.2 release, code
from a previous buld (where nothing has changed), aimee.net, or
Lucille... All of them represent some version of .NET code for this
purpose. Ours will be yet another variation.

This is basically working up to a 3.0.2 compatible build in lucere,
with basic .NET styling happening during that process. After that's
complete, we'll re-design and refactor.

So, to answer your question directly, we're not working from any
specific build of Lucene.Net, but rather working from the Java Lucene
3.0.2 codebase for spec and implementing using a variety of
techniques/sources.

Thanks,
Troy

[Gaurave Sehgal]

I will start on defining service layer interfaces then. Any one else
if interested in same then we can share classes.

Sent from my iPhone

> You received this message because you are subscribed to the Google Groups "Lucere Development" group.
> To post to this group, send email to lucer...@googlegroups.com.
> To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.
>

[Gaurave Sehgal]

Well looking at Troy's email on layers, if someone needs help on any lower layer first then I can help there instead of starting on Services layer?

I am trying to spend about 1 hour on all week days and may be an hour or so on week ends.

Thanks

Gaurave

[Sergey Mirvoda]

io\store is a starting point for all work.

you can help us with IO. 

e-mail Mark to get the directions.

On Tue, Nov 16, 2010 at 7:01 PM, Gaurave Sehgal <gaurave...@gmail.com> wrote:

Gaurave

--
--Regards, Sergey Mirvoda

[Sergey Mirvoda]

@All

we have an issue with naming strategy

with lucere.io.lock namespace

lock is reserverd word and now we forced to use @ everywhere

for example lucere.io.@lock 

it looks very weird and I'm not sure is it portable?

--
--Regards, Sergey Mirvoda

[Mark Perry]

I spoke with Troy already on this and you can see on the latest version of the
code it's changed to "concurrency" so lucere.io.concurrency.

I will be making the changes and committing tonight.

Mark