Re: cvs commit: jakarta-tomcat-5 build.xml

2005-09-29 Thread Costin Manolache
BTW - there are still few files missing, but the end result is a 1.2M 
jar containing all deps, that can be run with java -jar and only 
requires a webapps/ dir in the current dir.


Costin

[EMAIL PROTECTED] wrote:

costin  2005/09/28 23:07:24

  Modified:.build.xml
  Log:
  Add a target to build the standalone jar - in case anyone wants to play with 
it.
  
  Revision  ChangesPath

  1.239 +87 -1 jakarta-tomcat-5/build.xml
  
  Index: build.xml

  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.238
  retrieving revision 1.239
  diff -u -r1.238 -r1.239
  --- build.xml 22 Sep 2005 10:39:37 -  1.238
  +++ build.xml 29 Sep 2005 06:07:24 -  1.239
  @@ -192,6 +192,7 @@
  property name=tomcat-util.build value=${tomcat.build} /
  property name=tomcat-util.lib value=${tomcat.build}/server/lib /
   /ant
  +
 /target
   
 target name=build-tomcatjk unless=tomcatjk.build.notrequired 
  @@ -658,7 +659,7 @@

   !-- antcall target=build-commons-modeler / --
   !-- antcall target=build-commons-daemon  / --
   
  -  	antcall target=downloadgz

  +antcall target=downloadgz
 param name=sourcefile value=${commons-collections-src.loc}/
 param name=destfile value=${tomcat-dbcp.jar} /
   /antcall
  @@ -1167,6 +1168,90 @@
   /ant
 /target
   
  +  !-- === Single-jar tomcat === --
  +   target name=prepare-runtime-once 
  + description=Do once before single jar tomcat

  +mkdir dir=runtime/deps /
  +mkdir dir=runtime/classes /
  +unjar dest=runtime/deps 
src=${base.path}/servlet-api-2.4/lib/servlet-api.jar /
  +!-- unjar dest=runtime/deps 
src=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
  +unjar dest=runtime/deps 
src=${base.path}/commons-modeler-1.1/commons-modeler.jar/
  +unjar dest=runtime/deps 
src=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
  +   /target
  +
  +
  +   target name=compile-runtime 
  +   description=Build single jar tomcat
  +  
  +  javac destdir=runtime/classes deprecation=false debug=false  

  +!-- classpath 
path=${base.path}/commons-beanutils-1.6.1/commons-beanutils.jar/ --
  +!-- classpath 
path=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
  +classpath 
path=${base.path}/commons-modeler-1.1/commons-modeler.jar/
  +classpath path=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
  +classpath 
path=${base.path}/servlet-api-2.4/lib/servlet-api.jar/
  +classpath path=${base.path}/jmxri-1.2.1.jar/
  +
  +src
  +pathelement path=${jtc.home}/util/java/  
  +pathelement path=${jtc.home}/mini/java /

  +!-- pathelement path=${jtc.home}/naming/src/ --
  +pathelement path=${jtc.home}/coyote/src/java/
  +pathelement path=${jtc.home}/http11/src/java/
  +pathelement path=${catalina.home}/catalina/src/share/
  +/src
  +exclude name=org/apache/naming/*.java/
  +exclude name=org/apache/naming/ant/**/
  +exclude name=org/apache/tomcat/util/net/puretls/**/
  +exclude 
name=org/apache/tomcat/util/net/jsse/JSSE15SocketFactory.java/
  +exclude 
name=org/apache/tomcat/util/net/jsse/JSSE15Factory.java/
  +exclude name=org/apache/tomcat/util/net/AprEndpoint.java/
  +exclude name=org/apache/coyote/tomcat3/**/
  +exclude name=org/apache/coyote/tomcat4/**/
  +exclude name=org/apache/coyote/memory/**/
  +exclude name=org/apache/coyote/standalone/**/
  +exclude 
name=org/apache/coyote/http11/Http11AprProcessor.java/
  +exclude name=org/apache/coyote/http11/Http11AprProtocol.java/
  +exclude 
name=org/apache/coyote/http11/InternalAprInputBuffer.java/
  +exclude 
