Mailing List Archive

Approach towards solving split package issues?
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 except 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 and 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
Re: Approach towards solving split package issues? [ In reply to ]
It was causing issues when I was building solr start resource website too.

So +1 on sorting it out.

Regards,
Alex.

On Mon., Aug. 31, 2020, 5:50 p.m. 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 except 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 and 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
>
Re: Approach towards solving split package issues? [ In reply to ]
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 try 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 except 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 and 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
RE: Approach towards solving split package issues? [ In reply to ]
Hi,

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.

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.

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 try 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 except 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 and 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
Re: Approach towards solving split package issues? [ In reply to ]
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?9?1?(?) 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 package 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), because you would
> never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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
>
>
Re: Approach towards solving split package issues? [ In reply to ]
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 in 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?9?1?(?) 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 package 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), because you would never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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
Re: Approach towards solving split package issues? [ In reply to ]
> 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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would
> never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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
>
>
Re: Approach towards solving split package issues? [ In reply to ]
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 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?

Tomoko


2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would
>> never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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
>>
>>
Re: Approach towards solving split package issues? [ In reply to ]
+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 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?
>
> Tomoko
>
>
> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would
>>> never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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
Re: Approach towards solving split package issues? [ In reply to ]
+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 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?
>>
>> Tomoko
>>
>>
>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would
>>>> never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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)
Re: Approach towards solving split package issues? [ In reply to ]
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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>>>
>>> Tomoko
>>>
>>>
>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would
>>>>> never run UNIT tests inside a module system, only integration 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 try 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 except
>>>>> 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 and
>>>>> 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)
>
Re: Approach towards solving split package issues? [ In reply to ]
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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>>>>
>>>> Tomoko
>>>>
>>>>
>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would
>>>>>> never run UNIT tests inside a module system, only integration 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 try 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 except
>>>>>> 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 and
>>>>>> 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)
>>
>
Re: Approach towards solving split package issues? [ In reply to ]
Hi,
please review LUCENE-9318, this refactors backward-codecs module (packages
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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>>>>>
>>>>> Tomoko
>>>>>
>>>>>
>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you
>>>>>>> would never run UNIT tests inside a module system, only integration 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 try
>>>>>>> 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 except
>>>>>>> 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 and
>>>>>>> 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)
>>>
>>
Re: Approach towards solving split package issues? [ In reply to ]
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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> Hi,
> please review LUCENE-9318, this refactors backward-codecs module (packages
> 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>>>>>>
>>>>>> Tomoko
>>>>>>
>>>>>>
>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in
>>>>>>>> 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?9?1?(?) 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 package 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), because you
>>>>>>>> would never run UNIT tests inside a module system, only integration 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 try
>>>>>>>> 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 except
>>>>>>>> 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 and
>>>>>>>> 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)
>>>>
>>>
Re: Approach towards solving split package issues? [ In reply to ]
Hi,
please review LUCENE-9600, this cleans up split packages in "misc" module
and makes some refactoring on classes in lucene/misc to keep lucene/core
unchanged.

Tomoko


2020?10?24?(?) 19:25 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> 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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
>> Hi,
>> please review LUCENE-9318, this refactors backward-codecs module
>> (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>>>>>>>
>>>>>>> Tomoko
>>>>>>>
>>>>>>>
>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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
>>>>>>>>> in 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?9?1?(?) 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 package 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), because you
>>>>>>>>> would never run UNIT tests inside a module system, only integration 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
>>>>>>>>> try 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
>>>>>>>>> except 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
>>>>>>>>> and 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)
>>>>>
>>>>
Re: Approach towards solving split package issues? [ In reply to ]
I closed LUCENE-9499, which means we now have no split packages in lucene
(except for test-framework).
Please keep in mind we still don't have any static analysis/validations to
prevent someone from adding another package name conflicts between modules.


2020?11?5?(?) 19:38 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:

> Hi,
> please review LUCENE-9600, this cleans up split packages in "misc" module
> and makes some refactoring on classes in lucene/misc to keep lucene/core
> unchanged.
>
> Tomoko
>
>
> 2020?10?24?(?) 19:25 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>
>> 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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>
>>> Hi,
>>> please review LUCENE-9318, this refactors backward-codecs module
>>> (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>>>>>>>>
>>>>>>>> Tomoko
>>>>>>>>
>>>>>>>>
>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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
>>>>>>>>>> in 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?9?1?(?) 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 package 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), because you
>>>>>>>>>> would never run UNIT tests inside a module system, only integration 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
>>>>>>>>>> try 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
>>>>>>>>>> except 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
>>>>>>>>>> and 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)
>>>>>>
>>>>>
Re: Approach towards solving split package issues? [ In reply to ]
Thanks Tomoko!

The check could be implemented (crudely) by looking at java
sourceSets, scanning which folders *.java files live in (packages) and
then checking for conflicts at the top-level project?

The test framework needs to be package-split to see core internals?

Dawid

On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> I closed LUCENE-9499, which means we now have no split packages in lucene (except for test-framework).
> Please keep in mind we still don't have any static analysis/validations to prevent someone from adding another package name conflicts between modules.
>
>
> 2020?11?5?(?) 19:38 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>
>> Hi,
>> please review LUCENE-9600, this cleans up split packages in "misc" module and makes some refactoring on classes in lucene/misc to keep lucene/core unchanged.
>>
>> Tomoko
>>
>>
>> 2020?10?24?(?) 19:25 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>>
>>> 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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>>>>
>>>> Hi,
>>>> please review LUCENE-9318, this refactors backward-codecs module (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>>>>>>>>>
>>>>>>>>> Tomoko
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Approach towards solving split package issues? [ In reply to ]
> The check could be implemented (crudely) by looking at java
> sourceSets, scanning which folders *.java files live in (packages) and
> then checking for conflicts at the top-level project?

I opened LUCENE-9604 some days ago, I've done nothing yet for it.

Maybe we can add a precommit check to find split packages using Gradle
APIs, but - how about having module-info.java now instead of an ad-hoc
temporary solution (though I don't know if there is another issue to be
considered)?
As a starter, we could open up (export) all existing packages...


2020?11?12?(?) 0:51 Dawid Weiss <dawid.weiss@gmail.com>:

> Thanks Tomoko!
>
> The check could be implemented (crudely) by looking at java
> sourceSets, scanning which folders *.java files live in (packages) and
> then checking for conflicts at the top-level project?
>
> The test framework needs to be package-split to see core internals?
>
> Dawid
>
> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > I closed LUCENE-9499, which means we now have no split packages in
> lucene (except for test-framework).
> > Please keep in mind we still don't have any static analysis/validations
> to prevent someone from adding another package name conflicts between
> modules.
> >
> >
> > 2020?11?5?(?) 19:38 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >>
> >> Hi,
> >> please review LUCENE-9600, this cleans up split packages in "misc"
> module and makes some refactoring on classes in lucene/misc to keep
> lucene/core unchanged.
> >>
> >> Tomoko
> >>
> >>
> >> 2020?10?24?(?) 19:25 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >>>
> >>> 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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >>>>
> >>>> Hi,
> >>>> please review LUCENE-9318, this refactors backward-codecs module
> (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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
> 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?
> >>>>>>>>>
> >>>>>>>>> Tomoko
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package
> 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),
> because you would never run UNIT tests inside a module system, only
> integration 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 try 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
> except 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 and 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)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Approach towards solving split package issues? [ In reply to ]
I think this sounds good!
D.

On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> > The check could be implemented (crudely) by looking at java
> > sourceSets, scanning which folders *.java files live in (packages) and
> > then checking for conflicts at the top-level project?
>
> I opened LUCENE-9604 some days ago, I've done nothing yet for it.
>
> Maybe we can add a precommit check to find split packages using Gradle APIs, but - how about having module-info.java now instead of an ad-hoc temporary solution (though I don't know if there is another issue to be considered)?
> As a starter, we could open up (export) all existing packages...
>
>
> 2020?11?12?(?) 0:51 Dawid Weiss <dawid.weiss@gmail.com>:
>>
>> Thanks Tomoko!
>>
>> The check could be implemented (crudely) by looking at java
>> sourceSets, scanning which folders *.java files live in (packages) and
>> then checking for conflicts at the top-level project?
>>
>> The test framework needs to be package-split to see core internals?
>>
>> Dawid
>>
>> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
>> <tomoko.uchida.1111@gmail.com> wrote:
>> >
>> > I closed LUCENE-9499, which means we now have no split packages in lucene (except for test-framework).
>> > Please keep in mind we still don't have any static analysis/validations to prevent someone from adding another package name conflicts between modules.
>> >
>> >
>> > 2020?11?5?(?) 19:38 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>> >>
>> >> Hi,
>> >> please review LUCENE-9600, this cleans up split packages in "misc" module and makes some refactoring on classes in lucene/misc to keep lucene/core unchanged.
>> >>
>> >> Tomoko
>> >>
>> >>
>> >> 2020?10?24?(?) 19:25 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>> >>>
>> >>> 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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>> >>>>
>> >>>> Hi,
>> >>>> please review LUCENE-9318, this refactors backward-codecs module (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>> >>>>>>>>>
>> >>>>>>>>> Tomoko
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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)
>>
>> ---------------------------------------------------------------------
>> 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
Re: Approach towards solving split package issues? [ In reply to ]
On second thought...
Adding module-info.java to all sub-modules seems to be a relatively simple
task (though it might involve laborious work), however, properly
maintaining them would not be so trivial I suspect. I'm not sure developers
(including me) are ready for the module system. Introducing it right now
could put another burden on us?

I'm not an expert in this area. What do you think?

Tomoko


2020?11?26?(?) 19:48 Dawid Weiss <dawid.weiss@gmail.com>:

> I think this sounds good!
> D.
>
> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > > The check could be implemented (crudely) by looking at java
> > > sourceSets, scanning which folders *.java files live in (packages) and
> > > then checking for conflicts at the top-level project?
> >
> > I opened LUCENE-9604 some days ago, I've done nothing yet for it.
> >
> > Maybe we can add a precommit check to find split packages using Gradle
> APIs, but - how about having module-info.java now instead of an ad-hoc
> temporary solution (though I don't know if there is another issue to be
> considered)?
> > As a starter, we could open up (export) all existing packages...
> >
> >
> > 2020?11?12?(?) 0:51 Dawid Weiss <dawid.weiss@gmail.com>:
> >>
> >> Thanks Tomoko!
> >>
> >> The check could be implemented (crudely) by looking at java
> >> sourceSets, scanning which folders *.java files live in (packages) and
> >> then checking for conflicts at the top-level project?
> >>
> >> The test framework needs to be package-split to see core internals?
> >>
> >> Dawid
> >>
> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
> >> <tomoko.uchida.1111@gmail.com> wrote:
> >> >
> >> > I closed LUCENE-9499, which means we now have no split packages in
> lucene (except for test-framework).
> >> > Please keep in mind we still don't have any static
> analysis/validations to prevent someone from adding another package name
> conflicts between modules.
> >> >
> >> >
> >> > 2020?11?5?(?) 19:38 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >> >>
> >> >> Hi,
> >> >> please review LUCENE-9600, this cleans up split packages in "misc"
> module and makes some refactoring on classes in lucene/misc to keep
> lucene/core unchanged.
> >> >>
> >> >> Tomoko
> >> >>
> >> >>
> >> >> 2020?10?24?(?) 19:25 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >> >>>
> >> >>> 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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
> >> >>>>
> >> >>>> Hi,
> >> >>>> please review LUCENE-9318, this refactors backward-codecs module
> (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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
> 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?
> >> >>>>>>>>>
> >> >>>>>>>>> Tomoko
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <
> tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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
> package 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),
> because you would never run UNIT tests inside a module system, only
> integration 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 try 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 except 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 and 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)
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: Approach towards solving split package issues? [ In reply to ]
I'm not an expert on modules either - haven't had the need to use
them. But then: it's part of the fun to discover new things. I don't
see the reason why we shouldn't do it (on master).

Dawid

On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida
<tomoko.uchida.1111@gmail.com> wrote:
>
> On second thought...
> Adding module-info.java to all sub-modules seems to be a relatively simple task (though it might involve laborious work), however, properly maintaining them would not be so trivial I suspect. I'm not sure developers (including me) are ready for the module system. Introducing it right now could put another burden on us?
>
> I'm not an expert in this area. What do you think?
>
> Tomoko
>
>
> 2020?11?26?(?) 19:48 Dawid Weiss <dawid.weiss@gmail.com>:
>>
>> I think this sounds good!
>> D.
>>
>> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida
>> <tomoko.uchida.1111@gmail.com> wrote:
>> >
>> > > The check could be implemented (crudely) by looking at java
>> > > sourceSets, scanning which folders *.java files live in (packages) and
>> > > then checking for conflicts at the top-level project?
>> >
>> > I opened LUCENE-9604 some days ago, I've done nothing yet for it.
>> >
>> > Maybe we can add a precommit check to find split packages using Gradle APIs, but - how about having module-info.java now instead of an ad-hoc temporary solution (though I don't know if there is another issue to be considered)?
>> > As a starter, we could open up (export) all existing packages...
>> >
>> >
>> > 2020?11?12?(?) 0:51 Dawid Weiss <dawid.weiss@gmail.com>:
>> >>
>> >> Thanks Tomoko!
>> >>
>> >> The check could be implemented (crudely) by looking at java
>> >> sourceSets, scanning which folders *.java files live in (packages) and
>> >> then checking for conflicts at the top-level project?
>> >>
>> >> The test framework needs to be package-split to see core internals?
>> >>
>> >> Dawid
>> >>
>> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
>> >> <tomoko.uchida.1111@gmail.com> wrote:
>> >> >
>> >> > I closed LUCENE-9499, which means we now have no split packages in lucene (except for test-framework).
>> >> > Please keep in mind we still don't have any static analysis/validations to prevent someone from adding another package name conflicts between modules.
>> >> >
>> >> >
>> >> > 2020?11?5?(?) 19:38 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>> >> >>
>> >> >> Hi,
>> >> >> please review LUCENE-9600, this cleans up split packages in "misc" module and makes some refactoring on classes in lucene/misc to keep lucene/core unchanged.
>> >> >>
>> >> >> Tomoko
>> >> >>
>> >> >>
>> >> >> 2020?10?24?(?) 19:25 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>> >> >>>
>> >> >>> 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?10?18?(?) 0:36 Tomoko Uchida <tomoko.uchida.1111@gmail.com>:
>> >> >>>>
>> >> >>>> Hi,
>> >> >>>> please review LUCENE-9318, this refactors backward-codecs module (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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 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?
>> >> >>>>>>>>>
>> >> >>>>>>>>> Tomoko
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package 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), because you would never run UNIT tests inside a module system, only integration 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 try 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 except 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 and 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)
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
RE: Approach towards solving split package issues? [ In reply to ]
Hi,

I wanted to just add:
We also need some testing of the artifacts! Our standard test environment can't do testing of module system. This needs some "integration" tests: A project using the JAR files on module path - no classpath. And here it must be JAR files, the non-packaged class files won't work as far as I remember.

When doing this, you will figure out that the SPI classes (codecs, analyzers) won't work on module path. Because we do not only need to open the packages in our modules, the contents on META-INF/servisices need to be added as "native services" to the module info. Every module-info file must list all class names that are services explicit. The META-INF/service files are not read in module mode:

See this blog post: https://blog.frankel.ch/migrating-serviceloader-java-9-module-system/

I am not sure if JDEPS figures this out automatically!

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: Saturday, November 28, 2020 9:52 PM
> To: Lucene Dev <dev@lucene.apache.org>
> Subject: Re: Approach towards solving split package issues?
>
> I'm not an expert on modules either - haven't had the need to use
> them. But then: it's part of the fun to discover new things. I don't
> see the reason why we shouldn't do it (on master).
>
> Dawid
>
> On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida
> <tomoko.uchida.1111@gmail.com> wrote:
> >
> > On second thought...
> > Adding module-info.java to all sub-modules seems to be a relatively simple
> task (though it might involve laborious work), however, properly maintaining
> them would not be so trivial I suspect. I'm not sure developers (including me)
> are ready for the module system. Introducing it right now could put another
> burden on us?
> >
> > I'm not an expert in this area. What do you think?
> >
> > Tomoko
> >
> >
> > 2020?11?26?(?) 19:48 Dawid Weiss <dawid.weiss@gmail.com>:
> >>
> >> I think this sounds good!
> >> D.
> >>
> >> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida
> >> <tomoko.uchida.1111@gmail.com> wrote:
> >> >
> >> > > The check could be implemented (crudely) by looking at java
> >> > > sourceSets, scanning which folders *.java files live in (packages) and
> >> > > then checking for conflicts at the top-level project?
> >> >
> >> > I opened LUCENE-9604 some days ago, I've done nothing yet for it.
> >> >
> >> > Maybe we can add a precommit check to find split packages using Gradle
> APIs, but - how about having module-info.java now instead of an ad-hoc
> temporary solution (though I don't know if there is another issue to be
> considered)?
> >> > As a starter, we could open up (export) all existing packages...
> >> >
> >> >
> >> > 2020?11?12?(?) 0:51 Dawid Weiss <dawid.weiss@gmail.com>:
> >> >>
> >> >> Thanks Tomoko!
> >> >>
> >> >> The check could be implemented (crudely) by looking at java
> >> >> sourceSets, scanning which folders *.java files live in (packages) and
> >> >> then checking for conflicts at the top-level project?
> >> >>
> >> >> The test framework needs to be package-split to see core internals?
> >> >>
> >> >> Dawid
> >> >>
> >> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
> >> >> <tomoko.uchida.1111@gmail.com> wrote:
> >> >> >
> >> >> > I closed LUCENE-9499, which means we now have no split packages in
> lucene (except for test-framework).
> >> >> > Please keep in mind we still don't have any static analysis/validations to
> prevent someone from adding another package name conflicts between
> modules.
> >> >> >
> >> >> >
> >> >> > 2020?11?5?(?) 19:38 Tomoko Uchida
> <tomoko.uchida.1111@gmail.com>:
> >> >> >>
> >> >> >> Hi,
> >> >> >> please review LUCENE-9600, this cleans up split packages in "misc"
> module and makes some refactoring on classes in lucene/misc to keep
> lucene/core unchanged.
> >> >> >>
> >> >> >> Tomoko
> >> >> >>
> >> >> >>
> >> >> >> 2020?10?24?(?) 19:25 Tomoko Uchida
> <tomoko.uchida.1111@gmail.com>:
> >> >> >>>
> >> >> >>> 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?10?18?(?) 0:36 Tomoko Uchida
> <tomoko.uchida.1111@gmail.com>:
> >> >> >>>>
> >> >> >>>> Hi,
> >> >> >>>> please review LUCENE-9318, this refactors backward-codecs module
> (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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
> 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?
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> Tomoko
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida
> <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package
> 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), because you would
> never run UNIT tests inside a module system, only integration 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 try 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
> except 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 and 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)
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Approach towards solving split package issues? [ In reply to ]
I think it'd be fun to switch to the module system at some point.
Perhaps offer dual release, initially (modules + JARs).

Dawid

On Mon, Nov 30, 2020 at 10:37 AM Uwe Schindler <uwe@thetaphi.de> wrote:
>
> Hi,
>
> I wanted to just add:
> We also need some testing of the artifacts! Our standard test environment can't do testing of module system. This needs some "integration" tests: A project using the JAR files on module path - no classpath. And here it must be JAR files, the non-packaged class files won't work as far as I remember.
>
> When doing this, you will figure out that the SPI classes (codecs, analyzers) won't work on module path. Because we do not only need to open the packages in our modules, the contents on META-INF/servisices need to be added as "native services" to the module info. Every module-info file must list all class names that are services explicit. The META-INF/service files are not read in module mode:
>
> See this blog post: https://blog.frankel.ch/migrating-serviceloader-java-9-module-system/
>
> I am not sure if JDEPS figures this out automatically!
>
> 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: Saturday, November 28, 2020 9:52 PM
> > To: Lucene Dev <dev@lucene.apache.org>
> > Subject: Re: Approach towards solving split package issues?
> >
> > I'm not an expert on modules either - haven't had the need to use
> > them. But then: it's part of the fun to discover new things. I don't
> > see the reason why we shouldn't do it (on master).
> >
> > Dawid
> >
> > On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida
> > <tomoko.uchida.1111@gmail.com> wrote:
> > >
> > > On second thought...
> > > Adding module-info.java to all sub-modules seems to be a relatively simple
> > task (though it might involve laborious work), however, properly maintaining
> > them would not be so trivial I suspect. I'm not sure developers (including me)
> > are ready for the module system. Introducing it right now could put another
> > burden on us?
> > >
> > > I'm not an expert in this area. What do you think?
> > >
> > > Tomoko
> > >
> > >
> > > 2020?11?26?(?) 19:48 Dawid Weiss <dawid.weiss@gmail.com>:
> > >>
> > >> I think this sounds good!
> > >> D.
> > >>
> > >> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida
> > >> <tomoko.uchida.1111@gmail.com> wrote:
> > >> >
> > >> > > The check could be implemented (crudely) by looking at java
> > >> > > sourceSets, scanning which folders *.java files live in (packages) and
> > >> > > then checking for conflicts at the top-level project?
> > >> >
> > >> > I opened LUCENE-9604 some days ago, I've done nothing yet for it.
> > >> >
> > >> > Maybe we can add a precommit check to find split packages using Gradle
> > APIs, but - how about having module-info.java now instead of an ad-hoc
> > temporary solution (though I don't know if there is another issue to be
> > considered)?
> > >> > As a starter, we could open up (export) all existing packages...
> > >> >
> > >> >
> > >> > 2020?11?12?(?) 0:51 Dawid Weiss <dawid.weiss@gmail.com>:
> > >> >>
> > >> >> Thanks Tomoko!
> > >> >>
> > >> >> The check could be implemented (crudely) by looking at java
> > >> >> sourceSets, scanning which folders *.java files live in (packages) and
> > >> >> then checking for conflicts at the top-level project?
> > >> >>
> > >> >> The test framework needs to be package-split to see core internals?
> > >> >>
> > >> >> Dawid
> > >> >>
> > >> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
> > >> >> <tomoko.uchida.1111@gmail.com> wrote:
> > >> >> >
> > >> >> > I closed LUCENE-9499, which means we now have no split packages in
> > lucene (except for test-framework).
> > >> >> > Please keep in mind we still don't have any static analysis/validations to
> > prevent someone from adding another package name conflicts between
> > modules.
> > >> >> >
> > >> >> >
> > >> >> > 2020?11?5?(?) 19:38 Tomoko Uchida
> > <tomoko.uchida.1111@gmail.com>:
> > >> >> >>
> > >> >> >> Hi,
> > >> >> >> please review LUCENE-9600, this cleans up split packages in "misc"
> > module and makes some refactoring on classes in lucene/misc to keep
> > lucene/core unchanged.
> > >> >> >>
> > >> >> >> Tomoko
> > >> >> >>
> > >> >> >>
> > >> >> >> 2020?10?24?(?) 19:25 Tomoko Uchida
> > <tomoko.uchida.1111@gmail.com>:
> > >> >> >>>
> > >> >> >>> 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?10?18?(?) 0:36 Tomoko Uchida
> > <tomoko.uchida.1111@gmail.com>:
> > >> >> >>>>
> > >> >> >>>> Hi,
> > >> >> >>>> please review LUCENE-9318, this refactors backward-codecs module
> > (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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
> > 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?
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>>> Tomoko
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>>>
> > >> >> >>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida
> > <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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 package
> > 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), because you would
> > never run UNIT tests inside a module system, only integration 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 try 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
> > except 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 and 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)
> > >> >>
> > >> >> ---------------------------------------------------------------------
> > >> >> 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
>
>
> ---------------------------------------------------------------------
> 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
RE: Approach towards solving split package issues? [ In reply to ]
Hi,

You can have both in same JAR file. No need to split releases, this would confuse users even more. For some stuff you just have to make sure that both usage possibilities are available, but in general the Gradle build should switch to "module" compilation mode, so all dependencies are checked by javac and the output is a module-compliant JAR file. The only special case I know of regarding discovery and usage of JAR files is Service provider files: They need to be in META-INF/services for classpath use cases, but they also need to be in module descriptor for module projects.

If we use the gradle module plugin, we must make sure that the render-javadocs task also uses modulepath not classpath. I have no idea about ECJ ????

But when adding module descriptors, we need at least a basic test that the module descriptors work, services work and a basic project compiles and builds (kinda integration test).

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: Monday, November 30, 2020 11:51 AM
> To: Lucene Dev <dev@lucene.apache.org>
> Subject: Re: Approach towards solving split package issues?
>
> I think it'd be fun to switch to the module system at some point.
> Perhaps offer dual release, initially (modules + JARs).
>
> Dawid
>
> On Mon, Nov 30, 2020 at 10:37 AM Uwe Schindler <uwe@thetaphi.de> wrote:
> >
> > Hi,
> >
> > I wanted to just add:
> > We also need some testing of the artifacts! Our standard test environment
> can't do testing of module system. This needs some "integration" tests: A
> project using the JAR files on module path - no classpath. And here it must be
> JAR files, the non-packaged class files won't work as far as I remember.
> >
> > When doing this, you will figure out that the SPI classes (codecs, analyzers)
> won't work on module path. Because we do not only need to open the
> packages in our modules, the contents on META-INF/servisices need to be
> added as "native services" to the module info. Every module-info file must list
> all class names that are services explicit. The META-INF/service files are not
> read in module mode:
> >
> > See this blog post: https://blog.frankel.ch/migrating-serviceloader-java-9-
> module-system/
> >
> > I am not sure if JDEPS figures this out automatically!
> >
> > 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: Saturday, November 28, 2020 9:52 PM
> > > To: Lucene Dev <dev@lucene.apache.org>
> > > Subject: Re: Approach towards solving split package issues?
> > >
> > > I'm not an expert on modules either - haven't had the need to use
> > > them. But then: it's part of the fun to discover new things. I don't
> > > see the reason why we shouldn't do it (on master).
> > >
> > > Dawid
> > >
> > > On Sat, Nov 28, 2020 at 4:04 PM Tomoko Uchida
> > > <tomoko.uchida.1111@gmail.com> wrote:
> > > >
> > > > On second thought...
> > > > Adding module-info.java to all sub-modules seems to be a relatively
> simple
> > > task (though it might involve laborious work), however, properly
> maintaining
> > > them would not be so trivial I suspect. I'm not sure developers (including
> me)
> > > are ready for the module system. Introducing it right now could put another
> > > burden on us?
> > > >
> > > > I'm not an expert in this area. What do you think?
> > > >
> > > > Tomoko
> > > >
> > > >
> > > > 2020?11?26?(?) 19:48 Dawid Weiss <dawid.weiss@gmail.com>:
> > > >>
> > > >> I think this sounds good!
> > > >> D.
> > > >>
> > > >> On Wed, Nov 25, 2020 at 2:20 PM Tomoko Uchida
> > > >> <tomoko.uchida.1111@gmail.com> wrote:
> > > >> >
> > > >> > > The check could be implemented (crudely) by looking at java
> > > >> > > sourceSets, scanning which folders *.java files live in (packages) and
> > > >> > > then checking for conflicts at the top-level project?
> > > >> >
> > > >> > I opened LUCENE-9604 some days ago, I've done nothing yet for it.
> > > >> >
> > > >> > Maybe we can add a precommit check to find split packages using
> Gradle
> > > APIs, but - how about having module-info.java now instead of an ad-hoc
> > > temporary solution (though I don't know if there is another issue to be
> > > considered)?
> > > >> > As a starter, we could open up (export) all existing packages...
> > > >> >
> > > >> >
> > > >> > 2020?11?12?(?) 0:51 Dawid Weiss <dawid.weiss@gmail.com>:
> > > >> >>
> > > >> >> Thanks Tomoko!
> > > >> >>
> > > >> >> The check could be implemented (crudely) by looking at java
> > > >> >> sourceSets, scanning which folders *.java files live in (packages) and
> > > >> >> then checking for conflicts at the top-level project?
> > > >> >>
> > > >> >> The test framework needs to be package-split to see core internals?
> > > >> >>
> > > >> >> Dawid
> > > >> >>
> > > >> >> On Wed, Nov 11, 2020 at 4:09 PM Tomoko Uchida
> > > >> >> <tomoko.uchida.1111@gmail.com> wrote:
> > > >> >> >
> > > >> >> > I closed LUCENE-9499, which means we now have no split packages
> in
> > > lucene (except for test-framework).
> > > >> >> > Please keep in mind we still don't have any static
> analysis/validations to
> > > prevent someone from adding another package name conflicts between
> > > modules.
> > > >> >> >
> > > >> >> >
> > > >> >> > 2020?11?5?(?) 19:38 Tomoko Uchida
> > > <tomoko.uchida.1111@gmail.com>:
> > > >> >> >>
> > > >> >> >> Hi,
> > > >> >> >> please review LUCENE-9600, this cleans up split packages in "misc"
> > > module and makes some refactoring on classes in lucene/misc to keep
> > > lucene/core unchanged.
> > > >> >> >>
> > > >> >> >> Tomoko
> > > >> >> >>
> > > >> >> >>
> > > >> >> >> 2020?10?24?(?) 19:25 Tomoko Uchida
> > > <tomoko.uchida.1111@gmail.com>:
> > > >> >> >>>
> > > >> >> >>> 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?10?18?(?) 0:36 Tomoko Uchida
> > > <tomoko.uchida.1111@gmail.com>:
> > > >> >> >>>>
> > > >> >> >>>> Hi,
> > > >> >> >>>> please review LUCENE-9318, this refactors backward-codecs
> module
> > > (packages 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?9?3?(?) 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?9?3?(?) 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?9?2?(?) 9:05 Gus Heck <gus.heck@gmail.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
> > > 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?
> > > >> >> >>>>>>>>>
> > > >> >> >>>>>>>>> Tomoko
> > > >> >> >>>>>>>>>
> > > >> >> >>>>>>>>>
> > > >> >> >>>>>>>>> 2020?9?1?(?) 22:08 Tomoko Uchida
> > > <tomoko.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?9?1?(?) 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 in 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?9?1?(?) 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
> package
> > > 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), because you
> would
> > > never run UNIT tests inside a module system, only integration 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 try 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
> > > except 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 and 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)
> > > >> >>
> > > >> >> ---------------------------------------------------------------------
> > > >> >> 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
> >
> >
> > ---------------------------------------------------------------------
> > 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