Akber Choudhry wrote:
>
> On Fri, 1 Mar 2002, Stefano Mazzocchi wrote:
>
> > Akber Choudhry wrote:
> > >
> > > Is there the possibliity of developer build, pro build, and enterprise
> > > build, complete with optional tomcat config files etc. and checking of
> > > java versions, xerces versions etc. during build and install. Cocoon
> > > rocks, it will become a killer!
> >
> > I don't get what you're trying to suggest, but I'm very interested in
> > knowing your thought on this.
> >
>
> With reference to build difficulties being reported on cocoon-users and
> today's posting by Nicola Ken re: castor, multiple builds should be
> considered. Let us look at the users -- developers and super-users,
> regular users who want to demonstrate a proof-of-concept with an example
> application, and enterprise development teams who, having chosen Cocoon,
> want to implement it for their project.
>
> This is what I meant by dev, pro and enterprise build. These are merely
> suggestions :) to give a better out-of-the box experience and can be
> implemented as --
> a. different builds
> b. different cocoon.xconf and sitemap.xmap files
> c. Base Cocoon + modules
> and -- d. different build.xml files
>
> Pro Build - this should have J2SDK detection, servlet API version
> detection from the directories provided by the user. Minimal cocoon.xconf
> and sitemap.xmap with an examples sub-sitemap of core examples.
> Optional packages -- hsqldb -- fo -- castor --
> (with instructions on changes to sitemap, jar placement).
> Step-by-step instructions on configuring and testing JDBC connections -
> under Websphere, Weblogic, JBOSSS connection pooling and/or Avalon/cocoon
> connection pooling. An example on using existing XML-producing
> applications. Compliance Matrix by OS/J2SDK/servlet engine vendor.
> Perhaps build bundled with Tomcat4.03LE (using tomcat rudimentary JNDI
> for JDBC and sharing the tomcat logs and config directory.
>
> Enterprise Build - more documentation, charts, slides. Multiple-topology
> deployment. EJB integration. Back-end ERP integration. Relationship to
> servlet containers. Guidelines for developing custom components. Cocoon
> wrapper development. LDAP authentication. Multiple-machine deployment.
> Different builds for each deployment environment (e.g. Websphere 4.0 .ear)
>
> I would be happy to contribute wherever asked to.
Akber,
your suggestions make perfect sense, now my suggestion is: do a clean
CVS checkout, work on your local copy to fix/cut/move/change/add stuff
as you think it appropriate for your personal taste or for what you need
in your day job.
The golden rule of OSS is: there must be an itch in order to trigger a
scratch. And an itch to make the build and installation process simple
*MUST* come from those who found problems with it.
>From my side, I can say that I like your ideas on the different
scenarios of use so I'd be very happy to have your patches incorporated
into the repository.
OSS works because if something bugs you enough, you'll dedicate
resources to it and if something doesn't bug you enough, well, than it's
ok as it is. Where do you stand? :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
