On Wed, 14 Nov 2001, Jason Dillon wrote:
> First off you are using the wrong cvs module to build a functional JBoss 3.0
> release. The build system and cvs organization has changed drammatically
> from 2.x
>
> I know there are not any docs to point this out directly, which I am going
> to fix.
On Thu, 15 Nov 2001, David Jencks wrote:
> Then you are insisting on wasting your time and the time of everyone on
> this list. You will only get the correct cvs versions of the entire jboss
> server by checking out jboss-all. The server (looks like jboss in cvs) is
> only a small part of jboss
On Thu, 15 Nov 2001, David Maplesden wrote:
> Settle down, it was very apparent to anyone following your conversation that
> you guys were talking about different cvs modules.
It's not apparent to me(who is new with jboss), and not apparent to Jason(who
is not). So, you can imagine my excaspera
On Wed, 14 Nov 2001, David Jencks wrote:
> On 2001.11.14 21:02:53 -0500 Adam Heath wrote:
> > On Wed, 14 Nov 2001, Jason Dillon wrote:
> >
> > > What are you talking about? build.sh makes no assumptions about the
> > users
> > > classpath and sets it up c
yOn Wed, 14 Nov 2001, Jason Dillon wrote:
> > On Wed, 14 Nov 2001, Jason Dillon wrote:
> >
> > > What are you talking about? build.sh makes no assumptions about the users
> > > classpath and sets it up correctly to use the jars from tools/lib.
> >
> > There are no jars whatsoever in jboss cvs.
On Wed, 14 Nov 2001, David Budworth wrote:
> Can you put a package in debian main that depends on a non-free software?
No. A package in main can only depend on other packages in main.
A package in contrib can depend on packages in non-free, or software that
doesn't exist in debian at all.
Pac
On Wed, 14 Nov 2001, Jason Dillon wrote:
> Why do you need to know anything about buildmagic to build JBoss? All you
> do is `cvs get jboss-all` and `build/build.sh` that is it. Why would it be
> any different to build a debian package (or any package for that matter).
When making a source pac
On Wed, 14 Nov 2001, Jason Dillon wrote:
> What are you talking about? build.sh makes no assumptions about the users
> classpath and sets it up correctly to use the jars from tools/lib.
There are no jars whatsoever in jboss cvs. Please, don't just assume
something.
> If you are trying to buil
On Wed, 14 Nov 2001, Jason Dillon wrote:
> Use the build.sh script.
That wouldn't help, since there is no planet57 code at all on my system. In
fact, build.sh makes no attempt at finding planet57 code, and assumes it is
just in the classpath.
It also assumes that ant will use $CLASSPATH.
___
On Wed, 14 Nov 2001, Jason Dillon wrote:
> Why do you need a planet57 .deb ?
A package in debian needs to be able to build with software in debian. Since
planet57 does not exist in debian, I'm making a deb of it.
This way, debian/control can contain a Build-Depends on
planet57-buildmagic.deb.
yOn Wed, 14 Nov 2001, Adam Heath wrote:
> adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
> Buildfile: build.xml
> [taskdef] Could not load definitions from resource
>planet57/tools/buildmagic/task/autoload.properties. It could not be found.
>
> BUILD FAILED
>
> /home/
adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
Buildfile: build.xml
[taskdef] Could not load definitions from resource
planet57/tools/buildmagic/task/autoload.properties. It could not be found.
BUILD FAILED
/home/adam/brainfood/jboss/cvs/jboss/build.xml:23: taskdef class
planet57.tools.buildm
yOn Wed, 14 Nov 2001, Jason Dillon wrote:
> Can we automate .deb building with the new build system?
Possibly. The whole point of debian is automation. We have lots of build
daemons setup(for all the architectures we support), that demand this sort of
feature.
I have just checked out the cvs
On Wed, 14 Nov 2001, Jason Dillon wrote:
> > Oh, and if we are talking about performance, I would appreciate everyone
> > being very careful about placing debug statements inside any code that is
> > executed for every message through the system. Several of these have been
> > introduced with th
On Wed, 14 Nov 2001, Scott M Stark wrote:
> Next week.
Ooh! I can't wait.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
On Wed, 14 Nov 2001, Scott M Stark wrote:
> 2.4.x is based on the archaic and fragmented build policy from the
> early days of JBoss and its not likely to change(at least by me).
> The build process has been totally reorganized in the main branch for the
> 3.0 release so focus on getting a source
On Thu, 15 Nov 2001, David Maplesden wrote:
> if(DEBUG) log.debug("a message");
>
> so that we can easily set the flag to false and recompile a higher
> performance version of the engine. With the static flag set to false the
> compiler removes the line completely, so there is no performance hit
On Thu, 15 Nov 2001, David Maplesden wrote:
> You might be jumping the gun a bit with this one. tools.jar is only needed
> afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp pages. Not
> everyone will want this, indeed many people will probably run JBoss without
> a servlet engine,
On Wed, 14 Nov 2001, Scott M Stark wrote:
> Jikes is not a Java program and you have to use a binary suitable for
> the target platform. I'm not interested in getting into supporting mutiple
> platform binaries.
Well, I guess now is as good a time as any to bring up a problem I have with
the cur
touch /var/lib/jboss/deploy/foo.jar
..
[AutoDeployer] Auto deploy of file:/home.local/var/lib/jboss/deploy/foo.jar
[J2EE Deployer Default] Deploy J2EE application:
file:/home.local/var/lib/jboss/deploy/foo.jar
[AutoDeployer] Deployment failed:file:/home.local/var/lib/jboss/deploy/foo.jar
[AutoDe
home.
BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>
yOn Mon, 12 Nov 2001, marc fleury wrote:
> |A coworker just brought up a good point. If we do this, we suddenly become
> |incompatible with other J2EE providers(I do know we don't have to
>
> no we don't
Yes, we do. Something developed for jboss will not run on other providers.
_
yOn Mon, 12 Nov 2001, marc fleury wrote:
> |It is very similar to GLUE
> |(http://www.themindelectric.com/products/glue/glue.html).
>
> there you go, let's do it then...
>
> marcf
A coworker just brought up a good point. If we do this, we suddenly become
incompatible with other J2EE providers(I
101 - 123 of 123 matches
Mail list logo
