[hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

[Strong Liu]

https://hibernate.atlassian.net/browse/HHH-8219 

https://hibernate.atlassian.net/browse/HHH-8220


-
Best Regards,

Strong Liu 
http://about.me/stliu/bio



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

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

[Gunnar Morling]

For the HHH-8219 - usage of JDK 7 API - I'm working on integrating the
Animal Sniffer plug-in to check that only Java 6 classes are used in the
code base.

--Gunnar



2013/5/3 Strong Liu 

>
> https://hibernate.atlassian.net/browse/HHH-8219
>
> https://hibernate.atlassian.net/browse/HHH-8220
>
>
> -
> Best Regards,
>
> Strong Liu 
> http://about.me/stliu/bio
>
>
>
> ___
> 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] Checkstyle breaking the OGM build

[Emmanuel Bernard]

I found the problem, not sure where that comes from though.

On a fresh repo clone it works as expected. So I did diff the two and
found that the failing version has lines ending as CRLF (Windows) and
the fresh repo has lines ending as LF (Unix).

On Fri 2013-05-03  8:32, Gunnar Morling wrote:
> Works for me on my Mac as expected, i.e. I get the violation only when I
> really add another new line.
> 
> > I'm wondering if we really want to keep this rule
> 
> Personally I like the rule, several empty lines always look a bit odd to
> me. But if the check can't be executed reliably, it's surely not big loss.
> 
> --Gunnar
> 
> 
> 
> 2013/5/3 Sanne Grinovero 
> 
> > Can't reproduce this either. I'm wondering if we really want to keep this
> > rule: its benefit is limited and even before this case we had trouble with
> > it on windows.
> > On 2 May 2013 23:41, "Guillaume SCHEIBEL" 
> > wrote:
> >
> > > Hi Emmanuel,
> > >
> > > Sorry I can't reproduce it and both maven & intellij plugins are telling
> > me
> > > the Label class respects the rules.
> > >
> > > Guillaume
> > >
> > >
> > > 2013/5/3 Emmanuel Bernard 
> > >
> > > > Taking OGM master, I get a checkstyle failure on one of the test file.
> > > > But what is surprising is that I don't see new lines at the end of the
> > > > described file.
> > > >
> > > > Can you guys reproduce?
> > > >
> > > > Emmanuel
> > > >
> > > > [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
> > > > hibernate-ogm-core ---
> > > > [debug] execute contextualize
> > > > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > > > [INFO] Copying 2 resources
> > > > [INFO]
> > > > [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> > > > hibernate-ogm-core ---
> > > > [INFO] Compiling 150 source files to
> > > > /Users/emmanuel/Code/ogm/hibernate-ogm-core/target/classes
> > > > [INFO]
> > > > [INFO] --- maven-checkstyle-plugin:2.10:checkstyle (check-style) @
> > > > hibernate-ogm-core ---
> > > > [INFO] Starting audit...
> > > >
> > > >
> > >
> > /Users/emmanuel/Code/ogm/hibernate-ogm-core/src/test/java/org/hibernate/ogm/test/id/Label.java:64:
> > > > Only one new line is allowed at the end of a file
> > > > Audit done.
> > > >
> > > > [INFO]
> > > >
> > 
> > > > [INFO] Reactor Summary:
> > > > [INFO]
> > > > [INFO] Hibernate OGM Aggregator .. SUCCESS
> > > > [3.493s]
> > > > [INFO] Hibernate Object Grid Mapper .. FAILURE
> > > > [28.596s]
> > > > [INFO] Hibernate OGM Ehcache integration . SKIPPED
> > > > [INFO] Hibernate OGM Infinispan integration .. SKIPPED
> > > > [INFO] Hibernate OGM Module .. SKIPPED
> > > > [INFO] Hibernate OGM Integration and performance Tests ... SKIPPED
> > > > [INFO] Hibernate OGM Integration Test case ... SKIPPED
> > > > [INFO]
> > > >
> > 
> > > > [INFO] BUILD FAILURE
> > > > [INFO]
> > > >
> > 
> > > > [INFO] Total time: 33.217s
> > > > [INFO] Finished at: Fri May 03 00:14:08 CEST 2013
> > > > [INFO] Final Memory: 36M/335M
> > > > [INFO]
> > > >
> > 
> > > > [ERROR] Failed to execute goal
> > > > org.apache.maven.plugins:maven-checkstyle-plugin:2.10:checkstyle
> > > > (check-style) on project hibernate-ogm-core: An error has occurred in
> > > > Checkstyle report generation. Failed during checkstyle execution: There
> > > > are 1 checkstyle errors. -> [Help 1]
> > > > [ERROR]
> > > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> > the
> > > > -e switch.
> > > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > > > [ERROR]
> > > > [ERROR] For more information about the errors and possible solutions,
> > > > please read the following articles:
> > > > [ERROR] [Help 1]
> > > >
> > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > > > [ERROR]
> > > > [ERROR] After correcting the problems, you can resume the build with
> > the
> > > > command
> > > > [ERROR]   mvn  -rf :hibernate-ogm-core
> > > > ___
> > > > 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
> >
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org

Re: [hibernate-dev] Checkstyle breaking the OGM build

[Guillaume SCHEIBEL]

Did you get the latest patch (added by Davide) to fix the endofline issue ?


2013/5/3 Emmanuel Bernard 

> I found the problem, not sure where that comes from though.
>
> On a fresh repo clone it works as expected. So I did diff the two and
> found that the failing version has lines ending as CRLF (Windows) and
> the fresh repo has lines ending as LF (Unix).
>
> On Fri 2013-05-03  8:32, Gunnar Morling wrote:
> > Works for me on my Mac as expected, i.e. I get the violation only when I
> > really add another new line.
> >
> > > I'm wondering if we really want to keep this rule
> >
> > Personally I like the rule, several empty lines always look a bit odd to
> > me. But if the check can't be executed reliably, it's surely not big
> loss.
> >
> > --Gunnar
> >
> >
> >
> > 2013/5/3 Sanne Grinovero 
> >
> > > Can't reproduce this either. I'm wondering if we really want to keep
> this
> > > rule: its benefit is limited and even before this case we had trouble
> with
> > > it on windows.
> > > On 2 May 2013 23:41, "Guillaume SCHEIBEL" <
> guillaume.schei...@gmail.com>
> > > wrote:
> > >
> > > > Hi Emmanuel,
> > > >
> > > > Sorry I can't reproduce it and both maven & intellij plugins are
> telling
> > > me
> > > > the Label class respects the rules.
> > > >
> > > > Guillaume
> > > >
> > > >
> > > > 2013/5/3 Emmanuel Bernard 
> > > >
> > > > > Taking OGM master, I get a checkstyle failure on one of the test
> file.
> > > > > But what is surprising is that I don't see new lines at the end of
> the
> > > > > described file.
> > > > >
> > > > > Can you guys reproduce?
> > > > >
> > > > > Emmanuel
> > > > >
> > > > > [INFO] --- maven-resources-plugin:2.5:resources
> (default-resources) @
> > > > > hibernate-ogm-core ---
> > > > > [debug] execute contextualize
> > > > > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > > > > [INFO] Copying 2 resources
> > > > > [INFO]
> > > > > [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> > > > > hibernate-ogm-core ---
> > > > > [INFO] Compiling 150 source files to
> > > > > /Users/emmanuel/Code/ogm/hibernate-ogm-core/target/classes
> > > > > [INFO]
> > > > > [INFO] --- maven-checkstyle-plugin:2.10:checkstyle (check-style) @
> > > > > hibernate-ogm-core ---
> > > > > [INFO] Starting audit...
> > > > >
> > > > >
> > > >
> > >
> /Users/emmanuel/Code/ogm/hibernate-ogm-core/src/test/java/org/hibernate/ogm/test/id/Label.java:64:
> > > > > Only one new line is allowed at the end of a file
> > > > > Audit done.
> > > > >
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [INFO] Reactor Summary:
> > > > > [INFO]
> > > > > [INFO] Hibernate OGM Aggregator .. SUCCESS
> > > > > [3.493s]
> > > > > [INFO] Hibernate Object Grid Mapper .. FAILURE
> > > > > [28.596s]
> > > > > [INFO] Hibernate OGM Ehcache integration . SKIPPED
> > > > > [INFO] Hibernate OGM Infinispan integration .. SKIPPED
> > > > > [INFO] Hibernate OGM Module .. SKIPPED
> > > > > [INFO] Hibernate OGM Integration and performance Tests ... SKIPPED
> > > > > [INFO] Hibernate OGM Integration Test case ... SKIPPED
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [INFO] BUILD FAILURE
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [INFO] Total time: 33.217s
> > > > > [INFO] Finished at: Fri May 03 00:14:08 CEST 2013
> > > > > [INFO] Final Memory: 36M/335M
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [ERROR] Failed to execute goal
> > > > > org.apache.maven.plugins:maven-checkstyle-plugin:2.10:checkstyle
> > > > > (check-style) on project hibernate-ogm-core: An error has occurred
> in
> > > > > Checkstyle report generation. Failed during checkstyle execution:
> There
> > > > > are 1 checkstyle errors. -> [Help 1]
> > > > > [ERROR]
> > > > > [ERROR] To see the full stack trace of the errors, re-run Maven
> with
> > > the
> > > > > -e switch.
> > > > > [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> > > > > [ERROR]
> > > > > [ERROR] For more information about the errors and possible
> solutions,
> > > > > please read the following articles:
> > > > > [ERROR] [Help 1]
> > > > >
> > >
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > > > > [ERROR]
> > > > > [ERROR] After correcting the problems, you can resume the build
> with
> > > the
> > > > > command
> > > > > [ERROR]   mvn  -rf :hibernate-ogm-core
> > > > > ___
> > > > > hibernate-dev mailing list
> > > > > hibernate-dev@lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > >
> > > > ___
> > > > hib

Re: [hibernate-dev] Checkstyle breaking the OGM build

[Gunnar Morling]

Ah, it may then be that you have to re-normalize the line endings in your
existing checkout as described in [1]:

git rm --cached -r .# Remove everything from the index.
git reset --hard# Write both the index and working directory from git's
database.

[1] https://help.github.com/articles/dealing-with-line-endings




2013/5/3 Emmanuel Bernard 

> I found the problem, not sure where that comes from though.
>
> On a fresh repo clone it works as expected. So I did diff the two and
> found that the failing version has lines ending as CRLF (Windows) and
> the fresh repo has lines ending as LF (Unix).
>
> On Fri 2013-05-03  8:32, Gunnar Morling wrote:
> > Works for me on my Mac as expected, i.e. I get the violation only when I
> > really add another new line.
> >
> > > I'm wondering if we really want to keep this rule
> >
> > Personally I like the rule, several empty lines always look a bit odd to
> > me. But if the check can't be executed reliably, it's surely not big
> loss.
> >
> > --Gunnar
> >
> >
> >
> > 2013/5/3 Sanne Grinovero 
> >
> > > Can't reproduce this either. I'm wondering if we really want to keep
> this
> > > rule: its benefit is limited and even before this case we had trouble
> with
> > > it on windows.
> > > On 2 May 2013 23:41, "Guillaume SCHEIBEL" <
> guillaume.schei...@gmail.com>
> > > wrote:
> > >
> > > > Hi Emmanuel,
> > > >
> > > > Sorry I can't reproduce it and both maven & intellij plugins are
> telling
> > > me
> > > > the Label class respects the rules.
> > > >
> > > > Guillaume
> > > >
> > > >
> > > > 2013/5/3 Emmanuel Bernard 
> > > >
> > > > > Taking OGM master, I get a checkstyle failure on one of the test
> file.
> > > > > But what is surprising is that I don't see new lines at the end of
> the
> > > > > described file.
> > > > >
> > > > > Can you guys reproduce?
> > > > >
> > > > > Emmanuel
> > > > >
> > > > > [INFO] --- maven-resources-plugin:2.5:resources
> (default-resources) @
> > > > > hibernate-ogm-core ---
> > > > > [debug] execute contextualize
> > > > > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > > > > [INFO] Copying 2 resources
> > > > > [INFO]
> > > > > [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> > > > > hibernate-ogm-core ---
> > > > > [INFO] Compiling 150 source files to
> > > > > /Users/emmanuel/Code/ogm/hibernate-ogm-core/target/classes
> > > > > [INFO]
> > > > > [INFO] --- maven-checkstyle-plugin:2.10:checkstyle (check-style) @
> > > > > hibernate-ogm-core ---
> > > > > [INFO] Starting audit...
> > > > >
> > > > >
> > > >
> > >
> /Users/emmanuel/Code/ogm/hibernate-ogm-core/src/test/java/org/hibernate/ogm/test/id/Label.java:64:
> > > > > Only one new line is allowed at the end of a file
> > > > > Audit done.
> > > > >
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [INFO] Reactor Summary:
> > > > > [INFO]
> > > > > [INFO] Hibernate OGM Aggregator .. SUCCESS
> > > > > [3.493s]
> > > > > [INFO] Hibernate Object Grid Mapper .. FAILURE
> > > > > [28.596s]
> > > > > [INFO] Hibernate OGM Ehcache integration . SKIPPED
> > > > > [INFO] Hibernate OGM Infinispan integration .. SKIPPED
> > > > > [INFO] Hibernate OGM Module .. SKIPPED
> > > > > [INFO] Hibernate OGM Integration and performance Tests ... SKIPPED
> > > > > [INFO] Hibernate OGM Integration Test case ... SKIPPED
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [INFO] BUILD FAILURE
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [INFO] Total time: 33.217s
> > > > > [INFO] Finished at: Fri May 03 00:14:08 CEST 2013
> > > > > [INFO] Final Memory: 36M/335M
> > > > > [INFO]
> > > > >
> > >
> 
> > > > > [ERROR] Failed to execute goal
> > > > > org.apache.maven.plugins:maven-checkstyle-plugin:2.10:checkstyle
> > > > > (check-style) on project hibernate-ogm-core: An error has occurred
> in
> > > > > Checkstyle report generation. Failed during checkstyle execution:
> There
> > > > > are 1 checkstyle errors. -> [Help 1]
> > > > > [ERROR]
> > > > > [ERROR] To see the full stack trace of the errors, re-run Maven
> with
> > > the
> > > > > -e switch.
> > > > > [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> > > > > [ERROR]
> > > > > [ERROR] For more information about the errors and possible
> solutions,
> > > > > please read the following articles:
> > > > > [ERROR] [Help 1]
> > > > >
> > >
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > > > > [ERROR]
> > > > > [ERROR] After correcting the problems, you can resume the build
> with
> > > the
> > > > > command
> > > > > [ERROR]   mvn  -rf :hibernate-ogm-core
> > > > > _

Re: [hibernate-dev] hibernate dialect for hana

[Sanne Grinovero]

Why not? Especially as Hana looks extremely interesting.

I recall some discussion about having the database vendors maintain them,
but to go that route we could at least document how it works and make sure
it's easy enough for end users.

I think I'd prefer to see if database vendors are willing to donate hosting
of a public instance of their db for test purposes.
 On 3 May 2013 04:02, "Strong Liu"  wrote:

> IIRC there was an agreement that we'd not accept new dialect anymore
>
> On May 2, 2013, at 3:41 AM, Andrew Clemons 
> wrote:
>
> > I'd like to follow up on the discussion started here[1]. I was asked to
> > port an existing application to Hana, so my first task was to write a
> > hibernate dialect for it. I've completed this and so far it is working
> > nicely in the integration tests for the application. My app is still
> > using Hibernate 3.3, so that was my starting point, but with a few small
> > changes it also compiles against the current git master. Is there still
> > interest in such a dialect? Should I open a jira ticket and submit a
> > pull request?
> >
> > Thanks,
> > Andrew
> >
> > [1]
> https://community.jboss.org/wiki/DoHibernatePlanToSupportSAPHANADatabase
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> -
> Best Regards,
>
> Strong Liu 
> http://about.me/stliu/bio
>
>
>
> ___
> 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] hibernate dialect for hana

[Strong Liu]

I think the main reason is the lack of dev resource, if someone is willing to 
promise that long time contribution / maintains, I'm fine with that, or it will 
just become some dead code that we don't have knowledge nor time to maintains.

On May 3, 2013, at 4:47 PM, Sanne Grinovero  wrote:

> Why not? Especially as Hana looks extremely interesting.
> 
> I recall some discussion about having the database vendors maintain them, but 
> to go that route we could at least document how it works and make sure it's 
> easy enough for end users.
> 
> I think I'd prefer to see if database vendors are willing to donate hosting 
> of a public instance of their db for test purposes. 
> On 3 May 2013 04:02, "Strong Liu"  wrote:
> IIRC there was an agreement that we'd not accept new dialect anymore
> 
> On May 2, 2013, at 3:41 AM, Andrew Clemons  wrote:
> 
> > I'd like to follow up on the discussion started here[1]. I was asked to
> > port an existing application to Hana, so my first task was to write a
> > hibernate dialect for it. I've completed this and so far it is working
> > nicely in the integration tests for the application. My app is still
> > using Hibernate 3.3, so that was my starting point, but with a few small
> > changes it also compiles against the current git master. Is there still
> > interest in such a dialect? Should I open a jira ticket and submit a
> > pull request?
> >
> > Thanks,
> > Andrew
> >
> > [1] https://community.jboss.org/wiki/DoHibernatePlanToSupportSAPHANADatabase
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> -
> Best Regards,
> 
> Strong Liu 
> http://about.me/stliu/bio
> 
> 
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio



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

Re: [hibernate-dev] hibernate dialect for hana

[Emmanuel Bernard]

But we can definitely have a wiki page or even better a table in the
documentation for third party dialects and where they are hosted.
That' cheap for us and keep the ecosystem thriving.

Emmanuel

On Fri 2013-05-03 17:17, Strong Liu wrote:
> I think the main reason is the lack of dev resource, if someone is willing to 
> promise that long time contribution / maintains, I'm fine with that, or it 
> will just become some dead code that we don't have knowledge nor time to 
> maintains.
> 
> On May 3, 2013, at 4:47 PM, Sanne Grinovero  wrote:
> 
> > Why not? Especially as Hana looks extremely interesting.
> > 
> > I recall some discussion about having the database vendors maintain them, 
> > but to go that route we could at least document how it works and make sure 
> > it's easy enough for end users.
> > 
> > I think I'd prefer to see if database vendors are willing to donate hosting 
> > of a public instance of their db for test purposes. 
> > On 3 May 2013 04:02, "Strong Liu"  wrote:
> > IIRC there was an agreement that we'd not accept new dialect anymore
> > 
> > On May 2, 2013, at 3:41 AM, Andrew Clemons  wrote:
> > 
> > > I'd like to follow up on the discussion started here[1]. I was asked to
> > > port an existing application to Hana, so my first task was to write a
> > > hibernate dialect for it. I've completed this and so far it is working
> > > nicely in the integration tests for the application. My app is still
> > > using Hibernate 3.3, so that was my starting point, but with a few small
> > > changes it also compiles against the current git master. Is there still
> > > interest in such a dialect? Should I open a jira ticket and submit a
> > > pull request?
> > >
> > > Thanks,
> > > Andrew
> > >
> > > [1] 
> > > https://community.jboss.org/wiki/DoHibernatePlanToSupportSAPHANADatabase
> > >
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> > -
> > Best Regards,
> > 
> > Strong Liu 
> > http://about.me/stliu/bio
> > 
> > 
> > 
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> -
> Best Regards,
> 
> Strong Liu 
> http://about.me/stliu/bio
> 
> 
> 
> ___
> 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] A synchronous JGroups backend for Hibernate Search

[Emmanuel Bernard]

I did not think of that but an "implicit" or "auto" setting makes some
sense.
Just to be sure, the new immplicit setting / behavior will break the
semantic of what's going on so it should at least but a minor version
bump. Correct?

BTW, did you guys even found out why using sync was taking so much time?

Emmanuel

On Mon 2013-04-15 18:00, Sanne Grinovero wrote:
> In my first draft for HSEARCH-1296 I was automatically enabling the
> blocking behaviour on JGroups if the worker backend was configured to
> be synchronous (which is the default for workers),
> but Emmanuel didn't like that and I think he has a good point:
> 
> The JGroups behaviour and the workers behaviour are two different
> things; so I just separated this into a new configuration property
> 
> "block_waiting_ack" (boolean)
> 
> which of course applies only to the JGroups backends.
> 
> I agree it's important to keep the two separate, but also if the user
> is configuring an ASYNC worker, he should set this option to false as
> there is no benefit in waiting for the delivery.
> Likewise, if SYNC is required, you would probably want to set this to true.
> 
> So I'm suggesting we make the default value ot "block_waiting_ack"
> dependant on the worker execution, exposing the property as an
> override.
> 
> Thoughts?
> 
> I guess it's much easier to understand the default behaviour if we
> keep them separate, still I don't see much use for configuring the two
> independently.
> 
> Cheers,
> Sanne
> 
> https://hibernate.atlassian.net/browse/HSEARCH-1296
> ___
> 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] hibernate dialect for hana

[Sanne Grinovero]

+1

But I'd really like to see - for example - Oracle providing free to
use (and hosted) RDBMS instance, 10gen a MongoDB instance, etc.. so
they can update it as they see fit and deal with the maintenance
aspects of it (and licencing + execution costs).

Ideally if someone - like Andrew in this case - would be willing to be
notified from continuous integration failures and make sure someone
will help, then I think it would be more effective to keep the code in
Hibernate.


On 3 May 2013 10:29, Emmanuel Bernard  wrote:
> But we can definitely have a wiki page or even better a table in the
> documentation for third party dialects and where they are hosted.
> That' cheap for us and keep the ecosystem thriving.
>
> Emmanuel
>
> On Fri 2013-05-03 17:17, Strong Liu wrote:
>> I think the main reason is the lack of dev resource, if someone is willing 
>> to promise that long time contribution / maintains, I'm fine with that, or 
>> it will just become some dead code that we don't have knowledge nor time to 
>> maintains.
>>
>> On May 3, 2013, at 4:47 PM, Sanne Grinovero  wrote:
>>
>> > Why not? Especially as Hana looks extremely interesting.
>> >
>> > I recall some discussion about having the database vendors maintain them, 
>> > but to go that route we could at least document how it works and make sure 
>> > it's easy enough for end users.
>> >
>> > I think I'd prefer to see if database vendors are willing to donate 
>> > hosting of a public instance of their db for test purposes.
>> > On 3 May 2013 04:02, "Strong Liu"  wrote:
>> > IIRC there was an agreement that we'd not accept new dialect anymore
>> >
>> > On May 2, 2013, at 3:41 AM, Andrew Clemons  
>> > wrote:
>> >
>> > > I'd like to follow up on the discussion started here[1]. I was asked to
>> > > port an existing application to Hana, so my first task was to write a
>> > > hibernate dialect for it. I've completed this and so far it is working
>> > > nicely in the integration tests for the application. My app is still
>> > > using Hibernate 3.3, so that was my starting point, but with a few small
>> > > changes it also compiles against the current git master. Is there still
>> > > interest in such a dialect? Should I open a jira ticket and submit a
>> > > pull request?
>> > >
>> > > Thanks,
>> > > Andrew
>> > >
>> > > [1] 
>> > > https://community.jboss.org/wiki/DoHibernatePlanToSupportSAPHANADatabase
>> > >
>> > > ___
>> > > hibernate-dev mailing list
>> > > hibernate-dev@lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> > -
>> > Best Regards,
>> >
>> > Strong Liu 
>> > http://about.me/stliu/bio
>> >
>> >
>> >
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> -
>> Best Regards,
>>
>> Strong Liu 
>> http://about.me/stliu/bio
>>
>>
>>
>> ___
>> 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] A synchronous JGroups backend for Hibernate Search

[Sanne Grinovero]

On 3 May 2013 10:47, Emmanuel Bernard  wrote:
> I did not think of that but an "implicit" or "auto" setting makes some
> sense.
> Just to be sure, the new immplicit setting / behavior will break the
> semantic of what's going on so it should at least but a minor version
> bump. Correct?

Correct, this was released as 4.3.0.Alpha1 :
http://docs.jboss.org/hibernate/search/4.3/reference/en-US/html_single/#jgroups-backend

[http://in.relation.to/Bloggers/HibernateSearch43SimplifyClusteringAndJBossEAP61Integrations]

BUT I didn't realize it would effectively change interpretation of
existing configurations; my bad, updating the migration guide now..

>
> BTW, did you guys even found out why using sync was taking so much time?

Yes, although it was a painfully long debug session (week+): the way
we where using the JGroups API was "unexpected" and would trigged
faulty behaviour. This is way our backend ended up to be mostly
rewritten, to better match JGroups typical usage. Also JGroups issues
where opened to avoid the pitfall.

In short, the operation would complete quickly (<5 milliseconds) on
the master node, but then the client thread would be stuck waiting for
one more reply than what it would receive in practice, waiting for the
timeout: so that added 10 seconds for each RPC. After the timeout
would trigger, the client thread would actually realize the ACK *was*
received, so wouldn't throw an error as all was processed fine. Added
very strict test for this ;-)


>
> Emmanuel
>
> On Mon 2013-04-15 18:00, Sanne Grinovero wrote:
>> In my first draft for HSEARCH-1296 I was automatically enabling the
>> blocking behaviour on JGroups if the worker backend was configured to
>> be synchronous (which is the default for workers),
>> but Emmanuel didn't like that and I think he has a good point:
>>
>> The JGroups behaviour and the workers behaviour are two different
>> things; so I just separated this into a new configuration property
>>
>> "block_waiting_ack" (boolean)
>>
>> which of course applies only to the JGroups backends.
>>
>> I agree it's important to keep the two separate, but also if the user
>> is configuring an ASYNC worker, he should set this option to false as
>> there is no benefit in waiting for the delivery.
>> Likewise, if SYNC is required, you would probably want to set this to true.
>>
>> So I'm suggesting we make the default value ot "block_waiting_ack"
>> dependant on the worker execution, exposing the property as an
>> override.
>>
>> Thoughts?
>>
>> I guess it's much easier to understand the default behaviour if we
>> keep them separate, still I don't see much use for configuring the two
>> independently.
>>
>> Cheers,
>> Sanne
>>
>> https://hibernate.atlassian.net/browse/HSEARCH-1296
>> ___
>> 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] A synchronous JGroups backend for Hibernate Search

[Ales Justin]

> I did not think of that but an "implicit" or "auto" setting makes some
> sense.
> Just to be sure, the new immplicit setting / behavior will break the
> semantic of what's going on so it should at least but a minor version
> bump. Correct?
> 
> BTW, did you guys even found out why using sync was taking so much time?

Afaik, JGroups were waiting for response, which they didn't get -- can't 
remember now why not;
hence it only continued on default JGroups timeout, which is 10sec -- and we 
had 5 ops aka ~50sec.

-Ales

> On Mon 2013-04-15 18:00, Sanne Grinovero wrote:
>> In my first draft for HSEARCH-1296 I was automatically enabling the
>> blocking behaviour on JGroups if the worker backend was configured to
>> be synchronous (which is the default for workers),
>> but Emmanuel didn't like that and I think he has a good point:
>> 
>> The JGroups behaviour and the workers behaviour are two different
>> things; so I just separated this into a new configuration property
>> 
>> "block_waiting_ack" (boolean)
>> 
>> which of course applies only to the JGroups backends.
>> 
>> I agree it's important to keep the two separate, but also if the user
>> is configuring an ASYNC worker, he should set this option to false as
>> there is no benefit in waiting for the delivery.
>> Likewise, if SYNC is required, you would probably want to set this to true.
>> 
>> So I'm suggesting we make the default value ot "block_waiting_ack"
>> dependant on the worker execution, exposing the property as an
>> override.
>> 
>> Thoughts?
>> 
>> I guess it's much easier to understand the default behaviour if we
>> keep them separate, still I don't see much use for configuring the two
>> independently.
>> 
>> Cheers,
>> Sanne
>> 
>> https://hibernate.atlassian.net/browse/HSEARCH-1296
>> ___
>> 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] hibernate dialect for hana

[Andrew Clemons]

Hi,

On 2013-05-03 17:17:28 +0800, Strong Liu wrote:
> I think the main reason is the lack of dev resource, if someone is
> willing to promise that long time contribution / maintains, I'm fine
> with that, or it will just become some dead code that we don't have
> knowledge nor time to maintains.

I probably should have mentioned this in my first email, but I work for
SAP (through an acquisition). I am not involved in HANA development, but
was told it might be interesting to port the app I work on to HANA, so
that's how I got started working on the dialect on my own time. I asked
around internally at SAP and was told there was a lot of interest in
having Hibernate support for HANA and that quite a few external
inquiries had been made about it. I was encouraged to submit this (which
I was planning anyway) and that SAP are also willing to maintain it. SAP
have also already submitted code for HANA to EclipseLink.

Andrew

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

Re: [hibernate-dev] improved Eclipse project support

[Gunnar Morling]

Hi Steve,

I've pushed some commits for using the Animal Sniffer plug-in to discover
the usage of Java 7 APIs to my fork [1]. This uses the Ant task and fails
the build when using methods not existent in Java 6 such as emptyIterator().

I'm still in the process of testing this but thought it would be good to
get some early feedback since this is my first change to the ORM build
scripts. If you think the change is ok I'll create a PR for this. I'm
currently only checking the main classes, if you think test classes should
be checked as well that's easy to add.

--Gunnar

[1] https://github.com/gunnarmorling/hibernate-orm/compare/HHH-8219



2013/4/17 Steve Ebersole 

>  I think it would be great if you wanted to try including this in the ORM
> build.  Worst case you could just use the sniffer ant tasks from Gradle.
>
>
>
> On 04/16/2013 09:44 AM, Gunnar Morling wrote:
>
> 2013/4/16 Steve Ebersole 
>
>> What is "configured JDK baseline"?  Do you have to point to a JDK path?
>> If so, no difference than just setting the javac bootstrap option to a
>> local path.
>
>
>  No, you don't point to another JDK path, you use the JDK you are on,
> i.e. Java 7. You just say which JDK version you want to target, e.g. 1.6.
> In the HV case, the config is this:
>
>  
> org.codehaus.mojo
> animal-sniffer-maven-plugin
> 1.9
> 
> 
> org.codehaus.mojo.signature
> java16
> 1.0
> 
> 
> 
>
>  The referenced signature artifact contains the API signature for that
> JDK version, i.e. all Java 1.6 methods, public fields etc. If your code
> uses a method which is not part of that API signature, the plug-in will
> fail the build.
>
>  That is, you still use the Java 7 API to compile against, but the
> plug-in makes sure you use only those parts of the API which where there
> already as of Java 6. So this emulates building against Java 6, but without
> the hassle of handling several actual JDKs, setting up the boot classpath
> etc.
>
>
>
>>
>>
>> On Tue 16 Apr 2013 08:38:37 AM CDT, Gunnar Morling wrote:
>>
>>>  In HV, we use the Animal Sniffer plug-in [1] for that purpose.
>>>
>>> This checks the code base against a configured JDK baseline and fails
>>> the build, when e.g. using a method which is not part of the targeted
>>> JDK release. In other words, you still use your current JDK for
>>> building (avoiding any bootstrap path fiddling) but make sure you
>>> invoke only those parts of the API which are also available in the
>>> targeted Java version.
>>>
>>> Together with the source/target level correctly set, this allows to
>>> safely compile with newer JDK versions and still be sure that the code
>>> e.g. runs on 6.
>>>
>>> We use the Maven plug-in, but via the Ant task, this should also be
>>> usable for Gradle builds. If you like me to, I can give this a try for
>>> ORM.
>>>
>>> --Gunnar
>>>
>>> [1] http://mojo.codehaus.org/animal-sniffer/index.html
>>>
>>>
>>> 2013/4/16 Steve Ebersole >>  >
>>>
>>>
>>> Mainly thats an issue with that fact that so far we have not
>>> defined 'bootstrap class path' option to javac to go along with
>>> the source/target compatibility settings.  The difficulty is that
>>> defining bootstrap for javac becomes very system specific (it
>>> needs to name a path).  Sure we could externalize that into a
>>> setting, but then what do you do when someone wants to build
>>> Hibernate but has not defined this setting?  Do you let the build
>>> continue (aka, make the bootstrap setting optional)?
>>>
>>> Bottom line, just setting source/target compatibility is never
>>> enough.
>>>
>>>
>>> On Tue 16 Apr 2013 03:44:29 AM CDT, Gunnar Morling wrote:
>>>
>>> On a related note:
>>>
>>> I know Java 7 is required to compile ORM, but is Java 7 also the
>>> required runtime Java version now (I vaguely remember a related
>>> discussion around the JPA API JAR)?
>>>
>>> I'm asking, because the Java 7 method
>>> Collections#emptyIterator() is
>>> used at two places, making this code not runnable on Java 6. If
>>> requiring 7 is intentional, feel free  to ignore this mail ;)
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2013/4/16 Gunnar Morling >> 
>>>  >>
>>>
>>>
>>> 2013/4/15 Steve Ebersole >> 
>>>  >>
>>> >>
>>>
>>>
>>> I am not touching this :)
>>>
>>> I think I have explained this 198,052 times thus far lol
>>>
>>>
>>> I must have missed this then. Or I was not yet part of the
>>> team at
>>> that time.
>>>
>>>
>>>  https://community.jboss.org/w

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

[Steve Ebersole]

I dont understand what you mean with HHH-8220.  OK its a change, but how 
is that breaking any builds?

And for JDK 7 we have discussed that on this list already.  Gunnar will 
work on integrating some checks into the build to make sure we are not 
using JDK 7 features...

On 05/03/2013 02:08 AM, Strong Liu wrote:
> https://hibernate.atlassian.net/browse/HHH-8219
>
> https://hibernate.atlassian.net/browse/HHH-8220
>
>
> -
> Best Regards,
>
> Strong Liu 
> http://about.me/stliu/bio
>
>
>
> ___
> 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] improved Eclipse project support

[Steve Ebersole]

I'll take a look.

Thanks Gunnar!

On Fri 03 May 2013 06:13:53 AM CDT, Gunnar Morling wrote:
> Hi Steve,
>
> I've pushed some commits for using the Animal Sniffer plug-in to
> discover the usage of Java 7 APIs to my fork [1]. This uses the Ant
> task and fails the build when using methods not existent in Java 6
> such as emptyIterator().
>
> I'm still in the process of testing this but thought it would be good
> to get some early feedback since this is my first change to the ORM
> build scripts. If you think the change is ok I'll create a PR for
> this. I'm currently only checking the main classes, if you think test
> classes should be checked as well that's easy to add.
>
> --Gunnar
>
> [1] https://github.com/gunnarmorling/hibernate-orm/compare/HHH-8219
>
>
>
> 2013/4/17 Steve Ebersole  >
>
> I think it would be great if you wanted to try including this in
> the ORM build.  Worst case you could just use the sniffer ant
> tasks from Gradle.
>
>
>
> On 04/16/2013 09:44 AM, Gunnar Morling wrote:
>> 2013/4/16 Steve Ebersole > >
>>
>> What is "configured JDK baseline"?  Do you have to point to a
>> JDK path? If so, no difference than just setting the javac
>> bootstrap option to a local path.
>>
>>
>> No, you don't point to another JDK path, you use the JDK you are
>> on, i.e. Java 7. You just say which JDK version you want to
>> target, e.g. 1.6. In the HV case, the config is this:
>>
>> 
>> org.codehaus.mojo
>> animal-sniffer-maven-plugin
>> 1.9
>> 
>> 
>> org.codehaus.mojo.signature
>> java16
>> 1.0
>> 
>> 
>> 
>>
>> The referenced signature artifact contains the API signature for
>> that JDK version, i.e. all Java 1.6 methods, public fields etc.
>> If your code uses a method which is not part of that API
>> signature, the plug-in will fail the build.
>>
>> That is, you still use the Java 7 API to compile against, but the
>> plug-in makes sure you use only those parts of the API which
>> where there already as of Java 6. So this emulates building
>> against Java 6, but without the hassle of handling several actual
>> JDKs, setting up the boot classpath etc.
>>
>>
>>
>> On Tue 16 Apr 2013 08:38:37 AM CDT, Gunnar Morling wrote:
>>
>> In HV, we use the Animal Sniffer plug-in [1] for that
>> purpose.
>>
>> This checks the code base against a configured JDK
>> baseline and fails
>> the build, when e.g. using a method which is not part of
>> the targeted
>> JDK release. In other words, you still use your current
>> JDK for
>> building (avoiding any bootstrap path fiddling) but make
>> sure you
>> invoke only those parts of the API which are also
>> available in the
>> targeted Java version.
>>
>> Together with the source/target level correctly set, this
>> allows to
>> safely compile with newer JDK versions and still be sure
>> that the code
>> e.g. runs on 6.
>>
>> We use the Maven plug-in, but via the Ant task, this
>> should also be
>> usable for Gradle builds. If you like me to, I can give
>> this a try for
>> ORM.
>>
>> --Gunnar
>>
>> [1] http://mojo.codehaus.org/animal-sniffer/index.html
>>
>>
>> 2013/4/16 Steve Ebersole > 
>> > >>
>>
>>
>> Mainly thats an issue with that fact that so far we
>> have not
>> defined 'bootstrap class path' option to javac to go
>> along with
>> the source/target compatibility settings.  The
>> difficulty is that
>> defining bootstrap for javac becomes very system
>> specific (it
>> needs to name a path).  Sure we could externalize
>> that into a
>> setting, but then what do you do when someone wants
>> to build
>> Hibernate but has not defined this setting?  Do you
>> let the build
>> continue (aka, make the bootstrap setting optional)?
>>
>> Bottom line, just setting source/target compatibility
>> is never enough.
>>
>>
>> On Tue 16 Apr 2013 03:44:29 AM CDT, Gunnar Morling wrote:
>>
>> On a related note:
>>
>> I know Java 7 is required to compile ORM, but is
>> Java 7 also the
>> required runtime Java versio

