Asciidoctor and Gradle
by Steve Ebersole
I just pushed the initial work getting Asciidoctor building through Gradle.
I have done zero styling or layout etc. This is just the initial
ability to generate Asciidoctor docs via Gradle.
At the moment there is just one doc (the ServiceRegistry guide that is
still WiP) that is rendered to just HTML. If you want to give it a try,
cd into the documentation directory and execute `gradle
generateRegistryGuideHtml`. The output for now goes into
target/asciidoc/topical/html
10 years, 6 months
[HV] HV and RESTEasy integration
by Emmanuel Bernard
I was once again working on the demo showing Bean Validation and its
integration inside Java EE 7.
When you put constraints on the method parameter of a JAX-RS call, you
get a nice rendering of the error on the client side (basically the
HTTP entity returns a JSON representation of the errors).
But if from this method you call JPA or Bean Validation directly and a
ConstraintViolationException is raised, then this exception is processed
as a generic exception crossing RESTEasy.
Would it make sense you think to treat ConstraintViolationException
raised by JAX-RS methods like we would do parameter or return value
exceptions?
The error handling would be the same / unified. I might miss some parts
of the whole picture so this email is really for discussions.
WDYT?
Emmanuel
10 years, 6 months
Search compatibility with WildFly
by Sanne Grinovero
I'm working to replace the integration tests using the now outdated
EAP Alphas with WildFly 8.0.0.Beta1, which also has the benefit to
remove the need for the enterprise repository.
This requires:
- updating to ORM 4.3
- updating to Infinispan 6.0.x
- building the project with Java7
Java7 is needed as the Arquillian connectors for WildFly are compiled
without Java6 compatibility, my guess is the whole WildFly needs it
too.
As a consequence, that would mean that Hibernate Search from 4.5.x
would need to be compiled with Java7, ideally attempting to maintain
Java6 compatibility as possible (Animal sniffer & co).
Thoughts?
Cheers,
Sanne
10 years, 6 months
[OGM] Requiring Java 7?
by Gunnar Morling
Hi,
In the context of the notorious JavaDoc CSS issue ([OGM-341] - an updated
stylesheet is required when building our projects with Java 7) Sanne,
Davide and I were wondering whether we should take the opportunity and
actually require Java 7 as the minimum version for Hibernate OGM, not only
at build but also at run time.
This would give us some interesting opportunities for the implementation,
language-wise (e.g. diamond operator, multi-catch) as well as library-wise
(e.g. the fork/join framework). On the downside we might exclude some users
who are still running on Java 6.
Given that OGM is a rather new project, I'd assume though that at this
point most users are in a more experimental stage of using it. I'd thus
also expect that they use a more current version than 6 which has reached
the end of its (public) support lifecycle. So this change might not effect
many in reality.
Any thoughts?
--Gunnar
[OGM-341] https://hibernate.atlassian.net/browse/OGM-341
10 years, 6 months
Re: [hibernate-dev] [OGM] Requiring Java 7?
by Gunnar Morling
2013/10/9 Steve Ebersole <steven.ebersole(a)gmail.com>
> What is gained needs to be balanced by what you are giving up.
>
> OGM itself is new, but at the end of the day its a JPA provider which is
> not new. Basing on Java 7 will limit adaption from folks wanting to drop
> OGM in to their app as replacement for their JPA provider to give it a spin
> in certain environments.
Yes, that's true. Hard to say how many such cases there would be without
some real figures. Maybe it's just not worth taking the risk.
> On Wed 09 Oct 2013 07:54:14 AM CDT, Sanne Grinovero wrote:
>
>> +1 for requiring Java7
>>
>> On 9 October 2013 12:55, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>>
>>> Hi,
>>>
>>> In the context of the notorious JavaDoc CSS issue ([OGM-341] - an updated
>>> stylesheet is required when building our projects with Java 7) Sanne,
>>> Davide and I were wondering whether we should take the opportunity and
>>> actually require Java 7 as the minimum version for Hibernate OGM, not
>>> only
>>> at build but also at run time.
>>>
>>> This would give us some interesting opportunities for the implementation,
>>> language-wise (e.g. diamond operator, multi-catch) as well as
>>> library-wise
>>> (e.g. the fork/join framework). On the downside we might exclude some
>>> users
>>> who are still running on Java 6.
>>>
>>> Given that OGM is a rather new project, I'd assume though that at this
>>> point most users are in a more experimental stage of using it. I'd thus
>>> also expect that they use a more current version than 6 which has reached
>>> the end of its (public) support lifecycle. So this change might not
>>> effect
>>> many in reality.
>>>
>>> Any thoughts?
>>>
>>> --Gunnar
>>>
>>> [OGM-341] https://hibernate.atlassian.**net/browse/OGM-341<https://hibernate.atlassian.net/browse/OGM-341>
>>> ______________________________**_________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>
>> ______________________________**_________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>
>
10 years, 6 months
starting release
by Steve Ebersole
Per subject. Please dont push anything to upstream master until the
release is done. Thanks.
10 years, 6 months
