Re: [gentoo-dev] Re: Re: [gentoo-java] Help with new Cocoon ebuild

[Eivind Tagseth]

* Jörg Schaible <joerg.schaible@×××.de> [2004-01-08 23:23:55 +0100]:

> Just to clarify, what "usually means": You can provide a web application
> either as war file or as a complete directory tree. The war file just
> contains this tree for (installation) convenience, but may have to be
> extracted to adjust configuration files.

Good point.

> Well, coming to frameworks like Cocoon the things get even more compilcated.
> Cocoon itself is a framework i.e. you either include it into your own web
> application or you adjust the Cocoon web application to your own needs for
> your application. The delivered Cocoon web application is basically just a
> demonstration, but not of much use as a real world app. This implies, that
> it is normally not really useful for normal users (i.e. not a developer) to
> install Cocoon at all in a servelt engine IMHO. Either it is included in
> another web application or it is used to build other (web) applications
> which implies no need for an installation in a servlet engine also.

I'm not quite sure what you mean here.  My cocoon installation _is_ deployed
as an unpacked war file.  I've modified it's sitemap and a config file and
using cocoon to pipeline several XSL transformations.

So personally, I have the need to get cocoon installed into my favorite
servlet engine, preferably unpacked.  But of course, I can do this myself,
providing I have a sensible place to find it (not in tomcat's webapps
directory).

Since a tool for installing "normal" web applications is being developed, it
would be nice if it was also able to install war files.  As far as I
understand, this tool is not part of the normal emerge-process, but must
be executed manually (or perhaps using ebuild <package> config?).

> Additionally a developer might have the need to have multiple versions of
> Cocoon, since he could develop multiple applications using it or
> maintaining different versions of his application using different Cocoon
> versions also (and probably supporting diferent servlet engines). Both
> scenarios do not fit very well into the current portage characteristics.

Part of it does. What you are saying is that portage must be able to
"hold" several versions of cocoon, while there must be a way to install
serveral instances of all versions.  I think the ebuilds should handle the
first part (by installing into /usr/share/webapps or something), while
a web app installation tool could handle the latter part.

> But there is more. Same situation applies for Enterprise Applications (EAR
> files), that should be running in any conforming J2EE server (jBoss,
> Enhydra, Jonas, Sun J2ee SDK, WebLogic, ...). Robert, don't get confused: a
> servlet engine is part of the J2EE spec.

Hehe... poor Robert.  I think EARs could be handled pretty much the same
way as WARs though.

> While I think we should solve the basic problem installing real world web or
> enterprise applications, but Cocoon and other frameworks/toolkits should
> not be handled in the same way.

Cocoon is indeed a poor example, since it is both a framework and a demo
web application.  I used it as an example because this was the app originally
mentioned, and the only servlet I know of in portage.



Eivind

-- 
Eivind Tagseth,
E-post jobb: eivind.tagseth@×××××××××.no, e-post priv: eivindt@××××××××.no
Mobil: [phone]

--
gentoo-dev@g.o mailing list