[prev in list] [next in list] [prev in thread] [next in thread]
List: lucene-dev
Subject: Re: Approach towards solving split package issues?
From: Tomoko Uchida <tomoko.uchida.1111 () gmail ! com>
Date: 2020-10-24 10:25:14
Message-ID: CAHpHuj=m3nyST=Fv2z+ki3zyDiAkoUQrFf9dTi=dgo3c6h9gxQ () mail ! gmail ! com
[Download RAW message or body]
Hi,
please review LUCENE-9319. This tries to resolve package name conflicts
between "sandbox" and "core" modules.
Looks like many eyeballs are needed for cleaning up our sandbox.
Tomoko
2020=E5=B9=B410=E6=9C=8818=E6=97=A5(=E6=97=A5) 0:36 Tomoko Uchida <tomoko.u=
chida.1111@gmail.com>:
> Hi,
> please review LUCENE-9318, this refactors backward-codecs module (package=
s
> are renamed).
> I'm going to merge it into the master after waiting a week or so if there
> is no objection/feedback.
>
> Tomoko
>
>
> 2020=E5=B9=B49=E6=9C=883=E6=97=A5(=E6=9C=A8) 22:35 Tomoko Uchida <tomoko.=
uchida.1111@gmail.com>:
>
>> I also opened SOLR-14826 as the placeholder. I'm not fully sure of its
>> priority but at least Alexandre expressed an interest in fixing it for
>> Solr, thanks.
>> If there is someone who wants to take the ownership, please feel free to
>> join. I will leave it there until LUCENE-9499 is done anyway.
>>
>>
>>
>> 2020=E5=B9=B49=E6=9C=883=E6=97=A5(=E6=9C=A8) 0:12 Tomoko Uchida <tomoko.=
uchida.1111@gmail.com>:
>>
>>> I opened LUCENE-9499 as the umbrella.
>>> I set "Fix version" to 9.0 - means once we make a commit on it, this
>>> will be a blocker for release 9.0.0. (I don't think the changes should =
be
>>> delivered across two major releases; all changes have to be out at once=
in
>>> a major release.) If there are any objections or concerns, please leave
>>> comments. For now I have no idea about the total volume of changes or
>>> technical obstacles that have to be handled.
>>>
>>> About Solr - do we really need to fix split packages? Solr is a server
>>> app, the benefits seem to be smaller than Lucene (a library) for me. I'=
d
>>> like to hear opinions/thoughts from others.
>>>
>>> Tomoko
>>>
>>>
>>> 2020=E5=B9=B49=E6=9C=882=E6=97=A5(=E6=B0=B4) 9:05 Gus Heck <gus.heck@gm=
ail.com>:
>>>
>>>> +1 to fixing and +1 to doing it in a major release.
>>>>
>>>> On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <jpountz@gmail.com> wrote:
>>>>
>>>>> +1 Changing packages of many classes should be done in a major.
>>>>>
>>>>> On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida <
>>>>> tomoko.uchida.1111@gmail.com> wrote:
>>>>>
>>>>>> Just to make sure, could I confirm "when the changes will be out"...
>>>>>> Resolving split package issues should break backward compatibility
>>>>>> (changing package names and moving classes from one module to anothe=
r
>>>>>> modules). So we have just two options, we can have these changes onl=
y on
>>>>>> major releases - 9.0.0 or 10.0.0; we cannot release such changes at =
minor
>>>>>> versions. Is that correct?
>>>>>>
>>>>>> Tomoko
>>>>>>
>>>>>>
>>>>>> 2020=E5=B9=B49=E6=9C=881=E6=97=A5(=E7=81=AB) 22:08 Tomoko Uchida <to=
moko.uchida.1111@gmail.com>:
>>>>>>
>>>>>>> > As I recall one issue was around where to put analysis packages?
>>>>>>>
>>>>>>> It's LUCENE-9317. I had worked on it before, you can see what
>>>>>>> changes will be needed for analyzers-common (and core).
>>>>>>>
>>>>>>>
>>>>>>> 2020=E5=B9=B49=E6=9C=881=E6=97=A5(=E7=81=AB) 22:00 Michael Sokolov =
<msokolov@gmail.com>:
>>>>>>>
>>>>>>>> I'm in favor - there may be some difficult choices though. As I
>>>>>>>> recall
>>>>>>>> one issue was around where to put analysis packages? I forget the
>>>>>>>> details, but there was some pretty strong feeling that you should
>>>>>>>> have
>>>>>>>> a functioning system with core only. However some basic analysis
>>>>>>>> tools
>>>>>>>> are required for that, while most of our analyzers and so on are i=
n
>>>>>>>> a
>>>>>>>> separate analysis module. Perhaps we will need to move some basic
>>>>>>>> analyzers out of com.amazon.lucene.analysis? Or the reverse - move
>>>>>>>> all
>>>>>>>> the analysis code into the analysis module and acknowledge that it
>>>>>>>> is
>>>>>>>> a fundamental dependency (more essential than core, really).
>>>>>>>>
>>>>>>>> On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida
>>>>>>>> <tomoko.uchida.1111@gmail.com> wrote:
>>>>>>>> >
>>>>>>>> > yes, Jigsaw was on my mind too...
>>>>>>>> >
>>>>>>>> > > why not go ahead and try to clean it up right away?
>>>>>>>> >
>>>>>>>> > > So a strong +1 to clean this up!
>>>>>>>> >
>>>>>>>> > OK, maybe I should open two issues, one for Lucene and one for
>>>>>>>> Solr, and link existing wip issues to them.
>>>>>>>> > Once we start it, these will be blockers for 9.0.0 release I
>>>>>>>> believe (for now I have no idea about the volume of the changes or
>>>>>>>> technical obstacles). Are there any objections or comments?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > 2020=E5=B9=B49=E6=9C=881=E6=97=A5(=E7=81=AB) 19:34 Uwe Schindler=
<uwe@thetaphi.de>:
>>>>>>>> >>
>>>>>>>> >> Hi,
>>>>>>>> >>
>>>>>>>> >> The biggest issue is that split packages make migrating to the
>>>>>>>> Java 9 module system impossible. It's not allowed to have same pac=
kage name
>>>>>>>> (with classes) in different JAR files.
>>>>>>>> >>
>>>>>>>> >> Some of those require to open up visibility of classes. Some
>>>>>>>> split packages issues were done because of package private access,=
which is
>>>>>>>> very bad between JAR files. This also affects the test framework, =
although
>>>>>>>> this is not such a big deal (I would exclude that for now), becaus=
e you
>>>>>>>> would never run UNIT tests inside a module system, only integratio=
n tests.
>>>>>>>> >>
>>>>>>>> >> So a strong +1 to clean this up!
>>>>>>>> >> Uwe
>>>>>>>> >>
>>>>>>>> >> -----
>>>>>>>> >> Uwe Schindler
>>>>>>>> >> Achterdiek 19, D-28357 Bremen
>>>>>>>> >> https://www.thetaphi.de
>>>>>>>> >> eMail: uwe@thetaphi.de
>>>>>>>> >>
>>>>>>>> >> > -----Original Message-----
>>>>>>>> >> > From: Dawid Weiss <dawid.weiss@gmail.com>
>>>>>>>> >> > Sent: Tuesday, September 1, 2020 9:22 AM
>>>>>>>> >> > To: Lucene Dev <dev@lucene.apache.org>
>>>>>>>> >> > Subject: Re: Approach towards solving split package issues?
>>>>>>>> >> >
>>>>>>>> >> > This is a big headache for many things. I wouldn't mind doing
>>>>>>>> this
>>>>>>>> >> > even for 9x. This is a major release, why not go ahead and tr=
y
>>>>>>>> to
>>>>>>>> >> > clean it up right away?
>>>>>>>> >> >
>>>>>>>> >> > Dawid
>>>>>>>> >> >
>>>>>>>> >> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida
>>>>>>>> >> > <tomoko.uchida.1111@gmail.com> wrote:
>>>>>>>> >> > >
>>>>>>>> >> > > Hello devs,
>>>>>>>> >> > >
>>>>>>>> >> > > we have lots of package name conflicts (shared package
>>>>>>>> names) between
>>>>>>>> >> > modules in the Lucene/Solr source tree. It is not only
>>>>>>>> annoying for devs/users
>>>>>>>> >> > but also indeed bad practice since Java 9 (according to my
>>>>>>>> understanding), and
>>>>>>>> >> > we already have some problems with Javadocs due to these
>>>>>>>> splitted packages
>>>>>>>> >> > as some of us would know. I'm curious about the issue from a
>>>>>>>> while ago. My
>>>>>>>> >> > questions are, Q1: How can we solve the issue in an organized
>>>>>>>> way? Q2: How
>>>>>>>> >> > many of us really have interests about that?
>>>>>>>> >> > >
>>>>>>>> >> > > To break down Q1,
>>>>>>>> >> > > - A JIRA for building a grand design and organizing sub
>>>>>>>> tasks is needed? We
>>>>>>>> >> > have a couple of issues (e.g. LUCENE-9317 and LUCENE-9319)
>>>>>>>> about it and I
>>>>>>>> >> > had been playing around them before; but I feel like an
>>>>>>>> umbrella ticket would
>>>>>>>> >> > be needed.
>>>>>>>> >> > > - When to start and what's the target version to be out? My
>>>>>>>> feeling is that
>>>>>>>> >> > after cutting branch_9x is the right moment to start and
>>>>>>>> 10.0.0 is suitable for
>>>>>>>> >> > the target, does this make sense?
>>>>>>>> >> > > - Are there any other tasks/concerns to be considered excep=
t
>>>>>>>> for just
>>>>>>>> >> > renaming packages?
>>>>>>>> >> > >
>>>>>>>> >> > > Regarding Q2,
>>>>>>>> >> > > I know some of us have deep knowledge and thoughts in this
>>>>>>>> topic, but for
>>>>>>>> >> > now I am not sure how many of you have the will to give help
>>>>>>>> or take time for
>>>>>>>> >> > that.
>>>>>>>> >> > > It can't be a one-man effort. The more people understand an=
d
>>>>>>>> can contribute
>>>>>>>> >> > to the build, the more healthy it will be. (I borrowed this
>>>>>>>> phrase from Gradle
>>>>>>>> >> > build issue LUCENE-9077).
>>>>>>>> >> > >
>>>>>>>> >> > > I don't intend to rush into making a decision, my purpose
>>>>>>>> here is to collect
>>>>>>>> >> > information to see if I can handle it before opening a JIRA.
>>>>>>>> >> > >
>>>>>>>> >> > > Thanks,
>>>>>>>> >> > > Tomoko
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> ------------------------------------------------------------------=
---
>>>>>>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> ------------------------------------------------------------------=
---
>>>>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>> >>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------=
---
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> --
>>>>> Adrien
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.needhamsoftware.com (work)
>>>> http://www.the111shift.com (play)
>>>>
>>>
[Attachment #3 (text/html)]
<div dir="ltr"><div>Hi,</div><div>please review LUCENE-9319. This tries to resolve \
package name conflicts between "sandbox" and "core" \
modules.</div><div>Looks like many eyeballs are needed for cleaning up our \
sandbox.<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature">Tomoko</div></div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年10月18日(日) 0:36 \
Tomoko Uchida <<a \
href="mailto:tomoko.uchida.1111@gmail.com">tomoko.uchida.1111@gmail.com</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div>please review \
LUCENE-9318, this refactors backward-codecs module (packages are \
renamed).<br></div><div>I'm going to merge it into the master after waiting a \
week or so if there is no objection/feedback.<br></div><div><br></div><div><div><div \
dir="ltr">Tomoko</div></div><br></div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">2020年9月3日(木) 22:35 Tomoko Uchida <<a \
href="mailto:tomoko.uchida.1111@gmail.com" \
target="_blank">tomoko.uchida.1111@gmail.com</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I also opened SOLR-14826 as \
the placeholder. I'm not fully sure of its priority but at least Alexandre \
expressed an interest in fixing it for Solr, thanks.<br></div><div>If there is \
someone who wants to take the ownership, please feel free to join. I will leave it \
there until LUCENE-9499 is done \
anyway.<br></div><div><br></div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年9月3日(木) 0:12 \
Tomoko Uchida <<a href="mailto:tomoko.uchida.1111@gmail.com" \
target="_blank">tomoko.uchida.1111@gmail.com</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I opened LUCENE-9499 as the \
umbrella.</div><div>I set "Fix version" to 9.0 - means once we make a \
commit on it, this will be a blocker for release 9.0.0. (I don't think the \
changes should be delivered across two major releases; all changes have to be out at \
once in a major release.) If there are any objections or concerns, please
leave comments. For now I have no idea about the total volume of changes
or technical obstacles that have to be handled.</div><div><br></div><div>About Solr \
- do we really need to fix split packages? Solr is a server app, the benefits seem to \
be smaller than Lucene (a library) for me. I'd like to hear opinions/thoughts \
from others.<br></div><div><br></div><div><div><div \
dir="ltr">Tomoko</div></div><br></div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">2020年9月2日(水) 9:05 Gus Heck <<a \
href="mailto:gus.heck@gmail.com" \
target="_blank">gus.heck@gmail.com</a>>:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1 to fixing and +1 to doing it in \
a major release.<br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <<a \
href="mailto:jpountz@gmail.com" target="_blank">jpountz@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1 \
Changing packages of many classes should be done in a major.</div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 1, 2020 at 5:50 PM \
Tomoko Uchida <<a href="mailto:tomoko.uchida.1111@gmail.com" \
target="_blank">tomoko.uchida.1111@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Just to make sure, could I \
confirm "when the changes will be out"... <br></div><div>Resolving split \
package issues should break backward compatibility (changing package names and moving \
classes from one module to another modules). So we have just two options, we can have \
these changes only on major releases - 9.0.0 or 10.0.0; we cannot release such \
changes at minor versions. Is that correct?</div><div><br></div><div><div><div \
dir="ltr">Tomoko</div></div><br></div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">2020年9月1日(火) 22:08 Tomoko Uchida <<a \
href="mailto:tomoko.uchida.1111@gmail.com" \
target="_blank">tomoko.uchida.1111@gmail.com</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">> As I recall one issue was \
around where to put analysis packages?<br clear="all"><div><div \
dir="ltr"><br></div></div><div>It's LUCENE-9317. I had worked on it before, you \
can see what changes will be needed for analyzers-common (and \
core).</div><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">2020年9月1日(火) 22:00 Michael Sokolov <<a \
href="mailto:msokolov@gmail.com" \
target="_blank">msokolov@gmail.com</a>>:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">I'm in favor - there may be some difficult \
choices though. As I recall<br> one issue was around where to put analysis packages? \
I forget the<br> details, but there was some pretty strong feeling that you should \
have<br> a functioning system with core only. However some basic analysis tools<br>
are required for that, while most of our analyzers and so on are in a<br>
separate analysis module. Perhaps we will need to move some basic<br>
analyzers out of com.amazon.lucene.analysis? Or the reverse - move all<br>
the analysis code into the analysis module and acknowledge that it is<br>
a fundamental dependency (more essential than core, really).<br>
<br>
On Tue, Sep 1, 2020 at 8:26 AM Tomoko Uchida<br>
<<a href="mailto:tomoko.uchida.1111@gmail.com" \
target="_blank">tomoko.uchida.1111@gmail.com</a>> wrote:<br> ><br>
> yes, Jigsaw was on my mind too...<br>
><br>
> > why not go ahead and try to clean it up right away?<br>
><br>
> > So a strong +1 to clean this up!<br>
><br>
> OK, maybe I should open two issues, one for Lucene and one for Solr, and link \
existing wip issues to them.<br> > Once we start it, these will be blockers for \
9.0.0 release I believe (for now I have no idea about the volume of the changes or \
technical obstacles). Are there any objections or comments?<br> ><br>
><br>
> 2020年9月1日(火) 19:34 Uwe Schindler <<a href="mailto:uwe@thetaphi.de" \
target="_blank">uwe@thetaphi.de</a>>:<br> >><br>
>> Hi,<br>
>><br>
>> The biggest issue is that split packages make migrating to the Java 9 module \
system impossible. It's not allowed to have same package name (with classes) in \
different JAR files.<br> >><br>
>> Some of those require to open up visibility of classes. Some split packages \
issues were done because of package private access, which is very bad between JAR \
files. This also affects the test framework, although this is not such a big deal (I \
would exclude that for now), because you would never run UNIT tests inside a module \
system, only integration tests.<br> >><br>
>> So a strong +1 to clean this up!<br>
>> Uwe<br>
>><br>
>> -----<br>
>> Uwe Schindler<br>
>> Achterdiek 19, D-28357 Bremen<br>
>> <a href="https://www.thetaphi.de" rel="noreferrer" \
target="_blank">https://www.thetaphi.de</a><br> >> eMail: <a \
href="mailto:uwe@thetaphi.de" target="_blank">uwe@thetaphi.de</a><br> >><br>
>> > -----Original Message-----<br>
>> > From: Dawid Weiss <<a href="mailto:dawid.weiss@gmail.com" \
target="_blank">dawid.weiss@gmail.com</a>><br> >> > Sent: Tuesday, \
September 1, 2020 9:22 AM<br> >> > To: Lucene Dev <<a \
href="mailto:dev@lucene.apache.org" target="_blank">dev@lucene.apache.org</a>><br> \
>> > Subject: Re: Approach towards solving split package issues?<br> \
>> ><br> >> > This is a big headache for many things. I \
wouldn't mind doing this<br> >> > even for 9x. This is a major release, \
why not go ahead and try to<br> >> > clean it up right away?<br>
>> ><br>
>> > Dawid<br>
>> ><br>
>> > On Mon, Aug 31, 2020 at 11:50 PM Tomoko Uchida<br>
>> > <<a href="mailto:tomoko.uchida.1111@gmail.com" \
target="_blank">tomoko.uchida.1111@gmail.com</a>> wrote:<br> >> > \
><br> >> > > Hello devs,<br>
>> > ><br>
>> > > we have lots of package name conflicts (shared package names) \
between<br> >> > modules in the Lucene/Solr source tree. It is not only \
annoying for devs/users<br> >> > but also indeed bad practice since Java 9 \
(according to my understanding), and<br> >> > we already have some problems \
with Javadocs due to these splitted packages<br> >> > as some of us would \
know. I'm curious about the issue from a while ago. My<br> >> > \
questions are, Q1: How can we solve the issue in an organized way? Q2: How<br> \
>> > many of us really have interests about that?<br> >> > ><br>
>> > > To break down Q1,<br>
>> > > - A JIRA for building a grand design and organizing sub tasks is \
needed? We<br> >> > have a couple of issues (e.g. LUCENE-9317 and \
LUCENE-9319) about it and I<br> >> > had been playing around them before; \
but I feel like an umbrella ticket would<br> >> > be needed.<br>
>> > > - When to start and what's the target version to be out? My \
feeling is that<br> >> > after cutting branch_9x is the right moment to \
start and 10.0.0 is suitable for<br> >> > the target, does this make \
sense?<br> >> > > - Are there any other tasks/concerns to be considered \
except for just<br> >> > renaming packages?<br>
>> > ><br>
>> > > Regarding Q2,<br>
>> > > I know some of us have deep knowledge and thoughts in this topic, \
but for<br> >> > now I am not sure how many of you have the will to give \
help or take time for<br> >> > that.<br>
>> > > It can't be a one-man effort. The more people understand and \
can contribute<br> >> > to the build, the more healthy it will be. (I \
borrowed this phrase from Gradle<br> >> > build issue LUCENE-9077).<br>
>> > ><br>
>> > > I don't intend to rush into making a decision, my purpose here \
is to collect<br> >> > information to see if I can handle it before opening \
a JIRA.<br> >> > ><br>
>> > > Thanks,<br>
>> > > Tomoko<br>
>> ><br>
>> > ---------------------------------------------------------------------<br>
>> > To unsubscribe, e-mail: <a \
href="mailto:dev-unsubscribe@lucene.apache.org" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> >> > For \
additional commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
target="_blank">dev-help@lucene.apache.org</a><br> >><br>
>><br>
>> ---------------------------------------------------------------------<br>
>> To unsubscribe, e-mail: <a href="mailto:dev-unsubscribe@lucene.apache.org" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> >> For additional \
commands, e-mail: <a href="mailto:dev-help@lucene.apache.org" \
target="_blank">dev-help@lucene.apache.org</a><br> >><br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href="mailto:dev-unsubscribe@lucene.apache.org" \
target="_blank">dev-unsubscribe@lucene.apache.org</a><br> For additional commands, \
e-mail: <a href="mailto:dev-help@lucene.apache.org" \
target="_blank">dev-help@lucene.apache.org</a><br> <br>
</blockquote></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Adrien</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div \
dir="ltr"><div><a href="http://www.needhamsoftware.com" \
target="_blank">http://www.needhamsoftware.com</a> (work)</div><div><a \
href="http://www.the111shift.com" target="_blank">http://www.the111shift.com</a> \
(play)</div></div></div> </blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic