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

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

[D. Tuinstra]

I'm beginning to install and evaluate various Java frameworks, IDEs,
and plugins, and would like to write ebuilds for them. Some
questions arise:

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. 

    It would be even nicer if there was an eclass or portage
function for webapp install that would DTRT with whatever container
was installed, or if there were functions such as dowar_jetty(),
dowar_tomcat3(), dowar_tomcat4(), etc. Or should this functionality
be put in a utility, say java_servlet_config, modelled on
java_config, for ebuilds to use?)

2) Related question: what should the default container dependency be
if none is installed? Tomcat?

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? 

    If such flags are used, there should also be a
"java_tool_standalone" flag to indicate installation as a
standalone tool when possible. (Apropos this matter, Oracle just
introduced a proposal into the JCP to standardise plugin
architecture across IDEs.)

Thanks,

  --Dwight Tuinstra



--
gentoo-dev@gentoo.org mailing list

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

[Dylan Carlson]

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

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.

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.

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


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


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

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Developer, Java Lead -- Gentoo Linux
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+7uKiPQS8wXCOFl8RAmTMAJ4n7/KvV2CfE4uJ0cfnyE/B1JHOYgCgly53
tzUw3Q4NdL7/MhF1E1oXsc8=
=x1tv
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

[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@gentoo.org mailing list