On 9 Jan 2013, at 11:51 PM, Sanne Grinovero sa...@hibernate.org wrote:
Maven first appeared in March 2012 scoring Hold because of it's lack
of flexibility and never made any progress... never!
I think that is very true. I think we all have come across its lack of
flexibility at least once.
Yes between each other but the scrutiny is mostly applied to non team member
contribs too, we are just a tad nicer :) interestingly in search and OGM, I
don't think we had much small PRs from the community, it was almost always big
protein packed feature requests.
On 9 juil. 2013, at 22:53,
On 9 juil. 2013, at 21:39, Hardy Ferentschik ha...@hibernate.org wrote:
I also think opening issues to things that are not fully on the topic is
a good strategy to keep the cycle on a given PR short.
What is the definition of not fully on topic. I would not suggest a change in
class X
Hi,
In a copy of the OGM job I've added a post build step which runs
hibernate-ogm-mongodb and hibernate-ogm-integrationtest-mongodb against
an external MongoDB.
This works as expected, the only shortcoming being, that the test results
reported by Jenkins are always those created by the embedded
What is the definition of not fully on topic. I would not suggest a change in
class X for a pull request where only class Y and Z are affected. However,
if class X is touched and I see a potential improvement I think it can be
considered
being part of the topic. Boy Scout rule number one:
On 10 Jan 2013, at 11:06 AM, Gunnar Morling gun...@hibernate.org wrote:
I think the proper way of doing this kind of thing in Jenkins would be to
set up a multi-configuration job which builds one project applying
different configurations (here once with embedded and once with external
On 10 July 2013 10:12, Hardy Ferentschik ha...@hibernate.org wrote:
On 10 Jan 2013, at 11:06 AM, Gunnar Morling gun...@hibernate.org wrote:
I think the proper way of doing this kind of thing in Jenkins would be to
set up a multi-configuration job which builds one project applying
different
+1
On Wed, Jul 10, 2013 at 11:15 AM, Sanne Grinovero sa...@hibernate.orgwrote:
On 10 July 2013 10:12, Hardy Ferentschik ha...@hibernate.org wrote:
On 10 Jan 2013, at 11:06 AM, Gunnar Morling gun...@hibernate.org
wrote:
I think the proper way of doing this kind of thing in Jenkins
On Wed 2013-07-10 11:09, Hardy Ferentschik wrote:
What is the definition of not fully on topic. I would not suggest a change
in
class X for a pull request where only class Y and Z are affected. However,
if class X is touched and I see a potential improvement I think it can be
I think we all agree that the current process is very good: don't take
this too seriously. I'm merely trying to identify how we can improve
on efficiency even more, and also I am coming to the conclusion that
often I'm the bottleneck myself so I'm trying to figure out what's
preventing me to
On 10 July 2013 13:00, Emmanuel Bernard emman...@hibernate.org wrote:
On Wed 2013-07-10 11:09, Hardy Ferentschik wrote:
What is the definition of not fully on topic. I would not suggest a
change in
class X for a pull request where only class Y and Z are affected. However,
if class X is
Hi,
I am wondering whether anyone can use the checkstyle plugin after HSEARCH-1326
and the introduction of our own custom Checkstyle Checks (Eclipse or Idea)?
I have been using the Idea Checkstyle plugin and that worked just fine. But
since the latest changes I get the following exception:
Option A, you rework that logic as part of the spatial feature PR. I am
claiming that this is breaking the flow of getting spatial out the doors
unnecessarily.
Option B, the reviewer comment is converted in a JIRA that can be
addressed as soon as the spatial query is pushed to master.
I think it was a great idea to introduce checkstyle, but I think it
really needs to work in the IDE as wel
Actually for me it is just a nice feature but not a must have.i've never
used checkstyle in the IDE and I'm quite happy to use it in the terminal.
If we cannot find a solution for this I
On 10 Jan 2013, at 2:04 PM, Sanne Grinovero sa...@hibernate.org wrote:
- your metadata API is not complete, yet I merged two chunks of
progress, as I considered them solidly good stuff. You don't disagree
do you?
No, of course not, but how does this example fit into this? If you had told me
On Wed 2013-07-10 14:12, Hardy Ferentschik wrote:
Option A, you rework that logic as part of the spatial feature PR. I am
claiming that this is breaking the flow of getting spatial out the doors
unnecessarily.
Option B, the reviewer comment is converted in a JIRA that can be
I disagree here and agree with Hardy. It is important to have these
working in IDE
On Jul 10, 2013 7:24 AM, Davide D'Alto dav...@hibernate.org wrote:
I think it was a great idea to introduce checkstyle, but I think it
really needs to work in the IDE as wel
Actually for me it is just a nice
If this is forcing Hardy to use a non-favourite workflow we should
disable it for now.
Of course if you happen to find a solution, that's even better ;-)
On 10 July 2013 13:24, Davide D'Alto dav...@hibernate.org wrote:
I think it was a great idea to introduce checkstyle, but I think it
really
On 10 Jan 2013, at 2:24 PM, Davide D'Alto dav...@hibernate.org wrote:
I think it was a great idea to introduce checkstyle, but I think it really
needs to work in the IDE as wel
Actually for me it is just a nice feature but not a must have.i've never used
checkstyle in the IDE and I'm
In the end the rule check double spaces so I'm ok about disable it for now.
Formatters should be already compatiible with the checkstyle file.
But they aren't
Out of curiosity, which rule throws a checkstyle violation when the code is
formatted using the formatters?
On Wed, Jul 10, 2013 at
Hi,
Hardy and I have been musing about how to mark new API members (methods,
classes etc.) which are still incubating or experimental.
Of course we have Alpha, Beta releases etc. but there can be cases where it
makes sense to ship new functionality with a final release and still leave
the door
The Gradle team do this exact thing as well. They have been doing that
for over a year. You might want to ask them about their experiences.
On 07/10/2013 10:48 AM, Gunnar Morling wrote:
Hi,
Hardy and I have been musing about how to mark new API members (methods,
classes etc.) which are
I remember a few discussion where something like that has been
contemplated. One thing that made us not do it AFAIR is that we would
need some kind of shared project to host this across ORM, OGM, SEARCH
etc. In the past we have deemed it not worth it.
Emmanuel
On Wed 2013-07-10 17:48, Gunnar
To share the annotation?
We where contemplating a shared jar anyway to maintain the checkstyle
rules. I guess this could also contain some other shared stuff, like
the CSS extensions to the javadoc, etc..
On 10 July 2013 17:13, Emmanuel Bernard emman...@hibernate.org wrote:
I remember a few
http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
I sometimes think about a similar approach (in terms of using
annotations) to marking the API/SPI/INTERNAL split.
On 07/10/2013 11:23 AM, Sanne Grinovero wrote:
To share the annotation?
We where contemplating a shared jar
there was some problems with sybase blob support, but I think from Sybase ASE
15.7 it is resolved now
the problem here is using scrollable result set
something worth to try though:
1. using FORWARD_ONLY in the org.hibernate.Query#scroll since the sybase driver
seems supports this mode best
2013/7/10 Sanne Grinovero sa...@hibernate.org
To share the annotation?
We where contemplating a shared jar anyway to maintain the checkstyle
rules. I guess this could also contain some other shared stuff, like
the CSS extensions to the javadoc, etc..
But isn't there a difference between
2013/7/10 Steve Ebersole st...@hibernate.org
http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
Thanks for the link. I like their approach of explicitly documenting this
kind of thing.
I sometimes think about a similar approach (in terms of using
annotations) to marking
On Wed 10 Jul 2013 04:07:33 PM CDT, Gunnar Morling wrote:
I sometimes think about a similar approach (in terms of using
annotations) to marking the API/SPI/INTERNAL split.
An interesting idea. Would this mean to add annotations to every type?
If so, I'm not sure though how well
29 matches
Mail list logo