Re: [hibernate-dev] hibernate dialect for hana

[Steve Ebersole]

We've never said we were not accepting new dialects.  What was said is 
that there needs to be some accountability for new dialects. Sounds like 
we have that here...

On 05/03/2013 05:37 AM, Andrew Clemons wrote:
> Hi,
>
> On 2013-05-03 17:17:28 +0800, Strong Liu wrote:
>> I think the main reason is the lack of dev resource, if someone is
>> willing to promise that long time contribution / maintains, I'm fine
>> with that, or it will just become some dead code that we don't have
>> knowledge nor time to maintains.
> I probably should have mentioned this in my first email, but I work for
> SAP (through an acquisition). I am not involved in HANA development, but
> was told it might be interesting to port the app I work on to HANA, so
> that's how I got started working on the dialect on my own time. I asked
> around internally at SAP and was told there was a lot of interest in
> having Hibernate support for HANA and that quite a few external
> inquiries had been made about it. I was encouraged to submit this (which
> I was planning anyway) and that SAP are also willing to maintain it. SAP
> have also already submitted code for HANA to EclipseLink.
>
> Andrew
>
> ___
> 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] breaking compatibility issues found in 4.3.0.Beta3

[Strong Liu]

On May 3, 2013, at 8:13 PM, Steve Ebersole  wrote:

> I dont understand what you mean with HHH-8220.  OK its a change, but how is 
> that breaking any builds?
> 

suppose there is a WAR project that uses hibernate, and it has a compile scope 
dependency of h-em

before this 4.3.0.Beta2, the HEM will brings all required dependencies in ( for 
example, h-core )

but after upgrade to 4.3.0.Beta2, the build WAR will only contains HEM and no 
H-Core since HEM now has a runtime scope dependency of h-core

then the WAR will fail when being deployed 


> And for JDK 7 we have discussed that on this list already.  Gunnar will work 
> on integrating some checks into the build to make sure we are not using JDK 7 
> features…
> 


I'm aware of this , just pointed out that this 4.3.0.Beta2 will fail on JDK 6, 
and others who run into this issue will know the reason

> 
> On 05/03/2013 02:08 AM, Strong Liu wrote:
>> https://hibernate.atlassian.net/browse/HHH-8219
>> 
>> https://hibernate.atlassian.net/browse/HHH-8220
>> 
>> 
>> -
>> Best Regards,
>> 
>> Strong Liu 
>> http://about.me/stliu/bio
>> 
>> 
>> 
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio



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

