Hello Berin,
I think what you need to divide cocoon demo webapp into separate
components which can installed independenly.
Example components tree:
- Editor
- Documentation
- Static content
- Dynamic content
- Simple samples
- Database samples
See at welcome page - blocks is a tables...
Add interactive mode on this page - install/uninstall buttons,
component tree, some options.
At the end I see some InstallShield analogue through web-interface.
You also can setup/upgrage additional components use Internet download from
your site (see CYGWIN for good InstallShield example)
Use hsqldb for storing setup state.
Or (!) you can write java awt/swing program for install.
I.e. simply use general path for all applications which become too complex.
What do you think about it?
Friday, September 07, 2001, 3:35:09 AM, you wrote:
> I want to create an installable Cocoon for version 2.1.
> We have already discussed its features a couple of months
> ago. The most important ones are the predictable classloaders,
> the separation of implementation and interface, and smaller
> webapps.
> Currently, the Cocoon demonstration Web App weighs in at
> an impressive 11MB. By specifying an install directory,
> Cocoon can be accessed by any webapp on a machine. It does
> not negate the ability to deploy like we normally do, it
> simply provides another option. Cocoon should also be
> installable in a J2EE EAR file, and used from multiple
> webapps there.
> Most of the changes are straight-forward. It will require
> us to separate the Tools libraries into a separate directory
> to facilitate automatic discovery of jars without grabbing the
> wrong ones.
> The one change that is not so straight forward is repartitioning
> Cocoon into separate jars. It is important to define what is
> a user accessible API, and what is not. For the important
> interfaces, this is simple:
> Generator, Transformer, Serializer, Reader, Matcher, Selector,
> Action, and Processor should all be publicly exposed interfaces.
> Below, I compiled an exaustive list of all the interfaces and
> classes that should be in a cocoon-api.jar file. Please let me
> know if I missed something.
> I will set up the packaging to generate the following jars:
> cocoon.jar (main implementation and component implementations)
> cocoon-api.jar (main interface and utility classes)
> cocoon-servlet22.jar (environment implementations for servlet 2.2 spec)
> cocoon-servlet23.jar (environment implementations for servlet 2.3 spec)
> cocoon-cli.jar (environment implementations for the command line)
> In the WEB-INF/libs directory, all you would need are:
> cocoon-api.jar
> avalon-framework.jar
> avalon-excalibur.jar
> cocoon-servlet22.jar (or cocoon-servlet23.jar)
> All the rest of the jars will be able to rest in a separate lib directory
> either inside or outside of the servlet context. That allows us to have
> a known classloader, and remove 90% of our installation problems.
> The classes/packages I forsee in the Cocoon API jar are:
> org.apache.cocoon.*Exception (all exception types)
> org.apache.cocoon.Processor
> org.apache.cocoon.CocoonManager (NEW CLASS)
> org.apache.cocoon.Modifiable (NOTE: prefer the version in current Avalon)
> org.apache.cocoon.components.language.generator.ProgramGenerator
> org.apache.cocoon.components.language.generator.CompiledComponent
> org.apache.cocoon.components.language.markup.MarkupLanguage
> org.apache.cocoon.components.language.programming.ProgrammingLanguage
> org.apache.cocoon.components.language.programming.CodeFormatter
> org.apache.cocoon.components.language.LanguageException
> org.apache.cocoon.components.browser.Browser
> org.apache.cocoon.components.store.Store
> org.apache.cocoon.components.store.StoreJanitor
> org.apache.cocoon.components.sax.*
> org.apache.cocoon.components.saxconnector.SAXConnector
> org.apache.cocoon.components.source.SourceFactory
> org.apache.cocoon.components.source.SourceHandler
> org.apache.cocoon.components.parser.Parser
> org.apache.cocoon.components.resolver.Resolver
> org.apache.cocoon.components.url.URLFactory
> org.apache.cocoon.components.xslt.XSLTProcessor
> org.apache.cocoon.acting.Action
> org.apache.cocoon.caching.* (all caching classes)
> org.apache.cocoon.environment.* (but none of the sub packages)
> org.apache.cocoon.generation.Generator
> org.apache.cocoon.i18n.*
> org.apache.cocoon.matching.Matcher
> org.apache.cocoon.reading.Reader
> org.apache.cocoon.selection.Selector
> org.apache.cocoon.selection.Serializer
> org.apache.cocoon.transformation.Transformer
> org.apache.cocoon.util.*
> org.apache.cocoon.xml.** (all sub packages)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
Best regards,
Andrew mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
