Re: request feedback on JBOSS debs
On Mon, 2003-01-20 at 14:44, Adam Heath wrote:
> On Mon, 20 Jan 2003, Greg Wilkins wrote:
>
> > + The setting of JAVA_HOME should be done by an auto search and/or
> > a debconf dialog.
>
> Use /etc/defaults/jboss, and if not set, have it look at standard locations
> that java debs(from blackdown, maybe /usr/local) contain.
this, along with debconf are planned for future releases.
> > + The default webcontainer for jboss is Jetty, but you don't appear
> > to allow just the default deployment - as it depends on tomcat.
> > Tomcat is an optional extra and really should be presented that
> > way. Alternately you should have a jboss-jetty deb that is
> > the default webcontainer for jboss, which may be replaced by
> > jboss-tomcat.
>
> jboss debs on jboss-web-container, a virtual package
> jboss-jetty(does not exist) and jboss-catalina provide jboss-web-container.
>
> That's how my 2.4 packages worked. I even made a test jboss-jetty, and even
> had *both* deployed at once(I used alternatives to select the default web
> container).
good idea.
> > + I see you have taken the approach of just including all the jars
> > that jboss uses in the lib directories as if you had installed
> > jboss normally. I can see the logic of this (simplicity) but
> > in reality it really should use the jars from /usr/share/java
> > is that your eventual intent?
>
> All jars that already exist as packages should be listed as deps.
planned. This is where I think we'll meet resistance from jboss
developers. The including/packaging of dependancies within jboss has
been described to me as a feature. I can see the value in it but I
definitely prefer relying on a packaging system to take care of
dependancies as in Debian.
> Any jars
> that don't should be in a separate jboss-contrib or jboss-nonfree package, so
> it makes things easier to keep track of.
I think we should work to package each individually (eg. javamail) if
possible and they fall into the above case. The jboss-contrib package
would shrink over time. The problem with this approach is that future
versions of jboss-contrib won't be backward compatible with earlier
versions as jars move from jboss-contrib to unique javamail packages -
yuk.
-joe
--
Innovation Software Group, LLC - http://www.innovationsw.com/
Business Automation Specialists
UNIX, Linux and Java Training
Reply to: