5:06 p.m.
Hello,
as you might already know by following the WildFly developer's mailing
list, most of the Hibernate Search jars and dependencies (Lucene) are
now included in the application server as modules.
This was not primarily driven by practical need of Hibernate users but
rather because of clustering needs of the application server, and also
CapeDwarf and other projects make extensive use of it.
Just a couple of small adjustments are needed to make it possible for
Hibernate users to also take advantage of it, so I'd think we should
make these adjustments to make it more useful?
This is what I'm thinking:
- The hibernate-search-orm jar is missing (an essential jar for our purposes)
-> add a module
- No additional analyzers are included
-> see how optional modules work, so that - while we won't ship all
those dependencies - it's still easy to add when you need one
- Jipijapa should help?
-> should we make Hibernate Search available to deployments
whenever Hibernate ORM is made available?
- Get it to a reasonable version: it's including 4.5.0.Alpha2 now
-> we need to release a Beta soon, any volunteer? I'm stuck on an
island with extremely slow connectivity.
- Contribute some integration tests to WildFly: there aren't any
today verifying the included modules
What shall we do about our modules distribution? I think it would be
nice to continue maintaining that, so that we can make frequent
releases and that would allow users to use a different version than
what they would get in WildFly - if they want to.
-- Sanne
4:23 a.m.
On 14 Jan 2014, at 00:06, Sanne Grinovero <sanne(a)hibernate.org> wrote:
as you might already know by following the WildFly developer's
mailing
list, most of the Hibernate Search jars and dependencies (Lucene) are
now included in the application server as modules.
Right. Still not sure whether this is such a great idea, but I guess it is too late.
Just a couple of small adjustments are needed to make it possible
for
Hibernate users to also take advantage of it, so I'd think we should
make these adjustments to make it more useful?
This is what I'm thinking:
- The hibernate-search-orm jar is missing (an essential jar for our purposes)
-> add a module
+1 Does this really need a separate module?
- No additional analyzers are included
-> see how optional modules work, so that - while we won't ship all
those dependencies - it's still easy to add when you need one
Is there some info about “optional” modules? I find information about modules
in general hard to find.
- Jipijapa should help?
-> should we make Hibernate Search available to deployments
whenever Hibernate ORM is made available?
Per default? So if there are no indexed entities nothing happens and if there are
Search gets automatically enabled? Is this what you are saying?
- Get it to a reasonable version: it's including 4.5.0.Alpha2
now
-> we need to release a Beta soon, any volunteer? I'm stuck on an
island with extremely slow connectivity.
I can do a release. Just wondering whether it should be a CR already?
The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already
upgraded now
to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final out.
We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of
weeks.
- Contribute some integration tests to WildFly: there aren't any
today verifying the included modules
+1
What shall we do about our modules distribution? I think it would be
nice to continue maintaining that, so that we can make frequent
releases and that would allow users to use a different version than
what they would get in WildFly - if they want to.
Not sure. The module won’t be a pure drop-in anymore. Now the module needs
to make sure that existing module(s) get properly “reconfigured”. What I mean is that
we might have to do more than extracting a tar ball. We might need to remove/change
existing files as well. Is it not easier to provide instructions on how to update the
exiting modules?
Unfortunately, this comes at a non optimal point in time. Not only will it take time from
the
Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we probably will
get very
quickly people asking on how to use Search 5 with Wildfly. If nothing else a lot of
dependencies
change at this point. It won’t be a simple replace of a single jar.
Will/Can CapeDwarf and clustering also switch to Search 5 once we start making releases?
—Hardy
5:25 a.m.
On 14 January 2014 11:23, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 14 Jan 2014, at 00:06, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> as you might already know by following the WildFly developer's mailing
> list, most of the Hibernate Search jars and dependencies (Lucene) are
> now included in the application server as modules.
Right. Still not sure whether this is such a great idea, but I guess it is too late.
Not sure either, but worst case we have our own release, so there
probably are no negative aspects (?).
More on this below.
> Just a couple of small adjustments are needed to make it possible
for
> Hibernate users to also take advantage of it, so I'd think we should
> make these adjustments to make it more useful?
>
> This is what I'm thinking:
> - The hibernate-search-orm jar is missing (an essential jar for our purposes)
> -> add a module
+1 Does this really need a separate module?
It's probably not strictly needed, but I think it's preferable so that
people can use a different version of it.
Also, it's our tested configuration.
> - No additional analyzers are included
> -> see how optional modules work, so that - while we won't ship all
> those dependencies - it's still easy to add when you need one
Is there some info about “optional” modules? I find information about modules
in general hard to find.
I wasn't aware of it either, I just learned about it in the face to
face meeting.
Need to try it out though..
> - Jipijapa should help?
> -> should we make Hibernate Search available to deployments
> whenever Hibernate ORM is made available?
Per default? So if there are no indexed entities nothing happens and if there are
Search gets automatically enabled? Is this what you are saying?
Yes. Should be great for usability.
> - Get it to a reasonable version: it's including 4.5.0.Alpha2 now
> -> we need to release a Beta soon, any volunteer? I'm stuck on an
> island with extremely slow connectivity.
I can do a release. Just wondering whether it should be a CR already?
The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already
upgraded now
to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final
out.
We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple of
weeks.
We also have the Infinispan indexmanager on the roadmap. All work was
done a year ago already, and the Infinispan issues which prevented me
to merge it at the time are fixed, so I should only need to rebase it.
I would love to merge it, but let's set a deadline for it.. if I can't
make it we release without it again :-(
Also I'm worried about HSEARCH-1260 and Guillaume's report. It would
be nice to get rid of those issues by applying the cleanup I've
suggested on that thread.
I fundamentally agree that if we don't address these quickly, we
should aim at a quick Final, still let's not rush it too much as
WildFly doesn't stricly need a Final from us (or at least I wasn't
asked for one).
> - Contribute some integration tests to WildFly: there aren't any
> today verifying the included modules
+1
> What shall we do about our modules distribution? I think it would be
> nice to continue maintaining that, so that we can make frequent
> releases and that would allow users to use a different version than
> what they would get in WildFly - if they want to.
Not sure. The module won’t be a pure drop-in anymore. Now the module needs
to make sure that existing module(s) get properly “reconfigured”. What I mean is that
we might have to do more than extracting a tar ball. We might need to remove/change
existing files as well. Is it not easier to provide instructions on how to update the
exiting modules?
Changing existing modules is highly discouraged and creates problems
to potentially deploying other frameworks who depend on it: there
should be a way to override the version that a specific deployment
wants to use.
This way, we can make it a "pure drop-in", without changing any existing files.
Unfortunately, this comes at a non optimal point in time. Not only
will it take time from the
Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we probably will
get very
quickly people asking on how to use Search 5 with Wildfly. If nothing else a lot of
dependencies
change at this point. It won’t be a simple replace of a single jar
+1, that's why I think we should keep _also_ releasing our own modules.
Will/Can CapeDwarf and clustering also switch to Search 5 once we
start making releases?
We're going to make it very interesting for them, so I'm sure they'll
find a solution :-)
Very likely, next version of WildFly will use 5, but now that it's
approaching a Final version, it's probably not too bad that we provide
a stable version.
-- Sanne
—Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:41 a.m.
On 14 Jan 2014, at 12:25, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> +1 Does this really need a separate module?
It's probably not strictly needed, but I think it's preferable so that
people can use a different version of it.
Also, it's our tested configuration.
ok
> Is there some info about “optional” modules? I find information
about modules
> in general hard to find.
I wasn't aware of it either, I just learned about it in the face to
face meeting.
Need to try it out though..
Reminds me of JBoss Logging. How are users supposed to understand all this,
if even between developers the only form of information is by word of mouth.
>> - Jipijapa should help?
>> -> should we make Hibernate Search available to deployments
>> whenever Hibernate ORM is made available?
>
> Per default? So if there are no indexed entities nothing happens and if there are
> Search gets automatically enabled? Is this what you are saying?
Yes. Should be great for usability.
+1
> I can do a release. Just wondering whether it should be a CR
already?
> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we already
upgraded now
> to 4.3.0.Final (just not released yet). So it would really be time to get 4.5.0.Final
out.
> We could cut a CR release and if nothing comes up promote it to 4.5 final in a couple
of weeks.
We also have the Infinispan indexmanager on the roadmap. All work was
done a year ago already, and the Infinispan issues which prevented me
to merge it at the time are fixed, so I should only need to rebase it.
I would love to merge it, but let's set a deadline for it.. if I can't
make it we release without it again :-(
Also I'm worried about HSEARCH-1260 and Guillaume's report. It would
be nice to get rid of those issues by applying the cleanup I've
suggested on that thread.
I fundamentally agree that if we don't address these quickly, we
should aim at a quick Final, still let's not rush it too much as
WildFly doesn't stricly need a Final from us (or at least I wasn't
asked for one).
Don’t you think that a lot of users might hold of an upgrade, because they want a final
or at least CR release? If we want people to use 4.5 we might need to give them
a final sooner than later. I don’t see the mentioned issues addressed in the near
future. Guillaume for example won’t be able to look at the mass indexer until some
time February. Is it in this case not better to do a 4.5.0.Final and then add the
mentioned features in a 4.5.x release?
>> What shall we do about our modules distribution? I think it
would be
>> nice to continue maintaining that, so that we can make frequent
>> releases and that would allow users to use a different version than
>> what they would get in WildFly - if they want to.
>
> Not sure. The module won’t be a pure drop-in anymore. Now the module needs
> to make sure that existing module(s) get properly “reconfigured”. What I mean is
that
> we might have to do more than extracting a tar ball. We might need to remove/change
> existing files as well. Is it not easier to provide instructions on how to update the
exiting modules?
Changing existing modules is highly discouraged and creates problems
to potentially deploying other frameworks who depend on it: there
should be a way to override the version that a specific deployment
wants to use.
“Should”!? LOL.
Is this via jboss-deployment-strucure? I guess we would at least somehow change the
module
names on our side to avoid conflicts with the wildfly provided ones. TBH, I am not a big
fan of this.
If I were a user, I’d rather update the existing modules, instead of adding new ones and
needing to
add magic xml files.
—Hardy
3:17 p.m.
>> I can do a release. Just wondering whether it should be a CR
already?
>> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we
already upgraded now
>> to 4.3.0.Final (just not released yet). So it would really be time to get
4.5.0.Final out.
>> We could cut a CR release and if nothing comes up promote it to 4.5 final in a
couple of weeks.
>
> We also have the Infinispan indexmanager on the roadmap. All work was
> done a year ago already, and the Infinispan issues which prevented me
> to merge it at the time are fixed, so I should only need to rebase it.
>
> I would love to merge it, but let's set a deadline for it.. if I can't
> make it we release without it again :-(
>
> Also I'm worried about HSEARCH-1260 and Guillaume's report. It would
> be nice to get rid of those issues by applying the cleanup I've
> suggested on that thread.
>
> I fundamentally agree that if we don't address these quickly, we
> should aim at a quick Final, still let's not rush it too much as
> WildFly doesn't stricly need a Final from us (or at least I wasn't
> asked for one).
Don’t you think that a lot of users might hold of an upgrade, because they want a final
or at least CR release? If we want people to use 4.5 we might need to give them
a final sooner than later. I don’t see the mentioned issues addressed in the near
future. Guillaume for example won’t be able to look at the mass indexer until some
time February. Is it in this case not better to do a 4.5.0.Final and then add the
mentioned features in a 4.5.x release?
Have we decided on a version? Sanne, you still vote for a 4.5 Beta1?
—Hardy
4:43 a.m.
On 15 January 2014 22:17, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>>> I can do a release. Just wondering whether it should be a CR already?
>>> The main point of 4.5 was to give us ORM 4.3 compatibility, right? AFAIK we
already upgraded now
>>> to 4.3.0.Final (just not released yet). So it would really be time to get
4.5.0.Final out.
>>> We could cut a CR release and if nothing comes up promote it to 4.5 final in
a couple of weeks.
>>
>> We also have the Infinispan indexmanager on the roadmap. All work was
>> done a year ago already, and the Infinispan issues which prevented me
>> to merge it at the time are fixed, so I should only need to rebase it.
>>
>> I would love to merge it, but let's set a deadline for it.. if I can't
>> make it we release without it again :-(
>>
>> Also I'm worried about HSEARCH-1260 and Guillaume's report. It would
>> be nice to get rid of those issues by applying the cleanup I've
>> suggested on that thread.
>>
>> I fundamentally agree that if we don't address these quickly, we
>> should aim at a quick Final, still let's not rush it too much as
>> WildFly doesn't stricly need a Final from us (or at least I wasn't
>> asked for one).
>
> Don’t you think that a lot of users might hold of an upgrade, because they want a
final
> or at least CR release? If we want people to use 4.5 we might need to give them
> a final sooner than later. I don’t see the mentioned issues addressed in the near
> future. Guillaume for example won’t be able to look at the mass indexer until some
> time February. Is it in this case not better to do a 4.5.0.Final and then add the
> mentioned features in a 4.5.x release?
Have we decided on a version? Sanne, you still vote for a 4.5 Beta1?
Yes I vote for a release; my preference would be a Beta1 but I have no
strong opinion on that, as you made some good points.
My meeting is over so while I guess my answer comes a bit late, at
this point today I could make the massindexer patch at least (as I
guess you won't be releasing over the weekend, but if I'm wrong on
that feel free to go ahead without waiting for my patch).
Sanne
—Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:45 a.m.
Unfortunately, this comes at a non optimal point in time. Not only
will it take time from the
Lucene 4 migration (aka Search 5), but if Search 4.x gets included now we probably will
get very
quickly people asking on how to use Search 5 with Wildfly. If nothing else a lot of
dependencies
change at this point. It won’t be a simple replace of a single jar.
You can always have more then one version of the "same" module.
By default we call it "main", but in this case you could add "5",
and then it's up to whoever to use what it wants.
If they will let you "bloat" WF even more. :-)
Will/Can CapeDwarf and clustering also switch to Search 5 once we
start making releases?
I'm always open to suggestions.
If things work and have better performance, why not.
For us API means GAE API, everything else is impl detail, hence easy to change.
Atm what we lack is better projections handling and distinct queries.
-Ales
8:46 a.m.
I am a big fan of Hibernate technologies and the search capabilities. I
am concerned though that we are deferring how to untangle the Hibernate
Search/Infinispan/WildFly dependencies.
I raised a few questions on the wildfly-dev mailing list, some that got
answered but one important issue didn't. The question is about
scheduling and how to coordinate the WildFly/Hibernate ORM/Hibernate
Search/Infinispan releases such that if one component breaks the others
at the end of a release cycle, how to deal with that. This isn't really
my problem as I don't schedule any of these components but it would be
wrong of me not to point this out.
Are there any infinispan-dev mailing list threads discussing how to
remove the Infinispan dependency on Hibernate Search in 2014, so that we
aren't forced into keeping Hibernate Search in WildFly 9?
On 01/13/2014 06:06 PM, Sanne Grinovero wrote:
Hello,
as you might already know by following the WildFly developer's mailing
list, most of the Hibernate Search jars and dependencies (Lucene) are
now included in the application server as modules.
This was not primarily driven by practical need of Hibernate users but
rather because of clustering needs of the application server, and also
CapeDwarf and other projects make extensive use of it.
Just a couple of small adjustments are needed to make it possible for
Hibernate users to also take advantage of it, so I'd think we should
make these adjustments to make it more useful?
This is what I'm thinking:
- The hibernate-search-orm jar is missing (an essential jar for our purposes)
-> add a module
- No additional analyzers are included
-> see how optional modules work, so that - while we won't ship all
those dependencies - it's still easy to add when you need one
- Jipijapa should help?
Jipijapa could help standardize how WildFly integrates with search
providers. I'm not sure if this is needed.
-> should we make Hibernate Search available to deployments
whenever Hibernate ORM is made available?
Would this slow deployment down at all for applications that don't use
Hibernate Search?
- Get it to a reasonable version: it's including 4.5.0.Alpha2
now
-> we need to release a Beta soon, any volunteer? I'm stuck on an
island with extremely slow connectivity.
- Contribute some integration tests to WildFly: there aren't any
today verifying the included modules
What shall we do about our modules distribution? I think it would be
nice to continue maintaining that, so that we can make frequent
releases and that would allow users to use a different version than
what they would get in WildFly - if they want to.
-- Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:29 a.m.
On 14 January 2014 15:46, Scott Marlow <smarlow(a)redhat.com> wrote:
I am a big fan of Hibernate technologies and the search capabilities.
I am
concerned though that we are deferring how to untangle the Hibernate
Search/Infinispan/WildFly dependencies.
I raised a few questions on the wildfly-dev mailing list, some that got
answered but one important issue didn't. The question is about scheduling
and how to coordinate the WildFly/Hibernate ORM/Hibernate Search/Infinispan
releases such that if one component breaks the others at the end of a
release cycle, how to deal with that. This isn't really my problem as I
don't schedule any of these components but it would be wrong of me not to
point this out.
We'll try to coordinate version compatibility across projects; We do
control the version being used in Infinispan and will keep it up to
date as there are various good reasons to do that.
The tricky part is that we don't control necessarily which versions of
ORM and Infinispan are going to be picked in a specific WildFly
release, but optimistically speaking I expect that this choice will
always be at "same generation".
To address the more pessimistic scenario, we'll need to be more
flexible in having +1 / -1 version compatibility at SPI levels.
Historically we'll have been quite good at keeping a level of
flexibility, but you're right it is a concern and we'll be handling
stricter compatibility checks via new CI jobs.
Worst case, we'll always be able to deploy additional modules.
Are there any infinispan-dev mailing list threads discussing how to remove
the Infinispan dependency on Hibernate Search in 2014, so that we aren't
forced into keeping Hibernate Search in WildFly 9?
Not yet, if any now that it's being included I think it should stay
there. A major release is a big change for our point of view but not a
reason to completely disrupt users's experience, from their point of
view it's not nice that the way to deploy something like this changes
*that* frequently.
On 01/13/2014 06:06 PM, Sanne Grinovero wrote:
>
> Hello,
> as you might already know by following the WildFly developer's mailing
> list, most of the Hibernate Search jars and dependencies (Lucene) are
> now included in the application server as modules.
>
> This was not primarily driven by practical need of Hibernate users but
> rather because of clustering needs of the application server, and also
> CapeDwarf and other projects make extensive use of it.
>
> Just a couple of small adjustments are needed to make it possible for
> Hibernate users to also take advantage of it, so I'd think we should
> make these adjustments to make it more useful?
>
> This is what I'm thinking:
> - The hibernate-search-orm jar is missing (an essential jar for our
> purposes)
> -> add a module
> - No additional analyzers are included
> -> see how optional modules work, so that - while we won't ship all
> those dependencies - it's still easy to add when you need one
> - Jipijapa should help?
Jipijapa could help standardize how WildFly integrates with search
providers. I'm not sure if this is needed.
I mean, I think it's probably Jipijapa's responsibility to inject the
module on the classpath for Hibernate users.
> -> should we make Hibernate Search available to deployments
> whenever Hibernate ORM is made available?
Would this slow deployment down at all for applications that don't use
Hibernate Search?
No, not at all.
Sanne
> - Get it to a reasonable version: it's including
4.5.0.Alpha2 now
> -> we need to release a Beta soon, any volunteer? I'm stuck on an
> island with extremely slow connectivity.
> - Contribute some integration tests to WildFly: there aren't any
> today verifying the included modules
>
> What shall we do about our modules distribution? I think it would be
> nice to continue maintaining that, so that we can make frequent
> releases and that would allow users to use a different version than
> what they would get in WildFly - if they want to.
>
> -- Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
4300
days inactive
4305
days old
8 comments
4 participants
participants (4)
-
Ales Justin -
Hardy Ferentschik -
Sanne Grinovero -
Scott Marlow