Approach towards solving split package issues?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Approach towards solving split package issues?

Tomoko Uchida
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
Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Alexandre Rafalovitch
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, <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: Approach towards solving split package issues?

Uwe Schindler
In reply to this post by Tomoko Uchida
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: [hidden email]

> -----Original Message-----
> From: Dawid Weiss <[hidden email]>
> Sent: Tuesday, September 1, 2020 9:22 AM
> To: Lucene Dev <[hidden email]>
> 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
> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Tomoko Uchida
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 <[hidden email]>:
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: [hidden email]

> -----Original Message-----
> From: Dawid Weiss <[hidden email]>
> Sent: Tuesday, September 1, 2020 9:22 AM
> To: Lucene Dev <[hidden email]>
> 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
> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Michael Sokolov-4
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Tomoko Uchida
> 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 <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Tomoko Uchida
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 <[hidden email]>:
> 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 <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Adrien Grand
+1 Changing packages of many classes should be done in a major.

On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien
Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Gus Heck
+1 to fixing and +1 to doing it in a major release.

On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <[hidden email]> wrote:
+1 Changing packages of many classes should be done in a major.

On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien


--
Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Tomoko Uchida
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 <[hidden email]>:
+1 to fixing and +1 to doing it in a major release.

On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <[hidden email]> wrote:
+1 Changing packages of many classes should be done in a major.

On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien


--
Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Tomoko Uchida
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 <[hidden email]>:
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 <[hidden email]>:
+1 to fixing and +1 to doing it in a major release.

On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <[hidden email]> wrote:
+1 Changing packages of many classes should be done in a major.

On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien


--
Reply | Threaded
Open this post in threaded view
|

Re: Approach towards solving split package issues?

Tomoko Uchida
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 <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]>:
+1 to fixing and +1 to doing it in a major release.

On Tue, Sep 1, 2020 at 4:32 PM Adrien Grand <[hidden email]> wrote:
+1 Changing packages of many classes should be done in a major.

On Tue, Sep 1, 2020 at 5:50 PM Tomoko Uchida <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]>:
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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: [hidden email]
>>
>> > -----Original Message-----
>> > From: Dawid Weiss <[hidden email]>
>> > Sent: Tuesday, September 1, 2020 9:22 AM
>> > To: Lucene Dev <[hidden email]>
>> > 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
>> > <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien


--