Jason van Zyl wrote:
>
> >
> > Never found the time to download it and move jetspeed on a TDK base :(
> > It's in my TODO list...
>
> I would be happy to work with you on this! All I've been working
> on lately is the TDK in preparation for making a new version
> of the sandbox for Scarab. Torque is now fully integrated: every
> last bit of SQL required by Turbine is automatically generated
> by Torque, the target database is created, and the SQL is inserted.
> All the Peers for your project (as defined in an XML schema) are
> auto generated and compiled.
>
Jetspeed doesn't use the Turbine Peer model right now so Torque support
is not currently very important for the project. I don't know what
other advantages there would be to move Jetspeed as TDK.
> > My goal is to be able to distribute a "binary" fully-built WAR of Jetspeed
> > off the web site, which can be dropped in any servlet 2.2 container and tried
> > out without any configuration tweaking. No more installation questions ! :)
> > I think it's something that can be of interest for most other Turbine based
> > project (Jyve, etc...)
>
> I will get rid of every last hard-wired path, so deploying TDK apps
> will be seemless. I am almost there, the TDK will produce apps that
> can be dropped in any contain on any path. I am in full agreement
> with you that any changes that are required in Turbine to make this
> happen are ultimately required to make deployment simple.
>
I think getting rid of the non-relative path in every component is the wrong
way to approach the problem because:
- you'll have to make sure every new component doesn't introduce new
path issues
- if increase the code complexity of every component and may tie them
to a servlet path resolution mechanism
IMO, the better approach is to allow TurbineResources to flexibly deliver
to the components their conf properties in whatever format is natural for
them. It's quicker to implement and will stay correct whatever new components
are introduced.
> I would also like to add something to Turbine where the initialization
> of the app can be done via a web browser. Drop the WAR file in
> the container. When the app runs for the first time, it will
> "know" that it's not configured. Present a form to the administrator:
> let them pick the target database, initial passwords and whatever
> else then create the database and all the SQL required for the
> app to run. I can already create a database app in 5 seconds
> using a Linux/MySQL combination and adding support for other
> platform/database combinations should be easy.
>
I like that ! This can be implemented as by using my
VariableTurbineResources implementation: by default, Turbine knows
the value of a few variables (webapp root, etc...) because they're
servlet container dependant. The resources service may gather at startup
any referenced variable in the config file and if they are some variables
which it doesn't know how fill, it throws an exception with the list
of variables to fill in.
The Turbine sevlet can then chose to intercept this exception and provide
a form screen for the user to fill them in...
What do you think ?
> I would like to make deploying turbine apps dead simple
> to deploy! For me the TDK is about easy development and
> easy deployment. I'm not far from this being a reality and
> I would love to see Jyve and Jetspeed use the TDK.
>
If we have the same goals, we're bound to converge sometimes soon.
--
Rapha�l Luta - [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
