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
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
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
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
[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 unn
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
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, bu
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 R
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 Cryptogr
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 bra
[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
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
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
==
[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
===
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 wan
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 l
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 en
[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,
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
[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 dow
[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.
T
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: ou
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 consistenc
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 updat
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
I know. Give me 10 minutes :-)
Costin, this line seems to break the build :-(
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 bro
[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'
27 matches
Mail list logo