[hibernate-dev] Developer IRC Meeting - 5/2

[Steve Ebersole]

Unfortunately my internet connection was spotty today...

[11:14]  Minutes: 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-05-02-15.03.html
[11:14]  Minutes (text): 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-05-02-15.03.txt
[11:14]  Log: 
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-05-02-15.03.log.html
 

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

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

[Steve Ebersole]

Have you tried this?  Runtimr and compile scopes are both transitive, so 
the situation you describe should work just as before

On 05/03/2013 07:23 AM, Strong Liu wrote:
>
> On May 3, 2013, at 8:13 PM, Steve Ebersole  > wrote:
>
>> I dont understand what you mean with HHH-8220.  OK its a change, but 
>> how is that breaking any builds?
>>
>
> suppose there is a WAR project that uses hibernate, and it has a 
> compile scope dependency of h-em
>
> before this 4.3.0.Beta2, the HEM will brings all required dependencies 
> in ( for example, h-core )
>
> but after upgrade to 4.3.0.Beta2, the build WAR will only contains HEM 
> and no H-Core since HEM now has a runtime scope dependency of h-core
>
> then the WAR will fail when being deployed
>
>
>> And for JDK 7 we have discussed that on this list already.  Gunnar 
>> will work on integrating some checks into the build to make sure we 
>> are not using JDK 7 features…
>>
>
>
> I'm aware of this , just pointed out that this 4.3.0.Beta2 will fail 
> on JDK 6, and others who run into this issue will know the reason
>
>>
>> On 05/03/2013 02:08 AM, Strong Liu wrote:
>>> https://hibernate.atlassian.net/browse/HHH-8219
>>>
>>> https://hibernate.atlassian.net/browse/HHH-8220
>>>
>>>
>>> -
>>> Best Regards,
>>>
>>> Strong Liu 
>>> http://about.me/stliu/bio
>>>
>>>
>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> -
> Best Regards,
>
> Strong Liu http://hibernate.org/>>
> http://about.me/stliu/bio
>
>
>

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

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

[Strong Liu]

sorry, I missed the provided scope and runtime scope

the problem is :

now hibernate-core is a runtime scope dependency of h-em

so, suppose a project depends on h-em ( compile scope ) and the project uses 
h-core classes, then the project won't be compiled.
since runtime scope dependencies are not available on compile time classpath

a simple maven project would approve this ( attached )



On May 3, 2013, at 8:34 PM, Steve Ebersole  wrote:

> Have you tried this?  Runtimr and compile scopes are both transitive, so the 
> situation you describe should work just as before
> On May 3, 2013 7:23 AM, "Strong Liu"  wrote:
> 
> On May 3, 2013, at 8:13 PM, Steve Ebersole  wrote:
> 
>> I dont understand what you mean with HHH-8220.  OK its a change, but how is 
>> that breaking any builds?
>> 
> 
> suppose there is a WAR project that uses hibernate, and it has a compile 
> scope dependency of h-em
> 
> before this 4.3.0.Beta2, the HEM will brings all required dependencies in ( 
> for example, h-core )
> 
> but after upgrade to 4.3.0.Beta2, the build WAR will only contains HEM and no 
> H-Core since HEM now has a runtime scope dependency of h-core
> 
> then the WAR will fail when being deployed 
> 
> 
>> And for JDK 7 we have discussed that on this list already.  Gunnar will work 
>> on integrating some checks into the build to make sure we are not using JDK 
>> 7 features…
>> 
> 
> 
> I'm aware of this , just pointed out that this 4.3.0.Beta2 will fail on JDK 
> 6, and others who run into this issue will know the reason
> 
>> 
>> On 05/03/2013 02:08 AM, Strong Liu wrote:
>>> https://hibernate.atlassian.net/browse/HHH-8219
>>> 
>>> https://hibernate.atlassian.net/browse/HHH-8220
>>> 
>>> 
>>> -
>>> Best Regards,
>>> 
>>> Strong Liu 
>>> http://about.me/stliu/bio
>>> 
>>> 
>>> 
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
> 
> -
> Best Regards,
> 
> Strong Liu 
> http://about.me/stliu/bio
> 
> 
> 

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio



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

Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3

[Steve Ebersole]

Well purists would argue that relying on transitivity for dependencies 
that you need for *compilation* is a baad idea. In fact Maven's 
own primer to dependency management discusses this very thing:

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

specifically "it is intended that this should be runtime scope instead, 
so that all compile dependencies must be explicitly listed - however, 
there is the case where the library you depend on extends a class from 
another library, forcing you to have available at compile time. For this 
reason, compile time dependencies remain as compile scope even when they 
are transitive."

These are some of the exact reasons why so many folks dislike Maven's 
limited notion of dependency groupings (scopes).


On Fri 03 May 2013 08:05:37 AM CDT, Strong Liu wrote:
>
> sorry, I missed the provided scope and runtime scope
>
> the problem is :
>
> now hibernate-core is a runtime scope dependency of h-em
>
> so, suppose a project depends on h-em ( compile scope ) and the
> project uses h-core classes, then the project won't be compiled.
> since runtime scope dependencies are not available on compile time
> classpath
>
> a simple maven project would approve this ( attached )
>
>
>
>
> On May 3, 2013, at 8:34 PM, Steve Ebersole  > wrote:
>
>>
>> Have you tried this? Runtimr and compile scopes are both transitive,
>> so the situation you describe should work just as before
>>
>> On May 3, 2013 7:23 AM, "Strong Liu" > > wrote:
>>
>>
>> On May 3, 2013, at 8:13 PM, Steve Ebersole
>> mailto:steven.ebers...@gmail.com>> wrote:
>>
>>>
>>> I dont understand what you mean with HHH-8220. OK its a change,
>>> but how is that breaking any builds?
>>>
>>
>>
>> suppose there is a WAR project that uses hibernate, and it has a
>> compile scope dependency of h-em
>>
>> before this 4.3.0.Beta2, the HEM will brings all required
>> dependencies in ( for example, h-core )
>>
>> but after upgrade to 4.3.0.Beta2, the build WAR will only
>> contains HEM and no H-Core since HEM now has a runtime scope
>> dependency of h-core
>>
>> then the WAR will fail when being deployed
>>
>>
>>>
>>> And for JDK 7 we have discussed that on this list already.
>>> Gunnar will work on integrating some checks into the build to
>>> make sure we are not using JDK 7 features…
>>>
>>
>>
>>
>> I'm aware of this , just pointed out that this 4.3.0.Beta2 will
>> fail on JDK 6, and others who run into this issue will know the
>> reason
>>
>>>
>>>
>>> On 05/03/2013 02:08 AM, Strong Liu wrote:

 https://hibernate.atlassian.net/browse/HHH-8219

 https://hibernate.atlassian.net/browse/HHH-8220


 -
 Best Regards,

 Strong Liu http://hibernate.org/>>
 http://about.me/stliu/bio



 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 
 https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>
>>
>> -
>> Best Regards,
>>
>> Strong Liu http://hibernate.org/>>
>> http://about.me/stliu/bio
>>
>>
>>
>
>
> -
> Best Regards,
>
> Strong Liu http://hibernate.org/>>
> http://about.me/stliu/bio
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Metamodel

[Emmanuel Bernard]

Hello Davide,

Technically most of the knowledge is in
https://hibernate.atlassian.net/browse/OGM-208 but it's definitely quite
blurry for a new comer ;)

Let me try and summarize it for you. With that you'll be able to better
grasp the comments in OGM-208

## Goals

We want a metadata facility as a way to pass mapping and configuration
from the developer to the grid dialect /
datastore provider. I will call these options. The facility should:
- be expressible via annotations
- be expressible via a programmatic API
- be as type-safe as possible but not too hard to add configuration
  options

This project is essentially smart plumbing so the "clients" of this API
are the developers on one hand and the Datastore providers on the other
hand.

## What to reuse

We will most likely use Jandex to read annotations to benefit from the
ORM and WildFly work esp wrt indexing.

## Scopes: overriding and refining options

Each option might be:
- global, per entity, per property (with optional overridability from
  one to the other)
