David Sean Taylor wrote:
>
> Raphael,
>
> I noticed that you updated the turbine.jar.
> Ingo recently zipped up the turbine source into /lib/src/turbine.zip when he
> checked in turbine.jar.
> I was hoping that we would continue to provide the current source for
> turbine with the latest jar if its not too much trouble?
>
Is that *really* useful ?
If you insist I may definitely do it but I didn't see it as necessary since
it's just a patched version of the current Turbine CVS and as soon as my
reosurces patches are integrated in the turbine CVS tree, I'll update again
the jar, this time using the
turbine-CVS12112000.jar
notation so it would easy ffor anybody interested in the source to check
the file for this date from the Turbine CVS.
Yes, I know that this introduce again version number in the jar contained
in the lib/ directory but now that we have WAR support and everything is
automatically configured, I don't see it as an issue.
> Thanks for updating the Hypersonic SQL database with the latest Turbine
> schema.
> Its been broken for the last week or so.
> Did you have trouble getting the turbine-hypersonic.sql script to run?
> I noticed that you didn't check it in. I had problems with the 'default -1'
> on the TURBINE_SCHEDULED_JOB table and had to remove the 'default'
> constraints. (Im not sure how SQL-2 compliant hypersonic is, but regardless
> Im really beginning to like it.) It now seems obvious to me that
> jetspeed.script was used to create the database for the WAR distribution.
>
Yes I had issues with the unique constraints and the default values but since
I hadn't updated hsql.jar for a long time I didn't know if it was related to
my jar file or a bug in the sql script. Once I'll know for sure, either I'll
notify Jason so that he can fix the torque generation files or I'll update
the db.
> To point out another point that may or may not be obvious, it appears that
> the 'jetspeed-system' directory will no longer be used. Now the default
> hypersonic database, cache and logs are all placed under the webapp/WEB-INF
> directory.
>
Yes, I think the WAR deprecates the need for jetspeed-system but I did not
modify the conf files in src/config/ on purpose.
I'll sync everything when the WAR is building, running and stable.
For now, you should consider the WAR building as experimental but committed in
the head so that everybody can have a say in what's going in.
For now, if you want to have a look at what JR.p and TR.p I use,
check /webapp/WEB-INF/conf/
BTW, I was considering to remove the Cocoon portlets from the default
jetspeed-config.jcfg (and default WAR operation) and only provide the
XSP functionality as a "configure yourself" portlet with the help of a
few examples.
Why ?
Because we won't have to distribute cocoon anymore with Jetspeed thus
removing a build and distribution dependency
Beccause the Cocoon support is a hell to maintain properly and generates
at least half the user questions
Because templated portlets will remove a lot from XSP support interest
Because Cocoon 1.8 is not actively developped anymore so it's an
evolutionary dead-end anyway without a serious reimplementation. We might
as well not promote too heavily a component which will need a complete
overhaul in the near future.
I short my opinion is that it's better not to integrate with cocoon and
provide a good alternate system ( JSP, velocity, XSL templates portlets)
rather than badly integrate with such a cool project.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