name=org/apache/coyote/http11/InternalAprOutputBuffer.java/
  +exclude name=**/CatalinaLaunchFilter.java/
  +exclude name=**/MailSessionFactory.java/
  +exclude name=**/SendMailFactory.java/
  +exclude name=**/SemaphoreValve.java/
  +exclude name=org/apache/catalina/ant/**/
  +exclude name=org/apache/catalina/ssi/**/
  +exclude 
name=org/apache/catalina/loader/CatalinaModuleListener.java/
  +/javac
  +
  +copy todir=runtime/classes 
  +fileset dir=${jtc.home}/util/java includes=**/*.properties 
**/*.xml/
  +fileset dir=${jtc.home}/naming/src includes=**/*.properties 
**/*.xml/
  +fileset dir=${jtc.home}/coyote/src/java includes=**/*.properties 
**/*.xml 
  +  exclude name=org/apache/coyote/tomcat4/**/
  +/fileset
  +fileset 

Re: cvs commit: jakarta-tomcat-5 build.xml

2005-09-22 Thread Mark Thomas

[EMAIL PROTECTED] wrote:

remm2005/09/22 03:39:37

  Modified:.build.xml
  Log:
  - Fix build by excluding tagPlugins.xml.
  - This file shouldn't be in the standard examples, but rather copied there
before precompiling (once it works again, of course).


This should be unnecessary. Bill has already removed the file from SVN.

For the record, all members of the tomcat pmc have karma for all 
modules including the specs. This allows us to fix issues with the 
examples.


Mark



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2005-09-22 Thread Remy Maucherat

Mark Thomas wrote:

[EMAIL PROTECTED] wrote:


remm2005/09/22 03:39:37

  Modified:.build.xml
  Log:
  - Fix build by excluding tagPlugins.xml.
  - This file shouldn't be in the standard examples, but rather copied 
there

before precompiling (once it works again, of course).


This should be unnecessary. Bill has already removed the file from SVN.


Yes, I saw it after my commit, you're completely right. I'm still using 
the CVS repository however, and it doesn't hurt much ;)


Will Yoav tag the CVS or SVN for the upcoming release ?

For the record, all members of the tomcat pmc have karma for all modules 
including the specs. This allows us to fix issues with the examples.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2005-09-22 Thread Yoav Shapira
Hi,

 Will Yoav tag the CVS or SVN for the upcoming release ?

I was going to tag both repositories this one time.

  For the record, all members of the tomcat pmc have karma for all modules 
  including the specs. This allows us to fix issues with the examples.

This is great.

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2005-09-22 Thread Mark Thomas

Yoav Shapira wrote:

Hi,



Will Yoav tag the CVS or SVN for the upcoming release ?



I was going to tag both repositories this one time.


I am 99% sure that you will not be able to tag the CVS repositories 
that have already migrated since they will be locked. This will only 
affect servletapi for TC5.


Mark



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: cvs commit: jakarta-tomcat-5 build.xml

2004-09-15 Thread Shapira, Yoav

Hi,
I think the new version numbering in build.xml is too complicated and
too high maintenance to be worth the small (and at this point purely
theoretical) gains.  I'd be happy going back to simple version is a
string property, without any math or conditionals around it.

Yoav Shapira
Millennium Research Informatics


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 15, 2004 9:06 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-5 build.xml

mturk   2004/09/15 06:05:41

  Modified:.build.xml
  Log:
  Increment build number. Aynone has idea how to automate this?

  Revision  ChangesPath
  1.213 +1 -1  jakarta-tomcat-5/build.xml

  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.212
  retrieving revision 1.213
  diff -u -r1.212 -r1.213
  --- build.xml13 Sep 2004 21:06:29 -  1.212
  +++ build.xml15 Sep 2004 13:05:41 -  1.213
  @@ -18,7 +18,7 @@
 !-- When releasing set the 'version.build' to even number
   and 'version.isdev' to zero.
 --
  -  property name=version.build value=2 /
  +  property name=version.build value=3 /
 property name=version.patch value=0 /
 property name=version.isdev value=1 /





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2004-09-15 Thread Mladen Turk
Shapira, Yoav wrote:
Hi,
I think the new version numbering in build.xml is too complicated and
too high maintenance to be worth the small (and at this point purely
theoretical) gains.  I'd be happy going back to simple version is a
string property, without any math or conditionals around it.
OK, but still you will need to update that, and be limited
to numbers only, cause the installer will break in case of
strings.
I agree that the build.xml is vrong place to maintain versions.
Perhaps to add some property file that will be accessible from
catalina too and give the 'true' version number even from
command line.
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature


RE: cvs commit: jakarta-tomcat-5 build.xml

2004-09-15 Thread Shapira, Yoav

Hi,

OK, but still you will need to update that, and be limited
to numbers only, cause the installer will break in case of
strings.
I agree that the build.xml is vrong place to maintain versions.

Perhaps to add some property file that will be accessible from
catalina too and give the 'true' version number even from
command line.

Can the installer be modified to accept a version string?  The version
usually has periods in it, making it a string and not a number.  I can
also see cases where we'd want -alpha, -beta, -rc as part of the
version.  So I don't like the installer limitation ;)  But I assume
you've looked at the issue and it's not feasible to get around it, so
I/we will just have to live with it.

What I don't understand is why we can't leave the base defaults in
build.xml as they are and just modify them in build.properties (a
private non-CVS file obviously) when I cut a release?  Why must I update
build.xml each time?

Yoav



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml tomcat.nsi

2004-09-02 Thread Mladen Turk
[EMAIL PROTECTED] wrote:
  - Remove useless stuff in installer: tools.jar and the JDK path are now useless.
Does it mean that the classloader is taking care of that?
Does 5_0 branch still needs the tools.jar?
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: cvs commit: jakarta-tomcat-5 build.xml tomcat.nsi

2004-09-02 Thread Remy Maucherat
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
  - Remove useless stuff in installer: tools.jar and the JDK path are 
now useless.

Does it mean that the classloader is taking care of that?
Well, there's a Java compiler bundled, so tools.jar is not needed (and 
Tomcat can now use a JRE).

Does 5_0 branch still needs the tools.jar?
Yes.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml tomcat.nsi

2004-09-02 Thread Mladen Turk
Remy Maucherat wrote:
Does it mean that the classloader is taking care of that?

Well, there's a Java compiler bundled, so tools.jar is not needed (and 
Tomcat can now use a JRE).

Wow, I'll try it then with the fresh 1.5.0-RC released today :).
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: cvs commit: jakarta-tomcat-5 build.xml

2004-03-12 Thread Henri Gomez
[EMAIL PROTECTED] wrote:

remm2004/03/12 06:35:45

  Modified:.build.xml
  Log:
  - Don't bother about the other JMX related binaries.
  
  Revision  ChangesPath
  1.180 +0 -6  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.179
  retrieving revision 1.180
  diff -u -r1.179 -r1.180
  --- build.xml	12 Mar 2004 14:31:24 -	1.179
  +++ build.xml	12 Mar 2004 14:35:45 -	1.180
  @@ -137,12 +137,6 @@
   copy todir=${tomcat.build}/bin 
  file=${commons-logging-api.jar} /
   copy tofile=${tomcat.build}/bin/jmx.jar file=${jmx.jar} /
  -copy tofile=${tomcat.build}/common/lib/jmx-tools.jar 
  -file=${jmx-tools.jar}  failonerror=false /
  -copy tofile=${tomcat.build}/common/lib/jmx-remote.jar 
  -file=${jmx-remote.jar} failonerror=false /
  -copy tofile=${tomcat.build}/common/lib/jmx-remote-tools.jar 
  -file=${jmx-remote-tools.jar} failonerror=false /
   
   copy todir=${tomcat.build}/server/lib file=${commons-modeler.jar} /
We have HTTP and JRMP support in jmx-tools.jar, are you sure we could 
forget to include them ?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2004-03-12 Thread Remy Maucherat
Henri Gomez wrote:
[EMAIL PROTECTED] wrote:

remm2004/03/12 06:35:45

  Modified:.build.xml
  Log:
  - Don't bother about the other JMX related binaries.
Revision  ChangesPath
  1.180 +0 -6  jakarta-tomcat-5/build.xml
Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.179
  retrieving revision 1.180
  diff -u -r1.179 -r1.180
  --- build.xml12 Mar 2004 14:31:24 -1.179
  +++ build.xml12 Mar 2004 14:35:45 -1.180
  @@ -137,12 +137,6 @@
   copy todir=${tomcat.build}/bin   
file=${commons-logging-api.jar} /
   copy tofile=${tomcat.build}/bin/jmx.jar file=${jmx.jar} /
  -copy tofile=${tomcat.build}/common/lib/jmx-tools.jar   
-file=${jmx-tools.jar}  failonerror=false /
  -copy tofile=${tomcat.build}/common/lib/jmx-remote.jar   
-file=${jmx-remote.jar} failonerror=false /
  -copy tofile=${tomcat.build}/common/lib/jmx-remote-tools.jar 
  -file=${jmx-remote-tools.jar} failonerror=false /
  copy todir=${tomcat.build}/server/lib 
file=${commons-modeler.jar} /


We have HTTP and JRMP support in jmx-tools.jar, are you sure we could 
forget to include them ?
I've never actually bundled these binaries (at least, not for a while), 
so there's no change.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2004-03-12 Thread Henri Gomez
Remy Maucherat wrote:

Henri Gomez wrote:

[EMAIL PROTECTED] wrote:

remm2004/03/12 06:35:45

  Modified:.build.xml
  Log:
  - Don't bother about the other JMX related binaries.
Revision  ChangesPath
  1.180 +0 -6  jakarta-tomcat-5/build.xml
Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.179
  retrieving revision 1.180
  diff -u -r1.179 -r1.180
  --- build.xml12 Mar 2004 14:31:24 -1.179
  +++ build.xml12 Mar 2004 14:35:45 -1.180
  @@ -137,12 +137,6 @@
   copy todir=${tomcat.build}/bin   
file=${commons-logging-api.jar} /
   copy tofile=${tomcat.build}/bin/jmx.jar file=${jmx.jar} /
  -copy tofile=${tomcat.build}/common/lib/jmx-tools.jar   
-file=${jmx-tools.jar}  failonerror=false /
  -copy tofile=${tomcat.build}/common/lib/jmx-remote.jar   
-file=${jmx-remote.jar} failonerror=false /
  -copy tofile=${tomcat.build}/common/lib/jmx-remote-tools.jar 
  -file=${jmx-remote-tools.jar} failonerror=false /
  copy todir=${tomcat.build}/server/lib 
file=${commons-modeler.jar} /


We have HTTP and JRMP support in jmx-tools.jar, are you sure we could 
forget to include them ?


I've never actually bundled these binaries (at least, not for a while), 
so there's no change.
Ok, they are needed if you want to use JMX from a JMX console like 
ExtremeJ or MC4J, since they use JRMP.

Just my .2 EUR

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-15 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
costin  2003/03/14 14:42:43

  Modified:.build.xml
  Log:
  Fix Filip's build.
  
  It seems my clean workspace wasn't that clean after all.
  
  This whole thing is unbelievable. I have no idea how we end up with this
  mess.
The build is really complex, so it's normal to run into trouble when you 
refactor it. Plus there are so many dependent components, doing ant 
build is not enough to do a clean build ;-)

BTW, are there any plans to put back a default for base.path ? 
Otherwise, the build instruction on the website are incorrect.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-15 Thread Costin Manolache
Remy Maucherat wrote:

 [EMAIL PROTECTED] wrote:
 costin  2003/03/14 14:42:43
 
   Modified:.build.xml
   Log:
   Fix Filip's build.
   
   It seems my clean workspace wasn't that clean after all.
   
   This whole thing is unbelievable. I have no idea how we end up with
   this mess.
 
 The build is really complex, so it's normal to run into trouble when you
 refactor it. Plus there are so many dependent components, doing ant
 build is not enough to do a clean build ;-)

The purpose of the refactoring was to make it simpler ( or at least
cleaner).

We do have a nice component structure, with only few circular deps ( which
we can someday resolve by moving coyote tomcat5-specific code to catalina ).
The main build file should only call child build files, and we should have
a very consistent layout and features in all components - similar with
jakarta-commons for example.

Each component should support a dist.dir ( unlike servlet/jsp api build
files), should support a build target that only builds the .jar - and 
should use the same patterns for finding the dependencies ( the other
components ).



 BTW, are there any plans to put back a default for base.path ?
 Otherwise, the build instruction on the website are incorrect.

I don't know why it got removed.  I think using /repository is a nice 
idea - and even using repository to build each of our component into.

We should consider each component ( coyote, jasper, jk, util, admin, etc )
as a separate piece - as components in jakarta-commons. 

And the main build script should just be a wrapper to build each component
and assemble the distribution(s).

Again - sorry for causing the pain.

Costin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-15 Thread Remy Maucherat
Costin Manolache wrote:
Remy Maucherat wrote:

The build is really complex, so it's normal to run into trouble when you
refactor it. Plus there are so many dependent components, doing ant
build is not enough to do a clean build ;-)


The purpose of the refactoring was to make it simpler ( or at least
cleaner).
We do have a nice component structure, with only few circular deps ( which
we can someday resolve by moving coyote tomcat5-specific code to catalina ).
The main build file should only call child build files, and we should have
a very consistent layout and features in all components - similar with
jakarta-commons for example.
The biggest problem was commons-el IMO.

Each component should support a dist.dir ( unlike servlet/jsp api build
files), should support a build target that only builds the .jar - and 
should use the same patterns for finding the dependencies ( the other
components ).
No problem with me if you want to do that.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-15 Thread Costin Manolache
Remy Maucherat wrote:

 Each component should support a dist.dir ( unlike servlet/jsp api build
 files), should support a build target that only builds the .jar - and
 should use the same patterns for finding the dependencies ( the other
 components ).
 
 No problem with me if you want to do that.

Gradually. Now the build is stable again - I started to add unless in
javadoc tags so we can avoid it in regular build.

In time I'll try to get all the build files we use to have an set of 
identical targets and behavior, and be able to produce a dist in
repository and use the other dists from the repository.

The repository can be created either by download or by building each
individual component ( assuming we get the order right - that's gump
speciality ), or by using the build.propertes redirection ( should be
renamed repository.properties ) or by gump.

If only gump could generate smaller wrappers we could use...



Costin 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-14 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
costin  2003/03/14 07:28:06

  Modified:.build.xml
  Log:
  Trying to guess what's wrong on Remy's machine.
  
  The APIs are built in download as dependencies, no need to build
  them twice.
I don't know what's wrong. I only tried ant clean, then ant download 
followed by ant.

The base.path is set to your ../repository.

That's it :)

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-14 Thread Costin Manolache
Remy Maucherat wrote:

 [EMAIL PROTECTED] wrote:
 costin  2003/03/14 07:28:06
 
   Modified:.build.xml
   Log:
   Trying to guess what's wrong on Remy's machine.
   
   The APIs are built in download as dependencies, no need to build
   them twice.
 
 I don't know what's wrong. I only tried ant clean, then ant download
 followed by ant.
 
 The base.path is set to your ../repository.
 
 That's it :)

Ant clean; ant update; ant download should work fine.

It's just calling ant dist with dist-dir set to
repository/servlet-api-2.4,  like the other packages.

Ok, I'll remove my repository and try again.

Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-13 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
jfarcand2003/03/13 11:32:56

  Modified:.build.xml
  Log:
  Proper file this time.
Well, the build is still broken for me. commons-logging inists on being 
built in ${tomcat.build} instead of ${tomcat.build}/common/lib and 
${tomcat.build}/server/lib.

What's the point of the updated build ?

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-13 Thread Jeanfrancois Arcand
I know. Give me 10 minutes :-)

Costin, this line seems to break the build :-(

property name=base.path location=../repository /

More to comes...

-- Jeanfrancois





Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

jfarcand2003/03/13 11:32:56

  Modified:.build.xml
  Log:
  Proper file this time.


Well, the build is still broken for me. commons-logging inists on 
being built in ${tomcat.build} instead of ${tomcat.build}/common/lib 
and ${tomcat.build}/server/lib.

What's the point of the updated build ?

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-13 Thread Remy Maucherat
Jeanfrancois Arcand wrote:
I know. Give me 10 minutes :-)
I thought I was the only one having issues ;-)

I can work around it, but now I'm having problem building the modeler's 
HEAD.

 [copy] Copying 1 file to 
