Raphael Luta wrote:
>
>
> 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 ?
Yes, I think so. I often look at the Turbine source, and its important to
have the matching source with Jetspeed in case of any problems that come up.
> 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.
>
+1
that will work
> > 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.
>
Yes, I had the same problem with Oracle, that the scripts had syntax errors.
Ive been meaning to take time and understand how Torque works. Its looks
pretty nice from what i've seen, great concept, but its kind of strange that
we are getting syntax errors in the schema generation scripts. Leaves me
wondering where the scripts in src/sql/external came from and if they are
even up-to-date.
> > 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/
>
Ok, thanks. I was about to try to integrate everything. I looks pretty
simple, but if things are going to change again I will wait til it
stabilizes.
> 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]
>
>
--
--------------------------------------------------------------
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]
