i also don't see a way to specify the insert statement on the nukes_group_membership table via the @jboss.relation-table xdoclet tag.
and the JDBCPeristentManager class will need to be updated to check to see if its tables exist, and create them if they don't.
still wanna use pure CMP :-) ?
In this thread Jae points his finger at the biggest remaining challenge we will need to overcome to get to a pure-CMP Nukes: we need to identify the remaining tricky subtle bugs in JBoss CMP itself, and get the appropriate JBoss CMP gurus to fix them.
Nukes is a prime real-world test suite against which JBoss CMP will have to measure up.
There is still some gap to be crossed before JBoss CMP (and indeed JBoss AS) can live up to the promise of transparent persistence that we have been working towards for the past half decade --- but the good news is that the gap is quite narrow compared to what it was just a short time ago.
After I started advocating the vision of pure-CMP for Nukes ~4 months ago, I began to realize it would be quite a long process. Frankly, I am very impressed with the movement so far -- I didn't dream that anybody would even think about tackling pure-CMP for the Nukes core prior to 1.1 coming out! My hat is off to Jae for taking the baton and really running with it, and making so much progress.
Now we are at the stage where we really do need some key help from the wider JBoss community outside of Nukes... but we are also almost at the stage where we can give them something really juicy in return:
"Sacha Labourey" wrote:
Do we have a xxx.war or xxx.sar standalone version that people can simply download and drop in any jboss instance? That is what people need I guess, is this available for download?
What Sacha is requesting can only be provided if we complete a pure-CMP solution.
(perhaps Sacha might even make it a priority to get us what we need so that we can more quickly push this over the top ;-) ;-) )
After that, we still have another major phase to accomplish before we can really say we have a pure-CMP solution: we have to transform the current "installer" (and it's large number of associated setup.xml and other files) into quite a different animal. (After my current travels, when I get settled down in later July, I plan on developing & committing a good chunk of the design & code needed to make that happen.)