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

[Jörg Schaible]

Eivind Tagseth wrote:

> * 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.

Well, seems you've done something manually. Compare your output of "etcat -f
cocoon" with mine:

==== snip ====
[ Results for search key : cocoon ]
[ Applications found : 1 ]

 Only printing found installed programs.


 * net-www/cocoon-2.0.2
/opt
/opt/tomcat
/opt/tomcat/webapps
/opt/tomcat/webapps/cocoon.war
/usr
/usr/share
/usr/share/doc
/usr/share/doc/cocoon-2.0.2
/usr/share/doc/cocoon-2.0.2/CREDITS.gz
/usr/share/doc/cocoon-2.0.2/INSTALL.gz
/usr/share/doc/cocoon-2.0.2/KEYS.gz
/usr/share/doc/cocoon-2.0.2/README.gz
/usr/share/doc/cocoon-2.0.2/changes.xml.gz
/usr/share/doc/cocoon-2.0.2/announcement.xml.gz
/usr/share/doc/cocoon-2.0.2/todo.xml.gz
/usr/share/doc/cocoon-2.0.2/html
<snip/>
==== snap ====

> 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).

Especially for Cocoon it does only make sence to do this manually. As you've
reported, you will have to adjust either the demo app or use Cocoon in an
completly own app yourself. But both is a developer's task.

> 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?).

I am nor sure what you're refering here ....
 
>> 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.

See other mailing from Karl. Somethin's goin' on.

>> 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.

Thought so too.

>> 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.

At least it's the one I have a new ebuild for <g>. I'll add it to bugzilla
as soon my next dependent ebuild for lenya is working also. But this will
arise some additional questions about the Cocoon ebuild ...

Regards,
Jörg



--
gentoo-dev@g.o mailing list