Petar, I just resolved HHH-9713 and it was working against my simplified
version of your demo. Just fyi...
On Mon, Apr 6, 2015 at 9:37 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
Petar, not sure what to say. That sounds like a local set up
problem. I
cannot really help with that.
Anyway, I have a "stripped down" version of your test. I ripped out
Spring and added a Gradle build script. The actual test class/method
changed slightly to be just one test method:
public class Hhh8805ApplicationTests {
@Test
public void testIt() {
final StandardServiceRegistry standardRegistry = new
StandardServiceRegistryBuilder()
.loadProperties( "demo/hibernate.properties" )
.build();
try {
final MetadataImplementor metadata = (MetadataImplementor) new
MetadataSources( standardRegistry )
.addAnnotatedClass(AbstractEntityModel.class)
.addAnnotatedClass( AbstractFilteredEntityModel.class )
.addAnnotatedClass( AbstractFilterModel.class )
.addAnnotatedClass( CategoryModel.class )
.addAnnotatedClass( ProductModel.class )
.addAnnotatedClass( DesktopFilter.class )
.addAnnotatedClass( MobileFilter.class )
.buildMetadata();
// export the schema
new SchemaExport( metadata ).execute( false, true, false,
false );
try {
// update the schema
new SchemaUpdate( metadata ).execute( false, true );
}
finally {
// drop the schema
new SchemaExport( metadata ).execute( false, true, false,
false );
}
}
finally {
StandardServiceRegistryBuilder.destroy( standardRegistry );
}
}
}
So basically, it does an explicit SchemaExport followed by an explicit
SchemaUpdate. Just like your tests, it does the initial SchemExport to
make sure that SchemaUpdate is finding the existing tables and altering
them. Anyway, this fails but it fails in a way I completely expect after
looking at it based on what is quite likely a bug but a bug that is in 4.3
(at least) as well. The failure is an attempt to create the index you
specified in the mappings. Hibernate is trying to create the index, but
for your database it is generating the name to use in the CREATE INDEX
command incorrectly (this is the bug):
09:34:08,484 ERROR SchemaExport:458 - HHH000389: Unsuccessful: create
index entity_filters.IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
(entity_pk)
09:34:08,484 ERROR SchemaExport:459 - invalid schema name: ENTITY_FILTERS
I need to investigate this one a bit. I created
https://hibernate.atlassian.net/browse/HHH-9713 to do that investigation.
On Mon, Apr 6, 2015 at 7:35 AM, Petar Tahchiev <paranoiabla(a)gmail.com>
wrote:
> Hi Steve,
>
> thank you soo much for your support. I tried changing it but it had no
> effect. I also added a breakpoint in
> InformationExtractorJdbcDatabaseMetaDataImpl:135 and :151 but the flow
> never really goes through those breakpoints :(
>
> 2015-04-06 15:22 GMT+03:00 Steve Ebersole <steve(a)hibernate.org>:
>
>> I am not fully aware of HSQLDB usage, but I wonder if you end up using 2
>> different databases. I am fairly certain you are using an in-memory
>> database. In the test you are asking Hibernate to create a
>> ConnectionProvider explicitly (your buildHibernateConfiguration method). I
>> know absolutely zero about spring boot to know how in the heck it is
>> creating the the Hibernate EntityManager for you, but I suspect it somehow
>> causes a different HSQLDB instance to be started.
>>
>> The reason I say that is in my simplified version of your test I re-use
>> the same HSQLDB instance for sure and get different results.
>>
>> Still there does seem to be a problem
>> in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl
>> where it is not finding tables. If you have a local fork of Hibernate
>> could you try changing the determineCatalogFilter and determineSchemaFilter
>> in
>>
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>> to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of
>> SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see
>> if that helps for you?
>>
>>
>> On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve(a)hibernate.org>
>> wrote:
>>
>>> Because compiling told me that none of the 5.0 bootstrapping
>>> packages/classes could be found.
>>>
>>> Anyway, I am working on simplifying your demo thing into something
>>> simpler.
>>>
>>> On Mon, Apr 6, 2015 at 6:33 AM, Petar Tahchiev <paranoiabla(a)gmail.com>
>>> wrote:
>>>
>>>> Hmm.. here's the result of mvn dependency:tree -Dverbose
>>>> -Dincludes=org.hibernate
>>>>
>>>> [INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ HHH-8805
>>>> ---
>>>> [WARNING] Using Maven 2 dependency tree to get verbose output, which
>>>> may be inconsistent with actual Maven 3 resolution
>>>> [INFO] org.test:HHH-8805:jar:0.0.1-SNAPSHOT
>>>> [INFO] \-
>>>>
org.springframework.boot:spring-boot-starter-data-jpa:jar:1.2.3.RELEASE:compile
>>>> [INFO] \-
>>>> org.hibernate:hibernate-entitymanager:jar:5.0.0-SNAPSHOT:compile
(version
>>>> managed from 4.3.8.Final)
>>>> [INFO] \- org.hibernate:hibernate-core:jar:5.0.0-SNAPSHOT:compile
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] BUILD SUCCESS
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>> How do you know it's using 4.3.8?
>>>>
>>>> 2015-04-06 14:25 GMT+03:00 Steve Ebersole <steve(a)hibernate.org>:
>>>>
>>>>> So your repo is still trying to use Hibernate 4.3.8. So I cannot
>>>>> reproduce this.
>>>>>
>>>>> On top of that, it uses tons of dependencies not needed for a simple
>>>>> bug reproducer.
>>>>>
>>>>> On Mon, Apr 6, 2015 at 5:58 AM, Steve Ebersole
<steve(a)hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> So on export the tables simply are not created due to lack of
>>>>>> privileges. So that explains why they are not found later.
>>>>>>
>>>>>> On Mon, Apr 6, 2015 at 5:56 AM, Steve Ebersole
<steve(a)hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Well there is a gigantic comment in
org.hibernate.tool.schema.
>>>>>>> extract.internal.*legacy*.DatabaseInformationImpl that says
how
>>>>>>> the tableInformationMap is not used, and why :)
>>>>>>>
>>>>>>> The problem is the HHH000262 log statement. That is saying
that
>>>>>>> the tables are not found querying the database metadata.
>>>>>>>
>>>>>>> On Mon, Apr 6, 2015 at 1:34 AM, Petar Tahchiev <
>>>>>>> paranoiabla(a)gmail.com> wrote:
>>>>>>>
>>>>>>>> Just a quick follow-up here: SchemaMigratorImpl:125 is
calling
>>>>>>>> existingDatabase.getTableInformation where
existingDatabase is of type
>>>>>>>>
org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl
>>>>>>>> (I have no idea why is it using the legacy one), and If I
step into it I
>>>>>>>> can see it's using a tableInformationMap which is
empty - really weird as I
>>>>>>>> can see before that the hbm2ddl was reporting tables were
not found so I
>>>>>>>> was expecting it to create them:
>>>>>>>>
>>>>>>>> 2015-04-06 09:29:40,608
>>>>>>>>
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>>>>>>>> [main] INFO : HHH000262: Table not found: warehouse
>>>>>>>> 2015-04-06 09:29:40,610
>>>>>>>>
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>>>>>>>> [main] INFO : HHH000262: Table not found:
widget_title_lv
>>>>>>>> 2015-04-06 09:29:40,614
>>>>>>>>
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>>>>>>>> [main] INFO : HHH000262: Table not found: wishlist
>>>>>>>> 2015-04-06 09:29:40,618
>>>>>>>>
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>>>>>>>> [main] INFO : HHH000262: Table not found: wishlist_entry
>>>>>>>> 2015-04-06 09:29:40,622
>>>>>>>>
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>>>>>>>> [main] INFO : HHH000262: Table not found: working_day
>>>>>>>>
>>>>>>>>
>>>>>>>> I'll try to create a test that reproduces the
problem
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-04-06 5:20 GMT+03:00 Steve Ebersole
<steve(a)hibernate.org>:
>>>>>>>>
>>>>>>>>> I see you have a test repository reproducing the
error. I will
>>>>>>>>> try to run from there.
>>>>>>>>>
>>>>>>>>> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev <
>>>>>>>>> paranoiabla(a)gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Steve,
>>>>>>>>>>
>>>>>>>>>> the test project that I created still fails with
the latest
>>>>>>>>>> SNAPSHOT release, although the foreign keys are
not created. Can you please
>>>>>>>>>> investigate if that is related to the same issue.
The test repository is
>>>>>>>>>> here:
>>>>>>>>>>
>>>>>>>>>>
https://github.com/paranoiabla/HHH-8805
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard <
>>>>>>>>>> emmanuel(a)hibernate.org>:
>>>>>>>>>>
>>>>>>>>>>> Steve, I think there is something fishy.
>>>>>>>>>>> I have created a branch with a blatant usage
of a JDK 8 API in
>>>>>>>>>>> hibernate-core
>>>>>>>>>>> There is one commit above today’s master:
>>>>>>>>>>>
>>>>>>>>>>> protected EmptyInterceptor() {
>>>>>>>>>>> + final java.time.ZoneId id =
>>>>>>>>>>> java.time.ZoneId.systemDefault();
>>>>>>>>>>> + System.out.println(
id.getId() );
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer
>>>>>>>>>>> <
>>>>>>>>>>>
https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And when I run ./gradlew clean build
>>>>>>>>>>> things do pass, i.e. Animal Sniffer is either
not executed or
>>>>>>>>>>> it does not make the build fail. I did not
see any Animal Sniffer reference
>>>>>>>>>>> in the console while it was running.
>>>>>>>>>>>
>>>>>>>>>>> Does it do the same for you if you clone my
branch?
>>>>>>>>>>>
>>>>>>>>>>> Emmanuel
>>>>>>>>>>>
>>>>>>>>>>> PS: 18 mins here on a Mac + SSD. I guess
Linux beats the crap
>>>>>>>>>>> out of Mac on FindBug executions ;)
>>>>>>>>>>>
>>>>>>>>>>> > On 01 Apr 2015, at 18:09, Steve Ebersole
<steve(a)hibernate.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > I'm not going to argue with you man.
AnimalSniffer *is*
>>>>>>>>>>> run. If you don't
>>>>>>>>>>> > believe that and don't want to
verify it for yourself, oh
>>>>>>>>>>> well, nothing I
>>>>>>>>>>> > can do about that...
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar
Morling <
>>>>>>>>>>> gunnar(a)hibernate.org> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> >> Hum, you are not April-fooling me,
right ;)
>>>>>>>>>>> >>
>>>>>>>>>>> >> There is something Java-8-specific
in already: the usage of
>>>>>>>>>>> >> ConcurrentHashMap#keySet() (in
>>>>>>>>>>> >>
SessionFactoryImpl#iterateEntityNameResolvers()) which -
>>>>>>>>>>> when compiled on
>>>>>>>>>>> >> Java 8 - adds a reference to the
Java-8-only type KeySetView
>>>>>>>>>>> to the class
>>>>>>>>>>> >> file of SessionFactoryImpl.
That's the issue pointed out by
>>>>>>>>>>> Petar
>>>>>>>>>>> >> originally.
>>>>>>>>>>> >>
>>>>>>>>>>> >> But when running "./gradlew
build" on the current master,
>>>>>>>>>>> the build
>>>>>>>>>>> >> passes. I would expect it to fail
though, as AnimalSniffer
>>>>>>>>>>> should detect
>>>>>>>>>>> >> that usage of Java 8's
KeySetView class. So I don't see that
>>>>>>>>>>> AS is executed
>>>>>>>>>>> >> actually? Or are you saying it is
run but it's findings
>>>>>>>>>>> don't cause the
>>>>>>>>>>> >> build to fail?
>>>>>>>>>>> >>
>>>>>>>>>>> >> If I go back to the original
approach of using AS (via git
>>>>>>>>>>> checkout
>>>>>>>>>>> >> 5f6d1~1), it behaves as I'd
expect it: "./gradlew build"
>>>>>>>>>>> fails due to that
>>>>>>>>>>> >> reference from
>>>>>>>>>>>
SessionFactoryImpl#iterateEntityNameResolvers().
>>>>>>>>>>> >>
>>>>>>>>>>> >> Do you actually see the build on
master fail due to that
>>>>>>>>>>> reference being
>>>>>>>>>>> >> discovered by AS?
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> 2015-04-01 15:03 GMT+02:00 Steve
Ebersole <
>>>>>>>>>>> steve(a)hibernate.org>:
>>>>>>>>>>> >>
>>>>>>>>>>> >>> Gunnar, it is applied. Add
something that is java 8
>>>>>>>>>>> specific and see...
>>>>>>>>>>> >>> On Apr 1, 2015 7:59 AM,
"Gunnar Morling" <
>>>>>>>>>>> gunnar(a)hibernate.org> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>> I saw the plug-in, Steve.
But how/when is it executed?
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Running "./gradlew
build" used to execute AnimalSniffer
>>>>>>>>>>> and would have
>>>>>>>>>>> >>>> revealed that accidental
usage of KeySetView. That's not
>>>>>>>>>>> the case anymore.
>>>>>>>>>>> >>>> It would be nice if that new
plug-in could be applied
>>>>>>>>>>> automatically after
>>>>>>>>>>> >>>> compileJava as it used to be
the case with the Ant-based
>>>>>>>>>>> approach.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> 2015-04-01 13:48 GMT+02:00
Steve Ebersole <
>>>>>>>>>>> steve(a)hibernate.org>:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>> Increase your Gradle-fu
we must young apprentice :)
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> AnimalSniffer is still
run. I simply converted it to be
>>>>>>>>>>> a plugin.
>>>>>>>>>>> >>>>> Check out
>>>>>>>>>>>
org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's
>>>>>>>>>>> >>>>> /buildSrc project
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> AnimalSniffer will
apparently not detect this :)
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> On Wed, Apr 1, 2015 at
4:32 AM, Gunnar Morling <
>>>>>>>>>>> gunnar(a)hibernate.org>
>>>>>>>>>>> >>>>> wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>>> Currently,
AnimalSniffer is in place to prevent this
>>>>>>>>>>> very category
>>>>>>>>>>> >>>>>> of error and I'm
wondering why it didn't detect the
>>>>>>>>>>> "usage" of KeySetView.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Looked at this a bit
closer. Turns out, AnimalSniffer
>>>>>>>>>>> *will* detect
>>>>>>>>>>> >>>>>> this issue if it
actually is run. The problem is that AS
>>>>>>>>>>> apparently is
>>>>>>>>>>> >>>>>> not executed by
default anymore, due to the recent
>>>>>>>>>>> change to how AS is used
>>>>>>>>>>> >>>>>> [1].
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Prior to that
change, running AS was done automatically
>>>>>>>>>>> after the compileJava
>>>>>>>>>>> >>>>>> task and would have
reported that usage of KeySetView:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Undefined
reference:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>>
java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>>>>>>>> >>>>>> in
>>>>>>>>>>> >>>>>>
>>>>>>>>>>>
[...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Unfortunately my
Gradle Foo is rather limited, so I'm
>>>>>>>>>>> not sure how to
>>>>>>>>>>> >>>>>> re-establish that
behaviour with the new AS plug-in.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> --Gunnar
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> [1]
>>>>>>>>>>> >>>>>>
>>>>>>>>>>>
https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6...
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> 2015-04-01 9:39
GMT+02:00 Gunnar Morling <
>>>>>>>>>>> gunnar(a)hibernate.org>:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>>> 2015-04-01 2:21
GMT+02:00 Steve Ebersole <
>>>>>>>>>>> steve(a)hibernate.org>:
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>> Just to
clarify... I *think* that as long as we run
>>>>>>>>>>> the build with
>>>>>>>>>>> >>>>>>>> Java 8
>>>>>>>>>>> >>>>>>>> and set the
bootclasspath to 6 or 7 we should be fine.
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> Yes, setting the
boot classpath to 6 (or 7) makes sure
>>>>>>>>>>> you only use
>>>>>>>>>>> >>>>>>> classes present
in that JDK (be it explicitly or
>>>>>>>>>>> implicitly as in the
>>>>>>>>>>> >>>>>>>
ConcurrentHashMap case), because it's that class
>>>>>>>>>>> library which will be used
>>>>>>>>>>> >>>>>>> for compilation
then. It is cumbersome to use though as
>>>>>>>>>>> you need to specify
>>>>>>>>>>> >>>>>>> the location of
a 6 or 7 JDK which makes the build less
>>>>>>>>>>> easily portable
>>>>>>>>>>> >>>>>>> between
machines.
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> Currently,
AnimalSniffer is in place to prevent this
>>>>>>>>>>> very category of
>>>>>>>>>>> >>>>>>> error and
I'm wondering why it didn't detect the
>>>>>>>>>>> "usage" of KeySetView. It
>>>>>>>>>>> >>>>>>> really should
have detected it, assuming it analyses
>>>>>>>>>>> the byte code of
>>>>>>>>>>> >>>>>>> classes. But
this makes me wonder now whether it only
>>>>>>>>>>> analyses the source
>>>>>>>>>>> >>>>>>> code actually.
Then it wouldn't be usable to prevent
>>>>>>>>>>> this sort of issue.
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>> Coding against
the ConcurrentMap interface is the best
>>>>>>>>>>> way to avoid
>>>>>>>>>>> >>>>>>> the issue. But
of course there is no guarantee that it
>>>>>>>>>>> happens again,
>>>>>>>>>>> >>>>>>> unless e.g.
having a build on CI which uses 6 or 7 on
>>>>>>>>>>> its boot classpath.
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>> On Tue, Mar
31, 2015 at 7:13 PM, Steve Ebersole <
>>>>>>>>>>> steve(a)hibernate.org>
>>>>>>>>>>> >>>>>>>> wrote:
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>>> Well the
idea is to run the Gradle process with Java
>>>>>>>>>>> 8 (the build
>>>>>>>>>>> >>>>>>>> itself
>>>>>>>>>>> >>>>>>>>> is a
Java process too don't forget). We pass in the
>>>>>>>>>>> older JDK
>>>>>>>>>>> >>>>>>>>
specifically
>>>>>>>>>>> >>>>>>>>> to be
able to set the bootclasspath for compilation
>>>>>>>>>>> and the
>>>>>>>>>>> >>>>>>>> executable
for
>>>>>>>>>>> >>>>>>>>> running
tests. That's the theory.
>>>>>>>>>>> >>>>>>>>>
>>>>>>>>>>> >>>>>>>>>
Interestingly I developed a simplified project to
>>>>>>>>>>> test these
>>>>>>>>>>> >>>>>>>> theories:
>>>>>>>>>>> >>>>>>>>>
https://github.com/sebersole/gradle-mixed-jdk And
>>>>>>>>>>> of course this
>>>>>>>>>>> >>>>>>>> all
>>>>>>>>>>> >>>>>>>>> works
there. As you'd expect right?
>>>>>>>>>>> >>>>>>>>>
>>>>>>>>>>> >>>>>>>>> I think
the JAXB thing comes into play here as well.
>>>>>>>>>>> Gradle does
>>>>>>>>>>> >>>>>>>> not have
>>>>>>>>>>> >>>>>>>>> any XJC
support built in, so we have to make use of
>>>>>>>>>>> its Ant
>>>>>>>>>>> >>>>>>>> support to
run
>>>>>>>>>>> >>>>>>>>> the XJC
Ant tasks for JAXB model generation. The
>>>>>>>>>>> problem there is
>>>>>>>>>>> >>>>>>>> that,
>>>>>>>>>>> >>>>>>>>> afaik,
there is no way to tell Gradle's AntBuilder to
>>>>>>>>>>> use a JDK
>>>>>>>>>>> >>>>>>>> other than
>>>>>>>>>>> >>>>>>>>> the one
that launched Gradle. I think this is why we
>>>>>>>>>>> see a JAXB
>>>>>>>>>>> >>>>>>>> model
>>>>>>>>>>> >>>>>>>>> defined
for Java 7, rather than Java 6, because we
>>>>>>>>>>> essentially run
>>>>>>>>>>> >>>>>>>> XJC with
>>>>>>>>>>> >>>>>>>>> Java 8.
>>>>>>>>>>> >>>>>>>>>
>>>>>>>>>>> >>>>>>>>> Anyway,
this certainly makes the build more complex
>>>>>>>>>>> and we
>>>>>>>>>>> >>>>>>>> definitely
have
>>>>>>>>>>> >>>>>>>>> to think
through all these scenarios. In fact after
>>>>>>>>>>> Beta1, one of
>>>>>>>>>>> >>>>>>>> my todos
>>>>>>>>>>> >>>>>>>>> is to
build up the build "from scratch" using that
>>>>>>>>>>> >>>>>>>>
gradle-mixed-jdk project
>>>>>>>>>>> >>>>>>>>> as a
basis.
>>>>>>>>>>> >>>>>>>>>
>>>>>>>>>>> >>>>>>>>> In
general the plan though is to run all the tests
>>>>>>>>>>> (other than
>>>>>>>>>>> >>>>>>>>>
hibernate-java8, obviously) with the "baseline JDK,
>>>>>>>>>>> whether that
>>>>>>>>>>> >>>>>>>> be Java 6
>>>>>>>>>>> >>>>>>>>> or 7.
>>>>>>>>>>> >>>>>>>>>
>>>>>>>>>>> >>>>>>>>> On Tue,
Mar 31, 2015 at 6:59 PM, Sanne Grinovero <
>>>>>>>>>>> >>>>>>>>
sanne(a)hibernate.org>
>>>>>>>>>>> >>>>>>>>> wrote:
>>>>>>>>>>> >>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
There are many similar issues discussed on the
>>>>>>>>>>> Lucene developer's
>>>>>>>>>>> >>>>>>>>>>
mailing list, it's an interesting read:
>>>>>>>>>>> >>>>>>>>>> -
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401...
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>> I
see no alternative than to have those test jobs
>>>>>>>>>>> actually
>>>>>>>>>>> >>>>>>>> exercising
>>>>>>>>>>> >>>>>>>>>> ORM
with JDK6, or maybe even compile it all with
>>>>>>>>>>> JDK6 except the
>>>>>>>>>>> >>>>>>>> Java8
>>>>>>>>>>> >>>>>>>>>>
additional module to be compiled with JDK8 ?
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>> On 1
April 2015 at 00:36, Steve Ebersole <
>>>>>>>>>>> steve(a)hibernate.org>
>>>>>>>>>>> >>>>>>>> wrote:
>>>>>>>>>>> >>>>>>>>>>>
Ahh, seems this may be an option to work around it:
>>>>>>>>>>> >>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>>
<quote>
>>>>>>>>>>> >>>>>>>>>>>
Using the general *Map* interface in place of the
>>>>>>>>>>> concrete
>>>>>>>>>>> >>>>>>>>>>>
*ConcurrentHashMap* type here side-steps the
>>>>>>>>>>> coupling to the
>>>>>>>>>>> >>>>>>>> Java 8
>>>>>>>>>>> >>>>>>>>>>
return
>>>>>>>>>>> >>>>>>>>>>>
type and will allow this code to be compiled with
>>>>>>>>>>> Java 8 and
>>>>>>>>>>> >>>>>>>> run on
>>>>>>>>>>> >>>>>>>>>> Java
7.
>>>>>>>>>>> >>>>>>>>>>>
</quote>
>>>>>>>>>>> >>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>>
I had missed that part.
>>>>>>>>>>> >>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>>
On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <
>>>>>>>>>>> >>>>>>>>
steve(a)hibernate.org>
>>>>>>>>>>> >>>>>>>>>>
wrote:
>>>>>>>>>>> >>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> When I say "internal" here, I
mean internal to
>>>>>>>>>>> java classes.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve
Ebersole <
>>>>>>>>>>> >>>>>>>>
steve(a)hibernate.org>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Nope. It just effects any code
compiled with
>>>>>>>>>>> Java 8 even
>>>>>>>>>>> >>>>>>>> though the
>>>>>>>>>>>
>>>>>>>>>>>>> change is internal. The problem is
the generated
>>>>>>>>>>> bytecode
>>>>>>>>>>> >>>>>>>>>>
incorporates
>>>>>>>>>>>
>>>>>>>>>>>>> this change. Like I said, this
should be
>>>>>>>>>>> compiled with 1.6
>>>>>>>>>>> >>>>>>>>>>
compatibility,
>>>>>>>>>>>
>>>>>>>>>>>>> but that is apparently not working
atm. I am
>>>>>>>>>>> having a
>>>>>>>>>>> >>>>>>>> struggle
>>>>>>>>>>> >>>>>>>>>>
getting a
>>>>>>>>>>>
>>>>>>>>>>>>> mixed JDK build working "just
right".
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM,
Petar Tahchiev <
>>>>>>>>>>> >>>>>>>>>>
paranoiabla(a)gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> According to this:
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
https://gist.github.com/AlainODea/1375759b8720a3f9f094
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> Notably the Java 1.7
>>>>>>>>>>> *ConcurrentHashMap#keySet()* returns a
>>>>>>>>>>> >>>>>>>>
Set<K>
>>>>>>>>>>> >>>>>>>>>>
while
>>>>>>>>>>>
>>>>>>>>>>>>>> the
1.8*ConcurrentHashMap#keySet()* returns a
>>>>>>>>>>>
>>>>>>>>>>>>>>
ConcurrentHashMap.KeySetView<K,V>`.
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> I think you're using some
Java8 API.
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar
Tahchiev <
>>>>>>>>>>> >>>>>>>>
paranoiabla(a)gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>
petar@petar-ThinkPad-X1-Carbon:~$ java -version
>>>>>>>>>>>
>>>>>>>>>>>>>>> java version
"1.7.0_71"
>>>>>>>>>>>
>>>>>>>>>>>>>>> Java(TM) SE Runtime
Environment (build
>>>>>>>>>>> 1.7.0_71-b14)
>>>>>>>>>>>
>>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit
Server VM (build
>>>>>>>>>>> 24.71-b01, mixed
>>>>>>>>>>> >>>>>>>> mode)
>>>>>>>>>>>
>>>>>>>>>>>>>>>
petar@petar-ThinkPad-X1-Carbon:~$ uname -a
>>>>>>>>>>>
>>>>>>>>>>>>>>> Linux
petar-ThinkPad-X1-Carbon
>>>>>>>>>>> 3.16.0-33-generic #44-Ubuntu
>>>>>>>>>>> >>>>>>>> SMP Thu
>>>>>>>>>>> >>>>>>>>>> Mar
>>>>>>>>>>>
>>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64
x86_64 x86_64
>>>>>>>>>>> GNU/Linux
>>>>>>>>>>>
>>>>>>>>>>>>>>>
petar@petar-ThinkPad-X1-Carbon:~$
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00
Steve Ebersole <
>>>>>>>>>>> >>>>>>>>
steve(a)hibernate.org>:
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>> What JRE are you trying
to use? This error:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
java.lang.NoSuchMethodError:
>>>>>>>>>>> java.util.concurrent.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
ConcurrentHashMap.keySet()Ljava/util/concurrent/
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
ConcurrentHashMap$KeySetView;
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>> is indicative of an issue
in cross-jre support
>>>>>>>>>>> due to a
>>>>>>>>>>> >>>>>>>> change
>>>>>>>>>>>
>>>>>>>>>>>>>>>> internal to java
classes.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at
6:03 PM, Petar
>>>>>>>>>>> Tahchiev <
>>>>>>>>>>> >>>>>>>>>>
paranoiabla(a)gmail.com
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks Steve,
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I managed to migrate
my configuration to the
>>>>>>>>>>> new
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> MetamodelImplementor.
Now when I run the
>>>>>>>>>>> scema export I
>>>>>>>>>>> >>>>>>>> get a lot
>>>>>>>>>>> >>>>>>>>>> of
these
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> warning:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> INFO : HHH000400:
Using dialect:
>>>>>>>>>>> >>>>>>>>>>
org.hibernate.dialect.MySQL5Dialect
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : JDBC Driver
reports it stores quoted
>>>>>>>>>>> identifiers
>>>>>>>>>>> >>>>>>>> in both
>>>>>>>>>>> >>>>>>>>>>
mixed
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and upper case
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : HHH000072:
Duplicate joins for class:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
com.xxx.platform.core.model.cms.AbstractPageModel
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : HHH000072:
Duplicate joins for class:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
com.xxx.platform.module.invoice.core.model.InvoicePageModel
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : HHH000072:
Duplicate joins for class:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : HHH000072:
Duplicate joins for class:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : HHH000072:
Duplicate joins for class:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : HHH000072:
Duplicate joins for class:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WARN : HHH000072:
Duplicate joins for class:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
com.xxx.platform.module.promotion.core.model.PromotionModel
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and when I run some
test I get the following
>>>>>>>>>>> exception:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
java.lang.NoSuchMethodError:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>>
org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>>
org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2015-04-01 1:23
GMT+03:00 Steve Ebersole <
>>>>>>>>>>> >>>>>>>>
steve(a)hibernate.org>:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am told that
the bug does not affect the
>>>>>>>>>>> >>>>>>>>
JBoss->Central sync
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> process. So at
some point the artifacts
>>>>>>>>>>> should all be
>>>>>>>>>>> >>>>>>>> available
>>>>>>>>>>> >>>>>>>>>> in
Central
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Mar 31,
2015 at 5:19 PM, Steve
>>>>>>>>>>> Ebersole <
>>>>>>>>>>> >>>>>>>>>>
steve(a)hibernate.org
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
hibernate-core seems to be the only
>>>>>>>>>>> artifact that is
>>>>>>>>>>> >>>>>>>> available
>>>>>>>>>>> >>>>>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JBoss Nexus.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Mar
31, 2015 at 5:18 PM, Steve
>>>>>>>>>>> Ebersole <
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
steve(a)hibernate.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So
apparently the artifacts / repo issue
>>>>>>>>>>> is a Nexus
>>>>>>>>>>> >>>>>>>> bug that is
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> effecting
the JBoss repo (and therefore
>>>>>>>>>>> us)...
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
http://issues.sonatype.org/browse/NEXUS-7654
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As I
pointed out in the announcement, I am
>>>>>>>>>>> managing the
>>>>>>>>>>> >>>>>>>>>>
"migration
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
guide" in source repo while I develop the
>>>>>>>>>>> Betas. See
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat...
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As far
are the new bootstrapping apis, see
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot...
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot...
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue,
Mar 31, 2015 at 5:07 PM, Petar
>>>>>>>>>>> Tahchiev <
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
paranoiabla(a)gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi
guys,
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I
just tried the latest beta and I cannot
>>>>>>>>>>> compile my
>>>>>>>>>>> >>>>>>>> project.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> With
the
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
latest hibernate 4.3.X I was able to do
>>>>>>>>>>> this:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
-------
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
final
>>>>>>>>>>> org.hibernate.cfg.Configuration
>>>>>>>>>>> >>>>>>>>
configuration =
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
getHibernateConfiguration();
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
configuration.buildMappings();
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
final SchemaUpdate schemaUpdate =
>>>>>>>>>>> new
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
SchemaUpdate(configuration);
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
-------
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
however it seems that the SchemaUpdate
>>>>>>>>>>> constructor
>>>>>>>>>>> >>>>>>>> has been
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
removed and now
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> a new
one is added:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
--------
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
public
>>>>>>>>>>> SchemaUpdate(MetadataImplementor metadata)
>>>>>>>>>>> >>>>>>>> {
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
this(
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
metadata.getMetadataBuildingOptions().getServiceRegistry(),
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
metadata );
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
---------
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Also
the configuration.buildMappings()
>>>>>>>>>>> method has been
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
deprecated. Where do
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I get
the MetadataImplementor from? Also
>>>>>>>>>>> is there any
>>>>>>>>>>> >>>>>>>>>>
changelog I
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> can
refer
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> to?
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
Thanks.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
Regards, Petar!
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
Karlovo, Bulgaria.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
Public PGP Key at:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Key
Fingerprint: A369 A7EE 61BC 93A3
>>>>>>>>>>> CDFF 55A5 1965
>>>>>>>>>>> >>>>>>>> 8550 C311
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 0611
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
hibernate-dev mailing list
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
hibernate-dev(a)lists.jboss.org
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards, Petar!
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Key Fingerprint: A369
A7EE 61BC 93A3 CDFF
>>>>>>>>>>> 55A5 1965 8550
>>>>>>>>>>> >>>>>>>> C311
>>>>>>>>>>> >>>>>>>>>>
0611
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, Petar!
>>>>>>>>>>>
>>>>>>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>>>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>>>
>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE
61BC 93A3 CDFF 55A5
>>>>>>>>>>> 1965 8550
>>>>>>>>>>> >>>>>>>> C311 0611
>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>>>> Regards, Petar!
>>>>>>>>>>>
>>>>>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>>>
>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC
93A3 CDFF 55A5
>>>>>>>>>>> 1965 8550
>>>>>>>>>>> >>>>>>>> C311 0611
>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>>>
_______________________________________________
>>>>>>>>>>> >>>>>>>>>>>
hibernate-dev mailing list
>>>>>>>>>>> >>>>>>>>>>>
hibernate-dev(a)lists.jboss.org
>>>>>>>>>>> >>>>>>>>>>>
>>>>>>>>>>>
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
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>
>>>>>>>>>>> >
_______________________________________________
>>>>>>>>>>> > hibernate-dev mailing list
>>>>>>>>>>> > hibernate-dev(a)lists.jboss.org
>>>>>>>>>>> >
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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards, Petar!
>>>>>>>>>> Karlovo, Bulgaria.
>>>>>>>>>> ---
>>>>>>>>>> Public PGP Key at:
>>>>>>>>>>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5
1965 8550 C311
>>>>>>>>>> 0611
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards, Petar!
>>>>>>>> Karlovo, Bulgaria.
>>>>>>>> ---
>>>>>>>> Public PGP Key at:
>>>>>>>>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550
C311 0611
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>>>
>>>
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
>
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>