> We ended up moving the core schemas to http://www.hibernate.org/dtd,
> http://www.hibernate.org/xsd
you mean creating new ones there, right ? the sourceforge ones are still there
for backwards compatibility, correct
> If you want to keep them under SourceForge, you have to access the project
> What I am discussing here has no effect on this concern.
>
> In the new terminology, what we are discussing is the process for handling
> "metadata sources" (o.h.metamodel.source). What you describe is really a
> parallel source (o.h.metamodel.source.jdbc???). So it is going to be
> complet
We ended up moving the core schemas to http://www.hibernate.org/dtd,
http://www.hibernate.org/xsd
If you want to keep them under SourceForge, you have to access the
project web site. Totally forget how to do that. But its part of the
site support docs.
On 06/14/2011 01:35 AM, Max Rydahl And
That is a great point about components. Thinking components should
really be handled just like we propose for entities. Especially if we
allow inheritance hierarchies with components (which I would love to do
generally and to account for here specifically).
itself poses a problem. It can co
What I am discussing here has no effect on this concern.
In the new terminology, what we are discussing is the process for
handling "metadata sources" (o.h.metamodel.source). What you describe
is really a parallel source (o.h.metamodel.source.jdbc???). So it is
going to be completely up to th
Any idea how much this would affect tools ability to reflect on the metamodel
without requiring the actual
model classes and types to be available ?
At what time will the classes/types be *required* to be available?
i.e. for H3 as long as we filled out all the type info in the xml hibernate did
Hey,
What's the process for updating the file behind
http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd ?
Been years since I last needed to update it and the systems changed since ;)
Anyone got an idea ?
/max
http://about.me/maxandersen
_
