Re: [hibernate-dev] ORM 5.1 vs compatibility with Java 6

[Gail Badner]

Hi Sanne,

I didn't notice the failures either. I've been running it with JAVA6_HOME
pointing to jdk7, but I can't remember why I would have changed it to that.

It sounds like 5.1 branch will be a product branch for a while, so if it's
easy to make it compatible to JDK6, then I'd prefer to do that.

It looks like there are only 2 failures:
1) an unused import for import java.util.Objects, which is easily deleted.
2) ReflectHelper#JAVA_CONSTANT_PATTERN uses java.util.regex.
Pattern.UNICODE_CHARACTER_CLASS.

Vlad, is there some other flag that can be used that is compatible with
JDK6? If not, is there some other reasonable flag that we can use instead?

Regards,
Gail

On Tue, Feb 13, 2018 at 9:24 AM, Sanne Grinovero 
wrote:

> Is Hibernate ORM 5.1 still meant to be compatible with Java 6?
>
> The readme seems to promise that it should be, but it's not: I
> happened to try compiling it and it failed, as some recent changes are
> using JDK classes which have been introduced in 7.
>
> Turns out it builds fine for Andrea an Chris, as they don't have the
> JAVA6_HOME variable set: in this case the build will be lenient: log a
> warning and move on.
>
> I guess the same was done by all others on the team? CI is not
> checking this either.
>
> Wondering if you all feel like it's worth fixing branch 5.1, or if
> it's a dead branch anyway.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] module org.hibernate.commons.annotations

[Steve Ebersole]

+1

On Tue, Feb 13, 2018, 3:42 PM Sanne Grinovero  wrote:

> I'd like to release an Hibernate Commons Annotations version
> 5.0.2.Final to declare its Jigsaw module name as an automatic module
> name. Version 6 - whihch I proposed in a different thread - should
> then use this module but have a proper module definition.
>
> Is module name `org.hibernate.commons.annotations` acceptable for you all?
>
> Incidentally, there happens to be another nice improvement in branch
> 5.0 which was never released so it would be nice to upgrade to this
> version even if you have no interest in modularity yet.
>
> As soon as there's agreement on the module name I'll release it.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] module org.hibernate.commons.annotations

[Sanne Grinovero]

I'd like to release an Hibernate Commons Annotations version
5.0.2.Final to declare its Jigsaw module name as an automatic module
name. Version 6 - whihch I proposed in a different thread - should
then use this module but have a proper module definition.

Is module name `org.hibernate.commons.annotations` acceptable for you all?

Incidentally, there happens to be another nice improvement in branch
5.0 which was never released so it would be nice to upgrade to this
version even if you have no interest in modularity yet.

As soon as there's agreement on the module name I'll release it.

Thanks,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] ORM 5.1 vs compatibility with Java 6

[Sanne Grinovero]

Is Hibernate ORM 5.1 still meant to be compatible with Java 6?

The readme seems to promise that it should be, but it's not: I
happened to try compiling it and it failed, as some recent changes are
using JDK classes which have been introduced in 7.

Turns out it builds fine for Andrea an Chris, as they don't have the
JAVA6_HOME variable set: in this case the build will be lenient: log a
warning and move on.

I guess the same was done by all others on the team? CI is not
checking this either.

Wondering if you all feel like it's worth fixing branch 5.1, or if
it's a dead branch anyway.

Thanks,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate OGM 5.3 CR1 released

[Fabio Massimo Ercoli]

HIbernate OGM 5.3 CR1 is ready!

The major improvement was the version upgrade for Hibernate ORM
(5.2.13.Final) and Hibernate Search (5.9.0.Final).
The application of Clustered Counters, for Infinispan Embedded dialect, has
been improved in this version.

All the details in the blog post:
http://in.relation.to/2018/02/13/hibernate-ogm-5-3-CR1-released/

Thanks, ​Fabio
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

Hi,

Here are the minutes of our biweekly meeting:

16:01 < jbott> Meeting ended Tue Feb 13 15:01:26 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:01 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-13-14.07.html
16:01 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-13-14.07.txt
16:01 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-02-13-14.07.log.html

Have a nice day.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM CI jobs - erroneous github triggers

[Davide D'Alto]

I can have a look at this issue.

If you have any suggestions, let me know.

Thanks

On Tue, Feb 13, 2018 at 2:22 PM, Sanne Grinovero  wrote:
> Unfortunately we have to reopen this thread. The issue is affecting us
> again (since some weeks I think) and in larger scale, affecting all
> builds. I guess it means the previous workaround is no longer
> effective after some of the recent Jenkins / plugins updates.
>
> On IRC we where wondering if we could fix this issue ourselves, or if
> it's even possible with the metadata that GitHub provides. I'm not
> sure of that but since we have the impression this previously worked
> fine, maybe the metadata is available?
>
> I won't have time for this this week but if someone else wishes to
> look into it I can give some pointers, let me know.
>
> Thanks,
> Sanne
>
>
> On 4 January 2018 at 12:09, Sanne Grinovero  wrote:
>> Also these jobs were configured to build automatically every 5 hours:
>>  - hibernate-orm-4.2-h2
>>  - hibernate-orm-4.3-h2
>>
>> I removed the schedule, they will be built when (and only when)
>> anything is committed to their respective branches.
>>
>>
>> On 3 January 2018 at 19:15, Steve Ebersole  wrote:
>>> Nice!  Glad you found something.  Thanks for making the changes.
>>>
>>>
>>>
>>> On Wed, Jan 3, 2018 at 12:16 PM Sanne Grinovero  wrote:

 I've made the change on:
- hibernate-orm-5.0-h2
- hibernate-orm-5.1-h2
- hibernate-orm-master-h2-main

 Let's see if it helps, then we can figure out a way to check all jobs
 are using this workaround.


 On 3 January 2018 at 18:12, Sanne Grinovero  wrote:
 > Hi Steve,
 >
 > this rings a bell, we had this bug in the past and apparently it's
 > regressed again :(
 >
 > The latest Jenkins bug seems to be:
 >  - https://issues.jenkins-ci.org/browse/JENKINS-42161
 >
 > I'll try the suggested workarount, aka to enable SCM poll without any
 > frequency.
 >
 > Thanks,
 > Sanne
 >
 >
 > On 3 January 2018 at 17:35, Steve Ebersole  wrote:
 >> So I just pushed to the ORM master branch, which has caused the
 >> following
 >> jobs to be queued up:
 >>
 >>
 >>- hibernate-orm-5.0-h2
 >>- hibernate-orm-5.1-h2
 >>- hibernate-orm-master-h2-main
 >>
 >> Only one of those jobs is configured to "watch" master.  So why do
 >> these
 >> other jobs keep getting triggered?
 >>
 >> I see the same exact thing on my personal fork as well.  At the same
 >> time I
 >> pushed to my fork's 5.3 branch, which triggered the 6.0 job to be
 >> queued.
 >>
 >>
 >>
 >> On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole 
 >> wrote:
 >>
 >>> The legacy ORM jobs (5.1-based ones at least) are getting triggered
 >>> when
 >>> they should not be.  Generally they all show they the run is triggered
 >>> by a
 >>> "SCM change", but it does not show any changes.  The underlying
 >>> problem
 >>> (although I am at a loss as to why) is that there has indeed been SCM
 >>> changes pushed to Github, but against completely different branches.
 >>> As
 >>> far as I can tell these job's Github setting are correct.  Any ideas
 >>> what
 >>> is going on?
 >>>
 >>> This would not be such a big deal if the CI environment did not
 >>> throttle
 >>> all waiting jobs down to one active job.  So the jobs I am actually
 >>> interested in are forced to wait (sometimes over an hour) for these
 >>> jobs
 >>> that should not even be running.
 >>>
 >>>
 >>>
 >> ___
 >> hibernate-dev mailing list
 >> hibernate-dev@lists.jboss.org
 >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM CI jobs - erroneous github triggers

[Sanne Grinovero]

Unfortunately we have to reopen this thread. The issue is affecting us
again (since some weeks I think) and in larger scale, affecting all
builds. I guess it means the previous workaround is no longer
effective after some of the recent Jenkins / plugins updates.

On IRC we where wondering if we could fix this issue ourselves, or if
it's even possible with the metadata that GitHub provides. I'm not
sure of that but since we have the impression this previously worked
fine, maybe the metadata is available?

I won't have time for this this week but if someone else wishes to
look into it I can give some pointers, let me know.

Thanks,
Sanne


On 4 January 2018 at 12:09, Sanne Grinovero  wrote:
> Also these jobs were configured to build automatically every 5 hours:
>  - hibernate-orm-4.2-h2
>  - hibernate-orm-4.3-h2
>
> I removed the schedule, they will be built when (and only when)
> anything is committed to their respective branches.
>
>
> On 3 January 2018 at 19:15, Steve Ebersole  wrote:
>> Nice!  Glad you found something.  Thanks for making the changes.
>>
>>
>>
>> On Wed, Jan 3, 2018 at 12:16 PM Sanne Grinovero  wrote:
>>>
>>> I've made the change on:
>>>- hibernate-orm-5.0-h2
>>>- hibernate-orm-5.1-h2
>>>- hibernate-orm-master-h2-main
>>>
>>> Let's see if it helps, then we can figure out a way to check all jobs
>>> are using this workaround.
>>>
>>>
>>> On 3 January 2018 at 18:12, Sanne Grinovero  wrote:
>>> > Hi Steve,
>>> >
>>> > this rings a bell, we had this bug in the past and apparently it's
>>> > regressed again :(
>>> >
>>> > The latest Jenkins bug seems to be:
>>> >  - https://issues.jenkins-ci.org/browse/JENKINS-42161
>>> >
>>> > I'll try the suggested workarount, aka to enable SCM poll without any
>>> > frequency.
>>> >
>>> > Thanks,
>>> > Sanne
>>> >
>>> >
>>> > On 3 January 2018 at 17:35, Steve Ebersole  wrote:
>>> >> So I just pushed to the ORM master branch, which has caused the
>>> >> following
>>> >> jobs to be queued up:
>>> >>
>>> >>
>>> >>- hibernate-orm-5.0-h2
>>> >>- hibernate-orm-5.1-h2
>>> >>- hibernate-orm-master-h2-main
>>> >>
>>> >> Only one of those jobs is configured to "watch" master.  So why do
>>> >> these
>>> >> other jobs keep getting triggered?
>>> >>
>>> >> I see the same exact thing on my personal fork as well.  At the same
>>> >> time I
>>> >> pushed to my fork's 5.3 branch, which triggered the 6.0 job to be
>>> >> queued.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jan 2, 2018 at 1:54 PM Steve Ebersole 
>>> >> wrote:
>>> >>
>>> >>> The legacy ORM jobs (5.1-based ones at least) are getting triggered
>>> >>> when
>>> >>> they should not be.  Generally they all show they the run is triggered
>>> >>> by a
>>> >>> "SCM change", but it does not show any changes.  The underlying
>>> >>> problem
>>> >>> (although I am at a loss as to why) is that there has indeed been SCM
>>> >>> changes pushed to Github, but against completely different branches.
>>> >>> As
>>> >>> far as I can tell these job's Github setting are correct.  Any ideas
>>> >>> what
>>> >>> is going on?
>>> >>>
>>> >>> This would not be such a big deal if the CI environment did not
>>> >>> throttle
>>> >>> all waiting jobs down to one active job.  So the jobs I am actually
>>> >>> interested in are forced to wait (sometimes over an hour) for these
>>> >>> jobs
>>> >>> that should not even be running.
>>> >>>
>>> >>>
>>> >>>
>>> >> ___
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev@lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Laurent Almeras]

Thanks for your feedback.

As I currently use QueryDSL generated queries, it's not easy to switch 
the way my queries are generated.

I post an issue with a github branch with some simple test-cases here: 
https://hibernate.atlassian.net/browse/HHH-12290


Laurent Almeras


Le 07/02/2018 à 19:43, Steve Ebersole a écrit :
> And I did say that this is indeed a problem assuming you are right, 
> and I have no reason to believe you are not.  In fact I can see how 
> that would happen.  Yes all based on Hibernate internals.
>
> So I am not trying to blow you off as "this is not a bug". I think it 
> is a bug.  I'm just saying I do not yet know what to do about it.
>
> On Wed, Feb 7, 2018 at 12:41 PM Steve Ebersole  > wrote:
>
> Yes, I understood the situation.
>
> I'm saying that in your query you should just be able to switch to
> use named parameters (prefixed with `:`, rather than `?`) as a
> workaround
>
> On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras
> >
> wrote:
>
> Hi,
>
> Thanks for this insight ; but as I stated (and this is a
> correction of the assumptions of my first email) in my second
> email, it seems that the wrong query (with mixed positional
> and named parameters) is built in hibernate inside layers (and
> not in QueryDSL).
>
> I get rid of my QueryDSL query and replace it with raw JPQL
> query :
>
>
> 
>         Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
>                 "from QueuedTaskHolder queuedTaskHolder\n" +
>                 "where queuedTaskHolder.status in (?1) and
> queuedTaskHolder.queueId = ?2\n" +
>                 "order by queuedTaskHolder.id
> asc").setParameter(1, ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter(2, "queue");
>         return query.getResultList();
> 
>
> And it fails with the very same message :
>
>
> 
>
>
> Cannot define positional and named parameterSpecs : select
> queuedTaskHolder
> from
> org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> queuedTaskHolder
>
> where queuedTaskHolder.status in (:x1_0, :x1_1) and
> queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
>     at
> 
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
>     at
> 
> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
> 
>
> It used to work with Hibernate 5.2.x ; and by reading JPQL
> spec (not sure if this is the right version -
> 
> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
> ) it seems that " IN (?param) " is a valid syntax.
>
> I agree that mixed query may not be supported, but even if
> positional parameter queries bring nothing more than named
> parameters ones, there are also required for JPA compliance ?
>
> Can you say me if I made some wrong assumptions ? If not, is
> it usefull I provide some minimal test-case ?
>
>
>
> *Side-note:* same query written with named parameters is OK
> (as expected):
>
>
> 
>         Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
>         "from QueuedTaskHolder queuedTaskHolder\n" +
>         "where queuedTaskHolder.status in (:statuses) and
> queuedTaskHolder.queueId = :queue\n" +
>         "order by queuedTaskHolder.id
> asc").setParameter("statuses",
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter("queue", "queue");
>         return query.getResultList();
> 
>
>
>
> Thanks,
>
>
> Le 07/02/2018 à 17:30, Steve Ebersole a écrit :
>> Yes, I can see this being a problem. Its caused by some very
>> old, fulgy code in how "list-valued parameters" are handled
>> internally.
>>
>> I'm not sure the best way to deal with this. Unfortunately
>> reverting this is not possible - its necessary for JPA
>> compliance.  The simple workaround of course is to use named
>> parameters yourself.  Honestly JPA's notion of "positional"
>> parameters is nonsensical since they are not positional - the
>> ordinals can repeat and can appear in any order... nothing
>> particularly positional about that.  In fact they are really
>> nothing more than 

[hibernate-dev] Jenkins Updates on Friday

[Davide D'Alto]

Hi,
I'm going to run some updates on Jenkins this Friday.

They are minor updates and should be painless but you never know.

Cheers,
Davide
___
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

[Guillaume Smet]

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

[hibernate-dev] HCANN 6

[Sanne Grinovero]

I'd like to push some updates to Hibernate Commons Annotations, looks
like a good time to plan it as a 6.0 release to nicely align with
plans of our other projects.

I plan to:
 - bump its version to 6.0.0-SNAPSHOT
 - upgrade the Gradle build
 - upgrade its dependencies to latest (which means just JBoss Logger)
 - baseline the requirement to Java 8 (still was on old Java 6 bytecode)
 - merge the one open PR: looks good to me and we were not confident
on merging it in 5.x
 - if possible, include a proper Jigsaw module definition.

Any objections? I hope not as I've already mostly done it all locally ;)

I'll create JIRA issues soon.

Thanks,
Sanne
___
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

[Gunnar Morling]

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 

Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules

[Sanne Grinovero]

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 

[hibernate-dev] JDK 10: First Release Candidate - JDK 10 b43

[Rory O'Donnell]

Hi Sanne,

*JDK 10 build 43 is our first JDK 10 Release Candidate [1]*

  * JDK 10 Early Access  build 43 is available at : - jdk.java.net/10/

Notable changes since previous email.**

*build 43
*

  * JDK-8194764  -
javac incorrectly flags deprecated for removal imports
  * JDK-8196678  -
avoid printing uninitialized buffer in os::print_memory_info on AIX
  * JDK-8195837  -
(tz) Upgrade time-zone data to tzdata2018c

**

*Bug fixes reported by Open Source Projects  :*

  * JDK-8196296 
Lucene test crashes C2 compilation

*Security Manager Survey
*

If you have written or maintain code that uses the SecurityManager or 
related APIs such as the AccessController,
then we would appreciate if you would complete this survey: 
https://www.surveymonkey.com/r/RSGMF3K
More info on the survey  [2]


Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000742.html
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

___
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

[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.

> 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 

Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules

[Gunnar Morling]

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 

Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules

[Gunnar Morling]

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.
> >> >
> >> >

Re: [hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules

[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*. 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