[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: