[gentoo-dev] Re: Q's: Java 'servlet' virtual? Java IDE use flags?

[D. Tuinstra]

Dylan ---

Thanks for the reply. I'm still new to Java development and trying
to sort out how it fits into portage and gentoo, so your
explanations (and patience) are appreciated. More comments
interspersed below.

Dylan Carlson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings Dwight,
>
> On Sun June 15 2003 5:31 pm, D. Tuinstra wrote:
>> 1) Should there be a virtual for servlet containers? At present
>> there are several containers available including tomcat, jetty,
>> and jboss (and that's just open source). I've only worked with
>> tomcat, but some of the references I've read say that each
>> servlet container has its own directory structure and its own way
>> to install servlet-based webapps. When writing an ebuild for a
>> webapp it would be nice to know, in a standard way, whether a
>> container is available and if so, which.
>
> Since the servlet 2.2 API spec, WAR files have a standard
> structure and this is used by all current versions of
> 2.2-compliant servlet containers I'm aware of.

OK, good.

> Some packages build WAR files that are entirely optional to the
> set of
> classes that the package provides.  For this reason and others, it
> doesn't make sense (from my perspective) to have an ebuild
> automatically deploy a
> WAR.   In doing so, it could have potential security issues ...
> especially on a server that is already running stuff live.
>
> Since the installation of a WAR is typically just a matter of
> copying the file in, and maybe touching a config file or two --
> WARs should be installed into:
>
> /usr/share/${PN}/war/
> ...or
> /usr/share/${PN}-${PV}/war/ for slotted apps
>
> I would like to keep a distinct line between installing a package
> and
> deploying it.   If the user wants to deploy the application, it
> has to be a separate action; no different than adding a script in
> /etc/init.d to a given runlevel.
>

This makes good sense. Perhaps (as a style convention) such ebuilds
should have an info message reminding the user that deployment is
still necessary as as a separate step, and mention any tools gentoo
provides to assist with this (such as the WAR addition to
java-config you mention below).

I will follow the suggestion for installing WAR-containing packages.
I'd also thought there might be some justification for putting them
in /opt, but if one considers /opt for pre-compiled packages meant
to be run by users found in /etc/passwd, then webapps don't fit the
bill.

> Adding support to java-config, supposing a virtual exists for
> servlet containers, is the ideal solution to installing WAR files
> in the long-term. Part of that will be some way of coupling WAR
> deployment and any
> corresponding config files in the same feature.   Currently
> java-config is undergoing a rewrite, so between Todd Berman and
> myself finishing that up, expect to see that sometime soon.

Great!

> Either way, I don't expect to support non-WAR servlet packages as
> there's
> just much that can go wrong.  Those types of packages will be put
> in /usr/share/${PN}/ until they can be installed as WARs, in which
> case the user will have to install them manually (not via
> java-config).

I suppose also that a sufficiently motivated ebuild author could
have the ebuild construct the WAR during the install() phase. One
issue that will arise is what to do with pre-builts that have their
own installer that wants to install a servlet container. I've
noticed this with frameworks that include examples. I suppose this
would require picking apart the provided jars and scripts and then
putting things back together reasonably. Ugh.

Case in point regarding non-WAR installs: struts. It's meant to be
installed 755 as a bunch of jars. During development you're
expected to put them on your classpath (either by appending to the
classpath or by copying the appropriate jars to your development
tree). During webapp deployment you're expected to have copies of
the jars in your WAR. At least so it seems; I'm still trying to
figure it out in my spare time. (I submitted an ebuild for struts
to bugzilla a week or two back (#21930) but I think now it's
probably not quite right --- flattens the file hierarchy a little
too much).

>> 2) Related question: what should the default container dependency
>> be if none is installed? Tomcat?
>
> We'll have to pick one for a virtual.  Tomcat is the official
> reference implementation; also considering everything else Apache
> produces, it makes overall sense for Tomcat to be the default.

I'd agree.

>> 3) Some Java tools, such as Struts Console, can be installed
>> standalone or as a plugin to one or more Java IDE's. Should there
>> be a USE variable for each of the IDE's, that an ebuild can
>> consult to see which IDE's it should install itself into? If so,
>> how would version dependency/compatability issues be handled?
>
> That's a complicated issue.  It might make sense to make a plugin
> a separate package (which depends on the main struts package for
> the member classes). e.g., dev-util/eclipse-struts.
>
> Alternatively, the ebuild can check for the presence of another
> package
> during src_compile (which is somewhat ugly but it works).  It
> depends on the circumstances.
>
> Either one of those two scenarios is more preferable IMO, than
> piling on
> more USE flags- even local ones.   Some may disagree with me, but
> USE flags should be conservative and restricted to compile-time
> options as much as possible.

I'm not sure that "...-plugin" ebuilds are a good idea (unless the
package is *only* a plugin). If struts-console is any indication,
there's not much different that makes the standalone into a plugin.
And if there are distinct plugin/standalone jars, they may be
wrapped into the same tarball (or buildable from the same source
tarball). In this case, separate ebuilds might double the
maintenance burden and bloat the number of packages. 

OTOH, if IDE-specific jars or source are individually downloadable,
"...-plugin" or even "...-plugin-IDEname" makes a lot of sense.
There's also a huge advantage to separate "...-plugin[-IDEname]"
ebuilds in that dependency issues are much easier.

Where things might get sticky is if the package is built from
source, and there are different build targets for standalone vs.
IDE-A vs. IDE-B vs. etc. In that case it would seem you have to
either build them all, employ USE flags, or check to see what's
installed.

Maybe the right approach is similar to the "install vs. deploy"
idea: "install vs. integrate". If a unified plugin architecture is
adopted it would make it possible to write an
"integrate-java-plugin" tool that a user could run after emerging.
Until then, the user could be pointed to whatever docs the package
provides describing the integration procedure for supported IDEs.
Those docs would hopefully point out version/IDE considerations
(struts-console does this). The downside is that someone searching
for plugins would have to do an "emerge -S plugin" instead of -s,
and hope the ebuild author put "plugin" in the description.

Regards,

  --Dwight



--
gentoo-dev@g.o mailing list