L:\home\tomcat-5\repository\commons-modeler-1.1dev\dist

BUILD FAILED
file:L:/home/tomcat-5/repository/commons-modeler-1.1dev/build.xml:229: 
Warning: Could not find file L:\home\tomcat-5\rep
ository\commons-modeler-1.1dev\RELEASE-NOTES**.txt to copy.

Costin, this line seems to break the build :-(

property name=base.path location=../repository /

More to comes...
Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-13 Thread Costin Manolache
Logging: I double fixed it, there was an missmatch with the logging 
build.xml ( I fixed that ), and I also removed the build, logging is 
stable and released.

We should only build the dependencies that are not stable and we may
need to change - el, modeler, daemon.

Regarding modeler: do an update, I checked in the file this morning ( I hope
)

Costin


Remy Maucherat wrote:

 Jeanfrancois Arcand wrote:
 I know. Give me 10 minutes :-)
 
 I thought I was the only one having issues ;-)
 
 I can work around it, but now I'm having problem building the modeler's
 HEAD.
 
   [copy] Copying 1 file to
 L:\home\tomcat-5\repository\commons-modeler-1.1dev\dist
 
 BUILD FAILED
 file:L:/home/tomcat-5/repository/commons-modeler-1.1dev/build.xml:229:
 Warning: Could not find file L:\home\tomcat-5\rep
 ository\commons-modeler-1.1dev\RELEASE-NOTES**.txt to copy.
 
 Costin, this line seems to break the build :-(
 
 property name=base.path location=../repository /
 
 More to comes...
 
 Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-13 Thread Costin Manolache
Remy Maucherat wrote:

 Well, the build is still broken for me. commons-logging inists on being
 built in ${tomcat.build} instead of ${tomcat.build}/common/lib and
 ${tomcat.build}/server/lib.
 
 What's the point of the updated build ?


The point of the updated build is to get some consistency. Some of the
components were built directly, some from j-t-catalina/catalina/build.xml,
files were built in 5 different places and copied over, etc.

Sorry for the breakage - I should have tested it more, I initially hoped
it'll be much smaller.

What we should have is a simpler and more consistent build:

- we download jars for all released components we depend on ( via tar.gz,
from a repository when it'll be available )

- we build all the components that we need to - like our own components 
or the components that are in active development or we don't want to use the
latest stable release ( modeler, el, etc )


Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-13 Thread Jeanfrancois Arcand
Will run the nightly build script and let you know. From my own 
workspace, everythings works fine.

Thanks,

-- Jeanfrancois

[EMAIL PROTECTED] wrote:

costin  2003/03/13 14:08:22

 Modified:.build.xml
 Log:
 Another try, I hope this clarifies things.
 
 We have 2 kinds of code: our code ( tomcat, jk, jasper ) and dependent code.
 
 There are 2 kinds of dependent code: released and unreleased.
 
 The download target will get the released versions, and will build the unreleased
 code.
 Gump will do the same thing - so we only have to deal with our own code.
 
 Since all our code is in modules, probably we can clean this up a bit more,
 but now it should work.
 
 Please let me know if you still have problems.
 
 Revision  ChangesPath
 1.105 +23 -33jakarta-tomcat-5/build.xml
 
 Index: build.xml
 ===
 RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
 retrieving revision 1.104
 retrieving revision 1.105
 diff -u -r1.104 -r1.105
 --- build.xml	13 Mar 2003 21:13:16 -	1.104
 +++ build.xml	13 Mar 2003 22:08:21 -	1.105
 @@ -49,6 +49,7 @@
property name=servlet.home value=../jakarta-servletapi-5/jsr154/dist/
property name=jsp.home value=../jakarta-servletapi-5/jsr152/dist/
property name=tomcat.build value=${basedir}/build/
 +  property name=build.home   value=${tomcat.build}/
property name=servletapi.jar   value=${tomcat.build}/common/lib/servlet-api.jar/
property name=jspapi.jar   value=${tomcat.build}/common/lib/jsp-api.jar/
property name=tomcat.dist  value=${basedir}/dist/
 @@ -83,9 +84,6 @@
  mkdir dir=${tomcat.build}/server/lib /
  mkdir dir=${tomcat.build}/common/lib /
  
 -copy todir=${tomcat.build}/common/lib file=${commons-logging-api.jar} /
 -copy todir=${tomcat.build}/server/lib file=${commons-logging.jar} /
 -
  uptodate property=servletapi.build.notrequired
targetfile=${servletapi.jar}
srcfiles dir=${api.home}/jsr154/src includes=** /
 @@ -125,8 +123,11 @@
  
  
!-- == DEPLOY: Copy Static Files === --
 -  target name=deploy-static depends=init/
 -
 +  target name=deploy-static depends=init
 +copy todir=${tomcat.build}/common/lib file=${commons-logging-api.jar} /
 +copy todir=${tomcat.build}/server/lib file=${commons-logging.jar} /
 +copy todir=${tomcat.build}/server/lib file=${commons-modeler.jar} /
 +  /target
  
!-- == Build all components === --
target name=build-servletapi unless=servletapi.build.notrequired 
 @@ -440,28 +441,30 @@
target name=build-commons-modeler unless=commons-modeler.build.notrequired 
  echo== Building: commons-modeler /echo
  
 -ant dir=${cvs.base}/jakarta-commons/modeler target=jar 
 +ant dir=${cvs.base}/jakarta-commons/modeler target=dist 
 +property name=dist.home location=${commons-modeler.home} /
  property name=commons-logging.jar location=${commons-logging.jar} /
 -property name=commons-modeler.jar location=${tomcat.build}/server/lib/commons-modeler.jar /
  property name=jmx.jar location=${jmx.jar} /
  property name=commons-digester.jar location=${commons-digester.jar} /
  property name=build.home value=${tomcat.build} /
  /ant
/target
  
 +
target name=build-commons-el unless=commons-el.build.notrequired 
  echo== Building: commons-el /echo
  
 -ant dir=${cvs.base}/jakarta-commons/el target=jar-only 
 +ant dir=${cvs.base}/jakarta-commons/el target=dist 
  property name=servlet-api.jar location=${servlet-api.jar} /
  property name=commons-el.jar location=${tomcat.build}/common/lib/commons-el.jar /
  property name=jsp-api.jar value=${jspapi.jar}/
  property name=compile.optimize value=false /
 +property name=dist.home value=commons-el.home /
  property name=build.home value=${tomcat.build} /
  /ant
/target
  
 -  target name=build-all depends=init,build-depends,build,build-webapps,embed/
 +  target name=build-all depends=init,deploy-static,build,build-webapps,embed/
  
  
target name=build-depends depends=init
 @@ -475,10 +478,17 @@
srcfiles dir=${cvs.base}/jakarta-commons/el/src/java includes=** /
  /uptodate
  
 -antcall target=build-commons-modeler /
  antcall target=build-servletapi/
  antcall target=build-jspapi/
 +
  antcall target=build-commons-el /
 +antcall target=build-commons-modeler /
 +
 +antcall target=cvsbuild
 +  param name=location value=${commons-daemon.cvs.loc}/
 +  param name=subdir value=${commons-daemon.home}/
 +  param name=destfile value=${commons-daemon.jar}/
 +/antcall
  
/target
  
 @@ -1316,12 +1326,6 @@
param name=destdir value=${base.path}/
  /antcall
  
 -antcall target=cvsbuild
 -  param name=location 

Re: cvs commit: jakarta-tomcat-5 build.xml

2003-03-13 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
costin  2003/03/13 14:08:22

  Modified:.build.xml
  Log:
  Another try, I hope this clarifies things.
  
  We have 2 kinds of code: our code ( tomcat, jk, jasper ) and dependent code.
  
  There are 2 kinds of dependent code: released and unreleased.
  
  The download target will get the released versions, and will build the unreleased
  code.
  Gump will do the same thing - so we only have to deal with our own code.
  
  Since all our code is in modules, probably we can clean this up a bit more,
  but now it should work.
  
  Please let me know if you still have problems.
I get that now:

BUILD FAILED
file:L:/home/tomcat-5/jakarta-tomcat-catalina/webapps/docs/build.xml:99: 
L:\home\tomcat-5\jakarta-tomcat-connectors\coyo
te\build\docs not found.

Sorry for the trouble ;-)

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]