- global, specific to a session, specific to an operation (e.g. query)

On top of that options can be polled together by functional affinities
like key/value generic options, Infinispan specific options, document
store options etc.

## Programmatic API

The programmatic API can be used to define mapping options as well as
session or even operation options. It should be type-safe and will
likely look like Hibernate Search's approach more or less.

This is more or less what is in the branch. Check out the
package-info.java for some more information.

## Annotation

We need a way to convert an annotation into calls to the programmatic
API (semantically speaking at least). Something like an (meta)annotation
based conversion:

@ToInternalModel(UnsafeConverter.class)
@interface Unsafe {
boolean value() default true;
static class UnsafeConverter implements 
Convert {
void call(Unsafe annotation, MongoDBMappingInternalModelGenerator 
generator) {
return generator.unsafe(annotation.value());
}
}
}

This is todo

## Reading API

Datastore providers and GridDialect implementations should be able to
read back these options.

This is more or less what you can see in the last few code lines of my
OGM-207 comment of 27/Jul/12 6:33 PM.
The seed of it is the MappingService API on the branch but it looks all
untypesafe and wrong :) Let's call it unfinished.

## Expressing options in a type-safe way

If you look at OGM-207's comment of 27/Jul/12 6:33 PM, you will wee an
example of NamedQuery and Quorum options and the infrastructure needed.

It shows how to uniquely identify an option and how to model options
like quorum that are identified by their name and options like named
queries that are identified by their name + a key (the query name in
this case).

It's available in options.Iteration2's class.

## Tests

Tests are available in org.hibernate.ogm.test.mapping.

## Examples of options

You can imagine the following examples of options:

- quorum: express the R/W quorum (globally, per entity, per collection, per 
session) ; useful for dynamo based systems
- WriteConcern: express the write concern options for MongoDB (globally,
  per entity, per collection)
- Whether or not store association information in the main document or
  in a separate document (see MongoDB IN_ENTITY etc. We could have this
  option on a per collection basis and not a global setting.
- all datastore specific options whether they are global or relate to
  one entity or one property

I hope I have been clearer, fire the questions away.

Emmanuel

PS: JIRA no longer has a way to link to comments?

On Wed 2013-05-01  9:41, Davide D'Alto wrote:
> Hi,
> I've started to work on the metamodel. I've look at the branch that
> emmanuel created and I've rebased it to the latest master fixing all
> checkstyle violations: https://github.com/DavideD/hibernate-ogm/tree/208
> 
> The problem is that I don't have a clear idea how the metamodel is supposed
> to work, what could be a good test case to start with?
> 
> Thanks,
> Davide
> ___
> 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] breaking compatibility issues found in 4.3.0.Beta3

[Steve Ebersole]

I asked about this on the gradle-dev list.  Seems likely this is a 
change stemming from the new publishing dsl which i just switched 
Hibernate to use.


On Fri 03 May 2013 08:12:40 AM CDT, Steve Ebersole wrote:
> Well purists would argue that relying on transitivity for dependencies
> that you need for *compilation* is a baad idea. In fact
> Maven's own primer to dependency management discusses this very thing:
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
>
> specifically "it is intended that this should be runtime scope
> instead, so that all compile dependencies must be explicitly listed -
> however, there is the case where the library you depend on extends a
> class from another library, forcing you to have available at compile
> time. For this reason, compile time dependencies remain as compile
> scope even when they are transitive."
>
> These are some of the exact reasons why so many folks dislike Maven's
> limited notion of dependency groupings (scopes).
>
>
> On Fri 03 May 2013 08:05:37 AM CDT, Strong Liu wrote:
>>
>> sorry, I missed the provided scope and runtime scope
>>
>> the problem is :
>>
>> now hibernate-core is a runtime scope dependency of h-em
>>
>> so, suppose a project depends on h-em ( compile scope ) and the
>> project uses h-core classes, then the project won't be compiled.
>> since runtime scope dependencies are not available on compile time
>> classpath
>>
>> a simple maven project would approve this ( attached )
>>
>>
>>
>>
>> On May 3, 2013, at 8:34 PM, Steve Ebersole > > wrote:
>>
>>>
>>> Have you tried this? Runtimr and compile scopes are both transitive,
>>> so the situation you describe should work just as before
>>>
>>> On May 3, 2013 7:23 AM, "Strong Liu" >> > wrote:
>>>
>>>
>>> On May 3, 2013, at 8:13 PM, Steve Ebersole
>>> mailto:steven.ebers...@gmail.com>> wrote:
>>>

 I dont understand what you mean with HHH-8220. OK its a change,
 but how is that breaking any builds?

>>>
>>>
>>> suppose there is a WAR project that uses hibernate, and it has a
>>> compile scope dependency of h-em
>>>
>>> before this 4.3.0.Beta2, the HEM will brings all required
>>> dependencies in ( for example, h-core )
>>>
>>> but after upgrade to 4.3.0.Beta2, the build WAR will only
>>> contains HEM and no H-Core since HEM now has a runtime scope
>>> dependency of h-core
>>>
>>> then the WAR will fail when being deployed
>>>
>>>

 And for JDK 7 we have discussed that on this list already.
 Gunnar will work on integrating some checks into the build to
 make sure we are not using JDK 7 features…

>>>
>>>
>>>
>>> I'm aware of this , just pointed out that this 4.3.0.Beta2 will
>>> fail on JDK 6, and others who run into this issue will know the
>>> reason
>>>


 On 05/03/2013 02:08 AM, Strong Liu wrote:
>
> https://hibernate.atlassian.net/browse/HHH-8219
>
> https://hibernate.atlassian.net/browse/HHH-8220
>
>
> -
> Best Regards,
>
> Strong Liu http://hibernate.org/>>
> http://about.me/stliu/bio
>
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


>>>
>>>
>>> -
>>> Best Regards,
>>>
>>> Strong Liu http://hibernate.org/>>
>>> http://about.me/stliu/bio
>>>
>>>
>>>
>>
>>
>> -
>> Best Regards,
>>
>> Strong Liu http://hibernate.org/>>
>> http://about.me/stliu/bio
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Scripting releases - SourceForge

[Steve Ebersole]

I am working on scripting more of the release steps into the Gradle 
build scripts.  When it comes to uploading the release bundles to 
SourceForge we have a choice to make.  I will use rsync since we already 
require people doing a release to have it installed because 
docs.jboss.org uploads require it.

I can either account for the various SourceForge users in the script, or 
we could define a single user in the SourceForge Hibernate project that 
is there for uploading release bundles from the build.  That upload user 
would have just the permissions necessary to upload.  We would need, 
however, to manage getting keys uploaded to that user.  Whereas if we 
used our own SourceForge users we'd simply use our own keys.

Preferences?

Personally I'd rather just use our own users and account for the 
different usernames in the script (read from ~/.gradle/gradle.settings 
maybe).
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Scripting releases - SourceForge

[Gunnar Morling]

Maybe you could reuse the scripts Hardy built for HV (to be found in the HV
project under distribution/src/scripts)? This release script expects the SF
user to be specified as argument when invoking the script.

--Gunnar

- sent from my mobile phone -
Am 03.05.2013 18:42 schrieb "Steve Ebersole" :

> I am working on scripting more of the release steps into the Gradle
> build scripts.  When it comes to uploading the release bundles to
> SourceForge we have a choice to make.  I will use rsync since we already
> require people doing a release to have it installed because
> docs.jboss.org uploads require it.
>
> I can either account for the various SourceForge users in the script, or
> we could define a single user in the SourceForge Hibernate project that
> is there for uploading release bundles from the build.  That upload user
> would have just the permissions necessary to upload.  We would need,
> however, to manage getting keys uploaded to that user.  Whereas if we
> used our own SourceForge users we'd simply use our own keys.
>
> Preferences?
>
> Personally I'd rather just use our own users and account for the
> different usernames in the script (read from ~/.gradle/gradle.settings
> maybe).
> ___
> 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] Scripting releases - SourceForge

[Brett Meyer]

+1 for listing the users

Brett Meyer
Red Hat Software Engineer, Hibernate

- Original Message -
From: "Steve Ebersole" 
To: "hibernate-dev" 
Sent: Friday, May 3, 2013 12:41:35 PM
Subject: [hibernate-dev] Scripting releases - SourceForge

