Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
2018-02-12 17:55 GMT+01:00 Sanne Grinovero :
> Picking automatic module names for Hibernate Search isn't going to be
> straight-forward as our two main jars (hibernate-search-engine &
> hibernate-search-orm) suffer from split package among them.
>
> We can't really fix the split package problem without breaking all
> users, so if we want to consider that, we can debate it but that will
> need to happen at another round as we're doing a minor release, so
> let's focus on:
> # Which names to pick
> # Should we pick the names at all
> # Which modules should have a name
>
> For a great background on the possible strategies and pitfalls I
> recommend reading Stephen Colebourne's blog on this subject [1].
> He persuaded me there are good reasons to use the "reverse DNS, the
> top level package", however since we have the split package problem we
> can't simply go with that.
>
> Still, we can respect the principles he recommends with a small
> variation. It's fair to assume that the `org.hibernate.search` prefix
> is "ours"; since the nature of the suggestion is focused on making
> sure there are no misunderstandings in the community about which names
> you can choose - as there is no central authority making sure module
> names aren't clashing - we should be fine within Hibernate projects
> with any `org.hibernate.X` prefix, as long as we coordinate and reach
> an agreement on this list.
>
> So, I propose we use:
>
> Engine module:
> - org.hibernate.search.engine
>
> ORM integration module:
> - org.hibernate.search.orm
>
> Those names sound good to me.
> JGroups, JMS backends:
> [ no automatic module name ? Excepting some "guidelines" in the JMS
> module, these are not public API so nobody would benefit from it -
> also we think we might want to phase out the name "backend" in the
> future ]
Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
> - org.hibernate.search.elasticsearch
>
> Elasticsearch / AWS security integration:
> [ no automatic module name: no public API ]
>
> Serialization / Avro
> [ no automatic module name: no public API ]
>
> WDYT?
>
The user may still need to reference those modules when launching a
modularized application. Also if they don't directly declare say the JMS
backend as a dependence of their own module, they'd still have to specify
it via --add-modules, so to resolve these additional modules and add them
to the module graph. Hence I'd declare automatic module names for these,
too.
>
> We could also pick names for the ones which I've listed as "no public
> API" but I see no point: as we're only assigning an "Automatic Module
> Name" we won't be able to explicitly state that the other modules
> depend on these. So nobody will use them, and things are a bit in flux
> anyway in this area because of Hibernate Search 6 plans.
>
I don't fully understand this paragraph.
>
> Another optional altogether: since we have split packages which we'll
> have to resolve before we can actually transform these into fully
> fledged modules, I think an acceptable position is also to say we
> won't be publishing any automatic module name yet. Personally I'm
> inclined to go with the names suggested above, at least some others
> can start making baby steps, even if it's not all there.
>
IMO automatic module names should only be declared after at least some
basic vetting that these modules will actually work when used as modules.
If that's not the case, I wouldn't add these headers, as users rightfully
may consider their presence as endorsement of using them as modules.
That said, I can't seem to find split packages between engine and orm. In
fact I can launch an application with both of them on the module path just
fine. So there may be no problem actually?
> # What I don't like:
> For one, that the typical application will need to import both
> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and
> likely more as well (e.g. Elasticsearch API, Lucene API module is
> coming, ..).
>
I'm not exactly sure what you mean by "import" here. But if it's about the
user having to declare dependences in their module descriptor to
o.h.s.engine and o.h.s.orm modules, you may consider to make the former a
transitive dependence of the latter once you add actual module descriptors:
module org.hibernate.search.orm {
requires transitive org.hibernate.search.engine;
...
}
That way the user just has to add declare the dependence to o.h.s.orm.
That's definitely suitable if APIs in o.h.s.orm use types from engine in
their public API signatures.
> Maybe similar to BOM's today we could publish a module which
> statically imports multiple of these, that could be nicer to use but
> we risk needing to publish (and document) one for each of a selection
> of combinations. So let's not start with such things yet.
>
> Thanks,
> Sanne
>
> [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
>
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
On 12 February 2018 at 18:00, Gunnar Morling wrote: > > > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : >> >> Picking automatic module names for Hibernate Search isn't going to be >> straight-forward as our two main jars (hibernate-search-engine & >> hibernate-search-orm) suffer from split package among them. >> >> We can't really fix the split package problem without breaking all >> users, so if we want to consider that, we can debate it but that will >> need to happen at another round as we're doing a minor release, so >> let's focus on: >> # Which names to pick >> # Should we pick the names at all >> # Which modules should have a name >> >> For a great background on the possible strategies and pitfalls I >> recommend reading Stephen Colebourne's blog on this subject [1]. >> He persuaded me there are good reasons to use the "reverse DNS, the >> top level package", however since we have the split package problem we >> can't simply go with that. >> >> Still, we can respect the principles he recommends with a small >> variation. It's fair to assume that the `org.hibernate.search` prefix >> is "ours"; since the nature of the suggestion is focused on making >> sure there are no misunderstandings in the community about which names >> you can choose - as there is no central authority making sure module >> names aren't clashing - we should be fine within Hibernate projects >> with any `org.hibernate.X` prefix, as long as we coordinate and reach >> an agreement on this list. >> >> So, I propose we use: >> >> Engine module: >> - org.hibernate.search.engine >> >> ORM integration module: >> - org.hibernate.search.orm >> > Those names sound good to me. > >> >> JGroups, JMS backends: >> [ no automatic module name ? Excepting some "guidelines" in the JMS >> module, these are not public API so nobody would benefit from it - >> also we think we might want to phase out the name "backend" in the >> future ] >> >> Elasticsearch integration module [hibernate-search-elasticsearch.jar]: >> - org.hibernate.search.elasticsearch >> >> Elasticsearch / AWS security integration: >> [ no automatic module name: no public API ] >> >> Serialization / Avro >> [ no automatic module name: no public API ] >> >> WDYT? > > > The user may still need to reference those modules when launching a > modularized application. Also if they don't directly declare say the JMS > backend as a dependence of their own module, they'd still have to specify it > via --add-modules, so to resolve these additional modules and add them to > the module graph. Hence I'd declare automatic module names for these, too. Good point, I had not thought that our modules wouldn't be able to load other extensions from classpath. >> We could also pick names for the ones which I've listed as "no public >> API" but I see no point: as we're only assigning an "Automatic Module >> Name" we won't be able to explicitly state that the other modules >> depend on these. So nobody will use them, and things are a bit in flux >> anyway in this area because of Hibernate Search 6 plans. > > > I don't fully understand this paragraph. You mostly invalidated it with the previous comment, but what I meant is that we can't have the `org.hibernate.search.engine` declare a dependency on any implementation module, as we're not adding a module-info definition. >> Another optional altogether: since we have split packages which we'll >> have to resolve before we can actually transform these into fully >> fledged modules, I think an acceptable position is also to say we >> won't be publishing any automatic module name yet. Personally I'm >> inclined to go with the names suggested above, at least some others >> can start making baby steps, even if it's not all there. > > > IMO automatic module names should only be declared after at least some basic > vetting that these modules will actually work when used as modules. If > that's not the case, I wouldn't add these headers, as users rightfully may > consider their presence as endorsement of using them as modules. > > That said, I can't seem to find split packages between engine and orm. In > fact I can launch an application with both of them on the module path just > fine. So there may be no problem actually? Interesting, I'm pretty sure we had some. We had several issues resolved over time to resolve them, I never realized we might have completed them all. The "line" defining what belongs where is still blurry though, we should make sure this won't have future regressions. I'll see if we can produce fully fledged module-info descriptors then :) > >> >> # What I don't like: >> For one, that the typical application will need to import both >> `org.hibernate.search.engine` and `org.hibernate.search.orm`, and >> likely more as well (e.g. Elasticsearch API, Lucene API module is >> coming, ..). > > > I'm not exactly sure what you mean by "import" here. But if it's about the > user having to declare dependences in their module descriptor to > o.
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
On 12 February 2018 at 18:28, Sanne Grinovero wrote: > On 12 February 2018 at 18:00, Gunnar Morling wrote: >> >> >> 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : >>> >>> Picking automatic module names for Hibernate Search isn't going to be >>> straight-forward as our two main jars (hibernate-search-engine & >>> hibernate-search-orm) suffer from split package among them. >>> >>> We can't really fix the split package problem without breaking all >>> users, so if we want to consider that, we can debate it but that will >>> need to happen at another round as we're doing a minor release, so >>> let's focus on: >>> # Which names to pick >>> # Should we pick the names at all >>> # Which modules should have a name >>> >>> For a great background on the possible strategies and pitfalls I >>> recommend reading Stephen Colebourne's blog on this subject [1]. >>> He persuaded me there are good reasons to use the "reverse DNS, the >>> top level package", however since we have the split package problem we >>> can't simply go with that. >>> >>> Still, we can respect the principles he recommends with a small >>> variation. It's fair to assume that the `org.hibernate.search` prefix >>> is "ours"; since the nature of the suggestion is focused on making >>> sure there are no misunderstandings in the community about which names >>> you can choose - as there is no central authority making sure module >>> names aren't clashing - we should be fine within Hibernate projects >>> with any `org.hibernate.X` prefix, as long as we coordinate and reach >>> an agreement on this list. >>> >>> So, I propose we use: >>> >>> Engine module: >>> - org.hibernate.search.engine >>> >>> ORM integration module: >>> - org.hibernate.search.orm >>> >> Those names sound good to me. >> >>> >>> JGroups, JMS backends: >>> [ no automatic module name ? Excepting some "guidelines" in the JMS >>> module, these are not public API so nobody would benefit from it - >>> also we think we might want to phase out the name "backend" in the >>> future ] >>> >>> Elasticsearch integration module [hibernate-search-elasticsearch.jar]: >>> - org.hibernate.search.elasticsearch >>> >>> Elasticsearch / AWS security integration: >>> [ no automatic module name: no public API ] >>> >>> Serialization / Avro >>> [ no automatic module name: no public API ] >>> >>> WDYT? >> >> >> The user may still need to reference those modules when launching a >> modularized application. Also if they don't directly declare say the JMS >> backend as a dependence of their own module, they'd still have to specify it >> via --add-modules, so to resolve these additional modules and add them to >> the module graph. Hence I'd declare automatic module names for these, too. > > Good point, I had not thought that our modules wouldn't be able to > load other extensions from classpath. > >>> We could also pick names for the ones which I've listed as "no public >>> API" but I see no point: as we're only assigning an "Automatic Module >>> Name" we won't be able to explicitly state that the other modules >>> depend on these. So nobody will use them, and things are a bit in flux >>> anyway in this area because of Hibernate Search 6 plans. >> >> >> I don't fully understand this paragraph. > > You mostly invalidated it with the previous comment, but what I meant > is that we can't have the `org.hibernate.search.engine` declare a > dependency on any implementation module, as we're not adding a > module-info definition. > >>> Another optional altogether: since we have split packages which we'll >>> have to resolve before we can actually transform these into fully >>> fledged modules, I think an acceptable position is also to say we >>> won't be publishing any automatic module name yet. Personally I'm >>> inclined to go with the names suggested above, at least some others >>> can start making baby steps, even if it's not all there. >> >> >> IMO automatic module names should only be declared after at least some basic >> vetting that these modules will actually work when used as modules. If >> that's not the case, I wouldn't add these headers, as users rightfully may >> consider their presence as endorsement of using them as modules. >> >> That said, I can't seem to find split packages between engine and orm. In >> fact I can launch an application with both of them on the module path just >> fine. So there may be no problem actually? > > Interesting, I'm pretty sure we had some. We had several issues > resolved over time to resolve them, I never realized we might have > completed them all. The "line" defining what belongs where is still > blurry though, we should make sure this won't have future regressions. > > I'll see if we can produce fully fledged module-info descriptors then :) Well, sorry I sent that too fast without thinking. Of course making full modules is not an option as several of our dependencies aren't modular yet. Thanks anyway that was a very interesting observation! Sanne > >> >>> >>> #
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
2018-02-12 19:28 GMT+01:00 Sanne Grinovero : > On 12 February 2018 at 18:00, Gunnar Morling wrote: > > > > > > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : > >> > >> Picking automatic module names for Hibernate Search isn't going to be > >> straight-forward as our two main jars (hibernate-search-engine & > >> hibernate-search-orm) suffer from split package among them. > >> > >> We can't really fix the split package problem without breaking all > >> users, so if we want to consider that, we can debate it but that will > >> need to happen at another round as we're doing a minor release, so > >> let's focus on: > >> # Which names to pick > >> # Should we pick the names at all > >> # Which modules should have a name > >> > >> For a great background on the possible strategies and pitfalls I > >> recommend reading Stephen Colebourne's blog on this subject [1]. > >> He persuaded me there are good reasons to use the "reverse DNS, the > >> top level package", however since we have the split package problem we > >> can't simply go with that. > >> > >> Still, we can respect the principles he recommends with a small > >> variation. It's fair to assume that the `org.hibernate.search` prefix > >> is "ours"; since the nature of the suggestion is focused on making > >> sure there are no misunderstandings in the community about which names > >> you can choose - as there is no central authority making sure module > >> names aren't clashing - we should be fine within Hibernate projects > >> with any `org.hibernate.X` prefix, as long as we coordinate and reach > >> an agreement on this list. > >> > >> So, I propose we use: > >> > >> Engine module: > >> - org.hibernate.search.engine > >> > >> ORM integration module: > >> - org.hibernate.search.orm > >> > > Those names sound good to me. > > > >> > >> JGroups, JMS backends: > >> [ no automatic module name ? Excepting some "guidelines" in the JMS > >> module, these are not public API so nobody would benefit from it - > >> also we think we might want to phase out the name "backend" in the > >> future ] > >> > >> Elasticsearch integration module [hibernate-search-elasticsearch.jar]: > >> - org.hibernate.search.elasticsearch > >> > >> Elasticsearch / AWS security integration: > >> [ no automatic module name: no public API ] > >> > >> Serialization / Avro > >> [ no automatic module name: no public API ] > >> > >> WDYT? > > > > > > The user may still need to reference those modules when launching a > > modularized application. Also if they don't directly declare say the JMS > > backend as a dependence of their own module, they'd still have to > specify it > > via --add-modules, so to resolve these additional modules and add them to > > the module graph. Hence I'd declare automatic module names for these, > too. > > Good point, I had not thought that our modules wouldn't be able to > load other extensions from classpath. > > >> We could also pick names for the ones which I've listed as "no public > >> API" but I see no point: as we're only assigning an "Automatic Module > >> Name" we won't be able to explicitly state that the other modules > >> depend on these. So nobody will use them, and things are a bit in flux > >> anyway in this area because of Hibernate Search 6 plans. > > > > > > I don't fully understand this paragraph. > > You mostly invalidated it with the previous comment, but what I meant > is that we can't have the `org.hibernate.search.engine` declare a > dependency on any implementation module, as we're not adding a > module-info definition. > > >> Another optional altogether: since we have split packages which we'll > >> have to resolve before we can actually transform these into fully > >> fledged modules, I think an acceptable position is also to say we > >> won't be publishing any automatic module name yet. Personally I'm > >> inclined to go with the names suggested above, at least some others > >> can start making baby steps, even if it's not all there. > > > > > > IMO automatic module names should only be declared after at least some > basic > > vetting that these modules will actually work when used as modules. If > > that's not the case, I wouldn't add these headers, as users rightfully > may > > consider their presence as endorsement of using them as modules. > > > > That said, I can't seem to find split packages between engine and orm. In > > fact I can launch an application with both of them on the module path > just > > fine. So there may be no problem actually? > > Interesting, I'm pretty sure we had some. We had several issues > resolved over time to resolve them, I never realized we might have > completed them all. The "line" defining what belongs where is still > blurry though, we should make sure this won't have future regressions. > Where I had problems with split packages was when exploring HSearch @ Java 9 modules last year was Lucene. In the version used back then (not sure whether it's still an issue today), there was a split package bet
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
The split package problem with Lucene won't easily go away, as we can't upgrade Lucene now. But I vaguely remember working with you on that, didn't we figure out that one of the Lucene modules wasn't essential? Either way, that's interesting to experiment with but we can't publish full modules as almost none of our dependencies are ready; they should at least all have an automatic module name. Thanks, Sanne On 12 February 2018 at 19:43, Gunnar Morling wrote: > > > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero : >> >> On 12 February 2018 at 18:00, Gunnar Morling wrote: >> > >> > >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : >> >> >> >> Picking automatic module names for Hibernate Search isn't going to be >> >> straight-forward as our two main jars (hibernate-search-engine & >> >> hibernate-search-orm) suffer from split package among them. >> >> >> >> We can't really fix the split package problem without breaking all >> >> users, so if we want to consider that, we can debate it but that will >> >> need to happen at another round as we're doing a minor release, so >> >> let's focus on: >> >> # Which names to pick >> >> # Should we pick the names at all >> >> # Which modules should have a name >> >> >> >> For a great background on the possible strategies and pitfalls I >> >> recommend reading Stephen Colebourne's blog on this subject [1]. >> >> He persuaded me there are good reasons to use the "reverse DNS, the >> >> top level package", however since we have the split package problem we >> >> can't simply go with that. >> >> >> >> Still, we can respect the principles he recommends with a small >> >> variation. It's fair to assume that the `org.hibernate.search` prefix >> >> is "ours"; since the nature of the suggestion is focused on making >> >> sure there are no misunderstandings in the community about which names >> >> you can choose - as there is no central authority making sure module >> >> names aren't clashing - we should be fine within Hibernate projects >> >> with any `org.hibernate.X` prefix, as long as we coordinate and reach >> >> an agreement on this list. >> >> >> >> So, I propose we use: >> >> >> >> Engine module: >> >> - org.hibernate.search.engine >> >> >> >> ORM integration module: >> >> - org.hibernate.search.orm >> >> >> > Those names sound good to me. >> > >> >> >> >> JGroups, JMS backends: >> >> [ no automatic module name ? Excepting some "guidelines" in the JMS >> >> module, these are not public API so nobody would benefit from it - >> >> also we think we might want to phase out the name "backend" in the >> >> future ] >> >> >> >> Elasticsearch integration module [hibernate-search-elasticsearch.jar]: >> >> - org.hibernate.search.elasticsearch >> >> >> >> Elasticsearch / AWS security integration: >> >> [ no automatic module name: no public API ] >> >> >> >> Serialization / Avro >> >> [ no automatic module name: no public API ] >> >> >> >> WDYT? >> > >> > >> > The user may still need to reference those modules when launching a >> > modularized application. Also if they don't directly declare say the JMS >> > backend as a dependence of their own module, they'd still have to >> > specify it >> > via --add-modules, so to resolve these additional modules and add them >> > to >> > the module graph. Hence I'd declare automatic module names for these, >> > too. >> >> Good point, I had not thought that our modules wouldn't be able to >> load other extensions from classpath. >> >> >> We could also pick names for the ones which I've listed as "no public >> >> API" but I see no point: as we're only assigning an "Automatic Module >> >> Name" we won't be able to explicitly state that the other modules >> >> depend on these. So nobody will use them, and things are a bit in flux >> >> anyway in this area because of Hibernate Search 6 plans. >> > >> > >> > I don't fully understand this paragraph. >> >> You mostly invalidated it with the previous comment, but what I meant >> is that we can't have the `org.hibernate.search.engine` declare a >> dependency on any implementation module, as we're not adding a >> module-info definition. >> >> >> Another optional altogether: since we have split packages which we'll >> >> have to resolve before we can actually transform these into fully >> >> fledged modules, I think an acceptable position is also to say we >> >> won't be publishing any automatic module name yet. Personally I'm >> >> inclined to go with the names suggested above, at least some others >> >> can start making baby steps, even if it's not all there. >> > >> > >> > IMO automatic module names should only be declared after at least some >> > basic >> > vetting that these modules will actually work when used as modules. If >> > that's not the case, I wouldn't add these headers, as users rightfully >> > may >> > consider their presence as endorsement of using them as modules. >> > >> > That said, I can't seem to find split packages between engine and orm. >> > In >> > fact I can launch an a
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
> IMO automatic module names should only be declared after at least some basic vetting that these modules will actually work when used as modules. If that's not the case, I wouldn't add these headers, as users rightfully may consider their presence as endorsement of using them as modules. If I understood correctly, automatic module names were introduced to facilitate the transition to Jigsaw modules. The point was to allow projects to give a name to their modules, and, yes, declare them as ready, but even if they couldn't be made full modules yet because of their dependencies. Declaring a name doesn't mean the module will work, it means it will work *when dependencies are fixed*. If we wait for all of our dependencies to work in a modular environment before we give a name to our modules, we may very well never do it because of circular dependencies ( Infinispan comes to mind: Infinispan-query depends on Search for, which depends on ORM, which depends on the Infinispan 2nd level cache provider). Declaring a full module-info.java is another matter, but as you mentioned, we simply can't do that yet because of split packages in Lucene. Back to naming... It looks good and consistent with the current naming our Maven artifacts. In 6, I would probably choose to rename the Elasticsearch one to something like org.hibernate.search..elasticsearch, but we still have to coin the right term for "", and I would probably rename the Maven artifact too, so that can wait. I think you forgot the JSR 352 integration, but I guess the name would be rather obvious: - org.hibernate.search.jsr352 As to non-public APIs, can you confirm automatic modules can access the classpath transparently? If so then I agree, no need to name those Except for the JMS backend: it is unusable without the user extending AbstractJMSHibernateSearchController, so this class at least must be exposed to the user. Even if it's just SPI. On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero wrote: > The split package problem with Lucene won't easily go away, as we > can't upgrade Lucene now. > > But I vaguely remember working with you on that, didn't we figure out > that one of the Lucene modules wasn't essential? > > Either way, that's interesting to experiment with but we can't publish > full modules as almost none of our dependencies are ready; they should > at least all have an automatic module name. > > Thanks, > Sanne > > On 12 February 2018 at 19:43, Gunnar Morling wrote: > > > > > > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero : > >> > >> On 12 February 2018 at 18:00, Gunnar Morling > wrote: > >> > > >> > > >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : > >> >> > >> >> Picking automatic module names for Hibernate Search isn't going to be > >> >> straight-forward as our two main jars (hibernate-search-engine & > >> >> hibernate-search-orm) suffer from split package among them. > >> >> > >> >> We can't really fix the split package problem without breaking all > >> >> users, so if we want to consider that, we can debate it but that will > >> >> need to happen at another round as we're doing a minor release, so > >> >> let's focus on: > >> >> # Which names to pick > >> >> # Should we pick the names at all > >> >> # Which modules should have a name > >> >> > >> >> For a great background on the possible strategies and pitfalls I > >> >> recommend reading Stephen Colebourne's blog on this subject [1]. > >> >> He persuaded me there are good reasons to use the "reverse DNS, the > >> >> top level package", however since we have the split package problem > we > >> >> can't simply go with that. > >> >> > >> >> Still, we can respect the principles he recommends with a small > >> >> variation. It's fair to assume that the `org.hibernate.search` prefix > >> >> is "ours"; since the nature of the suggestion is focused on making > >> >> sure there are no misunderstandings in the community about which > names > >> >> you can choose - as there is no central authority making sure module > >> >> names aren't clashing - we should be fine within Hibernate projects > >> >> with any `org.hibernate.X` prefix, as long as we coordinate and reach > >> >> an agreement on this list. > >> >> > >> >> So, I propose we use: > >> >> > >> >> Engine module: > >> >> - org.hibernate.search.engine > >> >> > >> >> ORM integration module: > >> >> - org.hibernate.search.orm > >> >> > >> > Those names sound good to me. > >> > > >> >> > >> >> JGroups, JMS backends: > >> >> [ no automatic module name ? Excepting some "guidelines" in the JMS > >> >> module, these are not public API so nobody would benefit from it - > >> >> also we think we might want to phase out the name "backend" in the > >> >> future ] > >> >> > >> >> Elasticsearch integration module > [hibernate-search-elasticsearch.jar]: > >> >> - org.hibernate.search.elasticsearch > >> >> > >> >> Elasticsearch / AWS security integration: > >> >> [ no automatic module name: no public API ] > >> >> > >> >> Serialization / Avro >
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
2018-02-13 0:37 GMT+01:00 Sanne Grinovero : > The split package problem with Lucene won't easily go away, as we > can't upgrade Lucene now. > > But I vaguely remember working with you on that, didn't we figure out > that one of the Lucene modules wasn't essential? > The split package is only between lucene.core and lucene.misc. I believe the latter is only needed for the uninverting index reader. So you could extract the functionality requiring the latter into its own HSearch module, and only this one would depend on lucene.misc. Then everything else should be usable as Java 9 modules, only that particular functionality won't be usable until we're on a Lucene version without that split package. For users on Java 8 nothing will change, apart from the fact that they'll have to add this additional dependency should they want to use the uninverting reader. But I think using the uninverting reader was a non-preferred fallback only anyways in case the index doesn't contain all doc fields required for sorting. So this seems like an acceptable compromise. > Either way, that's interesting to experiment with but we can't publish > full modules as almost none of our dependencies are ready; they should > at least all have an automatic module name. > > Thanks, > Sanne > > On 12 February 2018 at 19:43, Gunnar Morling wrote: > > > > > > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero : > >> > >> On 12 February 2018 at 18:00, Gunnar Morling > wrote: > >> > > >> > > >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : > >> >> > >> >> Picking automatic module names for Hibernate Search isn't going to be > >> >> straight-forward as our two main jars (hibernate-search-engine & > >> >> hibernate-search-orm) suffer from split package among them. > >> >> > >> >> We can't really fix the split package problem without breaking all > >> >> users, so if we want to consider that, we can debate it but that will > >> >> need to happen at another round as we're doing a minor release, so > >> >> let's focus on: > >> >> # Which names to pick > >> >> # Should we pick the names at all > >> >> # Which modules should have a name > >> >> > >> >> For a great background on the possible strategies and pitfalls I > >> >> recommend reading Stephen Colebourne's blog on this subject [1]. > >> >> He persuaded me there are good reasons to use the "reverse DNS, the > >> >> top level package", however since we have the split package problem > we > >> >> can't simply go with that. > >> >> > >> >> Still, we can respect the principles he recommends with a small > >> >> variation. It's fair to assume that the `org.hibernate.search` prefix > >> >> is "ours"; since the nature of the suggestion is focused on making > >> >> sure there are no misunderstandings in the community about which > names > >> >> you can choose - as there is no central authority making sure module > >> >> names aren't clashing - we should be fine within Hibernate projects > >> >> with any `org.hibernate.X` prefix, as long as we coordinate and reach > >> >> an agreement on this list. > >> >> > >> >> So, I propose we use: > >> >> > >> >> Engine module: > >> >> - org.hibernate.search.engine > >> >> > >> >> ORM integration module: > >> >> - org.hibernate.search.orm > >> >> > >> > Those names sound good to me. > >> > > >> >> > >> >> JGroups, JMS backends: > >> >> [ no automatic module name ? Excepting some "guidelines" in the JMS > >> >> module, these are not public API so nobody would benefit from it - > >> >> also we think we might want to phase out the name "backend" in the > >> >> future ] > >> >> > >> >> Elasticsearch integration module [hibernate-search- > elasticsearch.jar]: > >> >> - org.hibernate.search.elasticsearch > >> >> > >> >> Elasticsearch / AWS security integration: > >> >> [ no automatic module name: no public API ] > >> >> > >> >> Serialization / Avro > >> >> [ no automatic module name: no public API ] > >> >> > >> >> WDYT? > >> > > >> > > >> > The user may still need to reference those modules when launching a > >> > modularized application. Also if they don't directly declare say the > JMS > >> > backend as a dependence of their own module, they'd still have to > >> > specify it > >> > via --add-modules, so to resolve these additional modules and add them > >> > to > >> > the module graph. Hence I'd declare automatic module names for these, > >> > too. > >> > >> Good point, I had not thought that our modules wouldn't be able to > >> load other extensions from classpath. > >> > >> >> We could also pick names for the ones which I've listed as "no public > >> >> API" but I see no point: as we're only assigning an "Automatic Module > >> >> Name" we won't be able to explicitly state that the other modules > >> >> depend on these. So nobody will use them, and things are a bit in > flux > >> >> anyway in this area because of Hibernate Search 6 plans. > >> > > >> > > >> > I don't fully understand this paragraph. > >> > >> You mostly invalidated it with the previous commen
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
2018-02-13 9:44 GMT+01:00 Yoann Rodiere : > > IMO automatic module names should only be declared after at least some > basic vetting that these modules will actually work when used as modules. > If that's not the case, I wouldn't add these headers, as users rightfully > may consider their presence as endorsement of using them as modules. > > If I understood correctly, automatic module names were introduced to > facilitate the transition to Jigsaw modules. The point was to allow > projects to give a name to their modules, and, yes, declare them as ready, > but even if they couldn't be made full modules yet because of their > dependencies. Declaring a name doesn't mean the module will work, it means > it will work *when dependencies are fixed*. > How can you be sure of that though without trying it out? > If we wait for all of our dependencies to work in a modular environment > before we give a name to our modules, we may very well never do it because > of circular dependencies (Infinispan comes to mind: Infinispan-query depends > on Search for, which depends on ORM, which depends on the Infinispan 2nd > level cache provider). > If there are cycles, problems go far beyond finding good names. The default resolver will not allow cycles between modules. > Declaring a full module-info.java is another matter, but as you mentioned, > we simply can't do that yet because of split packages in Lucene. > > Back to naming... It looks good and consistent with the current naming our > Maven artifacts. In 6, I would probably choose to rename the Elasticsearch > one to something like org.hibernate.search..elasticsearch, > but we still have to coin the right term for "", and I > would probably rename the Maven artifact too, so that can wait. > > I think you forgot the JSR 352 integration, but I guess the name would be > rather obvious: > - org.hibernate.search.jsr352 > > As to non-public APIs, can you confirm automatic modules can access the > classpath transparently? If so then I agree, no need to name those > Except for the JMS backend: it is unusable without the user extending > AbstractJMSHibernateSearchController, so this class at least must be > exposed to the user. Even if it's just SPI. > Automatic modules can access the classpath (which is represented by the UNNAMED module, and all automatic modules read that). But I wouldn't recommend to rely on such mixed set-up as it's cumbersome to configure. For instance for an app with a module-info.java, Maven will put all dependencies to the module path when invoking javac; if you wanted to have some deps on the classpath and some on the module path, that'd be some manual effort. Hence my suggestion to give automatic module names to all of them and using them on the module path. > On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero wrote: > >> The split package problem with Lucene won't easily go away, as we >> can't upgrade Lucene now. >> >> But I vaguely remember working with you on that, didn't we figure out >> that one of the Lucene modules wasn't essential? >> >> Either way, that's interesting to experiment with but we can't publish >> full modules as almost none of our dependencies are ready; they should >> at least all have an automatic module name. >> >> Thanks, >> Sanne >> >> On 12 February 2018 at 19:43, Gunnar Morling >> wrote: >> > >> > >> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero : >> >> >> >> On 12 February 2018 at 18:00, Gunnar Morling >> wrote: >> >> > >> >> > >> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : >> >> >> >> >> >> Picking automatic module names for Hibernate Search isn't going to >> be >> >> >> straight-forward as our two main jars (hibernate-search-engine & >> >> >> hibernate-search-orm) suffer from split package among them. >> >> >> >> >> >> We can't really fix the split package problem without breaking all >> >> >> users, so if we want to consider that, we can debate it but that >> will >> >> >> need to happen at another round as we're doing a minor release, so >> >> >> let's focus on: >> >> >> # Which names to pick >> >> >> # Should we pick the names at all >> >> >> # Which modules should have a name >> >> >> >> >> >> For a great background on the possible strategies and pitfalls I >> >> >> recommend reading Stephen Colebourne's blog on this subject [1]. >> >> >> He persuaded me there are good reasons to use the "reverse DNS, the >> >> >> top level package", however since we have the split package problem >> we >> >> >> can't simply go with that. >> >> >> >> >> >> Still, we can respect the principles he recommends with a small >> >> >> variation. It's fair to assume that the `org.hibernate.search` >> prefix >> >> >> is "ours"; since the nature of the suggestion is focused on making >> >> >> sure there are no misunderstandings in the community about which >> names >> >> >> you can choose - as there is no central authority making sure module >> >> >> names aren't clashing - we should be fine within Hibernate projects >> >>
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
> How can you be sure of that though without trying it out? If what you meant by "work as modules" was "work as *automatic* modules" (i.e. with dependencies in the classpath), we already test that. We just happen to know they can't work as "full" modules (with module-info) yet. > If there are cycles, problems go far beyond finding good names. The default resolver will not allow cycles between modules. The cycles are merely between projects, not between modules. It's more a release issue than a technical issue. The problem arises mainly from the fact that Infinispan has two sides: the server, and the client libraries. I guess one way to do it would be for Infinispan to first switch to Jigsaw modules for their core modules and client library modules, then we do the switch on our side, then they can do the switch for their server modules. But I would expect such plan to be slower than switching to automatic modules first, then to full modules when every dependency is ready. In any case, there shouldn't be a problem at runtime, so it shouldn't prevent us from running Jigsaw modules once they are ready, but it's still a problem to do the switch to full Jigsaw modules. > Automatic modules can access the classpath (which is represented by the UNNAMED module, and all automatic modules read that). Thanks for confirming that. > But I wouldn't recommend to rely on such mixed set-up as it's cumbersome to configure. For instance for an app with a module-info.java, Maven will put all dependencies to the module path when invoking javac; if you wanted to have some deps on the classpath and some on the module path, that'd be some manual effort. Hence my suggestion to give automatic module names to all of them and using them on the module path. Let me get this straight: I want to just define automatic module names for our modules, but still rely exclusively on the classpath for our own dependencies, including internal ones (dependencies from one of our modules to another of our own modules). Are you saying this is not possible? I.e. once a jar is promoted to automatic module, it is not visible from other automatic modules anymore? Because the alternative doesn't seem workable either: declaring our dependencies as module dependencies (e.g. in a module-info) would not give us the option to have classpath dependencies (or would it?), and thus we would not be able to depend on Lucene... On Tue, 13 Feb 2018 at 10:08 Gunnar Morling wrote: > 2018-02-13 9:44 GMT+01:00 Yoann Rodiere : > >> > IMO automatic module names should only be declared after at least some >> basic vetting that these modules will actually work when used as modules. >> If that's not the case, I wouldn't add these headers, as users rightfully >> may consider their presence as endorsement of using them as modules. >> >> If I understood correctly, automatic module names were introduced to >> facilitate the transition to Jigsaw modules. The point was to allow >> projects to give a name to their modules, and, yes, declare them as ready, >> but even if they couldn't be made full modules yet because of their >> dependencies. Declaring a name doesn't mean the module will work, it means >> it will work *when dependencies are fixed*. >> > > How can you be sure of that though without trying it out? > > >> If we wait for all of our dependencies to work in a modular environment >> before we give a name to our modules, we may very well never do it because >> of circular dependencies (Infinispan comes to mind: Infinispan-query depends >> on Search for, which depends on ORM, which depends on the Infinispan 2nd >> level cache provider). >> > > If there are cycles, problems go far beyond finding good names. The > default resolver will not allow cycles between modules. > > >> Declaring a full module-info.java is another matter, but as you >> mentioned, we simply can't do that yet because of split packages in Lucene. >> >> Back to naming... It looks good and consistent with the current naming >> our Maven artifacts. In 6, I would probably choose to rename the >> Elasticsearch one to something like >> org.hibernate.search..elasticsearch, but we still have >> to coin the right term for "", and I would probably >> rename the Maven artifact too, so that can wait. >> >> I think you forgot the JSR 352 integration, but I guess the name would be >> rather obvious: >> - org.hibernate.search.jsr352 >> >> As to non-public APIs, can you confirm automatic modules can access the >> classpath transparently? If so then I agree, no need to name those >> Except for the JMS backend: it is unusable without the user extending >> AbstractJMSHibernateSearchController, >> so this class at least must be exposed to the user. Even if it's just SPI. >> > > Automatic modules can access the classpath (which is represented by the > UNNAMED module, and all automatic modules read that). > > But I wouldn't recommend to rely on such mixed set-up as it's cumbersome > to configure. For instance for a
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
On 13 February 2018 at 08:44, Yoann Rodiere wrote: >> IMO automatic module names should only be declared after at least some > basic vetting that these modules will actually work when used as modules. > If that's not the case, I wouldn't add these headers, as users rightfully > may consider their presence as endorsement of using them as modules. > > If I understood correctly, automatic module names were introduced to > facilitate the transition to Jigsaw modules. The point was to allow projects > to give a name to their modules, and, yes, declare them as ready, but even > if they couldn't be made full modules yet because of their dependencies. > Declaring a name doesn't mean the module will work, it means it will work > when dependencies are fixed. If we wait for all of our dependencies to work > in a modular environment before we give a name to our modules, we may very > well never do it because of circular dependencies (Infinispan comes to mind: > Infinispan-query depends on Search for, which depends on ORM, which depends > on the Infinispan 2nd level cache provider). > Declaring a full module-info.java is another matter, but as you mentioned, > we simply can't do that yet because of split packages in Lucene. Understood and agree. We should add the automatic module names to get people unstuck, and I wouldn't propose this if I didn't have enough confidence that they should work: we have some basic tests. > Back to naming... It looks good and consistent with the current naming our > Maven artifacts. In 6, I would probably choose to rename the Elasticsearch > one to something like > org.hibernate.search..elasticsearch, but we still have > to coin the right term for "", and I would probably > rename the Maven artifact too, so that can wait. > > I think you forgot the JSR 352 integration, but I guess the name would be > rather obvious: > - org.hibernate.search.jsr352 +1, thanks > As to non-public APIs, can you confirm automatic modules can access the > classpath transparently? If so then I agree, no need to name those > Except for the JMS backend: it is unusable without the user extending > AbstractJMSHibernateSearchController, so this class at least must be exposed > to the user. Even if it's just SPI. That's the "guidelines" I was referring to in my first email. We could give it a name, so let's suggest one, but I feel like this is not essential as while we suggest people to extend our SPI, there are alternatives to that. I wanted to avoid this one at a first shot as it might be controversial ;) Proposed name: - org.hibernate.search.jms-support Why: # I'd like to avoid using "backend" in the name. # Makes it clear this is the module you want to add when you're into JMS - or at the opposite if your system doesn't care about JMS. IMO the goal of Jigsaw modules is to trim a system from unnecessary stuff, so having the names express what kind of technologies it brings in is most helpful. Thanks, Sanne > On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero wrote: >> >> The split package problem with Lucene won't easily go away, as we >> can't upgrade Lucene now. >> >> But I vaguely remember working with you on that, didn't we figure out >> that one of the Lucene modules wasn't essential? >> >> Either way, that's interesting to experiment with but we can't publish >> full modules as almost none of our dependencies are ready; they should >> at least all have an automatic module name. >> >> Thanks, >> Sanne >> >> On 12 February 2018 at 19:43, Gunnar Morling wrote: >> > >> > >> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero : >> >> >> >> On 12 February 2018 at 18:00, Gunnar Morling >> >> wrote: >> >> > >> >> > >> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : >> >> >> >> >> >> Picking automatic module names for Hibernate Search isn't going to >> >> >> be >> >> >> straight-forward as our two main jars (hibernate-search-engine & >> >> >> hibernate-search-orm) suffer from split package among them. >> >> >> >> >> >> We can't really fix the split package problem without breaking all >> >> >> users, so if we want to consider that, we can debate it but that >> >> >> will >> >> >> need to happen at another round as we're doing a minor release, so >> >> >> let's focus on: >> >> >> # Which names to pick >> >> >> # Should we pick the names at all >> >> >> # Which modules should have a name >> >> >> >> >> >> For a great background on the possible strategies and pitfalls I >> >> >> recommend reading Stephen Colebourne's blog on this subject [1]. >> >> >> He persuaded me there are good reasons to use the "reverse DNS, the >> >> >> top level package", however since we have the split package problem >> >> >> we >> >> >> can't simply go with that. >> >> >> >> >> >> Still, we can respect the principles he recommends with a small >> >> >> variation. It's fair to assume that the `org.hibernate.search` >> >> >> prefix >> >> >> is "ours"; since the nature of the suggestion is focused on making >> >> >> sure there are
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
> - org.hibernate.search.jms-support Not sure it's a valid name (aren't hyphens forbidden in package names, and aren't module names constrained by the same rules?), but apart from that it looks good. Maybe "jms_support" instead, if "jms-support" is not allowed. I would like to find a name for what the JMS and JGroups modules provide in Hibernate Search 6 though, something less misleading than "backend". Something like "work routing" or "clustering support" or "distribution support" or whatever. Would you be ok with changing the module name in 6? If not, maybe we have to think about it now... Note that we'll change the Maven group ID anyway, so it's arguably just another breaking change. On Tue, 13 Feb 2018 at 11:43 Sanne Grinovero wrote: > On 13 February 2018 at 08:44, Yoann Rodiere wrote: > >> IMO automatic module names should only be declared after at least some > > basic vetting that these modules will actually work when used as modules. > > If that's not the case, I wouldn't add these headers, as users rightfully > > may consider their presence as endorsement of using them as modules. > > > > If I understood correctly, automatic module names were introduced to > > facilitate the transition to Jigsaw modules. The point was to allow > projects > > to give a name to their modules, and, yes, declare them as ready, but > even > > if they couldn't be made full modules yet because of their dependencies. > > Declaring a name doesn't mean the module will work, it means it will work > > when dependencies are fixed. If we wait for all of our dependencies to > work > > in a modular environment before we give a name to our modules, we may > very > > well never do it because of circular dependencies (Infinispan comes to > mind: > > Infinispan-query depends on Search for, which depends on ORM, which > depends > > on the Infinispan 2nd level cache provider). > > Declaring a full module-info.java is another matter, but as you > mentioned, > > we simply can't do that yet because of split packages in Lucene. > > Understood and agree. We should add the automatic module names to get > people unstuck, and I wouldn't propose this if I didn't have enough > confidence that they should work: we have some basic tests. > > > > Back to naming... It looks good and consistent with the current naming > our > > Maven artifacts. In 6, I would probably choose to rename the > Elasticsearch > > one to something like > > org.hibernate.search..elasticsearch, but we still > have > > to coin the right term for "", and I would probably > > rename the Maven artifact too, so that can wait. > > > > I think you forgot the JSR 352 integration, but I guess the name would be > > rather obvious: > > - org.hibernate.search.jsr352 > > +1, thanks > > > > As to non-public APIs, can you confirm automatic modules can access the > > classpath transparently? If so then I agree, no need to name those > > Except for the JMS backend: it is unusable without the user extending > > AbstractJMSHibernateSearchController, so this class at least must be > exposed > > to the user. Even if it's just SPI. > > That's the "guidelines" I was referring to in my first email. > We could give it a name, so let's suggest one, but I feel like this is > not essential as while we suggest people to extend our SPI, there are > alternatives to that. > I wanted to avoid this one at a first shot as it might be controversial ;) > > Proposed name: > - org.hibernate.search.jms-support > > Why: > # I'd like to avoid using "backend" in the name. > # Makes it clear this is the module you want to add when you're into > JMS - or at the opposite if your system doesn't care about JMS. > > IMO the goal of Jigsaw modules is to trim a system from unnecessary > stuff, so having the names express what kind of technologies it brings > in is most helpful. > > Thanks, > Sanne > > > On Tue, 13 Feb 2018 at 00:39 Sanne Grinovero > wrote: > >> > >> The split package problem with Lucene won't easily go away, as we > >> can't upgrade Lucene now. > >> > >> But I vaguely remember working with you on that, didn't we figure out > >> that one of the Lucene modules wasn't essential? > >> > >> Either way, that's interesting to experiment with but we can't publish > >> full modules as almost none of our dependencies are ready; they should > >> at least all have an automatic module name. > >> > >> Thanks, > >> Sanne > >> > >> On 12 February 2018 at 19:43, Gunnar Morling > wrote: > >> > > >> > > >> > 2018-02-12 19:28 GMT+01:00 Sanne Grinovero : > >> >> > >> >> On 12 February 2018 at 18:00, Gunnar Morling > >> >> wrote: > >> >> > > >> >> > > >> >> > 2018-02-12 17:55 GMT+01:00 Sanne Grinovero : > >> >> >> > >> >> >> Picking automatic module names for Hibernate Search isn't going to > >> >> >> be > >> >> >> straight-forward as our two main jars (hibernate-search-engine & > >> >> >> hibernate-search-orm) suffer from split package among them. > >> >> >> > >> >> >> We can't really fix the split package probl
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
2018-02-13 11:04 GMT+01:00 Yoann Rodiere : > > How can you be sure of that though without trying it out? > > If what you meant by "work as modules" was "work as *automatic* modules" > (i.e. with dependencies in the classpath), we already test that. We just > happen to know they can't work as "full" modules (with module-info) yet. > Automatic modules don't imply "dependencies in the classpath". While they *can* read everything from the unnamed module, they also read all resolved real modules (automatic or named ones). I'd recommend to gain some certainty that things work when only using the module path. As said, tool support isn't great for mixing them from what I know. > > > If there are cycles, problems go far beyond finding good names. The > default resolver will not allow cycles between modules. > > The cycles are merely between projects, not between modules. It's more a > release issue than a technical issue. The problem arises mainly from the > fact that Infinispan has two sides: the server, and the client libraries. I > guess one way to do it would be for Infinispan to first switch to Jigsaw > modules for their core modules and client library modules, then we do the > switch on our side, then they can do the switch for their server modules. > But I would expect such plan to be slower than switching to automatic > modules first, then to full modules when every dependency is ready. > In any case, there shouldn't be a problem at runtime, so it shouldn't > prevent us from running Jigsaw modules once they are ready, but it's still > a problem to do the switch to full Jigsaw modules. > > > Automatic modules can access the classpath (which is represented by the > UNNAMED module, and all automatic modules read that). > > Thanks for confirming that. > > > But I wouldn't recommend to rely on such mixed set-up as it's cumbersome > to configure. For instance for an app with a module-info.java, Maven will > put all dependencies to the module path when invoking javac; if you wanted > to have some deps on the classpath and some on the module path, that'd be > some manual effort. Hence my suggestion to give automatic module names to > all of them and using them on the module path. > > Let me get this straight: I want to just define automatic module names > for our modules, but still rely exclusively on the classpath for our own > dependencies, including internal ones (dependencies from one of our modules > to another of our own modules). > Are you saying this is not possible? > No, that's not what I'm saying. This is possible, but it's not what I'd recommend. I.e. also the backends should be provided on the module path, and for that they should have defined automatic module names, so users don't need to reference implict names in their --add-modules options. > I.e. once a jar is promoted to automatic module, it is not visible from > other automatic modules anymore? > No, see above. Because the alternative doesn't seem workable either: declaring our > dependencies as module dependencies (e.g. in a module-info) would not give > us the option to have classpath dependencies (or would it?), and thus we > would not be able to depend on Lucene... > I'm not quite following on this reasoning. But yes, a named module shouldn't depend on the UNNAMED module. But as per my previous mail you should be able to use Lucene as automatic modules (i.e. on the module path) as long as you exclude the lucene.misc module which shouldn't be too difficult as described. > > > > On Tue, 13 Feb 2018 at 10:08 Gunnar Morling wrote: > >> 2018-02-13 9:44 GMT+01:00 Yoann Rodiere : >> >>> > IMO automatic module names should only be declared after at least some >>> basic vetting that these modules will actually work when used as modules. >>> If that's not the case, I wouldn't add these headers, as users rightfully >>> may consider their presence as endorsement of using them as modules. >>> >>> If I understood correctly, automatic module names were introduced to >>> facilitate the transition to Jigsaw modules. The point was to allow >>> projects to give a name to their modules, and, yes, declare them as ready, >>> but even if they couldn't be made full modules yet because of their >>> dependencies. Declaring a name doesn't mean the module will work, it means >>> it will work *when dependencies are fixed*. >>> >> >> How can you be sure of that though without trying it out? >> >> >>> If we wait for all of our dependencies to work in a modular environment >>> before we give a name to our modules, we may very well never do it because >>> of circular dependencies (Infinispan comes to mind: Infinispan-query depends >>> on Search for, which depends on ORM, which depends on the Infinispan 2nd >>> level cache provider). >>> >> >> If there are cycles, problems go far beyond finding good names. The >> default resolver will not allow cycles between modules. >> >> >>> Declaring a full module-info.java is another matter, but as you >>> mentioned, we simpl
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
On Tue, Feb 13, 2018 at 11:59 AM, Yoann Rodiere wrote: > > - org.hibernate.search.jms-support > > Not sure it's a valid name (aren't hyphens forbidden in package names, and > aren't module names constrained by the same rules?), but apart from that it > looks good. Maybe "jms_support" instead, if "jms-support" is not allowed. > I would like to find a name for what the JMS and JGroups modules provide in > Hibernate Search 6 though, something less misleading than "backend". > Something like "work routing" or "clustering support" or "distribution > support" or whatever. Would you be ok with changing the module name in 6? > If not, maybe we have to think about it now... Note that we'll change the > Maven group ID anyway, so it's arguably just another breaking change. > +1 to find a distinctive name for JGroups and JMS artifacts and same for Lucene and Elasticsearch (either this round or for 6). org.hibernate.search.clustering.jms org.hibernate.search.clustering.jgroups and org.hibernate.search.indexing.lucene org.hibernate.search.indexing.elasticsearch would be my choice as it's very understandable by the end user. It might be an orthogonal discussion so feel free to ignore me :). -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
On 13 February 2018 at 11:48, Guillaume Smet wrote: > On Tue, Feb 13, 2018 at 11:59 AM, Yoann Rodiere wrote: >> >> > - org.hibernate.search.jms-support >> >> Not sure it's a valid name (aren't hyphens forbidden in package names, and >> aren't module names constrained by the same rules?), but apart from that >> it >> looks good. Maybe "jms_support" instead, if "jms-support" is not allowed. >> I would like to find a name for what the JMS and JGroups modules provide >> in >> Hibernate Search 6 though, something less misleading than "backend". >> Something like "work routing" or "clustering support" or "distribution >> support" or whatever. Would you be ok with changing the module name in 6? >> If not, maybe we have to think about it now... Note that we'll change the >> Maven group ID anyway, so it's arguably just another breaking change. > > > +1 to find a distinctive name for JGroups and JMS artifacts and same for > Lucene and Elasticsearch (either this round or for 6). > > org.hibernate.search.clustering.jms > org.hibernate.search.clustering.jgroups > > and > > org.hibernate.search.indexing.lucene > org.hibernate.search.indexing.elasticsearch > > would be my choice as it's very understandable by the end user. Great names! I'll take them. These will allow us to gracefully phase out the backend terminology, and also suggest the additional dependency tree they will pull in. > > It might be an orthogonal discussion so feel free to ignore me :). > > -- > Guillaume > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
Since the names are about to be set in stone, and there has been some
discussion off list, I'd like to talk a bit about the Elasticsearch/Lucene
module names...
In the Search 6 architecture, these modules really provide a "backend",
i.e. a component that actually implements indexing/querying over multiple
indexes, but operates "behind" the engine (the engine uses the backend).
Essentially the data flow is:
Indexing: User => Mapper (user APIs) => Engine => Backend => Disk/network
Querying: User <= Mapper (user APIs) <= Engine <= Backend <= Disk/network
We discussed it a bit with Sanne (and with Guillaume) and agreed that
"backend" was the right word for this part of our architecture.
Now, the discussion is about module names, not component names.
Still, there are several reasons because of which I'd rather use
"org.hibernate.search.backend.":
- It is closer to how we will probably refer to the module on a
day-to-day basis: I don't know about you, but I'll probably talk about "the
Elasticsearch backend" rather than "Elasticsearch indexing" or "the
Elasticsearch module".
- It is generic enough to cover all of the tasks we delegate to
Elasticsearch/Lucene.
"org.hibernate.search.indexing.",
on the other hand, feels like it's only about indexing, and not querying,
maybe not even about defining a schema.
- It is consistent with our architecture and APIs in Search 6:
- The main component (and entry point) in those modules will be an
object implementing BackendImplementor (SPI)
- We will actually expose "backends" as part of our Java APIs, for
instance to allow users to retrieve the Elasticsearch client, or to query
some backend-scoped metadata.
- We will also use the word "backend" in the user configuration,
where the user will have to define a backend, its type and its options
using the "hibernate.search.backends..*" properties
- As opposed to the "prefix-less" naming scheme
("org.hibernate.search."), it makes it easy to infer
what the module actually provides to users: the actual implementation
behind Hibernate Search, even without extensive knowledge about Hibernate
Search.
- When listing all the modules of Hibernate Search, it makes it easy
to spot which module is about what, and which modules provide the same
thing using a different technology:
org.hibernate.search.engine
org.hibernate.search.orm
org.hibernate.search.clustering.jms
org.hibernate.search.clustering.jgroups
org.hibernate.search.backend.elasticsearch
org.hibernate.search.backend.lucene
vs:
org.hibernate.search.engine
org.hibernate.search.orm
org.hibernate.search.jms
org.hibernate.search.jgroups
org.hibernate.search.elasticsearch
org.hibernate.search.lucene
- When the module name appears in some error message (for instance
when a user starts experimenting with Java 9), it will also make it clear
which part of Hibernate Search is misconfigured. And that may be
important
to some users, since not all the people working on an application
know the details of every part of the application...
Of course, in the meantime in Search 5, there will be some confusion due to
the fact "backend" has a different meaning in Search 5.
If you are worried about that, I'm not opposed to slightly altering the
module names between Search 5 and Search 6: users will have to make changes
when migrating anyway.
In particular, a lot of APIs will change, some class may be moved to
different packages to comply the "no split package" constraint of Java 9,
Maven coordinates will change to use the "org.hibernate.search" group ID
instead of "org.hibernate", and people using the Lucene backend will have
to depend on a new module (both in their Maven dependencies and in their
Java 9 module dependencies).
So we could just use "org.hibernate.elasticsearch" in Search 5, and switch
to "org.hibernate.backend.elasticsearch" in Search 6. It's not even a big
deal, since the Elastisearch module is openly advertised as experimental.
On Tue, 13 Feb 2018 at 22:51 Sanne Grinovero wrote:
> On 13 February 2018 at 11:48, Guillaume Smet
> wrote:
> > On Tue, Feb 13, 2018 at 11:59 AM, Yoann Rodiere
> wrote:
> >>
> >> > - org.hibernate.search.jms-support
> >>
> >> Not sure it's a valid name (aren't hyphens forbidden in package names,
> and
> >> aren't module names constrained by the same rules?), but apart from that
> >> it
> >> looks good. Maybe "jms_support" instead, if "jms-support" is not
> allowed.
> >> I would like to find a name for what the JMS and JGroups modules provide
> >> in
> >> Hibernate Search 6 though, something less misleading than "backend".
> >> Something like "work routing" or "clustering support" or "distribution
> >> support" or whatever. Would you be ok with changing the module name in
> 6?
> >> If not, maybe we have to think about it now... Note th
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
On Thu, May 3, 2018 at 2:17 PM, Yoann Rodiere wrote: > Still, there are several reasons because of which I'd rather use > "org.hibernate.search.backend.": > >- It is closer to how we will probably refer to the module on a >day-to-day basis: I don't know about you, but I'll probably talk about "the >Elasticsearch backend" rather than "Elasticsearch indexing" or "the >Elasticsearch module". > > So, you might remember that I was the one proposing "indexing.elasticsearch" and this is the main argument that convinced me. > >- It is consistent with our architecture and APIs in Search 6: > - The main component (and entry point) in those modules will be an > object implementing BackendImplementor (SPI) > - We will actually expose "backends" as part of our Java APIs, for > instance to allow users to retrieve the Elasticsearch client, or to > query > some backend-scoped metadata. > - We will also use the word "backend" in the user configuration, > where the user will have to define a backend, its type and its options > using the "hibernate.search.backends..*" properties > > + this one. We can use whatever name we want for Search 5 but I think the "backend" choice is pretty obvious for Search 6. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
Ok, I surrender. so it's going to be `org.hibernate.search.backend.elasticsearch`. Even if it's not ideal in the context of Hibernate Search 5.x, IMO long term stability is more important for people. For the record I still think this tendency to over-qualify things and add many prefixes should be put under control. I totally understand it makes sense to "us" but please make an effort to look at how people use things: for users this is just "the ES stuff", but whatever they won't care about the prefix anyway :) Remember this though: when you'll want to include include more than just the backend bits in this module you will have resistance against changing the name. Thanks, Sanne On 3 May 2018 at 13:26, Guillaume Smet wrote: > On Thu, May 3, 2018 at 2:17 PM, Yoann Rodiere wrote: >> >> Still, there are several reasons because of which I'd rather use >> "org.hibernate.search.backend.": >> >> It is closer to how we will probably refer to the module on a day-to-day >> basis: I don't know about you, but I'll probably talk about "the >> Elasticsearch backend" rather than "Elasticsearch indexing" or "the >> Elasticsearch module". > > > So, you might remember that I was the one proposing "indexing.elasticsearch" > and this is the main argument that convinced me. > >> >> It is consistent with our architecture and APIs in Search 6: >> >> The main component (and entry point) in those modules will be an object >> implementing BackendImplementor (SPI) >> We will actually expose "backends" as part of our Java APIs, for instance >> to allow users to retrieve the Elasticsearch client, or to query some >> backend-scoped metadata. >> We will also use the word "backend" in the user configuration, where the >> user will have to define a backend, its type and its options using the >> "hibernate.search.backends..*" properties > > > + this one. > > We can use whatever name we want for Search 5 but I think the "backend" > choice is pretty obvious for Search 6. > > -- > Guillaume > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
