Of course I meant "continuing with Javassist..." :P
On Tue, Jan 2, 2018 at 3:50 PM Steve Ebersole wrote:
> ASM is a completely different model though, unless the part you think
> could be used here is different.
>
> I did say though that we could leverage Jandex for this
ASM is a completely different model though, unless the part you think could
be used here is different.
I did say though that we could leverage Jandex for this part. The problem
(iiuc) there though is that Jandex would require all classes to be indexed
- we could not just ask it to index a
2017-12-29 21:34 GMT+01:00 Steve Ebersole :
> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole
> wrote:
>
>>
>> * When using ByteBuddy as the byte code provider, I still needed to have
>>> Javassist around, as it's used in ClassFileArchiveEntryHandler. I
On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole wrote:
>
> * When using ByteBuddy as the byte code provider, I still needed to have
>> Javassist around, as it's used in ClassFileArchiveEntryHandler. I
>> understand that eventually this should be using Jandex, but I'm
Sorry folks, responding to this thread out of order...
Steve, at first glance, this looks fine!
On 12/28/17 10:06 AM, Steve Ebersole wrote:
> After tweaking this, here is what I have...
>
> Manifest-Version: 1.0
> Created-By: 1.8.0_121 (Oracle Corporation)
> Main-Class: org.hibernate.Version
>
Actually I found the problem. Its actually not related to the manifest
change. The problem was a mismatch in the bundle group/module names for
JPA since we switched to the (now published) standard JPA API jar. Fixing
that fixed the failures. Sorry for the noise.
On Fri, Dec 29, 2017 at 10:35
Hey Steve, just to clarify, did this start failing directly after the
manifest change? Or are you saying it could be from other
dependency-related updates?
On 12/29/17 10:58 AM, Steve Ebersole wrote:
> Maybe this is similar to the problems we've had with the WildFly
> hibernate-orm-moudles
Maybe this is similar to the problems we've had with the WildFly
hibernate-orm-moudles stuff - versions of karaf/aries/etc not yet
supporting EE8 techs (JPA 2.2, CDI 2.0, etc)?
On Thu, Dec 28, 2017 at 11:56 AM Steve Ebersole wrote:
> Brett, after making these changes the
2017-12-28 19:10 GMT+01:00 Steve Ebersole :
>
>- Main-Class is fine afaik. It was requested previously by users and
>added accordingly. I'm not going to change it unless you can show me
>concrete reason to.
>
> Seeing now that Version indeed defines a main()
- Main-Class is fine afaik. It was requested previously by users and
added accordingly. I'm not going to change it unless you can show me
concrete reason to.
- Specification-* - I had considered that. TBH its not important
afaik. And Hibernate defines a specification as well
Automatic-Module-Name looks good.
While unrelated, those look odd:
* Main-Class: I don't think ORM - as a library - should declare this
* Specification-Title, Specification-Version: should these rather relate to
JPA title and version (as opposed to the Implementation-* ones)?
2017-12-28 16:06
Brett, after making these changes the osgi tests now fail[1] with a RMI
connection error which I cannot decipher. Could you see if you can
understand the problem?
Thanks
[1]
http://ci.hibernate.org/job/hibernate-orm-master-h2-main/942/testReport/junit/org.hibernate.osgi.test/
On Thu, Dec 28,
Gunnar, back to the original discussion...
I asked you about this specifically in Paris and you responded "no" - but
reading info I have found online seems to indicate that it is indeed
perfectly valid to build with Java 9 and include a module-info.class into
the jar and be able to load that into
After tweaking this, here is what I have...
Manifest-Version: 1.0
Created-By: 1.8.0_121 (Oracle Corporation)
Main-Class: org.hibernate.Version
Specification-Title: hibernate-core
Specification-Version: 5.3
Specification-Vendor: Hibernate.org
Implementation-Title: hibernate-core
I had intended this for 5.3 which hasn't even gone Beta yet (we wont have
an Alpha).
On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer wrote:
> +1 from me on making them consistent. In practice, Bundle-SymbolicName
> isn't used for much, other than a guaranteed unique
Another thing I was noticing was an annoying minor difference between the
OSGi bundle name and the Java 9 module name:
Automatic-Module-Name: org.hibernate.orm.core
Bundle-SymbolicName: org.hibernate.core
Does it make sense to adjust the OSGi bundle name to follow the module
naming?
On Sat, Dec
I already did a PR for the `Automatic-Module-Name` yesterday and added you
as a reviewer. when you get a chance...
On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling wrote:
> 2017-12-22 23:07 GMT+01:00 Steve Ebersole :
>
>> I created a Jira to track
2017-12-22 23:07 GMT+01:00 Steve Ebersole :
> I created a Jira to track this: https://hibernate.
> atlassian.net/browse/HHH-12188
>
> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole
> wrote:
>
>> Thanks for investigating this Gunnar.
>>
>> Some thoughts
I created a Jira to track this:
https://hibernate.atlassian.net/browse/HHH-12188
On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole wrote:
> Thanks for investigating this Gunnar.
>
> Some thoughts inline...
>
> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling
Thanks for investigating this Gunnar.
Some thoughts inline...
On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling wrote:
> * JDK 9 comes with an incomplete JTA module (java.transaction), so a
> complete one must be provided via --upgrade-module-path (I'm using the
>
20 matches
Mail list logo