Hi, devs.
I committed first version of XWQL (or XQL) language to our sandbox
(xwiki-query/xwql) for review.
I worked ~2 last weeks for it.
install info is in xwiki-query/README.
Currently it works according my proposal[1], but it is quite easy to modify.
It is not perfect, but it works and will be improved.
You can test it via QueryManager. (for example in velocity:
$xwiki.xWiki.store.queryManager.createQuery("select doc.fullName from
Document as doc, doc.XWiki.ArticleClass as a where a.title like
'%Launch'", "xwql").execute() )
plan for xwql (for fix in next week):
* use xwiki-bridge instead of xwiki-core in xwql.
(some methods in bridge are needed)
* create query velocity service
accessible like $services.query.xwql('...')
(according Vincent's velocity services proposal [2])
* move xwiki-query maven module from sandbox to platform/components/
* move QueryManager component from xwiki-core to xwiki-query
I would like to integrate xwql for hql in 1.6M2 (8 Sept) and improve it
in RC if needed.
JCRStore:
old JCRStore with some modifications is partly working (save/load
document is ok) on recent Jackrabbit, but missing some new stores and
need redesign.
plan:
* create xwiki-store/jcr maven module in platform/components (at
sandbox first)
it have to depend on xwiki-core (but not reverse). Is it a problem
for platform/components?
* split JCRStore into components. (RepositoryFacory, SessionFactory,
SessionPool, Stores, DAOs)
* jcrstore will contains DefaultStores which will contain only
business logic on data model, and use DAOs components for store/load data.
DefaultStores will be reused in future HibernateStore to remove
duplicating of code.
* get rid of patched graffito-jcr-mapping (~ORM for JCR). it is old and
unsupported.
candidates:
jcrom [3],
jackrabbit-ocm (former graffito),
simple hand-made annotation based mapping.
I'll look at jcrom first.
I already have some code and plan to work on it in sandbox, after finish
with xwql-hql.
I plan to create working version of JCRStore at the end of September.
xwql on JCRStore will work only on JCRv2 implementation.
[1] http://xwiki.markmail.org/message/uar73uglivj6fbbn
[2] http://markmail.org/message/jwcjomrck3yo2kjq
[3] http://code.google.com/p/jcrom/
--
Artem Melentyev
Hello everybody,
Discussing we Vincent we agreed that currently XWiki Core components on
JIRA are very scattered and do not make very much sense. We propose to
reorganize the project and have one component per module in platform
core and web, which would be :
* action
* cache
* component
* containers
* context
* xwiki-core
* observation
* patchservice
* plexus
* rendering
* url
* velocity
* xml
* xmlrpc
* web-standard
* web-exo
* web-gwt
* web-wysiwyg
+1 for that.
A question now I have is : since it will be quite a big refactoring, do
we move all issues ? or only open issues ?
Thanks,
Jerome.
Hi Devs,
>From today onwards I'll be working on integrating the xwiki-webdav plugin in
the xwiki ui. And in the process i will resurrect the foxwiki firefox
extension as well.
By integrating xwiki-webdav on the xwiki ui, we mean to provide the users
the ability to open / edit / save various types of attachments with their
favourite editor.
For an example, we'll provide a "open with word" link next to a ".doc"
attachment in the attachments section of the UI. When the user clicks on
this link it will fire up word and let the user edit the content and save it
back as he/she wishes.
Currently this functionality is available natively on IE (phew) and there
isn't much to be done on that. But for this to work on firefox we're going
to have to resurrect the foxwiki extension. So the tentative workplan would
be as bellow:
* Make foxwiki work with firefox 3 - (Estimated : 2 days - Already started
working on this)
* Add the functionality to load the corresponding application (to edit the
attachment) via foxwiki - (Estimated : 3 days ?)
* Provide a common javascript API (javascript.vm ?) that can be used to
launch an application from pages - (Estimated : ?)
* Modify attachments.vm to automatically include the links for editing
attachments.
These are the goals I currently have in my mind and i'm still bit shaky
about some topics myself. If any of you have sugesstions / comments /
thoughts please let me know.
Thanks.
- Asiri
Hi XWikiers,
Those last months we've discussed a lot about precise elements of the
new XWiki 2.0 syntax :
- usage of 2 chars for **bold** and [[links]]
- {{macro/}} syntax
- Linebreaks on carriage returns
- Linking to attachments/Insert link to image
- |table| syntax
- styling syntax
- emoticons
So far the idea was to keep the xwiki/2.0 syntax as close as possible
from xwiki/1.0.
IMHO we've reached a point where xwiki/2.0 is so different from
xwiki/1.0 that it could be the occasion to go further and replace our
few radeox leftovers by their widespread equivalent.
That's the first thing I'd like to discuss, do we all agree to make
other substantial modifications to xwiki/2.0 ?
Here's my +1.
Being completely in line with Creole [1] or WikiSyntaxCommon [2] is
not an option since we've already made some incompatible choices (like
linebreaks on carriage returns) and it would imply a big amount of
work now that the new rendering is approaching a stable state. That's
the reason why this proposal is about 2 basic (and important) wiki
syntax elements, those 2 modifications would make xwiki syntax
familiar to wikiPowerUsers.
1) Usage of // instead of ~~ for italic
Creole rationale : A slash (/) looks like slanted italics, so it is
intuitive and thus easier to remember.
See http://www.wikicreole.org/wiki/BoldAndItalicsReasoning
Note : on all the keyboard mappings I know slashes are more easily
reachable than ~.
Here's my +1.
2) Usage of equal signs instead of 1./1.1/etc for Headings
Creole rationale : Using equal signs (=) is the most popular wiki
header markup. Since there are more equal signs for smaller headers,
subheaders will become more indented making it easier to get a visual
overview from the markup alone.
See http://www.wikicreole.org/wiki/HeadingsReasoning
Note : We've experienced problems in the past with the 1/1.1 syntax
(bad document section computation, problems with table cells starting
with 1, etc) but those problems are addressed in the new rendering.
Anyway I think users are more likely to unintentionaly start a line
with a 1 than a = (like in "1 is more than 2" in the middle of a
paragraph).
What I personnaly like with this syntax is that it makes sections very
visible when editing a page in wiki mode.
About unclosed titles :
=== Also level 3
=== Also level 3 =
=== Also level 3 ==
a) Don't interpret them
+0.
b) Interpret them but make closed title our default (generated by wysiwyg)
+1, as I wrote above I think that having clear sections in a page
helps to navigate in edit mode.
c) Interpret them and make it our default
-0.
[1] : http://www.wikicreole.org/wiki/Creole1.0
[2] : http://code.google.com/p/wikimodel/wiki/WikiSyntaxCommon
Thanks,
JV.
Hello,
I would like to write a document containing some javascript functions... For
example:
in "MySpace.MyJSDoc":
{pre}
print('This is my javascript');
{/pre}
Then, instead of using Velocity #includeMacros, I would like to use it with
the classical external javascript link "<script src=""/> and take advantage
of usual JS caching features of web browsers in order not to load this JS
everytime... Thus, keeping a way of editing my javascript online...
In the middle of a page, I would like to put something like:
... Some wiki content to render...
<script type="text/javascript"
src="$xwiki.getURL('MySpace.MyJSDoc')?xpage=plain"/>
... Some wiki content to render...
(I use "xpage=plain" to retrieve only the JS content...)
But it appears that web browsers don't wait until the whole page is received
and make a nested call to the XWiki engine immediately after reading the
<script src=""> and the receiving of the remaining part of the page is
simply stopped at this stage (XWiki seems to trash the remaining part of the
page).
So my questions:
is my idea totally stupid?
if not, do you have an idea to make it possible or at least, at first sight,
do you see what happens exactly to give me some clues before going deeper
with debuggers?
best regards
Pascal
Hello,
I've tried building platform and XE from trunk under Eclipse 3.4(Ganymede)
with last M2Eclipse (Maven embedded 2.1.0 with m2eclipse 0.9.5) which brings
lots of new features but also some new problems...
I've checked out full platform trunk and tried to use the "nested modules
management" of m2eclipse in order to have something clean... so check out
using Subclipse and then activated Maven dependency management, Workspace
resolution and Nested Modules...
Due to some new features of both maven and m2eclipse and due to new nested
modules, there are some problems building everything from scratch...
Here are my short remarks (I'm only maven and eclipse user so this is what I
can seem with an external point of view):
- the famous out-of-memory still exists when building aspects so still needs
to creates a specific Run target with the now famous "-XmxLOTS_OF_MEMORY"
- now in Maven, compiled classes are separated: main classes goes in
target/classes and test classes goes in target/test-classes (which is not so
bad)
- In XWiki platform, we have now up to 3 levels of nested modules and
apparently the maven inheritance is not well managed by m2eclipse. By
default, maven tests are not run using parent compiled classes and I had to
explicitely trigger "resolve Workspace artifact" in my specific Maven Run
target not to have "no class def found exception for ...XWikiContext" when
running maven:test.
- the "resolve Workspace artifact" is sometimes not good: for web/standard,
it tries to copy the file xwiki-core/target/classes but as it is a
directory, it fails to copy it :)...
- Moreover, m2eclipse seems to run maven tests using target/classes from
parent or locally dependent maven modules but not target/test-classes. And
in XWiki, xwiki-rendering/xwiki-rendering-tests, for example, uses classes
from xwiki-core tests classes. I haven't found a clever solution for this.
- I can also see some code errors in Eclipse in web/gwt because Eclipse trie
to resolve some deprecated functions from xwiki-core trunk... not a problem
when compiling with maven
One other question about something I remark:
when compiling, I see this tens of times:
url = http://maven.xwiki.org/externals
Downloading:
http://maven.xwiki.org/externals/groovy/groovy-all-1.0-jsr/06/groovy-all-1.…
url = http://maven.xwiki.org/releases
Downloading:
http://maven.xwiki.org/releases/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0…
url = http://repo1.maven.org/maven2
Downloading:
http://repo1.maven.org/maven2/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0-j…
Apparently, it doesn't see it has already downloaded it... Do you know why?
So finally, compiling module per module triggering some options is OK but
compiling from scratch implies skipping tests...
Pascal
Summary :
1) Usage of // instead of ~~ for italic
Three +1, two 0, no -1.
2) Usage of equal signs instead of 1./1.1/etc for Headings
Three +1, two 0, no -1 for this change.
Three +1, two 0, no -1 for choice a) : consider a line as a heading
only if there is the same number of equal signs at the beginning and
at the end of the line.
Thanks,
JV.
On Fri, Sep 12, 2008 at 5:29 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
> Hi XWikiers,
>
> Those last months we've discussed a lot about precise elements of the
> new XWiki 2.0 syntax :
> - usage of 2 chars for **bold** and [[links]]
> - {{macro/}} syntax
> - Linebreaks on carriage returns
> - Linking to attachments/Insert link to image
> - |table| syntax
> - styling syntax
> - emoticons
>
> So far the idea was to keep the xwiki/2.0 syntax as close as possible
> from xwiki/1.0.
> IMHO we've reached a point where xwiki/2.0 is so different from
> xwiki/1.0 that it could be the occasion to go further and replace our
> few radeox leftovers by their widespread equivalent.
> That's the first thing I'd like to discuss, do we all agree to make
> other substantial modifications to xwiki/2.0 ?
>
> Here's my +1.
>
> Being completely in line with Creole [1] or WikiSyntaxCommon [2] is
> not an option since we've already made some incompatible choices (like
> linebreaks on carriage returns) and it would imply a big amount of
> work now that the new rendering is approaching a stable state. That's
> the reason why this proposal is about 2 basic (and important) wiki
> syntax elements, those 2 modifications would make xwiki syntax
> familiar to wikiPowerUsers.
>
> 1) Usage of // instead of ~~ for italic
>
> Creole rationale : A slash (/) looks like slanted italics, so it is
> intuitive and thus easier to remember.
> See http://www.wikicreole.org/wiki/BoldAndItalicsReasoning
> Note : on all the keyboard mappings I know slashes are more easily
> reachable than ~.
>
> Here's my +1.
>
> 2) Usage of equal signs instead of 1./1.1/etc for Headings
>
> Creole rationale : Using equal signs (=) is the most popular wiki
> header markup. Since there are more equal signs for smaller headers,
> subheaders will become more indented making it easier to get a visual
> overview from the markup alone.
> See http://www.wikicreole.org/wiki/HeadingsReasoning
>
> Note : We've experienced problems in the past with the 1/1.1 syntax
> (bad document section computation, problems with table cells starting
> with 1, etc) but those problems are addressed in the new rendering.
> Anyway I think users are more likely to unintentionaly start a line
> with a 1 than a = (like in "1 is more than 2" in the middle of a
> paragraph).
> What I personnaly like with this syntax is that it makes sections very
> visible when editing a page in wiki mode.
>
> About unclosed titles :
>
> === Also level 3
> === Also level 3 =
> === Also level 3 ==
>
> a) Don't interpret them
>
> +0.
>
> b) Interpret them but make closed title our default (generated by wysiwyg)
>
> +1, as I wrote above I think that having clear sections in a page
> helps to navigate in edit mode.
>
> c) Interpret them and make it our default
>
> -0.
>
> [1] : http://www.wikicreole.org/wiki/Creole1.0
> [2] : http://code.google.com/p/wikimodel/wiki/WikiSyntaxCommon
>
> Thanks,
> JV.
>
--
Jean-Vincent Drean
Hi,
I have a problem in the new rendering. We cannot differentiate between
a URI and a multiwiki link. For example: [[prefix:value]]
This can be considered as a URI or as a space/page (another ambiguity)
pointing to the "prefix" subwiki...
Right now what I've done is to only support mailto: URI and URI with
the format scheme://value.
Any other prefix:value is considered a multiwiki link.
Ideally we should have a better format so that there's no ambiguity.
WDYT? (I don't have a good proposal right now).
Thanks
-Vincent
Hi,
I add a test case for escaped symbol, but it does not pass. The test
case is like below. The xhtmlparser only realize the "[" "]" as the
SpecialSymbol.
.#------------------------------------------------------------------------------
.input|xwiki/2.0
.#------------------------------------------------------------------------------
\[notlink\]
.#-----------------------------------------------------
.expect|event
.#-----------------------------------------------------
beginDocument
beginParagraph: []
onEscape: [[]
onWord: [notlink]
onEscape: []]
endParagraph: []
endDocument
.#-----------------------------------------------------
.expect|xhtml
.#-----------------------------------------------------
<p>[notlink]</p>
.#-----------------------------------------------------
.expect|xwiki
.#-----------------------------------------------------
\[notlink\]
.#-----------------------------------------------------
.input|xhtml/1.0
.#-----------------------------------------------------
<html><p>[notlink]</p></html>
I see the class WikiModelXHTMLParser can handle the escaped symbols,
by add them like
return new XhtmlParser(Arrays.asList("**", "~~", "##", "--", "__",
"^^", ",,"));\
How about add [ ] in it, like
return new XhtmlParser(Arrays.asList("**", "~~", "##", "--", "__",
"^^", ",,", "[", "]"));
Thanks
Wang Ning
Might be good to upgrade to Hibernate 3.3.1 for Platform 1.7. We could
do it as soon as we create the 1.6 branch (next week).
WDYT?
Thanks
-Vincent
Here's the changelog since our 3.2.6 version:
3.3.0CR1 Changes:
** Bug
* [HHH-1312] - Unclosed ResultSet when using Identity
* [HHH-1396] - Table.validateColumns fails on valid column
* [HHH-1569] - Immutable Natural Id check fails with
ArrayIndexOutOfBounds in some cases
* [HHH-1593] - Infinite loop/StackOverflow when calling
configuration.setListener(null)
* [HHH-1753] - DB2Dialect.getCurrentTimestampSQLFunctionName()
uses Oracle syntax
* [HHH-1916] - param values in generator element should be
trimmed during HbmBinding
* [HHH-1920] - Incorrect documentation regarding XML manipulation
in Hibernate reference manual (chapter 18.3).
* [HHH-1956] - Interceptor.afterTransactionCompletion not called
with JTATransaction (CacheSynchronization.hibernateTransaction not set)
* [HHH-2159] - NullPointerException in
FromElement#findIntendedAliasedFromElementBasedOnCrazyJPARequirements
with 'hibernate.query.jpaql_strict_compliance' enabled
* [HHH-2164] - Minor bug in section "20.1.1. Customizing the
schema"
* [HHH-2200] - Memory leak in AbstractBatcher with Generated
Properties
* [HHH-2320] - Regression: optional properties under a <join> tag
no longer update properly
* [HHH-2503] - AbstractEntityPersister swallows JDBCExceptions in
processGeneratedProperties
* [HHH-2513] - Abusive WARN logged during deserialization of
replicated SessionFactory
* [HHH-2542] - NullPointerException in
TypeFactory.replaceAssociations for ComponentType
* [HHH-2553] - New LoadContexts Implementation causing possible
performance degradation
* [HHH-2593] - Keyword UNION is prefixed with "this_." in filter
conditions
* [HHH-2616] - No event is fired on Collection recreate/remove/
update action
* [HHH-2627] - Generated properties leak prepared statements in
Hibernate 3.2.3 and higher.
* [HHH-2631] - Leaking PreparedStatement and ResultSet via
CollectionLoadContext instances maintained in Map
collectionLoadContexts in LoadContexts
* [HHH-2711] - PropertyAccessException with backref and
<composite-map-key/>
* [HHH-2726] - spelling o your CLASSPATH
* [HHH-2728] - Calling session.clear() while retrieving objects
via an iterator will cause a "LazyInitializationException - No
Session" by the CGLIBLazyInitializer
* [HHH-2788] - Oracl8iDialect No Dialect mapping for JDBC type 91
* [HHH-2795] - CollectionLoadContexts for empy collections are
not removed until PersistenceContext.clear()
* [HHH-2816] - DefaultFlushEntityEventListener.checkNaturalId()
causes extra SELECTs on read-only entities
* [HHH-2833] - insert-select query fails with NPE when select
includes join
* [HHH-2857] - schemaSupport for HSQLDialect remote connections
doesn't work
* [HHH-2861] - cascade="delete-orphan,all" is ignored
* [HHH-2863] - testsuite fix-ups for maven and/or directory changes
* [HHH-2864] - Merging a detached instance with a new child in a
unidirectional one-to-many association fails if the parent was
previously loaded as a proxy
* [HHH-2892] - skip up-to-date checks of query cache for natural-
id only if immutable
* [HHH-2928] - optimizers for enhanced id generators should be
synchronized against multi-threaded access
* [HHH-2948] - QueryStatistics.executionMinTime always = 0
* [HHH-3111] - WebSphereExtendedJTATransactionLookup
$TransactionManagerAdapter.getStatus() implemented incorrect
* [HHH-3140] - Region prefix ignored for entities and collections
** Deprecation
* [HHH-2755] - Wrong "jsdk.jar" referenced in the tutorial
** Improvement
* [HHH-1786] - JTASessionContext.CleanupSynch does not remove
sessions from currentSessionMap
* [HHH-2048] - Incomplete MappingException at
org.hibernate.mapping.SimpleValue
* [HHH-2156] - Section 19.3, "Managing the caches" doesn't
document CacheMode.IGNORE
* [HHH-2533] - redesign Cache/CacheProviders
* [HHH-2662] - Workaround PostgreSQL issues in testsuite
* [HHH-2663] - Map java.sql.Types.REAL to Hibernate FloatType for
auto-discovery stuff
* [HHH-2665] - Split Oracle9Dialect into Oracle9iDialect and
Oracle10gDialect
* [HHH-2669] - Unequivocally map MySQL LOB types to the LONG
variant
* [HHH-2682] - support for auto-discovery of H2 dialect
* [HHH-2696] - Consider migrating to slf4j
* [HHH-2761] - Handle null and empty string consistently in
PropertiesHelper
* [HHH-2778] - TransactionManagerLookup implementation for
Bitronix Transaction Manager
* [HHH-2789] - Section 19.2 of the documentation does not show
OSCache as supporting clusters. It does.
* [HHH-2822] - timestamp extraction functions for SAPDBDialect
* [HHH-2826] - IS [NOT] NULL checks with component values
* [HHH-2859] - Introduce a 'Work' API for user to perform JDBC work
* [HHH-3131] - Add a method to ActionQueue to tell whether there
are currently entries in the executions collection
** New Feature
* [HHH-1] - Optimize Hibernate for the bulk insertion of related
entities
* [HHH-2555] - Create new RegionFactory for JBossCache
* [HHH-2884] - Provide a sessionFactory close event or hook for
the event listeners
** Patch
* [HHH-952] - Patch to allow subqueries with joins using Criteria
API and Subqueries with DetachedCriteria
* [HHH-2070] - Expand DB2Dialect auto-discovery support (Martin
Renner)
* [HHH-2519] - Schema dropping not documented with
hibernate.hbm2ddl.auto=create
* [HHH-2630] - Hibernate Dialect is not auto-detected for Sybase
ASE and DB2 (Shelley McGowan)
* [HHH-2758] - Patch IngresDialect based on certification
* [HHH-2839] - Don't use dummy dual table for hsqldb (David Bala?
ic)
* [HHH-2849] - Better error logging in IdentifierGeneratorFactory
(Antony Stubbs)
* [HHH-2957] - ActionQueue Insertion sort performance degrades
exponentially (Jay Erb)
* [HHH-3084] - DialectFactory detection of Ingres metadata
(Michael Leo)
** Task
* [HHH-2702] - Officially move to JDK 1.4
* [HHH-2704] - Migrate to Maven2 for build
3.3.0CR2 changes:
** Bug
* [HHH-1697] - OracleDialect fails to recognize sequence
accessible through syonyms when validating schema
* [HHH-2604] - Isolator.JdbcDelegate masks the exception if it
isn't possible to open a connection.
* [HHH-2683] - "datediff" is declared as NoArgSQLFunction in
H2Dialect, but actually accepts 3 arguments.
* [HHH-3006] - ConcurrentModificationException in AbstractBatcher
results in infinite loop
* [HHH-3229] - Merge can fail when there is a transient entity
reachable by multiple paths and at least one path does not cascade on
merge
* [HHH-3257] - Content images not displayed
* [HHH-3260] - Hibernate wraps a listener init or destroy
exception into an AssertionFailure
* [HHH-3261] - Do not wrap exceptions raised by event listeners
(at init or destroy time)
* [HHH-3265] - change license url in pom to http://www.gnu.org/licenses/lgpl-2.1.html
* [HHH-3266] - distribution bundle missing jta dependency
* [HHH-3272] - using of Integer.valueOf(int), which is not
available in JDK 1.4
* [HHH-3282] - DB2Dialect should report
supportsLobValueChangePropogation() == false
* [HHH-3309] - Serialize/Deserialize problem in
AbstractLazyInitializer with entitymode.MAP.
* [HHH-3409] - ResultTransformers need smarter equals() and
hashCode() impls
** Improvement
* [HHH-1786] - JTASessionContext.CleanupSynch does not remove
sessions from currentSessionMap
* [HHH-2060] - To be able to use <generator> with <composite-id>
* [HHH-2506] - Make javassist the default ByteCodeProvider
* [HHH-2875] - repackage cglib/asm under org.hibernate namespace
* [HHH-3269] - upgrade to jDocBook plugin version 2.1.1
* [HHH-3283] - protect
BulkManipulationTest#testInsertWithGeneratedTimestampVersion where
Dialect#supportsParametersInInsertSelect == false
* [HHH-3358] - Enable JTATransactionFactory and JTATransaction
factory to work without JNDI
* [HHH-3390] - Use READ_COMMITTED for JBC 2 cache
** Patch
* [HHH-3294] - Version incorrectly incremented for unchanged
persistent entity that is parent of a one to many relationship
** Task
* [HHH-3270] - follow up on documentation license questions
3.3.0GA changes:
** Bug
* [HHH-2021] - org.hibernate.cache.QueryKey has a fragile
equals() method
* [HHH-3333] - build Wiki has a typo and includes a lie re:jdk
version
* [HHH-3378] - DB2CustomSQLTest fails, need "RESULT SETS 1" in
proc definitions
* [HHH-3430] - distribution bundles cglib directly instead of the
hibernate repackaging
** Improvement
* [HHH-2926] - All *Event must inherit AbstractEvent
* [HHH-3247] - Provide more information in TypeMismatchException
message
3.3.0SP1 changes:
** Bug
* [HHH-3437] - re-add incorrectly removed public getSource()
methods on events
3.3.1GA changes:
** Bug
* [HHH-2694] - create-drop with c3p0 causes SQLException
* [HHH-3231] - org.hibernate.id.enhanced.TableGenerator throws
"IllegalArgumentException: alias not found: tbl" under Oracle
* [HHH-3392] - Query Cache entries are not distributable
* [HHH-3472] - JTASessionContext broken for WebSphere
** Improvement
* [HHH-2686] - Include a primary key in the sequence table used
by id.enhanced.TableGenerator
* [HHH-3249] - Make o.h.id.enhanced.TableGenerator more extension-
friendly
* [HHH-3424] - concat() with param binding fails function on derby
* [HHH-3454] - Allow enhanced.TableGenerator to segment itself
per entity as default
* [HHH-3456] - Make o.h.id.enhanced.SequenceStyleGenerator more
extension-friendly
* [HHH-3471] - Provide true-false type that maps to int values
** Task
* [HHH-3474] - Upgrade to use slf4j 1.5 (1.5.2)