<https://hibernate.atlassian.net/browse/HHH-9740>on jira but to get a
> quick response I posted the issue here again.
> I do not see any traction on the jira issue, neither did stackoverflow or
> the IRC chat help out.
> Any help would be appreciated.
>
> Thanks !
>
> On
Har
On Tue, Apr 21, 2015 at 1:52 PM, Hardy Ferentschik
wrote:
> On Tue, Apr 21, 2015 at 01:09:53PM -0500, Steve Ebersole wrote:
> > Ok, silence will be taken as a vote to do whatever I feel is best
> > regardless of impact on these integration impls... So anyone?
>
> Sorry
Ferentschik
wrote:
> On Tue, Apr 21, 2015 at 01:09:53PM -0500, Steve Ebersole wrote:
> > Ok, silence will be taken as a vote to do whatever I feel is best
> > regardless of impact on these integration impls... So anyone?
>
> Sorry, I forgot about this one. TBH, I have not
Where does that wrapping happen?
On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling
wrote:
> Hi,
>
> while working on making OGM work with ORM 5, I noticed a slightly different
> behaviour wrt. to exceptions occurring during flushes.
>
> Previously, such exceptions would bubble up as is, whereas n
We discussed this before on the list. The main thing to decide is
Session#load and proxies. Basically there are times when:
public T load(Class entityType, Object id)
simply will not work. This is the discussion I started wrt annotating the
proxy interface, rather than the impl class.
Basical
ing
wrote:
> TransactionImpl#commit(); The before-completion code is now invoked
> through transactionDriverControl.commit(); whereas previously this
> happened out of a try/catch block.
>
> 2015-04-28 23:26 GMT+02:00 Steve Ebersole :
>
>> Where does that wrapping happen?
>>
&g
I had originally planned on today's release being the first CR for 5.0. I
am re-thinking that now. Here is why...
1) If we were to ever start offering a typed API, a major major release
would be the time to do that. However, we'd still have the "load() + proxy
interfaces" issue to decide a cour
Oh... and I'd *like* to get the Karaf features file figured out. Not
blocker, but a nice to have.
On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole
wrote:
> I had originally planned on today's release being the first CR for 5.0. I
> am re-thinking that now. Here is why...
>
uld love that as I should really check on two last things but
> couldn't make time yet.
> - the Locking API
> - checking if what I'm having in mind regarding EntityKey vs CacheKey
> needs any API change
>
> +1 for a little extra time
>
> Thanks!
> Sanne
>
WRT performance testing... well I think we can agree that the performance
would not be worse. So I don't see the harm in that regard.
On Wed, Apr 29, 2015 at 11:15 AM, Sanne Grinovero
wrote:
> On 29 April 2015 at 16:54, Steve Ebersole wrote:
> > For EntityKey vs CacheKey, t
Ok, I'll call it a quorum in terms of making this Beta2...
On Wed, Apr 29, 2015 at 12:02 PM, Steve Ebersole
wrote:
> WRT performance testing... well I think we can agree that the performance
> would not be worse. So I don't see the harm in that regard.
>
> On Wed, Ap
https://hibernate.atlassian.net/browse/HHH-9760
On Wed, Apr 29, 2015 at 8:21 AM, Steve Ebersole wrote:
> Yes, I think that logic is not correct. A bigger concern I have there tbh
> is HEM; there is some very fragile (at best) code that tries to "decode"
> the exceptions t
https://hibernate.atlassian.net/browse/HHH-9761
On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole wrote:
> We discussed this before on the list. The main thing to decide is
> Session#load and proxies. Basically there are times when:
>
> public T load(Class entityType, Object id)
>
http://in.relation.to/Bloggers/HibernateORM500Beta2Release
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 2015-04-30 5:41 GMT+02:00 Steve Ebersole :
>
>> https://hibernate.atlassian.net/browse/HHH-9761
>>
>> On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole
>> wrote:
>>
>> > We discussed this before on the list. The main thing to decide is
>
, Apr 30, 2015 at 4:17 AM, Max Rydahl Andersen
wrote:
> On 30 Apr 2015, at 6:35, Steve Ebersole wrote:
>
> http://in.relation.to/Bloggers/HibernateORM500Beta2Release
>>
>
> with respect to:
>
> Much improved (and still improving!) schema management tooling for expor
Hard to say exactly without knowing the exact nature of the data you keep,
but couldn't you keep the same principle as before and keep this on your
return from getTransactionDriverControl (the *Inflow contract, Andrea I
thought we had decided to rename that interface as well?)?
On Thu, Apr 30, 201
Gail, I saw your ping on IRC and thought it made sense to address here,
since you were not around on IRC anymore.
Overall, starting with 5.0, the idea is for Hibernate to automatically
quote any identifiers is recognizes as a keyword. This is all encapsulated
within the org.hibernate.engine.jdbc.
) (?) Augment with application-provided keywords
FWIW (4) can actually be handles via custom PhysicalNamingStrategy in terms
of a custom PhysicalNamingStrategy deciding to quote a given identifier.
On Fri, May 1, 2015 at 8:51 AM, Steve Ebersole wrote:
> Gail, I saw your ping on IRC and thought
on standards, wouldn't it be more
> useful to base it on *exactly* what the used database requires?
>
> In other words, why wouldn't it suffice to have a single source of
> keywords: the Dialect.
>
> --Sanne
>
>
>
> On 1 May 2015 at 15:19, Steve Ebersole wr
So here is what I did. I think this is the best compromise, short of us
hand crafting the keywords for each and every one of our Dialects...
1) I added this method to Dialect:
/**
* Hook into auto-quoting of identifiers that are deemed to be keywords.
By default we
* return all of the followi
I recently have seen a bunch of attempts (and questions about) using JPA
callbacks with SessionFactory. At the moment, a user would need to
manually enable the proper event listeners to get this to work. I am
thinking about enabling this "out of the box". Wanted to get everyone's
opinion. I am
In regards to the first 2 sets, yes I agree.
In regards to your second point, see the discussion on
https://hibernate.atlassian.net/browse/HHH-9761 first. One idea was to
keep those methods as an "untyped API". Another option would be to add
another byId (etc) method for untyped operations, some
Petar, I have just been focusing on other things the past 3 days or so.
Chill :)
I will look at this this week. If you happen to have a chance to debug it
any further by then, that would rock. FWIW, I do not think it is in any
way related to the duplicate secondary table warnings. Those are
com
Why? Why even deprecate methods then?
On Tue, May 5, 2015 at 8:18 AM, Sanne Grinovero wrote:
> Please don't remove deprecated methods if there is no real need!
>
>
>
> On 5 May 2015 at 14:12, Steve Ebersole wrote:
> > In regards to the first 2 sets, yes I agree.
FWIW, those hooks in Hibernate 5 already exist, based on Jandex 1, of
course :)
We are not currently using Jandex. That was work happening under the
metamodel redesign, which we had to push to 6.0.
When we do start using Jandex, the plan is to use the provided Jandex as a
base. But the problem
Sure, I can take a look at a Pull Request. Just ping us on the list when
it is ready (sometimes the PR notifications "get lost" in the shuffle).
On Wed, May 6, 2015 at 9:00 AM, Guillaume Smet
wrote:
> Hi all,
>
> (sorry for the long silence, have been dealing with personal issues)
>
> I have cy
As outlined in
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html#_migration,
Configuration#setInterceptor
calls now map to the SessionFactoryBuilder#applyInterceptor method. So
really we need to look at choices for how to influence the Interceptor on
SessionFa
hibernate.listeners.envers.autoRegister is the old property. See:
public static final String INTEGRATION_ENABLED =
"hibernate.integration.envers.enabled";
The old one is still recognized...
On Thu, May 7, 2015 at 1:28 PM, Brett Meyer wrote:
> ...heh, it's already in the docs ;)
>
>
> http://d
t it
> be easy for people to upgrade to 5 as that's an intimidating process;
> let them realise that with a couple of changes they can do it. Once
> they're over the scary part, you can remove the long deprecated
> methods in some minor.
> But if any of these methods is a hin
12:59 PM, Sanne Grinovero
wrote:
> On 8 May 2015 at 18:33, Steve Ebersole wrote:
> > I don't know if I agree with this. I'll play the other side... What if
> you
> > had done the Lucene 4 upgrade and spent a bunch of time managing API
> changes
> > and fi
Sorry I forgot I had not yet integrated my newest work on that plugin
upstream. Check out my fork of it and publish that locally
: g...@github.com:sebersole/lb-gradle-plugins.git
On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero wrote:
> Hi,
> I'm having some trouble to build a fresh checkout fro
Interesting... The ORM master CI builds stopped pulling changes and auto
building. Any idea why?
On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole wrote:
> Sorry I forgot I had not yet integrated my newest work on that plugin
> upstream. Check out my fork of it and publish that locally
Sanne, I actually went ahead and published my local work SNAPSHOT to the
JBoss snapshot repo. You build should just find it now...
On Sat, May 9, 2015 at 8:11 AM, Steve Ebersole wrote:
> Interesting... The ORM master CI builds stopped pulling changes and auto
> building. Any idea why?
t know.. we had two slaves running out
> of disk space, that's likely going to happen on all remaining slaves
> soon if I don't rebuild them..
>
> On 9 May 2015 at 14:11, Steve Ebersole wrote:
> > Interesting... The ORM master CI builds stopped pulling changes and auto
&g
d. Infinispan tests fail.. I'll ignore that.
>
> Cheers,
> Sanne
>
> On 9 May 2015 at 14:27, Steve Ebersole wrote:
> > It is the dsl-extension branch. But like I said, you should just be
> able to
> > find it from JBoss snapshot repo now.
> >
> > On S
iew your
> > changes.
> >
> > Sanne
> >
> > On 11 May 2015 at 14:37, andrea boriero wrote:
> > > I have spotted the problem and I'm fixing the infinispan tests.
> > >
> > > On 9 May 2015 at 19:23, Steve Ebersole wrote:
> > >>
WRT 4.4, no! :)
On Mon, May 11, 2015 at 10:52 AM, Sanne Grinovero
wrote:
> On 11 May 2015 at 16:35, Galder Zamarreño wrote:
> >
> >> On 11 May 2015, at 17:26, Sanne Grinovero wrote:
> >>
> >> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan
> 7.2.1.Final ?
> >> Was
None of the bootstrapping contracts are kept around after the SF is
bootstrapped. Nothing different there from Configuration. There is
nothing meaningful on SessionFactory for performing any schema tools. For
what its worth I hope to change that with the metamodel work (6.0), but for
now this is
HHH-9792 - Clean up missed Configuration methods
On Tue, May 12, 2015 at 11:05 PM, Steve Ebersole
wrote:
> None of the bootstrapping contracts are kept around after the SF is
> bootstrapped. Nothing different there from Configuration. There is
> nothing meaningful on SessionFa
a chance to read up on what you suggested. I sounded
> like it had some limitations that would not work, but maybe I
> misunderstood. I'll look into it today.
>
> The last couple of days have been very long. Sorry for the oversights.
>
> - Original Message -
> >
Subject: Build failed in Jenkins: hibernate-orm-master-h2 #900
To:
Cc:
See <http://ci.hibernate.org/job/hibernate-orm-master-h2/900/changes>
>
> Changes:
>
> [Steve Ebersole] HHH-9790 - Remove deprecated methods from Session and
> SessionFactory
>
>
GMT+03:00 Steve Ebersole :
>
>> Petar, I have just been focusing on other things the past 3 days or so.
>> Chill :)
>>
>> I will look at this this week. If you happen to have a chance to debug
>> it any further by then, that would rock. FWIW, I do not think it
t is very much appreciated.
>
> Gail
>
> [1]
> http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html
>
> - Original Message -
> > From: "Scott Marlow"
> > To: "Gail Badner" , "Steve Ebersole" <
>
No word on the new test case I take it?
WRT the HHH72 logged warnings, like i said the warning is inocuous.
But I did correct it: https://hibernate.atlassian.net/browse/HHH-9797
On Wed, May 13, 2015 at 3:52 PM, Steve Ebersole wrote:
> Nope. Well, specifically yes your test fails as
out where the problem, but I'm not really that good
> to investigate further.
>
> 2015-05-14 19:27 GMT+03:00 Steve Ebersole :
>
>> No word on the new test case I take it?
>>
>> WRT the HHH72 logged warnings, like i said the warning is inocuous.
>> But I
; https://github.com/hibernate/hibernate-search/commit/12df1b654cefad17b5186e3d3f4c5419d41295d1#diff-f3753a568f2086a66b118016751498edR21
>
> Filed HHH-9801, very low priority though.
>
> On 13 May 2015 at 17:48, Sanne Grinovero wrote:
> > Thanks Steve, that was very helpful.
> &
Actually that cannot be it. JPA does not define schema update capability.
On May 14, 2015 4:27 PM, "Steve Ebersole" wrote:
> So you're original test was using JPA? See this illustrates why it's best
> to isolate tests down to SSCCE.
>
> I will try again with JPA
Hmm I might not have set up the task deps properly for the task that
generates that file. It should depend on the hibernate-osgi jar task. You
can try setting the deps or you can try running the task directly. It's
called something like generateKarafFeatures
On May 15, 2015 6:52 AM, "Sanne Grino
task
to implement certain extra interfaces. So in the short term I just named
the file. Anyway, for now setting up the task deps manually or running the
task directly as I mentioned before should work.
On Fri, May 15, 2015 at 7:12 AM, Steve Ebersole wrote:
> Hmm I might not have set up the t
The problem is legacy databases and how to help users migrate the id
generation strategies. Or are you thinking that existing users would have
to disable this on upgrade?
On Fri, May 15, 2015 at 3:14 PM, Sanne Grinovero
wrote:
> I just noticed that the ORM testsuite seems to consistently set th
FYI : https://hibernate.atlassian.net/browse/HHH-9803
Its not super high on my priority list, but I want to get to a point where
we can start to fail the build on "serious checkstyle regressions". Part
of that is being more realistic with what is considered serious, and part
of that is fixing up
igrate those values?
On Sat, May 16, 2015 at 9:16 AM, Sanne Grinovero
wrote:
> On 15 May 2015 at 23:55, Steve Ebersole wrote:
> > The problem is legacy databases and how to help users migrate the id
> > generation strategies. Or are you thinking that existing users would
> ha
onal header includes the
> year, which was sometimes problematic (like you'd copy an header in a
> new class and mark it with a 6 years old copyright); so now we're
> using a simplified copyright template which is shorter and has no
> mention years:
> -
> https://g
ng a non-Hibernate template. The traditional header includes the
>> year, which was sometimes problematic (like you'd copy an header in a
>> new class and mark it with a 6 years old copyright); so now we're
>> using a simplified copyright template which is shorter
Sanne, can you give me the low-down on this line?
On Sat, May 16, 2015 at 1:26 PM, Steve Ebersole wrote:
> Actually a few others I will add:
>
> 3) missing @Override
> 4) missing @Deprecated/@deprecated
> 5) missing braces
> 6) star imports
> 7) redundant imports
> 8)
k it with a 6 years old copyright); so now we're
> > using a simplified copyright template which is shorter and has no
> > mention years:
> > -
> https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/analyzer/Discriminator.jav
As far as the file header, I have often thought of condensing our ORM one
so that is awesome information. For my own curiosity did Richard give you
a reason that the copyright statement is not necessary?
On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero
wrote:
> On 18 May 2015 at 15:23, Emmanuel
Sorry hit send too soon :(
Anyway.. I assume it is because we know this information from commit
history?
As far as the ORM one, I propose a similar change. Any objections?
On Mon, May 18, 2015 at 10:14 AM, Steve Ebersole
wrote:
> As far as the file header, I have often thought of condens
;
> > On 18 mai 2015, at 17:20, Steve Ebersole wrote:
> >
> > Sorry hit send too soon :(
> >
> > Anyway.. I assume it is because we know this information from commit
> > history?
> >
> > As far as the ORM one, I propose a similar change. Any objection
Hardy, do you happen to still have your sed script for updating these file
headers?
On Mon, May 18, 2015 at 2:48 PM, Sanne Grinovero
wrote:
> On 18 May 2015 at 19:44, Steve Ebersole wrote:
> > And see, this[1] is exactly the kind of thing I always try to avoid...
> Why
> > d
The recent discussion on Checkstyle got me thinking about best ways to
share/distribute code styles for IDE setup. Storing them in the project
itself is not very workable for IntelliJ at least. I started thinking
about a separate repository under the hibernate GitHub organization. Does
everyone
ORM master is now enforcing checkstyle. The CI builds will fail if you
commit anything that was deemed a severity of error/high. The only part
missing there is headers, which I will follow up with once I hear back from
Hardy.
On Mon, May 18, 2015 at 3:07 PM, Steve Ebersole wrote:
> Hardy,
l :-)
>
> Either way, differences should not be so huge.
>
> --Hardy
>
> On Mon, May 18, 2015 at 10:01:28PM -0500, Steve Ebersole wrote:
> > The recent discussion on Checkstyle got me thinking about best ways to
> > share/distribute code styles for IDE setup. Storing them
Jakub,
Thanks for starting on this :)
I think the thing that is missing here is the one that most users will want
which is support for Optional attributes in their domain model. Of course
that is the harder one because it would require changes inside Hibernate.
I'll take a look at the code and
t think it's a big problem as long no one re-formats entire
> files just for the sake of it. And if explicit formatting changes are
> needed for whatever reason, they should go in dedicated commits
> independently from actual code changes. Reviewing is otherwise a pain.
>
>
>
>
Let's keep this on list ok? Thanks.
First, have you seen the new hibernate-java8 module that is part of 5.0?
Some replies in-line...
> But I am curious what would be your opinion on this extended API idea and
approach that I took and whether you would for instance consider taking it
under the h
On Tue, May 19, 2015 at 12:51 PM, Jakub Narloch wrote:
>
>
> 2015-05-19 18:16 GMT+02:00 Steve Ebersole :
>>
>> > - Enable registration of LocaleDate, LocalTime as query params.
>>
>> You can do that now:
>> * org.hibernate.Query#setPa
Now that 5.0 is settling down I wanted to start planning where we go from
here in terms of feature development and schedule/releases.
Here is my high-level list of features/work:
* rework SQL generation & HQL parser
* change JDBC extraction to work by position, rather than alias (reworking
SQL gen
s in ordering of
> import statements.
>
> On 19 May 2015 at 17:15, Steve Ebersole wrote:
> > I just did some bulk reformatting to get things conforming with styles.
> > But moving forward I agree that we should not be reformatting entire
> > files. Eclipse used to do th
Checkstyle in ORM is now good to go and enforced in the CI jobs.
So I started thinking about FindBugs. We do have FindBugs set up. However
it is utterly out of control at the moment. Maybe it's just me, but I find
FindBugs impossible to configure "well". Granted I have little experience
with i
The difference is that insert ordering is merely a question of performance
in order to better leverage JDBC batching. Here you are suggesting that
there is a bug in the order of deletes. Or are you just wanting to order
the deletes to better leverage JDBC batching as well? It's not clear.
On We
I am having trouble building 4.3 even from a clean checkout:
:hibernate-core:runSourceGenerators
:hibernate-core:runAnnotationProcessors FAILED
FAILURE: Build failed with an exception.
* Where:
Script
'/home/sebersole/projects/hibernate/hibernate-4.3/hibernate-orm/source-generation.gradle'
line:
Ah, yes that was it. Thanks!
On Thu, May 21, 2015 at 12:34 PM, andrea boriero
wrote:
> are you using java 8?
>
>
>
> On 21 May 2015 at 18:27, Steve Ebersole wrote:
>
>> I am having trouble building 4.3 even from a clean checkout:
>>
>> :hibernate-co
Brett,
As part of HHH-7527 (Enterprise OSGi support) you had changed
the org.hibernate.jpa.boot.spi.Bootstrap contract to basically overload
each method to additional accept a "providedClassLoader".
Every one of those methods however, also accepts
a org.hibernate.jpa.boot.spi.PersistenceUnitDescr
M 4,
> since CL handling was still really static. But admittedly, I'm a bit out
> of touch with ORM 5, so I'm not sure if that's feasible yet.
>
> - Original Message -
> > From: "Steve Ebersole"
> > To: "hibernate-dev"
> > S
way.
> > >
> > > Right, assuming you're talking about
> > > 'ClassLoaderHelper.overridenClassLoader'. But the intention there was
> to
> > > remove that whole class ASAP -- that was just a temporary hack for ORM
> 4,
> > > since CL
I created the following 2 issues to track these improvements:
https://hibernate.atlassian.net/browse/HHH-9818
https://hibernate.atlassian.net/browse/HHH-9819
On Tue, May 26, 2015 at 3:57 PM, Steve Ebersole wrote:
> Awesome, thanks! So I'll investigate BundleListener...
>
> Is
I am not sure what all makes up that ClassLoader.
On Tue, May 26, 2015 at 4:49 PM, Steve Ebersole wrote:
> I created the following 2 issues to track these improvements:
>
> https://hibernate.atlassian.net/browse/HHH-9818
> https://hibernate.atlassian.net/browse/HHH-9819
>
>
>
What follows is solely an issue with schema update and schema validation, 2
tools that to date we have not "really" supported, but I am trying to
change that with 5.0.
We discussed before the idea of auto-quoting and who should be the
authority in regards to keywords. We decided that it would be
If anyone is interested, the issue is here:
https://hibernate.atlassian.net/browse/HHH-9820
I do wonder overall about the interplay that should happen between a
Dialect and the JdbcEnvironment.
On Tue, May 26, 2015 at 10:29 PM, Steve Ebersole
wrote:
> What follows is solely an issue w
On Wed, May 27, 2015 at 5:23 AM, Max Rydahl Andersen
wrote:
> On 27 May 2015, at 5:49, Steve Ebersole wrote:
>
> If anyone is interested, the issue is here:
>> https://hibernate.atlassian.net/browse/HHH-9820
>>
>> I do wonder overall about the interplay that should
I actually started with the third approach. But you bring up a good point
about allowing the Dialect to access the DatabaseMetaData (and hence
Connection) if it wanted to. So I would change that a bit. See the
updated gist
On Wed, May 27, 2015 at 7:33 AM, Max Rydahl Andersen
wrote:
>
> > The
I went ahead and got something in for CR1. Take a look...
On Wed, May 27, 2015 at 8:50 AM, Steve Ebersole wrote:
> I actually started with the third approach. But you bring up a good point
> about allowing the Dialect to access the DatabaseMetaData (and hence
> Connection) if it
am planning for the in-line
migration guide too.
On Mon, Mar 4, 2013 at 10:40 AM, Steve Ebersole wrote:
> Depends what you mean "sync it in master". Its not like you should be
> cherry-picking changelog changes from other branches to master.
>
> But, you should be collecting
https://hibernate.atlassian.net/browse/HHH-9827
On Wed, May 27, 2015 at 8:56 PM, Steve Ebersole wrote:
> If I may dig up a zombie thread.. :)
>
> What I plan to do unless I hear loud arguments to the contrary is to
> truncate this to just the current major release indicated by
http://in.relation.to/Bloggers/HibernateORM500CR1Release
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
At the moment we write release announcements using in.relation.to and then
announce in other mediums by posting that link. We all agree (more or
less) that the wiki editor and rendering on there leaves much to be desired.
Brett had mentioned a long time ago about GitHub and its release
capabiliti
the other hand, do we really need to keep
> maintaining that to begin with? I guess I never thought simply having
> users go to the JIRA release notes was a big deal. Just my $.02.
>
> - Original Message -----
> > From: "Steve Ebersole"
> > To: "Brett Meye
On Wed, May 27, 2015 at 9:09 PM, Brett Meyer wrote:
> > Is that the best way to know when TransactionManagers and DataSources
> come
> > and go too? Or is there a more specific concept for listening to an
> "OSGi
> > service"?
>
> At least for TransactionManagers, yes, the BundleListener is prob
More I mean what bundle(s) should I listen to in order to know that the
ClassLoader is no longer valid? Or how would I otherwise know that or be
notified of that?
I can ping Christian regarding Aries specifically and get his thoughts.
On Wed, May 27, 2015 at 9:16 PM, Brett Meyer wrote:
> > In
WildFly consuming ORM 5.0 is still hitting one last TCCL issue with HCANN.
It happens in
the org.hibernate.annotations.common.annotationfactory.AnnotationFactory#create
method trying to build the "annotation proxy class".
There are a few possible approaches to resolve this...
The simplest potenti
Now that CR1 is out one of my tasks is to start setting up the database
specific jobs on CI. Initially I will just work with MySQL and PostrgeSQL
(and maybe HSQLDB).
Part of this will be auditing how we do database testing (matrix plugin)
and what does/doesn't work there. I definitely like the i
On Thu, May 28, 2015 at 8:07 AM, Emmanuel Bernard
wrote:
> The banner is indeed driven by RSS
I have not seen any RSS capability from the GitHub Release "system".
> so we would lose that. Also push driven news persons would not go
> regularly to GitHub to see if anything is new.
That depe
On Thu, May 28, 2015 at 8:44 AM, Sanne Grinovero
wrote:
> +1
> I particularly like the idea of having H2 start/stop like any other db.
>
> Regarding profiles, rather than running the build with a single
> profile in "maven style", would it not be feasible to have one build
> iterate on each confi
Ok, then everyone seems to be on board with the simple approach. Awesome!
FWIW I'd have to imagine this is close to what the VM does for annotations
anyway. So that's an extra win in my book.
On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero
wrote:
With that TCCL trick in place it seems it was
ple mostly ignore our reminders and expect
> the components to be aligned on the major number. Therefore we expect
> Search to upgrade to ORM 5 in a minor version.
>
> On 28 May 2015 at 15:23, Steve Ebersole wrote:
> > Ok, then everyone seems to be on board with the simple approa
Wow. There are so many open issues against HCANN...
On Thu, May 28, 2015 at 9:51 AM, Steve Ebersole wrote:
> Sold! https://hibernate.atlassian.net/browse/HCANN/fixforversion/20151
>
> On Thu, May 28, 2015 at 9:32 AM, Sanne Grinovero
> wrote:
>
>> What about making it
Anyone have any input here? Or should I just start scheduling them how I
want?
On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole wrote:
> Now that 5.0 is settling down I wanted to start planning where we go from
> here in terms of feature development and schedule/releases.
>
> Her
So even though GitHub does not support RSS per-se, it does have a lot of
JSON support, including around these releases, including even creating them!
On Thu, May 28, 2015 at 10:28 AM, Emmanuel Bernard
wrote:
>
> On 28 May 2015, at 16:06, Steve Ebersole wrote:
>
> The "next g
501 - 600 of 1361 matches
Mail list logo
