sion of ClasspathX-mail. The new
version has the following providers:
- imap
- pop3
- nntp
- smtp
- maildir
- mbox
most (if not all) of which are thanks to dog.
I expect we'll release before September but it may just slip over
because we're all very busy. The more people who download
sion of ClasspathX-mail. The new
version has the following providers:
- imap
- pop3
- nntp
- smtp
- maildir
- mbox
most (if not all) of which are thanks to dog.
I expect we'll release before September but it may just slip over
because we're all very busy. The more people who download
-)
I'm the ClasspathX maintainer.
I'd be really happy for someone to make a debian package... we're
going to make a new release of GNU JAXP soon... we have some build
issues to fix first.
Arnaud, if you want to build a debian package I'll help in whatever
way I can.
Nic
Arnaud Vandyck <[EMAIL PROTECTED]> writes:
> _______
> / Nic Ferrier <[EMAIL PROTECTED]> wrote:
> | I'd be really happy for someone to make a debian package... we're
> | going to make a new release of G
Ean Schuessler <[EMAIL PROTECTED]> writes:
> Dear self-rightous and non-appreciative Java Debian list,
> ...
You should all start using lisp.
Nic
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
to replace existing VM
class loaders (I'm not sure how well that would fit with gcj for
example) but it would be possible in traditional VMs.
The package would have to move and rename the existing VMs System
Class Loader and call that to deal with stuff on the boot classpath
and extension class
4.0) which is due Any Day Now.
But what you're getting at I suspect is "does this matter - Tomcat
has it's own repositories for jars it can just keep to them".
The point I was trying to make is that Debian may want to provide a
standard webapp directory or path (the place where WAR files are put
so that the servlet engine can find them).
Nic
n't it have some problems though if jar files inside the
webapp specified extensions to be loaded from relative paths?
The relative path they would find would be /usr/share/java/webapps
which would presumably not be the place one would find normal jar
files.
(I don't know if this is the case ot not - I haven't tested it).
Nic
e are now quite a few servlet dependant tools out there. I would
like to see this done as well, for 2 reasons:
1. I'm the architect of the GNU-Paperclips servlet container which I
would like to get into Debian for the next release
2. I'm involved in several projects that will utilise servlet
containers and I'd like those to be Debianized too.
Nic Ferrier
Paperclips, the FSF's servlet
engine) require GNUJSP to provide JSP services.
I will be packaging GNU-Paperclips for Debian once we are API 2.3
compliant. I hope that Debian will provide it in the main release when
I have done so.
Nic Ferrier
llow me to specify
GNU-Paperclips (the FSFs GPLed servlet engine) as something that could
be depended on by packages like Coccoon.
Nic
PS the problem with Jserv could be fixed with a
deployment-descriptor->jserv-conf translator but I doubt very much
whether there will ever be one.
in Thread. I was hoping that the tomcat code would
>be a good implementation of 1 that I didn't have to
>write all of.
C program to run JVM as a daemon here:
http://www.gnu.org/software/java/arc/djinn-1.1.tar.gz
Nic Ferrier
nding on the part of the developer
about what has changed.
Nic Ferrier
# JCD Makefile
# (c) Nic Ferrier - Tapsell-Ferrier Limited 2001
#
# You are free to redistribute this file. NO WARRANTY or fitness
# for purpose is implied by this notice.
#
# What goes on here?
# The SOURCEFILES should be a
web server?
You could also use GNU-Paperclips and GNUJSP (but Paperclips is still
in beta).
I would advise that you not use JServ. It's very old now and not
likely to implement what your customer might expect from a JSP engine.
Either of the other two would be ok.
Nic Ferrier
GNU-Papercl
o to contrib.
There are many other free JVMs now: ORP, KissMe, etc... The Classpath
page at GNU references them:
http://www.gnu.org/software/classpath
Nic Ferrier
GNU ClasspathX maintainer.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
to replace existing VM
class loaders (I'm not sure how well that would fit with gcj for
example) but it would be possible in traditional VMs.
The package would have to move and rename the existing VMs System
Class Loader and call that to deal with stuff on the boot classpath
and extension cl
4.0) which is due Any Day Now.
But what you're getting at I suspect is "does this matter - Tomcat
has it's own repositories for jars it can just keep to them".
The point I was trying to make is that Debian may want to provide a
standard webapp directory or path (the place where WAR files are put
so that the servlet engine can find them).
Nic
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
n't it have some problems though if jar files inside the
webapp specified extensions to be loaded from relative paths?
The relative path they would find would be /usr/share/java/webapps
which would presumably not be the place one would find normal jar
files.
(I don't know if this is the case
e are now quite a few servlet dependant tools out there. I would
like to see this done as well, for 2 reasons:
1. I'm the architect of the GNU-Paperclips servlet container which I
would like to get into Debian for the next release
2. I'm involved in several projects that will utili
ly GNU-Paperclips, the FSF's servlet
engine) require GNUJSP to provide JSP services.
I will be packaging GNU-Paperclips for Debian once we are API 2.3
compliant. I hope that Debian will provide it in the main release when
I have done so.
Nic Ferrier
--
To UNSUBSCRIBE, email to [EMAIL PRO
llow me to specify
GNU-Paperclips (the FSFs GPLed servlet engine) as something that could
be depended on by packages like Coccoon.
Nic
PS the problem with Jserv could be fixed with a
deployment-descriptor->jserv-conf translator but I doubt very much
whether there will ever be one.
--
To UNS
in Thread. I was hoping that the tomcat code would
>be a good implementation of 1 that I didn't have to
>write all of.
C program to run JVM as a daemon here:
http://www.gnu.org/software/java/arc/djinn-1.1.tar.gz
Nic Ferrier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nding on the part of the developer
about what has changed.
Nic Ferrier
# JCD Makefile
# (c) Nic Ferrier - Tapsell-Ferrier Limited 2001
#
# You are free to redistribute this file. NO WARRANTY or fitness
# for purpose is implied by this notice.
#
# What goes on here?
# The SOURCEFILES should be a
n my web server?
You could also use GNU-Paperclips and GNUJSP (but Paperclips is still
in beta).
I would advise that you not use JServ. It's very old now and not
likely to implement what your customer might expect from a JSP engine.
Either of the other two would be ok.
Nic Ferrier
GNU-
o to contrib.
There are many other free JVMs now: ORP, KissMe, etc... The Classpath
page at GNU references them:
http://www.gnu.org/software/classpath
Nic Ferrier
GNU ClasspathX maintainer.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-)
I'm the ClasspathX maintainer.
I'd be really happy for someone to make a debian package... we're
going to make a new release of GNU JAXP soon... we have some build
issues to fix first.
Arnaud, if you want to build a debian package I'll help in whatever
way I can.
Nic
Arnaud Vandyck <[EMAIL PROTECTED]> writes:
> _______
> / Nic Ferrier <[EMAIL PROTECTED]> wrote:
> | I'd be really happy for someone to make a debian package... we're
> | going to make a new release of G
well with ppc?
I do all my java development on ppc.
I use either Blackdown 1.3 or GCJ.
Nic
florian <[EMAIL PROTECTED]> writes:
> On Thu, 2003-04-24 at 13:00, Nic Ferrier wrote:
> > florian <[EMAIL PROTECTED]> writes:
> >
> > > hi!
> > >
> > > does anybody here do java development under ppc?
> > >
> > > i t
29 matches
Mail list logo