cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Answer <creat...@mail.ru>
Subject Re: [C2.1] Making an installable Cocoon
Date Fri, 07 Sep 2001 13:34:51 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

-- 
Best regards,
 Andrew                            mailto:creator0@mail.ru



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message