I am working on scripting more of the release steps into the Gradle 
build scripts.  When it comes to uploading the release bundles to 
SourceForge we have a choice to make.  I will use rsync since we already 
require people doing a release to have it installed because 
docs.jboss.org uploads require it.

I can either account for the various SourceForge users in the script, or 
we could define a single user in the SourceForge Hibernate project that 
is there for uploading release bundles from the build.  That upload user 
would have just the permissions necessary to upload.  We would need, 
however, to manage getting keys uploaded to that user.  Whereas if we 
used our own SourceForge users we'd simply use our own keys.

Preferences?

Personally I'd rather just use our own users and account for the 
different usernames in the script (read from ~/.gradle/gradle.settings 
maybe).
___
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] Scripting releases - SourceForge

[Sanne Grinovero]

can't you just omit the users?

I would assume that it's going to use rsync over SSH, so it should
pick the user I've defined for this server in my own ~/.ssh/config



On 3 May 2013 17:54, Brett Meyer  wrote:
> +1 for listing the users
>
> Brett Meyer
> Red Hat Software Engineer, Hibernate
>
> - Original Message -
> From: "Steve Ebersole" 
> To: "hibernate-dev" 
> Sent: Friday, May 3, 2013 12:41:35 PM
> Subject: [hibernate-dev] Scripting releases - SourceForge
>
> I am working on scripting more of the release steps into the Gradle
> build scripts.  When it comes to uploading the release bundles to
> SourceForge we have a choice to make.  I will use rsync since we already
> require people doing a release to have it installed because
> docs.jboss.org uploads require it.
>
> I can either account for the various SourceForge users in the script, or
> we could define a single user in the SourceForge Hibernate project that
> is there for uploading release bundles from the build.  That upload user
> would have just the permissions necessary to upload.  We would need,
> however, to manage getting keys uploaded to that user.  Whereas if we
> used our own SourceForge users we'd simply use our own keys.
>
> Preferences?
>
> Personally I'd rather just use our own users and account for the
> different usernames in the script (read from ~/.gradle/gradle.settings
> maybe).
> ___
> 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] Scripting releases - SourceForge

[Sanne Grinovero]

To clarify, this is the "interesting" part of my ~/.ssh/config :

http://pastebin.com/raw.php?i=tBq91kMH

As you can see, I specify the user it's going to use in the file on a
per-server basis. Very convenient, so I don't have to remember these
details, and also you can specify the correct key.

On 3 May 2013 18:04, Sanne Grinovero  wrote:
> can't you just omit the users?
>
> I would assume that it's going to use rsync over SSH, so it should
> pick the user I've defined for this server in my own ~/.ssh/config
>
>
>
> On 3 May 2013 17:54, Brett Meyer  wrote:
>> +1 for listing the users
>>
>> Brett Meyer
>> Red Hat Software Engineer, Hibernate
>>
>> - Original Message -
>> From: "Steve Ebersole" 
>> To: "hibernate-dev" 
>> Sent: Friday, May 3, 2013 12:41:35 PM
>> Subject: [hibernate-dev] Scripting releases - SourceForge
>>
>> I am working on scripting more of the release steps into the Gradle
>> build scripts.  When it comes to uploading the release bundles to
>> SourceForge we have a choice to make.  I will use rsync since we already
>> require people doing a release to have it installed because
>> docs.jboss.org uploads require it.
>>
>> I can either account for the various SourceForge users in the script, or
>> we could define a single user in the SourceForge Hibernate project that
>> is there for uploading release bundles from the build.  That upload user
>> would have just the permissions necessary to upload.  We would need,
>> however, to manage getting keys uploaded to that user.  Whereas if we
>> used our own SourceForge users we'd simply use our own keys.
>>
>> Preferences?
>>
>> Personally I'd rather just use our own users and account for the
>> different usernames in the script (read from ~/.gradle/gradle.settings
>> maybe).
>> ___
>> 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] hibernate dialect for hana

[Brett Meyer]

Andrew, could you create a pull request against our master branch and add your 
dialect to hibernate-core/src/main/java/org/hibernate/dialect?  We'll take a 
look.  Email me if you need help creating the PR.

Brett Meyer
Red Hat Software Engineer, Hibernate

- Original Message -
From: "Steve Ebersole" 
To: "Hibernate" 
Sent: Friday, May 3, 2013 8:16:29 AM
Subject: Re: [hibernate-dev] hibernate dialect for hana

We've never said we were not accepting new dialects.  What was said is 
that there needs to be some accountability for new dialects. Sounds like 
we have that here...

On 05/03/2013 05:37 AM, Andrew Clemons wrote:
> Hi,
>
> On 2013-05-03 17:17:28 +0800, Strong Liu wrote:
>> I think the main reason is the lack of dev resource, if someone is
>> willing to promise that long time contribution / maintains, I'm fine
>> with that, or it will just become some dead code that we don't have
>> knowledge nor time to maintains.
> I probably should have mentioned this in my first email, but I work for
> SAP (through an acquisition). I am not involved in HANA development, but
> was told it might be interesting to port the app I work on to HANA, so
> that's how I got started working on the dialect on my own time. I asked
> around internally at SAP and was told there was a lot of interest in
> having Hibernate support for HANA and that quite a few external
> inquiries had been made about it. I was encouraged to submit this (which
> I was planning anyway) and that SAP are also willing to maintain it. SAP
> have also already submitted code for HANA to EclipseLink.
>
> Andrew
>
> ___
> 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] Scripting releases - SourceForge

[Steve Ebersole]

We *could*.  But that obviously requires a different level of 
system-level assumptions.  If we all agree to that then fine.

I am going to leave the doc upload as is for now, mainly because that 
one is less in our control.


On Fri 03 May 2013 12:16:07 PM CDT, Sanne Grinovero wrote:
> To clarify, this is the "interesting" part of my ~/.ssh/config :
>
> http://pastebin.com/raw.php?i=tBq91kMH
>
> As you can see, I specify the user it's going to use in the file on a
> per-server basis. Very convenient, so I don't have to remember these
> details, and also you can specify the correct key.
>
> On 3 May 2013 18:04, Sanne Grinovero  wrote:
>> can't you just omit the users?
>>
>> I would assume that it's going to use rsync over SSH, so it should
>> pick the user I've defined for this server in my own ~/.ssh/config
>>
>>
>>
>> On 3 May 2013 17:54, Brett Meyer  wrote:
>>> +1 for listing the users
>>>
>>> Brett Meyer
>>> Red Hat Software Engineer, Hibernate
>>>
>>> - Original Message -
>>> From: "Steve Ebersole" 
>>> To: "hibernate-dev" 
>>> Sent: Friday, May 3, 2013 12:41:35 PM
>>> Subject: [hibernate-dev] Scripting releases - SourceForge
>>>
>>> I am working on scripting more of the release steps into the Gradle
>>> build scripts.  When it comes to uploading the release bundles to
>>> SourceForge we have a choice to make.  I will use rsync since we already
>>> require people doing a release to have it installed because
>>> docs.jboss.org uploads require it.
>>>
>>> I can either account for the various SourceForge users in the script, or
>>> we could define a single user in the SourceForge Hibernate project that
>>> is there for uploading release bundles from the build.  That upload user
>>> would have just the permissions necessary to upload.  We would need,
>>> however, to manage getting keys uploaded to that user.  Whereas if we
>>> used our own SourceForge users we'd simply use our own keys.
>>>
>>> Preferences?
>>>
>>> Personally I'd rather just use our own users and account for the
>>> different usernames in the script (read from ~/.gradle/gradle.settings
>>> maybe).
>>> ___
>>> 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] Scripting releases - SourceForge

[Hardy Ferentschik]

On 3 Jan 2013, at 6:41 PM, Steve Ebersole  wrote:

> Preferences?
> 
> Personally I'd rather just use our own users and account for the 
> different usernames in the script (read from ~/.gradle/gradle.settings 
> maybe).

+1, I think the best way is to use the users own account. Everyone can upload
their own key and the script could take the the user name as a parameter (that's
what the HV script is doing). 

I guess you still want to have a dedicated user for the release via ci server 
approach
(if this is what you are after).

--Hardy




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