You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Nick Bauman <ni...@cortexity.com> on 2000/11/04 05:52:13 UTC
[BUG TRACKING] searches re-enabled
Hello Jakarta-ers
Thanks to some sharp thinking by Ignacio Ortega, I have converted the
horrible sql BugRat originally used for searching with some better
code.
Suffice it to say, the original query would return in about 25
minutes. Ortega's code with the same data would returns in about 10
seconds. So what's that, an improvement of 150x?
Hopefully with this kind of person on our side, Tomcat will eventually
serve pages in the user's past.
So happy searching!
--
Nicolaus Bauman
http://znutar.cortexity.com
nick@cortexity.com
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Pier P. Fumagalli" wrote:
>
> So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were
> already voted upon with a bunch of +1s)...
>
> 1) Release Tomcat 3.2 final (soon, please!)
+1
> 2) Create a new proposal tree alongside with Catalina (new name to avoid
> confusion, please)
+0
> 3) Release Tomcat 4.0 (with Catalina, as we all decided)
+1
> 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
> proposal comes along.
>
-1, way too early to consider this
Get the Tomcat 4.0 Apache mod_warp connector committed.
+1, ;-)
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
cmanolache@yahoo.com wrote:
> What about this:
>
> - I start a new revolution in tomcat3.2 space ( proposals/something ),
> and all the implementation of 2.3 and all controversial stuff will go
> there ( i.e. all new features, like dav, http1.1, resource caching, the
> new SMTP and POP3 protocols - since any feature will be in fact just an
> interceptor plus the implementation itself )
>
+1
>
> - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3
> will continue to be servlet2.2/jsp1.1, etc
-0
I'm establishment now :-). I only care about 3.2 and 4.0, because they
are the plan of record at the moment.
And on 3.3, Costin can fix his own bugs :-)
>
> If the "revolution" rules still apply ( and I hope this is the case),
> there is no "vote" or procedure for revolutions, and any developer is free
> to work on whatever he likes. My preference is ( as you know ) to continue
> with the current stable codebase.
yep -- revolution rules still apply.
I do want to see one other tangible result. It would be useful if 3.2
could be returned to the main branch after you've moved the things you
want to keep. That will be much less confusing for people using
anonymous CVS, especially after 3.2 is released.
>
> That will be ( hopefully ) the last time we have this problem - I don't
> think we'll need any core change after 3.3 ( the code is very small now,
> and almost all work is delegated to modules - so it's very little that may
> change ). After that we can follow the 3.3.1, etc - again, only bug fixes.
>
> IMHO it's a decent proposal - I'll try to think of a name ( or names ) for
> the new "module-revolutions" - and everyone should be happy ( with some
> bad memories, maybe ). That will also allow to take more agressive steps
> in improving tomcat3 ( since the "revolution" branch will be less visible
> and the pressure will be lower ).
>
> It's cool to be revolutionar ( even if I still believe evolution is the
> way to go).
>
It definitely has its moments ;-)
>
> Costin
Craig
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by sa...@totalsync.com.
>> > - I start a new revolution in tomcat3.2 space ( proposals/something
>> > ), and all the implementation of 2.3 and all controversial stuff
>> > will go there ( i.e. all new features, like dav, http1.1, resource
>> > caching, the new SMTP and POP3 protocols - since any feature will be
>> > in fact just an interceptor plus the implementation itself )
>>
>> Okay, if you feel strongly about not working with the Tomcat 4.x code
>> base. This revolution branch would, however, not change the decision
>> to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest
>> it could be considered would be for the next version of the specs.
>
> Well, if it's a revolution it can implement anything - including 2.3.
> It's not going to be the "RI", of course. Again, support for 2.3 is
> just an independent module that doesn't have to be included in the
> default distribution.
>
Excellent. I think everyone is now on the same page, and that is great.
Costin, the ideas you have for all different types of modules are great,
and I think you need to be the revolutionary behind them. FWIW, for POP
and SMTP, you might want to check out some of the JAMES code, if you
haven't already.
I am personally not against having another choice. As a user, I just code
to the servlet spec, and then use the container that works the best for the
deployment environment (Resin, Tomcat 3.2, Tomcat 4.0, Costin's proposal,
JRun, blah blah blah). From another perspective, we may just see a little
competition in the performance arena, and I think everyone will win with
that.
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by cm...@yahoo.com.
> > - I start a new revolution in tomcat3.2 space ( proposals/something ),
> > and all the implementation of 2.3 and all controversial stuff will go
> > there ( i.e. all new features, like dav, http1.1, resource caching, the
> > new SMTP and POP3 protocols - since any feature will be in fact just an
> > interceptor plus the implementation itself )
>
> Okay, if you feel strongly about not working with the Tomcat 4.x code
> base. This revolution branch would, however, not change the decision
> to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest
> it could be considered would be for the next version of the specs.
Well, if it's a revolution it can implement anything - including 2.3. It's
not going to be the "RI", of course. Again, support for 2.3 is just an
independent module that doesn't have to be included in the default
distribution.
Costin
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
cmanolache@yahoo.com wrote:
>
> What about this:
>
> - I start a new revolution in tomcat3.2 space ( proposals/something ),
> and all the implementation of 2.3 and all controversial stuff will go
> there ( i.e. all new features, like dav, http1.1, resource caching, the
> new SMTP and POP3 protocols - since any feature will be in fact just an
> interceptor plus the implementation itself )
Okay, if you feel strongly about not working with the Tomcat 4.x code
base. This revolution branch would, however, not change the decision
to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest
it could be considered would be for the next version of the specs.
> - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3
> will continue to be servlet2.2/jsp1.1, etc
Agree.
> If the "revolution" rules still apply ( and I hope this is the case),
> there is no "vote" or procedure for revolutions, and any developer is free
> to work on whatever he likes. My preference is ( as you know ) to continue
> with the current stable codebase.
I've noticed ;-) I'm okay with another revolution branch, as long as we're
clear about which spec versions Tomcat 3.x and Tomcat 4.x supports.
> [...]
> It's cool to be revolutionar ( even if I still believe evolution is the
> way to go).
Sometimes evolution just doesn't work ;-) Anyway, if this makes everyone
happy, I'm all for it.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
cmanolache@yahoo.com <cm...@yahoo.com> wrote:
>
> What about this:
>
> - I start a new revolution in tomcat3.2 space ( proposals/something ),
> and all the implementation of 2.3 and all controversial stuff will go
> there ( i.e. all new features, like dav, http1.1, resource caching, the
> new SMTP and POP3 protocols - since any feature will be in fact just an
> interceptor plus the implementation itself )
>
> - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3
> will continue to be servlet2.2/jsp1.1, etc
>
> If the "revolution" rules still apply ( and I hope this is the case),
> there is no "vote" or procedure for revolutions, and any developer is free
> to work on whatever he likes. My preference is ( as you know ) to continue
> with the current stable codebase.
>
> That will be ( hopefully ) the last time we have this problem - I don't
> think we'll need any core change after 3.3 ( the code is very small now,
> and almost all work is delegated to modules - so it's very little that may
> change ). After that we can follow the 3.3.1, etc - again, only bug fixes.
>
> IMHO it's a decent proposal - I'll try to think of a name ( or names ) for
> the new "module-revolutions" - and everyone should be happy ( with some
> bad memories, maybe ). That will also allow to take more agressive steps
> in improving tomcat3 ( since the "revolution" branch will be less visible
> and the pressure will be lower ).
>
> It's cool to be revolutionar ( even if I still believe evolution is the
> way to go).
I like it... It is what I was asking since the beginning.
The ASF, as a member of the JCP (the only NON COMPANY member of the JCP, I
would like to underline), needs to ship the reference implementation of
Servlet 2.3 and Java Server Pages 1.2. This, as decided, will be Tomcat 4.0,
based on Catalina and Jasper.
If you and others want to continue the evolutionary process,
re-revolutioning (I like this phrase :) go ahead, and do it as Craig did for
Catalina.
And I'm the most open person to consider a "new" codebase as the next-next
generation of the Apache Servlet Engine...
Deal :)
Pier
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by cm...@yahoo.com.
What about this:
- I start a new revolution in tomcat3.2 space ( proposals/something ),
and all the implementation of 2.3 and all controversial stuff will go
there ( i.e. all new features, like dav, http1.1, resource caching, the
new SMTP and POP3 protocols - since any feature will be in fact just an
interceptor plus the implementation itself )
- in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3
will continue to be servlet2.2/jsp1.1, etc
If the "revolution" rules still apply ( and I hope this is the case),
there is no "vote" or procedure for revolutions, and any developer is free
to work on whatever he likes. My preference is ( as you know ) to continue
with the current stable codebase.
That will be ( hopefully ) the last time we have this problem - I don't
think we'll need any core change after 3.3 ( the code is very small now,
and almost all work is delegated to modules - so it's very little that may
change ). After that we can follow the 3.3.1, etc - again, only bug fixes.
IMHO it's a decent proposal - I'll try to think of a name ( or names ) for
the new "module-revolutions" - and everyone should be happy ( with some
bad memories, maybe ). That will also allow to take more agressive steps
in improving tomcat3 ( since the "revolution" branch will be less visible
and the pressure will be lower ).
It's cool to be revolutionar ( even if I still believe evolution is the
way to go).
Costin
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Pier P. Fumagalli" wrote:
>
> Hans Bergsten <ha...@gefionsoftware.com> wrote:
>
> > "Pier P. Fumagalli" wrote:
> >>
> >> Sorry for starting what it might end up as a long flamewar, but reading
> >> almost 500 emails on the list I ended up a little confused... Also, in a
> >> bunch of side discussions, but related always to the same topic, I feel
> >> there's something wrong going around here...
> >
> > Thanks Pier for bringing this issue to a vote. Based on the other replies
> > to this mail, it seems to me like the majority wants Tomcat 3.x to be the
> > RI for Servlet 2.2/JSP 1.1, with production quality of course, and
> > Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense
> > to me. The devil may be in the details, but I hope we can make it so.
>
> James might be an "instigator", but I'm for sure _THE_ "troublemaker" :) :)
> I fully agree with you on that. Let me explain better my position:
;-)
> I have NOTHING against a Tomcat 3.3 release, if we want to call it 3.3. The
> thing I am against is having two different releases of "Tomcat" (3.3 and
> 4.0) having the same features and capabilities...
We're in total agreement on this.
> [...]
> Servlet 2.0? Apache JServ (Actually, we might end up moving it to Jakarta as
> an "historic" piece of code when Java.Apache.ORG dies)
>
> Servlet 2.1? (fuck, we don't have it, any volunteer?)
>
> Servlet 2.2/JSP 1.1? Tomcat 3.x (3.2, 3.3, 3.4, 3.5 and so on, as long as
> there's people willing to deveop it)
>
> Servlet 2.3/JSP 1.2? Tomcat 4.x
>
> Servlet NEXT? When they come out, we'll see what we have in our hands and
> we'll decide....
>
> This _IS_ clear....
Right.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by cm...@yahoo.com.
> I think the Resources stuff are at the right spot in the architecture :
> hidden behind the ServletContext, so that the data they abstract is
> availible to any servlet.
The Resource stuff is fine ( I would liked a JNDI Context more as an
abstraction, but it's just my taste, I like Resource too ).
The only question is if it have to be part of the container ( i.e. any
container that supports webdav must be based on this interfaces ) - and I
think that's a very limitting requirement.
Or it is part of webdav app ( what I did when I ported it to tomcat3 ),
and the container doesn't have to do nothing ( if using file-based
webapps, which is still the most common thing ) or provide some attributes
with the "base" and "repository type" - or something similar ( i.e. light
enough for any container to support it without changing it's architecture
to catalina )
> > You are the main author and you can of course decide if you want it to be
> > used only with catalina or if other servlet containers are allowed to use
> > it.
>
> Lol. How can I do that with the APL ?? Hey Craig, let's write a Catalina
> Public Licence to address that ;)
>
> Seriously, I encourage anyone to reuse the code, but I just wanted to expose
> here the few reasons why that particular component is "tied" to Catalina.
Then why all this noise and screams I hear when I just tried to take
Apache code, in my free time, and reuse it in tomcat3?
One hour after I do that everyone is flaming me and asks me to go to
sourceforge and stop using the name "tomcat" and so on and so on ??
> I guess we could vote on the subject, but if we leave it in, we'd have to
> provide support / fixes for that within the 3.x branch, which could be a
> problem since nobody's actually taking care of that right now (except
> Craig).
??????
I am working on the 3.x branch for about a year and made clear many times
that I'll continue to work on it for a while. At least until it's the
fastest and most secure servlet container ( we are close, but not there ).
I see there is a lot of interest in killing 3.x and making it "EOL", but
unless the Apache licence was changed overnight it will be difficult to do
that.
Tomcat3.2 was ready months ago, but everyone kept fixing non-critical bugs
that should have gone into 3.3 ( the development branch after the
rules). I started working on the 3.3 as soon as 3.2 was "freezed" and
Larry, Nacho and few other took care of checking in the patches and
waiting for a release. There are some issues that can't be resolve in a
"freezed" code, but only in the a development branch.
I'm working on few major things I announced, and my time is right now
_very_ limitted, I do have a job ( that is not "tomcat" ) and I have few
terrible deadlines, so forgive me for working on what I feel is more
important ( and again, 3.2 should have been released long ago and any
putback and non-critical fix is just delaying that even longer ! ).
With all this I take many hours of my free time and keep working on
tomcat3.3:
- performance improvements ( all the things that we couldn't put into 3.2
because they were too "dangerous" and we needed more time testing them )
( you can measure them )
- Using MessageBytes instead of Strings ( very important for performance,
but also to finally fix the "encoding bug )
- Fixing the class loader interceptor to support multiple operating modes
( including the one used in Catalina )
- remove all deprecated methods, finish cleaning up the core
- adding back JspInterceptor ( you can measure the improvement in jsp
execution )
- support "jikes" compiler ( you can measure the improvement in jsp
compilation time !)
- refactoring of connectors to have access to the full Interceptor API,
better configuration for interceptors ( no longer need "<property>" ).
- ( the recent ) webdav port, started support for resource caching ( will
be another performance and architecture enhancement for 3.x, reusing
apache code!)
- modularization, to allow people ( is it only me ???? ) to support
multiple facades. The servlet2.2 facade is in a bad shape and should be
rewritten, and we can do that while maintaining stability by following the
same evolutionary aproach - make it a module and replace it with something
better.
That also allows a nice "revolution" that will provide the 2.3 facade
without creating a new codebase or diverting from the 3.3 core, but as a
simple module.
Besides that, all the fixes from 3.2 must be integrated in, and some of
the good code from catalina should be ported ( http1.1, webdav, mod_warp
when ready ) - as long as they keep apache license and they are not glued
in. They are nice features and any user should benefit of them, without
having to change the container architecture.
Does it look like the 3.x branch is dead and nobody but Craig "is taking
care of it" ????
Costin
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Remy Maucherat <re...@apache.org>.
> > - If it was possible to avoid code duplication for as many components as
> > possible it would be great ;) Fixes / improvements are really hard to
merge
> > otherwise. Since I think the main point of disagreement is the servlet
> > engine core, that should be doable.
>
> That's what I think too - if you are referring to webdav, all I did was
> make it work with tomcat3.
Catalina's DefaultServlet and WebdavServlet are only tied to Catalina's
extended ServletContext. Basically, we're doing all resource access
operations through it, in an abstracted way; however, since there are no
write / dir browse operations in the servlet context yet, we had to extend
it.
I think the Resources stuff are at the right spot in the architecture :
hidden behind the ServletContext, so that the data they abstract is
availible to any servlet.
> I don't think that's wrong - it is great code and it should be portable.
That's not wrong (that's right, actually ;)), but I don't see how it can be
portable except by either :
- Using java.io.File, and don't care about abstraction.
- Using an abstraction layer which is put underneath the servlet. That's
exactly what I'm doing in Slide, actually, and it's portable (JDK 1.1 /
Servlet 2.2) and everything.
> You are the main author and you can of course decide if you want it to be
> used only with catalina or if other servlet containers are allowed to use
> it.
Lol. How can I do that with the APL ?? Hey Craig, let's write a Catalina
Public Licence to address that ;)
Seriously, I encourage anyone to reuse the code, but I just wanted to expose
here the few reasons why that particular component is "tied" to Catalina.
Some other people have also expressed that it wasn't a good idea to add such
a big chunk of code into the 3.x codebase.
> ( of course, I'll have to track whatever happens in the main repositroy
> and keep the ported webdav up to date, or you may want to take some of the
> changes and make it an independent module, as it should be IMHO. )
>
> I don't know if "people don't want this kind of features in 3.x " - so
> I'll remove it from the main 3.x tree and make it a revolution ( move it
> to proposals), so nobody can complain about it and anyone who's
> interested can use it. From my point of view it's great code and it would
> be great to have it available in 3.3.
I guess we could vote on the subject, but if we leave it in, we'd have to
provide support / fixes for that within the 3.x branch, which could be a
problem since nobody's actually taking care of that right now (except
Craig).
Remy
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by cm...@yahoo.com.
> > Servlet2.0 -> Tocmat3.3
> > Servlet2.1 -> Tomcat3.3
> > Servlet2.2 -> Tomcat3.3
> > Servlet2.3 -> Tomcat3.3
> > Servlet.next -> Tomcat3.3
>
> I don't agree.
> Having :
> Servlet2.0 -> TocmatNext
> Servlet2.1 -> TomcatNext
> Servlet2.2 -> TomcatNext
> Servlet2.3 -> TomcatNext
> Servlet.next -> TomcatNext
> is very fine.
>
> I don't think people want anything but bug fixes (and perhaps a few more
> features) for Tomcat 3.2 and eventually 3.3.
I wish to be able to know what people want, but I agree with you on this
one - I'll do whatever I can to make sure 3.3 is the last major
( ok, dot.dot ) revision based on tomcat3.
I think tomcat3.3's core is reasonably clean and reflects all the original
design patterns, and it is flexible enough that it'll need only minor
fixes in the core.
All future versions of the spec can be implemented as modules by whoever
is interested - and people can decide what they want and will use that.
> I think that would be the best. Now, a few points :
> - The main branch in the jakarta-tomcat tree is broken, and is also a bug
> mess right now. I think it needs to be fixed so that it complies more with
> the objectives set for TC3.3.
Yes, there is one big fix that got in recently, needed to support "delayed
byte to char conversion", needed to fix the charset encoding problem ( one
of the biggest problems of tomcat 3.2 and before AFAIK, and I personally
don't know a better solution )
The fix is also very important for performance.
There are a number of bugs introduced in JSP by moving to JspInterceptor -
this can be reverted, but I think it's very important to do it right this
time, as the speed difference is very significant.
There are probably other bugs introduced between 3.2 and 3.3 - most of the
old deprecated methods ( deprecated since 3.1 !) were finally removed, and
also some changes to improve the modularity of 3.3 ( needed if we want 3.3
to be the last one - since almost everything can be done now in modules,
and almost nothing is in the 3.3 core )
I think it's important to finish with the big changes ( since those add
the most of the refactoring bugs), and after that start fixing.
I'll start doing that ASAP.
> - If it was possible to avoid code duplication for as many components as
> possible it would be great ;) Fixes / improvements are really hard to merge
> otherwise. Since I think the main point of disagreement is the servlet
> engine core, that should be doable.
That's what I think too - if you are referring to webdav, all I did was
make it work with tomcat3. I don't think that's wrong - it is great code
and it should be portable.
You are the main author and you can of course decide if you want it to be
used only with catalina or if other servlet containers are allowed to use
it.
( of course, I'll have to track whatever happens in the main repositroy
and keep the ported webdav up to date, or you may want to take some of the
changes and make it an independent module, as it should be IMHO. )
I don't know if "people don't want this kind of features in 3.x " - so
I'll remove it from the main 3.x tree and make it a revolution ( move it
to proposals), so nobody can complain about it and anyone who's
interested can use it. From my point of view it's great code and it would
be great to have it available in 3.3.
Costin
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Remy Maucherat <re...@apache.org>.
----- Original Message -----
From: <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Saturday, November 04, 2000 4:27 PM
Subject: Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
> And why not:
>
> Servlet2.0 -> Tocmat3.3
> Servlet2.1 -> Tomcat3.3
> Servlet2.2 -> Tomcat3.3
> Servlet2.3 -> Tomcat3.3
> Servlet.next -> Tomcat3.3
I don't agree.
Having :
Servlet2.0 -> TocmatNext
Servlet2.1 -> TomcatNext
Servlet2.2 -> TomcatNext
Servlet2.3 -> TomcatNext
Servlet.next -> TomcatNext
is very fine.
I don't think people want anything but bug fixes (and perhaps a few more
features) for Tomcat 3.2 and eventually 3.3.
> And even:
> "I have old servlet2.2 apps, and some new servlet3.0 apps, and there are
> some incompatibilities between 3.0 servlet API and 2.2, what can I do
> ? " -> Tomcat3.3
>
> Anyway, I'll be more than happy to remove the 2.3 facade from tomcat2.2 if
> that it's your concern.
>
> But I don't think you can stop me ( or someone else ) from implementing a
> 3.x Interceptor that plugs in a 2.3 ( or Servlet.Next ) into tomcat.
>
> If the rules for "revolution" are still accepted, I'll do that in a
> /proposal tree, if not - I'll do it on my home page. I think it's the
> right thing to do, instead of rewriting everything again and again.
I think that would be the best. Now, a few points :
- The main branch in the jakarta-tomcat tree is broken, and is also a bug
mess right now. I think it needs to be fixed so that it complies more with
the objectives set for TC3.3.
- If it was possible to avoid code duplication for as many components as
possible it would be great ;) Fixes / improvements are really hard to merge
otherwise. Since I think the main point of disagreement is the servlet
engine core, that should be doable.
> That's the main issue here, and that's what I think it's wrong in your
> table - the code should be reusable, and supporting multiple facades is
> not only easy, but it's important for future.
Remy
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by cm...@yahoo.com.
> Servlet 2.0? Apache JServ (Actually, we might end up moving it to Jakarta as
> an "historic" piece of code when Java.Apache.ORG dies)
>
> Servlet 2.1? (fuck, we don't have it, any volunteer?)
>
> Servlet 2.2/JSP 1.1? Tomcat 3.x (3.2, 3.3, 3.4, 3.5 and so on, as long as
> there's people willing to deveop it)
>
> Servlet 2.3/JSP 1.2? Tomcat 4.x
>
> Servlet NEXT? When they come out, we'll see what we have in our hands and
> we'll decide....
And why not:
Servlet2.0 -> Tocmat3.3
Servlet2.1 -> Tomcat3.3
Servlet2.2 -> Tomcat3.3
Servlet2.3 -> Tomcat3.3
Servlet.next -> Tomcat3.3
And even:
"I have old servlet2.2 apps, and some new servlet3.0 apps, and there are
some incompatibilities between 3.0 servlet API and 2.2, what can I do
? " -> Tomcat3.3
Anyway, I'll be more than happy to remove the 2.3 facade from tomcat2.2 if
that it's your concern.
But I don't think you can stop me ( or someone else ) from implementing a
3.x Interceptor that plugs in a 2.3 ( or Servlet.Next ) into tomcat.
If the rules for "revolution" are still accepted, I'll do that in a
/proposal tree, if not - I'll do it on my home page. I think it's the
right thing to do, instead of rewriting everything again and again.
That's the main issue here, and that's what I think it's wrong in your
table - the code should be reusable, and supporting multiple facades is
not only easy, but it's important for future.
Costin
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Hans Bergsten <ha...@gefionsoftware.com> wrote:
> "Pier P. Fumagalli" wrote:
>>
>> Sorry for starting what it might end up as a long flamewar, but reading
>> almost 500 emails on the list I ended up a little confused... Also, in a
>> bunch of side discussions, but related always to the same topic, I feel
>> there's something wrong going around here...
>
> Thanks Pier for bringing this issue to a vote. Based on the other replies
> to this mail, it seems to me like the majority wants Tomcat 3.x to be the
> RI for Servlet 2.2/JSP 1.1, with production quality of course, and
> Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense
> to me. The devil may be in the details, but I hope we can make it so.
James might be an "instigator", but I'm for sure _THE_ "troublemaker" :) :)
I fully agree with you on that. Let me explain better my position:
I have NOTHING against a Tomcat 3.3 release, if we want to call it 3.3. The
thing I am against is having two different releases of "Tomcat" (3.3 and
4.0) having the same features and capabilities...
I don't want to kill the 3.x tree, nor to abandon it, but I want to see, as
you clearly said 3.x being a 2.2 servlet engine, and tomcat 4.0 being a 2.3
one.
And why is that? Because when people come to http://jakarta.apache.org/ they
have to clearly see what we're doing and decide based on their needs.
Servlet 2.0? Apache JServ (Actually, we might end up moving it to Jakarta as
an "historic" piece of code when Java.Apache.ORG dies)
Servlet 2.1? (fuck, we don't have it, any volunteer?)
Servlet 2.2/JSP 1.1? Tomcat 3.x (3.2, 3.3, 3.4, 3.5 and so on, as long as
there's people willing to deveop it)
Servlet 2.3/JSP 1.2? Tomcat 4.x
Servlet NEXT? When they come out, we'll see what we have in our hands and
we'll decide....
This _IS_ clear....
Pier
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Pier P. Fumagalli" wrote:
>
> Sorry for starting what it might end up as a long flamewar, but reading
> almost 500 emails on the list I ended up a little confused... Also, in a
> bunch of side discussions, but related always to the same topic, I feel
> there's something wrong going around here...
Thanks Pier for bringing this issue to a vote. Based on the other replies
to this mail, it seems to me like the majority wants Tomcat 3.x to be the
RI for Servlet 2.2/JSP 1.1, with production quality of course, and
Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense
to me. The devil may be in the details, but I hope we can make it so.
> [...]
> So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were
> already voted upon with a bunch of +1s)...
>
> 1) Release Tomcat 3.2 final (soon, please!)
+1000.
Sam promised a release candidate a couple of weeks back, but it didn't
happen (I'm sure for a good reason). If Sam doesn't have the time to do
this now, maybe someone else who's familiar with the release procedures
can step up to the task?
When the release candidate is available, we should make sure it's tested
quickly (I promise to do so with a number of JSP applications I have handy).
Only serious regression bugs should be allowed to force another candidate
cycle.
For the future, I suggest we document the release procedures and put them
in CVS so it's easier for someone to help out with this if the appointed
release manager can't do it for any reason.
> 2) Create a new proposal tree alongside with Catalina (new name to avoid
> confusion, please)
-1, two code bases is more than enough ;-)
If we can agree that Tomcat 3.x is the RI for Servlet 2.2/JSP 1.1 *only*, it
makes sense for this code base to continue for bug fixes and improvements
that are in support of these spec versions. I would have preferred to call
these releases 3.2.1, 3.2.2 etc. instead of 3.3, but it's not all that
important.
Costin, Larry and others have put a lot of effort into 3.3, and even though
I have not tested it yet myself, based on comments from others it's much
better than 3.2 so lets take advantage of all that hard work and make
sure it's released as the next 2.2/1.1 RI instead of hiding it in a new
proposal branch.
> 3) Release Tomcat 4.0 (with Catalina, as we all decided)
+1, but this will take some time since the new specs will not be final
until next year, likely Q2.
> 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
> proposal comes along.
-1, let's focus on 3.x and 4.x for now.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Remy Maucherat <re...@apache.org> wrote:
> Pier P. Fumagalli <pi...@betaversion.org> wrote:
>>
>> So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were
>> already voted upon with a bunch of +1s)...
>>
>> 1) Release Tomcat 3.2 final (soon, please!)
>
> +1.
>
>> 2) Create a new proposal tree alongside with Catalina (new name to avoid
>> confusion, please)
>
> +1.
>
>> 3) Release Tomcat 4.0 (with Catalina, as we all decided)
>
> +1.
>
>> 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
>> proposal comes along.
>
> -1. At least wait until 4.0 is realeased ;)
Yes... Those items were in chronological order (once completed the
preceding, do the following...)
Pier
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Remy Maucherat <re...@apache.org>.
> Sorry for starting what it might end up as a long flamewar, but reading
> almost 500 emails on the list I ended up a little confused... Also, in a
> bunch of side discussions, but related always to the same topic, I feel
> there's something wrong going around here...
>
> Question: WHAT THE HACK IS TOMCAT 3.3 ???
Lol.
> I believe that this developer community once agreed that Tomcat 4.0
> _will_be_ the next major release of the Apache Software Foundation servlet
> engine, but, since a couple of weeks, I see a proliferation of emails
> talking about Tomcat 3.3.
>
> Here is where I'm getting confused... When did we vote about having a dual
> codebase for two different servlet engines at the same time??? Because
I've
> never seen such a discussion taking place...
I think what was voted was that the old repository will still be there for
providing support for existing users (bug fixes ...) while Tomcat 4 matures
a little bit.
> The "Rules for Evolution and Revolutions" still stands still, as one of
the
> major constitution documents for this community (James, WTF, post it
> somewhere!!! :) and IMNSHO needs to be used...
>
> I suggest to whoever is interested in further developement of the 3.3 tree
> to create a new proposal, as Craig did with Catalina, and stick it on the
> "proposals" directory in the CVS. And start working from it. I'm more than
> open to see, after Tomcat 4.0 sees light, to reconsider the effort, and
> maybe switching codebase again for what will be Tomcat 5.0.
>
> So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were
> already voted upon with a bunch of +1s)...
>
> 1) Release Tomcat 3.2 final (soon, please!)
+1.
> 2) Create a new proposal tree alongside with Catalina (new name to avoid
> confusion, please)
+1.
> 3) Release Tomcat 4.0 (with Catalina, as we all decided)
+1.
> 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
> proposal comes along.
-1. At least wait until 4.0 is realeased ;)
> My 0.02 $... Take care...
Remy
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Rob S." <rs...@home.com>.
Some non-committer 2c here from me. Both of these things...
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Nick Bauman <ni...@cortexity.com>.
On Fri, 3 Nov 2000, Pier P. Fumagalli wrote:
> Sorry for starting what it might end up as a long flamewar, but reading
> almost 500 emails on the list I ended up a little confused... Also, in a
> bunch of side discussions, but related always to the same topic, I feel
> there's something wrong going around here...
>
> Question: WHAT THE HACK IS TOMCAT 3.3 ???
I'm not disagreeing with you Pier, but I will say I believe that there are
2 possible ways to interpret the current situation, and I do not think
I'm the only one who thinks this.
1) The fact that there are smart software developers out there
contributing to Tomcat 3.x codebase and not necessarily contributing to
the 4.0 codebase is a failure of the Jakarta Apache community to obtain
sufficient buy-in from those people. The division of resources in this
situation is what should be avoided at all cost, because this is the one
major limitation OSS has: division of finite resources within a community
because of forking. I would assume one of ASF goals is to prevent this.
2) Or alternatively, anything beyond Tomcat 3.1 refects that Tomcat 3.1 is
a "rolling beta", which means the "code-train" is in such bad shape that
the developers are throwing track in front of it as it moves forward. Not
a good thing.
Or maybe we have a combination between the two. At any rate, ASF should
rule clearly whether to let the code-train of 3.x roll off the track,
whether to let it continue to roll on track but away from it's auspices,
or to support the two code bases as is.
By doing nothing ASF implicitly supports the latter, which is
counterintuive to ASF's entire raison d'etre.
my $0.02
-Nick
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by cm...@yahoo.com.
Sorry Pier, but I don't think I'm doing anything wrong.
I worked ( pretty hard ) on the last year or so on tomcat. I worked (
pretty hard ) convincing other people to contribute.
Tomcat 3.1 is better that tomcat 3.0 ( or the old JWSDK ). Tomcat 3.2 ( as
it was few months ago ) is better than tomcat3.1. It's not perfect - but
it's better. There are fundamental problems ( that are present in other
containers as well, even worse !), and 3.3 is going to fix them.
I don't care how it'll be called, or where it'll stay ( an Apache
Fundation member asked me to go to SourceForge and stop using the name
"tomcat" - and Pier is asking me to make it a "revolution" and change the
name to something else, as Tomcat is no longer correct ).
The fundamental problems are:
- can't support charset detection ( i.e. the encoding of the URI )
- there is a limit on performance because of excessive use of Strings
- the code still need improvements in the modular structure.
I have no idea why tomcat 3.2 hasn't been released - it's not my
decision. As far as I'm concerned 3.2 is over ( for me ) - it's a step
forward, but (as 3.1 ) it isn't perfect. I don't know any "critical" bug
in 3.2 that wasn't in 3.1 also.
Regarding the "confusion" of using "tomcat" ( i.e. 2 different
codebases with the same name ) - well, I don't quite understand how it is
my fault, but I'm going to work on the current (
"evolutionary" ) codebase, whatever you decide to call it.
If mighty Apache Members or PMC decide to ban this project, or to change
it's name - so be it. You can also revoke my account on locus - feel free
to do it, it seems my presence there is less and less wanted.
As long as my account still works ( and I'm still a commiter ), I'll
continue to work as before - if the code I commit is buggy, please -1 it.
I don't think I need a vote to add new features to tomcat 3.3 ( that
are present in catalina ) - after all none of that was "proposed" or
"voted" on the other codebase.
Regarding the implementation of Servlet2.3 and JSP1.2 - I'm curious to see
how will you "spin" this, but I think it's important to support the latest
specs, and tomcat3 was designed with "facades" from beginning - ask Duncan
why.
To conclude ( I hope my last mail on this topic ) - I think tomcat3 is
very good container, has a very good desing, and I don't think
Apache "politics" and Apache hierarchies can stop good code for beeing
developed.
Costin
P.S.
I am not allowed to say anything about tomcat 4.0 or catalina, but I do
hope that open source magic will work and people will compare the 2
architectures and decide what works better.
Documentation Progress
Posted by "Rob S." <rs...@home.com>.
Hi all, me again =)
The last time we spoke about this, beta 6 was about to be built. Mike
Bremford made some schmokin' changes to the mod_jk HOWTO, both of us to the
Apache HOWTO and the index page (User's Guide updates were in-progress).
There was some confusion w/the tree between Alex and Larry, and I think
(???) that was sorted out. The confusion is really why I stopped working on
the docs, because I had no clue what was going on and didn't really want to
get involved with school starting and whatnot.
Now that it's been about a month from that, and 3.2 still isn't released,
would anyone mind matching 3.2's branch up with the MAIN branch (docs only
of course) so there can be a single set of docs and I can get back to work?
Apologies in advance for my horrible CVS-speak, I'll learn it one of these
days =) It would mean that the online docs would refer to things not yet
working in 3.1, but they already do, and people shouldn't be using it
anyways <shrug>
Also, once this is done, is there some way to do this?
/tomcat/docs/ --> Tomcat CVS /docs
So the latest docs are always online? Maybe this is what's being done
already? I don't think the community is helped by having new, relevant
documentation buried at the bottom of some tree. Also, having me write
some, then send to Larry who has to back-edit them to fit into the 3.2 tree
probably isn't the best idea since there's a duplication of work and I'm
sure Larry and everyone else, prefer that he cut Java ;)
To add to this mess, I'm not sure what to do w.r.t. Catalina!
Goal: to help the jakarta-tomcat project as much as I can with docs (for
now!). How do I do that?
- r
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Rob S." <rs...@home.com>.
> Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3,
> expecially before 3.2 final is out of the door. The NEXT major release is
> going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago.
The impression I got from reading the dev list was that 4.x was where
everyone was going to be focussing, one 3.x was in a rockin' good state.
Isn't that what happened to JServ? I thought the JServ page said something
like, "JServ is only bug fixes from now on - go get Tomcat" ? I can't find
where I read that now, so maybe I didn't, but I sure thought I did ;)
Also, whatever the result of this discussion, we should most definitely have
Pier's stuff on the main page (jakarta home and Tomcat home). From an,
"I've never seen Tomcat before" being faced with two downloads, which one
would you grab, seeing 3.1, 3.2b6 and 4.0M4 available? Maybe 3.2b6 if
you're familiar with the software development process. It can confuse
people who want to contribute as well.
Who is the webmaster for jakarta? The project is very much alive and
kicking, but there hasn't been a news update since July! I wouldn't say
there there's no news considering the PHP home page <ducking =)> has updates
when new betas are released. Maybe the main page should be a combined
news/description page like the Java-Apache home. The list of products on
the right with a description and release number? That's hella cool!
- r
Re: Ant rant
Posted by Glenn Vanderburg <gl...@delphis.com>.
Bob Jamison <rj...@lincom-asg.com> writes:
>
> I can think of one major thing that restricts the use of Make on Java.
> The wizards at Sun, when they implemented inner classes, decided
> to use $ as the class name separator, like
> MyClass$SomeThread.class
> (why, O why, not % or @ or something else! ;-( )
Because those characters aren't legal in class and method names in the
VM spec. Changing the VM spec wasn't an option; if inner classes
required a new VM, they simply wouldn't have succeeded. '$' is legal
in class and method names, but the language spec has always stated
that it should only be used in mechanically generated source code.
So '$' was really the only character they could've used.
--
Glenn Vanderburg
Delphi Consultants, LLC
glv@delphis.com
Re: Ant rant
Posted by Bob Jamison <rj...@lincom-asg.com>.
Nick Bauman wrote:
> Question: WHAT THE HECK IS ANT?
>
> Now I know what ant is, I'm just hyperbolizing. But...
>
> It's just that I got the entire Tomcat 3.1 tree to compile with a single
> Makefile in around 10 minutes. I can't figure out what Ant is helping this
> project with. Maybe I'm just stupid or something but this Ant thing
> doesn't really impress me very much. Make is very stable, very cross
> platform; I just don't see what's so cool about ant.
>
> Why is ant better than Make?
>
> And don't say "ant is cross platform, make is not" because that just isn't
> true. Was someone just bored with the wheel and wanted to reinvent it?
>
I can think of one major thing that restricts the use of Make on Java.
The wizards at Sun, when they implemented inner classes, decided
to use $ as the class name separator, like
MyClass$SomeThread.class
(why, O why, not % or @ or something else! ;-( )
Make just -freaks- on $ when doing dependencies. In makefiles,
I had to hardcode every name with a $ in it with single quotes, in
order to prevent Make from attempting name substitution.
Another problem with using Make, is not make itself, but Javac.
Previously , and I think it has been fixed now, javac did
not return a true/false properly, so Make did not know when to stop.
Also, javac did not do a thorough enough dependency check.
Bob
Re: Ant rant
Posted by Michael Stanley <st...@paragon.ecs.syr.edu>.
> And don't say "ant is cross platform, make is not" because that just isn't
> true. Was someone just bored with the wheel and wanted to reinvent it?
Ant is more than a cross platform make utility. Ant is platform independent,
which means alot more than cross platform. Ant is a make utility geared to meet
the needs of Java. Java is "Write once run anywhere" and so is Ant. It is also
specifically made to meet the build requirements of Java code, capable of
anything from creating Jars to Javadocs. Its very easy to learn and its high
modularity makes it very easy to expand.
Ant also goes further than make by adapting to XML for data representation and I
assume there is no need for me to go into the benefits of that :)
My 2 cents
Michael Stanley
Re: Ant rant
Posted by person <mb...@pleiades.ca>.
yarrrr
see below
The memory management on PowerPC can be used to frighten small children.
-- Linus Torvalds
On Sun, 12 Nov 2000, Nick Bauman wrote:
> On Sun, 12 Nov 2000, Craig R. McClanahan wrote:
{snip}
>
> I'll take "doesn't pay the rent to know that" as probably the bottom line
> answer, and I'll agree. Has anyone gotten Jikes to work with ant?
I have
just wrapping in a shell script is what I do
java -Dbuild.compiler=jikes org.apache.ant.Main -f build.xml
or did you mean _compiling_ ant with jikes? that I've never tried
Micah Blake McCurdy
Re: Ant rant
Posted by Nick Bauman <ni...@cortexity.com>.
On Sun, 12 Nov 2000, Craig R. McClanahan wrote:
> One interesting note about your rant is that the only people who care
> about Ant in the first place are those trying to build Tomcat from
> source
> (or want to use it for their own development). If you just need a
> binary build of Tomcat (which is definitely the majority case), Ant is
> irrelevant.
True, except that to get mod_jserv (or mod_jk) to play nice with _my_
wierd apache installation I wanted to accomplish a fresh build of
everything.
> (And the particular classpath error that bit you would have shown up
> with a makefile too :-)
Again, you're right.
> Another note is a voice of personal experience. I've been doing
> primarily Java development for the last four years, and (until Ant came
> along) creating Make files that knew how to deal with Java's package
> structure correctly was always painful and error-prone. The arcane
> syntax and all the "magical" behavior is, quite frankly, a real pain.
> And it was never easy to port from the idiosyncracies of one "make" to
> another. Sure, I could have invested the time to become a "make maven",
> but expertise in this area doesn't pay the rent -- getting programs
> completed does.
I'll take "doesn't pay the rent to know that" as probably the bottom line
answer, and I'll agree. Has anyone gotten Jikes to work with ant?
> Autoconf? Well, the whole reason that autoconf exists is to make the
> fact that platforms are not compatible less painful -- but well designed
> Java
> programs don't suffer much from that. The fact that Ant runs out of the
> box on any platform with a JVM -- without having any configuration other
> than getting the classpath right -- tells me that tools like autoconf
> are no longer relevant to my life. Good riddance to them ... :-)
>
> A final note -- an increasing number of the Java based open source
> projects I'm familiar with, including many outside *.apache.org, have
> adopted Ant as their portable build tool. So I'm clearly not the only
> one who feels this way.
>
Re: Ant rant
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Nick Bauman wrote:
>
> I have all kinds of problems using new versions of Tomcat (and someone
> said that they are suprised at how few people try the milestone builds /
> betas) and many of them come from problems with Ant. So I think Ant is
> actually _preventing_ people from getting the most out of Tomcat. (just an
> opinion: no flame intended!)
Your comment prompted me to do a quick check of the download counts for
the latest betas and milestones:
Tomcat 3.2-b7 (posted last night):
Binary distribution: 434 successful downloads
Source distribution: 114 successful downloads
(These numbers will undoubtedly climb rapidly
since this is basically only people paying attention
on a weekend.)
Tomcat 4.0-m4 (posted 11/1/2000):
Binary distribution: 2922 successful downloads
Source distribution: 533 successful downloads
In addition, there are also an unknown number of people keeping up to
date via anonymous CVS and/or nightly builds.
(Ant 1.2 binaries have been downloaded 7,563 times since they were
posted 10/25/2000.)
> Many many programs that use autoconf are out there in OSS. I feel like we
> aren't leveraging our own past.
One interesting note about your rant is that the only people who care
about Ant in the first place are those trying to build Tomcat from
source
(or want to use it for their own development). If you just need a
binary build of Tomcat (which is definitely the majority case), Ant is
irrelevant.
(And the particular classpath error that bit you would have shown up
with a makefile too :-)
Another note is a voice of personal experience. I've been doing
primarily Java development for the last four years, and (until Ant came
along) creating Make files that knew how to deal with Java's package
structure correctly was always painful and error-prone. The arcane
syntax and all the "magical" behavior is, quite frankly, a real pain.
And it was never easy to port from the idiosyncracies of one "make" to
another. Sure, I could have invested the time to become a "make maven",
but expertise in this area doesn't pay the rent -- getting programs
completed does.
Autoconf? Well, the whole reason that autoconf exists is to make the
fact that platforms are not compatible less painful -- but well designed
Java
programs don't suffer much from that. The fact that Ant runs out of the
box on any platform with a JVM -- without having any configuration other
than getting the classpath right -- tells me that tools like autoconf
are no longer relevant to my life. Good riddance to them ... :-)
A final note -- an increasing number of the Java based open source
projects I'm familiar with, including many outside *.apache.org, have
adopted Ant as their portable build tool. So I'm clearly not the only
one who feels this way.
>
> > My 2 cents
> > Michael Stanley
> >
>
> And only mine as well, summarized by "Stand on The Shoulders of Giants"
>
I am. I hope that I will never ever have to write another makefile or
set up another config script. Thank you Ant developers!
>
> Nick
Craig McClanahan
Re: Make rant
Posted by Matthew Dornquast <ma...@webhelp.com>.
Hi Roy!
>> If someone can provide a link to something like "Make for Dummies" I'd
appreciate it.
You betcha, and fyi-- this format is VERY similar to the make file Nick
Bauman, myself and others use at our place of employment. (Some might say
better!?)
At the very least, it's well documented.
http://geosoft.no/javamake.html
enjoy.
-Matthew
PS>I've been resisting the temptation to get involved on the ant rant
thread, but this link might suggest I'm a Make fan.
PPS> I'm not.
Clarification
Posted by Roy Wilson <de...@bellatlantic.net>.
Nick,
"Toy" was referring to size of the makefile, not it's usefulness. Thanks
to Matthew for the link.
Roy
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 11/13/00, 6:31:13 PM, Nick Bauman <ni...@cortexity.com> wrote regarding
Re: Thanks for the make links and a rant:
> On Mon, 13 Nov 2000, Roy Wilson wrote:
> > Nick,
> >
> > I agree that your example is simple. Even I can understand and create
> > such "toy" makefile. What I am complaining about is getting
> Not a toy. Really works.
> By the way, Matthew, my boss, sent this earlier but it somehow never made
> it to the list:
> ------------MATTHEW------------
> Hi Roy!
> >
> > If someone can provide a link to something like "Make for Dummies" I'd
> > appreciate it.
> >
> You betcha, and fyi-- this format is VERY similar to the make file Nick
> Bauman, myself and others use at our place of employment. (Some might
> say better!?)
> At the very least, it's well documented.
> http://geosoft.no/javamake.html
> enjoy.
> -Matthew
> PS>I've been resisting the temptation to get involved on the ant rant
> thread, but this link might suggest I'm a Make fan.
> PPS> I'm not.
> ------------MATTHEW------------
> > evil/nasty/nested makefiles that don't work (unlike the MAKE_CONF
> > experience you've had) and having to understand all [exaggeration] of it
> > to find the presumably few line(s) that must be changed.
> If you don't know make, this will happen. Same with Ant. =)
> > I assume you're referring to Nash the game theorist. Back before WWII and
> > after, von Neumann (a founder of the discipline of computing) applied
> > functional analysis as developed by Banach to problems of mathematical
> > physics and economics. I didn't know that Nash used functional analysis
> > in game theory. Thanks for the opportunity to rant :-).
> Well, Nash is purported to have solved the embedding theorem and was
> working on a general theorem on turbulance before he lost his mind (maybe
> he was writing Makefiles when he snapped. I rememeber it was either
> Makefiles or Fermat's Last Theorem, I don't recall exactly, gah!)
> > Roy
> >
> > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> >
> > On 11/13/00, 5:58:34 PM, Nick Bauman <ni...@cortexity.com> wrote regarding
> > Re: Thanks for the make links and a rant:
> >
> >
> > <snip>
> >
> > > The makefile I used to compile Tomcat is thus:
> >
> > > ---------8<----------
> > > # Keep track of the package name
> > > PACKAGE=org.apache
> >
> > > # Keep track of the package version
> > > VERSION=3_2
> >
> > > # where the maketools be
> > > MAKE_CONF=./maketools
> >
> > > include $(MAKE_CONF)/config.mk
> > > include $(MAKE_CONF)/rules.mk
> > > ---------8<----------
> >
> > > Can it be any simpler?
> >
> > > Now I know that there is a lot of magic in the MAKE_CONF, but then you
> > > don't have to worry about that. It just works.
> >
> > > On Mon, 13 Nov 2000, Roy Wilson wrote:
> >
> > > > Nick,
> > > >
> > > > I have a copy of the FSF make manual: As our president used to say "I
> > > > recur to my former statement [about make documentation]." :-) I'll have
> > > > to check out the O'Reilly reference. See my rant below.
> > > >
> > > > Roy
> > > >
> >
> > > --
> > > Nicolaus Bauman
> > > Software Engineer
> > > Simplexity Systems
> >
> >
> >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> --
> Nicolaus Bauman
> Software Engineer
> Simplexity Systems
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Thanks for the make links and a rant
Posted by Nick Bauman <ni...@cortexity.com>.
On Mon, 13 Nov 2000, Roy Wilson wrote:
> Nick,
>
> I agree that your example is simple. Even I can understand and create
> such "toy" makefile. What I am complaining about is getting
Not a toy. Really works.
By the way, Matthew, my boss, sent this earlier but it somehow never made
it to the list:
------------MATTHEW------------
Hi Roy!
>
> If someone can provide a link to something like "Make for Dummies" I'd
> appreciate it.
>
You betcha, and fyi-- this format is VERY similar to the make file Nick
Bauman, myself and others use at our place of employment. (Some might
say better!?)
At the very least, it's well documented.
http://geosoft.no/javamake.html
enjoy.
-Matthew
PS>I've been resisting the temptation to get involved on the ant rant
thread, but this link might suggest I'm a Make fan.
PPS> I'm not.
------------MATTHEW------------
> evil/nasty/nested makefiles that don't work (unlike the MAKE_CONF
> experience you've had) and having to understand all [exaggeration] of it
> to find the presumably few line(s) that must be changed.
If you don't know make, this will happen. Same with Ant. =)
> I assume you're referring to Nash the game theorist. Back before WWII and
> after, von Neumann (a founder of the discipline of computing) applied
> functional analysis as developed by Banach to problems of mathematical
> physics and economics. I didn't know that Nash used functional analysis
> in game theory. Thanks for the opportunity to rant :-).
Well, Nash is purported to have solved the embedding theorem and was
working on a general theorem on turbulance before he lost his mind (maybe
he was writing Makefiles when he snapped. I rememeber it was either
Makefiles or Fermat's Last Theorem, I don't recall exactly, gah!)
> Roy
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 11/13/00, 5:58:34 PM, Nick Bauman <ni...@cortexity.com> wrote regarding
> Re: Thanks for the make links and a rant:
>
>
> <snip>
>
> > The makefile I used to compile Tomcat is thus:
>
> > ---------8<----------
> > # Keep track of the package name
> > PACKAGE=org.apache
>
> > # Keep track of the package version
> > VERSION=3_2
>
> > # where the maketools be
> > MAKE_CONF=./maketools
>
> > include $(MAKE_CONF)/config.mk
> > include $(MAKE_CONF)/rules.mk
> > ---------8<----------
>
> > Can it be any simpler?
>
> > Now I know that there is a lot of magic in the MAKE_CONF, but then you
> > don't have to worry about that. It just works.
>
> > On Mon, 13 Nov 2000, Roy Wilson wrote:
>
> > > Nick,
> > >
> > > I have a copy of the FSF make manual: As our president used to say "I
> > > recur to my former statement [about make documentation]." :-) I'll have
> > > to check out the O'Reilly reference. See my rant below.
> > >
> > > Roy
> > >
>
> > --
> > Nicolaus Bauman
> > Software Engineer
> > Simplexity Systems
>
>
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
Re: Thanks for the make links and a rant
Posted by Roy Wilson <de...@bellatlantic.net>.
Nick,
I agree that your example is simple. Even I can understand and create
such "toy" makefile. What I am complaining about is getting
evil/nasty/nested makefiles that don't work (unlike the MAKE_CONF
experience you've had) and having to understand all [exaggeration] of it
to find the presumably few line(s) that must be changed.
I assume you're referring to Nash the game theorist. Back before WWII and
after, von Neumann (a founder of the discipline of computing) applied
functional analysis as developed by Banach to problems of mathematical
physics and economics. I didn't know that Nash used functional analysis
in game theory. Thanks for the opportunity to rant :-).
Roy
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 11/13/00, 5:58:34 PM, Nick Bauman <ni...@cortexity.com> wrote regarding
Re: Thanks for the make links and a rant:
<snip>
> The makefile I used to compile Tomcat is thus:
> ---------8<----------
> # Keep track of the package name
> PACKAGE=org.apache
> # Keep track of the package version
> VERSION=3_2
> # where the maketools be
> MAKE_CONF=./maketools
> include $(MAKE_CONF)/config.mk
> include $(MAKE_CONF)/rules.mk
> ---------8<----------
> Can it be any simpler?
> Now I know that there is a lot of magic in the MAKE_CONF, but then you
> don't have to worry about that. It just works.
> On Mon, 13 Nov 2000, Roy Wilson wrote:
> > Nick,
> >
> > I have a copy of the FSF make manual: As our president used to say "I
> > recur to my former statement [about make documentation]." :-) I'll have
> > to check out the O'Reilly reference. See my rant below.
> >
> > Roy
> >
> --
> Nicolaus Bauman
> Software Engineer
> Simplexity Systems
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Thanks for the make links and a rant
Posted by Nick Bauman <ni...@cortexity.com>.
Roy,
Having just read a biography of John Forbes Nash, I have but a wisp of
understanding of what a Banach space is.
However, you echo what I already said. Make is unlike any other tool in
the unix world. I think you could write a white paper on this,
seriously; like, entitled "where the hell did Make come from?" because
it's actually an example of how diverse a genius (or sadist,
depending on your prespective. I prefer the former) RMS is. It
resembles, at times, treatise on lingusitics. But I digress.
The makefile I used to compile Tomcat is thus:
---------8<----------
# Keep track of the package name
PACKAGE=org.apache
# Keep track of the package version
VERSION=3_2
# where the maketools be
MAKE_CONF=./maketools
include $(MAKE_CONF)/config.mk
include $(MAKE_CONF)/rules.mk
---------8<----------
Can it be any simpler?
Now I know that there is a lot of magic in the MAKE_CONF, but then you
don't have to worry about that. It just works.
On Mon, 13 Nov 2000, Roy Wilson wrote:
> Nick,
>
> I have a copy of the FSF make manual: As our president used to say "I
> recur to my former statement [about make documentation]." :-) I'll have
> to check out the O'Reilly reference. See my rant below.
>
> Roy
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
Thanks for the make links and a rant
Posted by Roy Wilson <de...@bellatlantic.net>.
Nick,
I have a copy of the FSF make manual: As our president used to say "I
recur to my former statement [about make documentation]." :-) I'll have
to check out the O'Reilly reference. See my rant below.
Roy
--
Roy Wilson
E-mail: designrw@bellatlantic.net
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
<snip>
> http://www.gnu.org/manual/make/index.html
> It's not really that hard.
<snip>
Nothing is THAT hard once you have a context for new knowledge. For
example, once you know what a Banach space is (a normed linear space), it
is not THAT hard to understand what a Hilbert space is (a normed linear
space endowed with an inner product). Now you know what a Hilbert space
is, right? I don't take any pride in my "explanation" precisely because
it assumes knowledge that few non/new mathematicians have. If you have
that knowledge, I offer my congratulations/condolences. :-)
To begin to understand in a practical/computational way (yes, Dorothy,
economists and physicists do digital computation in Banach and Hilbert
space) the "explanation" I gave, however, you need to have worked with
simple abstract spaces like the vector space built on top of the set of
all continuous functions on the unit interval. Each continuous function
is like a point: You then define a distance function, consider sequences
of functions/points, convergence, topological completeness, etc. I would
only say that such work is not that HARD for those who already have the
context. My point was that most make documents I had seen seemed to
presuppose that I had that kind of contextual knowledge.
> But ant is much less opaque, to be sure. I think this is important and
the
> ant developers should be proud of this accomplishment.
> --
> Nicolaus Bauman
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Make rant
Posted by Nick Bauman <ni...@cortexity.com>.
On Mon, 13 Nov 2000, Roy Wilson wrote:
> I've struggled to find what was for me a useable tutorial on make, but
> did not succeed. Most seem to have been written by experts too close to
> their subject. If someone can provide a link to something like "Make for
> Dummies" I'd appreciate it. Having constructed abstract Turing Machines
> to do arithmetic, read and written technical papers, I'd like to think
> the problem is more than brain-death on my part. :-)
http://www.gnu.org/manual/make/index.html
It's not really that hard. At first glance a Makefile resembles
nothing else in Unix, it's not a shell, it's not a programming
language, and I think that's what puts people off of Make.
But ant is much less opaque, to be sure. I think this is important and the
ant developers should be proud of this accomplishment.
--
Nicolaus Bauman
Make rant
Posted by Roy Wilson <de...@bellatlantic.net>.
FWIW,
I've been unable to set up cross-compilers and other things because I
couldn't get enough knowledge to sort out the nested make files that
appear to have been written for a particular configuration (which was not
mine).
I've struggled to find what was for me a useable tutorial on make, but
did not succeed. Most seem to have been written by experts too close to
their subject. If someone can provide a link to something like "Make for
Dummies" I'd appreciate it. Having constructed abstract Turing Machines
to do arithmetic, read and written technical papers, I'd like to think
the problem is more than brain-death on my part. :-)
Roy
--
Roy Wilson
E-mail: designrw@bellatlantic.net
RE: Ant rant
Posted by James Cook <ji...@iname.com>.
Just thought I would throw in the most important factor to me....ANT is
extensible in a very straightforward, comprehensible and resuable manner.
jim
-----Original Message-----
From: Nick Bauman [mailto:nick@cortexity.com]
Sent: Sunday, November 12, 2000 9:39 PM
To: tomcat-dev@jakarta.apache.org
Subject: RE: Ant rant
"These kids today and their 'ant's! What's the world coming to?" But I'll
agree, and _is_ more intuitive and elegant than Make. But I put them at
about equal in difficulty in learning curve.
BTW, for those who are interested, I've asked our CTO if I can release the
maketools I used to compile Tomcat.
Now, about my broken Tomcat 3.2b7 build...
On Sun, 12 Nov 2000, person wrote:
> I'm another young developer, in the sense that I'm inexperienced - my
> first projects have been started about 8-9 months ago. I was faced with
> the choice of either learning ant or learning make, the two build systems
> available to me that I knew of. I expended a few hour of effort on each,
> and it's quite conclusive for me: ant is far and a way the more intuitive,
> elegant tool of the two. I grew up in OO concepts, it just feels like ant
> is a natural fit with java. Also, I seem to remember something on the ant
> page itself about why it was written instead of the author just using
> make. http://jakarta.apache.org/ant/, that's it.
>
> I give +1 for ant because of the learning curve involved, esp. when
> attracting new developers, considering that tomcat is likely to live a
> long lifetime and will likely (hopefully) see many new hands helping out.
>
> Micah Blake McCurdy
>
> The memory management on PowerPC can be used to frighten small children.
>
> -- Linus Torvalds
>
> On Sun, 12 Nov 2000, Rob S. wrote:
>
> > Allow me to insert my Java / *nix developer
novice-compared-to-people-here
> > 2c =)
> >
> > I've only been paid to write Java code for 6 months as a co-op. There
were
> > 10+ developers at the company, and only one of them understood
makefiles.
> > That one person wrote and maintained a number of makefiles, and it
really
> > came down to not being "worth it" for the rest of us to understand the
> > Makefile format. Why? When the files were there and working and
everyone
> > was happy.
> >
> > With Ant, I was able to accomplish the same thing, and fully understand
the
> > "whys" and "hows" of everything that was going on, in about 10 minutes
(with
> > the help of the ant docs and examples of course) and as many lines of
XML.
> >
> > I've always considered it peripheral to getting "real work" done, so I
don't
> > wish to devote much brain power to it. Call me lazy, but that's just
the
> > way I am ;) I actually have dreaded having to learn the Makefile format
for
> > my personal projects and when I got a hold of Ant, I was very relieved!
> >
> > - r
> >
> > p.s. i don't mean to trivialize the Makefile stuff. It's funky!
> >
> > > -----Original Message-----
> > > From: Nick Bauman [mailto:nick@cortexity.com]
> > > Sent: November 12, 2000 5:11 PM
> > > To: tomcat-dev@jakarta.apache.org; stanley@paragon.ecs.syr.edu
> > > Subject: Re: Ant rant
> > >
> > >
> > > On Sun, 12 Nov 2000, Michael Stanley wrote:
> > >
> > > > > And don't say "ant is cross platform, make is not" because
> > > that just isn't
> > > > > true. Was someone just bored with the wheel and wanted to reinvent
it?
> > > >
> > > > Ant is more than a cross platform make utility. Ant is
> > > platform independent,
> > > > which means alot more than cross platform. Ant is a make
> > > utility geared to meeet
> > > > the needs of Java. Java is "Write once run anywhere" and so
> > > is Ant. It is also
> > > > specifically made to meet the build requirements of Java code,
> > > capable of
> > > > anything from creating Jars to Javadocs. Its very easy to
> > > learn and its high
> > > > modularity makes it very easy to expand.
> > >
> > > I guess this is an important distinction to some people. I'm not a
> > > purist; the JVM is written in C, so none of us can claim to be purists
;)
> > >
> > > > Ant also goes further than make by adapting to XML for data
> > > representation and I
> > > > assume there is no need for me to go into the benefits of that :)
> > >
> > > Once again, standard data representation as opposed to
problem-specific
> > > data representation is an important distinction to some people.
> > >
> > > What would really be nice would be if there were some kind or
translator
> > > that could convert a GNU Makefile into Ant build script and vice
versa. Is
> > > this on the radar screen Ant devleopers?
> > >
> > > I have all kinds of problems using new versions of Tomcat (and someone
> > > said that they are suprised at how few people try the milestone builds
/
> > > betas) and many of them come from problems with Ant. So I think Ant is
> > > actually _preventing_ people from getting the most out of Tomcat.
(just an
> > > opinion: no flame intended!)
> > >
> > > Many many programs that use autoconf are out there in OSS. I feel like
we
> > > aren't leveraging our own past.
> > >
> > > > My 2 cents
> > > > Michael Stanley
> > > >
> > >
> > > And only mine as well, summarized by "Stand on The Shoulders of
Giants"
> > >
> > > Nick
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Ant rant
Posted by Nick Bauman <ni...@cortexity.com>.
"These kids today and their 'ant's! What's the world coming to?" But I'll
agree, and _is_ more intuitive and elegant than Make. But I put them at
about equal in difficulty in learning curve.
BTW, for those who are interested, I've asked our CTO if I can release the
maketools I used to compile Tomcat.
Now, about my broken Tomcat 3.2b7 build...
On Sun, 12 Nov 2000, person wrote:
> I'm another young developer, in the sense that I'm inexperienced - my
> first projects have been started about 8-9 months ago. I was faced with
> the choice of either learning ant or learning make, the two build systems
> available to me that I knew of. I expended a few hour of effort on each,
> and it's quite conclusive for me: ant is far and a way the more intuitive,
> elegant tool of the two. I grew up in OO concepts, it just feels like ant
> is a natural fit with java. Also, I seem to remember something on the ant
> page itself about why it was written instead of the author just using
> make. http://jakarta.apache.org/ant/, that's it.
>
> I give +1 for ant because of the learning curve involved, esp. when
> attracting new developers, considering that tomcat is likely to live a
> long lifetime and will likely (hopefully) see many new hands helping out.
>
> Micah Blake McCurdy
>
> The memory management on PowerPC can be used to frighten small children.
>
> -- Linus Torvalds
>
> On Sun, 12 Nov 2000, Rob S. wrote:
>
> > Allow me to insert my Java / *nix developer novice-compared-to-people-here
> > 2c =)
> >
> > I've only been paid to write Java code for 6 months as a co-op. There were
> > 10+ developers at the company, and only one of them understood makefiles.
> > That one person wrote and maintained a number of makefiles, and it really
> > came down to not being "worth it" for the rest of us to understand the
> > Makefile format. Why? When the files were there and working and everyone
> > was happy.
> >
> > With Ant, I was able to accomplish the same thing, and fully understand the
> > "whys" and "hows" of everything that was going on, in about 10 minutes (with
> > the help of the ant docs and examples of course) and as many lines of XML.
> >
> > I've always considered it peripheral to getting "real work" done, so I don't
> > wish to devote much brain power to it. Call me lazy, but that's just the
> > way I am ;) I actually have dreaded having to learn the Makefile format for
> > my personal projects and when I got a hold of Ant, I was very relieved!
> >
> > - r
> >
> > p.s. i don't mean to trivialize the Makefile stuff. It's funky!
> >
> > > -----Original Message-----
> > > From: Nick Bauman [mailto:nick@cortexity.com]
> > > Sent: November 12, 2000 5:11 PM
> > > To: tomcat-dev@jakarta.apache.org; stanley@paragon.ecs.syr.edu
> > > Subject: Re: Ant rant
> > >
> > >
> > > On Sun, 12 Nov 2000, Michael Stanley wrote:
> > >
> > > > > And don't say "ant is cross platform, make is not" because
> > > that just isn't
> > > > > true. Was someone just bored with the wheel and wanted to reinvent it?
> > > >
> > > > Ant is more than a cross platform make utility. Ant is
> > > platform independent,
> > > > which means alot more than cross platform. Ant is a make
> > > utility geared to meeet
> > > > the needs of Java. Java is "Write once run anywhere" and so
> > > is Ant. It is also
> > > > specifically made to meet the build requirements of Java code,
> > > capable of
> > > > anything from creating Jars to Javadocs. Its very easy to
> > > learn and its high
> > > > modularity makes it very easy to expand.
> > >
> > > I guess this is an important distinction to some people. I'm not a
> > > purist; the JVM is written in C, so none of us can claim to be purists ;)
> > >
> > > > Ant also goes further than make by adapting to XML for data
> > > representation and I
> > > > assume there is no need for me to go into the benefits of that :)
> > >
> > > Once again, standard data representation as opposed to problem-specific
> > > data representation is an important distinction to some people.
> > >
> > > What would really be nice would be if there were some kind or translator
> > > that could convert a GNU Makefile into Ant build script and vice versa. Is
> > > this on the radar screen Ant devleopers?
> > >
> > > I have all kinds of problems using new versions of Tomcat (and someone
> > > said that they are suprised at how few people try the milestone builds /
> > > betas) and many of them come from problems with Ant. So I think Ant is
> > > actually _preventing_ people from getting the most out of Tomcat. (just an
> > > opinion: no flame intended!)
> > >
> > > Many many programs that use autoconf are out there in OSS. I feel like we
> > > aren't leveraging our own past.
> > >
> > > > My 2 cents
> > > > Michael Stanley
> > > >
> > >
> > > And only mine as well, summarized by "Stand on The Shoulders of Giants"
> > >
> > > Nick
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
RE: Ant rant
Posted by person <mb...@pleiades.ca>.
I'm another young developer, in the sense that I'm inexperienced - my
first projects have been started about 8-9 months ago. I was faced with
the choice of either learning ant or learning make, the two build systems
available to me that I knew of. I expended a few hour of effort on each,
and it's quite conclusive for me: ant is far and a way the more intuitive,
elegant tool of the two. I grew up in OO concepts, it just feels like ant
is a natural fit with java. Also, I seem to remember something on the ant
page itself about why it was written instead of the author just using
make. http://jakarta.apache.org/ant/, that's it.
I give +1 for ant because of the learning curve involved, esp. when
attracting new developers, considering that tomcat is likely to live a
long lifetime and will likely (hopefully) see many new hands helping out.
Micah Blake McCurdy
The memory management on PowerPC can be used to frighten small children.
-- Linus Torvalds
On Sun, 12 Nov 2000, Rob S. wrote:
> Allow me to insert my Java / *nix developer novice-compared-to-people-here
> 2c =)
>
> I've only been paid to write Java code for 6 months as a co-op. There were
> 10+ developers at the company, and only one of them understood makefiles.
> That one person wrote and maintained a number of makefiles, and it really
> came down to not being "worth it" for the rest of us to understand the
> Makefile format. Why? When the files were there and working and everyone
> was happy.
>
> With Ant, I was able to accomplish the same thing, and fully understand the
> "whys" and "hows" of everything that was going on, in about 10 minutes (with
> the help of the ant docs and examples of course) and as many lines of XML.
>
> I've always considered it peripheral to getting "real work" done, so I don't
> wish to devote much brain power to it. Call me lazy, but that's just the
> way I am ;) I actually have dreaded having to learn the Makefile format for
> my personal projects and when I got a hold of Ant, I was very relieved!
>
> - r
>
> p.s. i don't mean to trivialize the Makefile stuff. It's funky!
>
> > -----Original Message-----
> > From: Nick Bauman [mailto:nick@cortexity.com]
> > Sent: November 12, 2000 5:11 PM
> > To: tomcat-dev@jakarta.apache.org; stanley@paragon.ecs.syr.edu
> > Subject: Re: Ant rant
> >
> >
> > On Sun, 12 Nov 2000, Michael Stanley wrote:
> >
> > > > And don't say "ant is cross platform, make is not" because
> > that just isn't
> > > > true. Was someone just bored with the wheel and wanted to reinvent it?
> > >
> > > Ant is more than a cross platform make utility. Ant is
> > platform independent,
> > > which means alot more than cross platform. Ant is a make
> > utility geared to meeet
> > > the needs of Java. Java is "Write once run anywhere" and so
> > is Ant. It is also
> > > specifically made to meet the build requirements of Java code,
> > capable of
> > > anything from creating Jars to Javadocs. Its very easy to
> > learn and its high
> > > modularity makes it very easy to expand.
> >
> > I guess this is an important distinction to some people. I'm not a
> > purist; the JVM is written in C, so none of us can claim to be purists ;)
> >
> > > Ant also goes further than make by adapting to XML for data
> > representation and I
> > > assume there is no need for me to go into the benefits of that :)
> >
> > Once again, standard data representation as opposed to problem-specific
> > data representation is an important distinction to some people.
> >
> > What would really be nice would be if there were some kind or translator
> > that could convert a GNU Makefile into Ant build script and vice versa. Is
> > this on the radar screen Ant devleopers?
> >
> > I have all kinds of problems using new versions of Tomcat (and someone
> > said that they are suprised at how few people try the milestone builds /
> > betas) and many of them come from problems with Ant. So I think Ant is
> > actually _preventing_ people from getting the most out of Tomcat. (just an
> > opinion: no flame intended!)
> >
> > Many many programs that use autoconf are out there in OSS. I feel like we
> > aren't leveraging our own past.
> >
> > > My 2 cents
> > > Michael Stanley
> > >
> >
> > And only mine as well, summarized by "Stand on The Shoulders of Giants"
> >
> > Nick
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
RE: Ant rant
Posted by "Rob S." <rs...@home.com>.
Allow me to insert my Java / *nix developer novice-compared-to-people-here
2c =)
I've only been paid to write Java code for 6 months as a co-op. There were
10+ developers at the company, and only one of them understood makefiles.
That one person wrote and maintained a number of makefiles, and it really
came down to not being "worth it" for the rest of us to understand the
Makefile format. Why? When the files were there and working and everyone
was happy.
With Ant, I was able to accomplish the same thing, and fully understand the
"whys" and "hows" of everything that was going on, in about 10 minutes (with
the help of the ant docs and examples of course) and as many lines of XML.
I've always considered it peripheral to getting "real work" done, so I don't
wish to devote much brain power to it. Call me lazy, but that's just the
way I am ;) I actually have dreaded having to learn the Makefile format for
my personal projects and when I got a hold of Ant, I was very relieved!
- r
p.s. i don't mean to trivialize the Makefile stuff. It's funky!
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: November 12, 2000 5:11 PM
> To: tomcat-dev@jakarta.apache.org; stanley@paragon.ecs.syr.edu
> Subject: Re: Ant rant
>
>
> On Sun, 12 Nov 2000, Michael Stanley wrote:
>
> > > And don't say "ant is cross platform, make is not" because
> that just isn't
> > > true. Was someone just bored with the wheel and wanted to reinvent it?
> >
> > Ant is more than a cross platform make utility. Ant is
> platform independent,
> > which means alot more than cross platform. Ant is a make
> utility geared to meeet
> > the needs of Java. Java is "Write once run anywhere" and so
> is Ant. It is also
> > specifically made to meet the build requirements of Java code,
> capable of
> > anything from creating Jars to Javadocs. Its very easy to
> learn and its high
> > modularity makes it very easy to expand.
>
> I guess this is an important distinction to some people. I'm not a
> purist; the JVM is written in C, so none of us can claim to be purists ;)
>
> > Ant also goes further than make by adapting to XML for data
> representation and I
> > assume there is no need for me to go into the benefits of that :)
>
> Once again, standard data representation as opposed to problem-specific
> data representation is an important distinction to some people.
>
> What would really be nice would be if there were some kind or translator
> that could convert a GNU Makefile into Ant build script and vice versa. Is
> this on the radar screen Ant devleopers?
>
> I have all kinds of problems using new versions of Tomcat (and someone
> said that they are suprised at how few people try the milestone builds /
> betas) and many of them come from problems with Ant. So I think Ant is
> actually _preventing_ people from getting the most out of Tomcat. (just an
> opinion: no flame intended!)
>
> Many many programs that use autoconf are out there in OSS. I feel like we
> aren't leveraging our own past.
>
> > My 2 cents
> > Michael Stanley
> >
>
> And only mine as well, summarized by "Stand on The Shoulders of Giants"
>
> Nick
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: 3.2b7 can't build -- fixed
Posted by Nick Bauman <ni...@cortexity.com>.
I found what I was missing. It was a jar in my classpath.A
On Sun, 12 Nov 2000, Nick Bauman wrote:
> What am I missing? I'm trying to build 3.2b7.
>
> [root@fatman jakarta-tomcat-3.2-b7-src]# ant
> Searching for build.xml ...
> Buildfile: /home/nick/build-web/jakarta-tomcat-3.2-b7-src/build.xml
>
> prepare:
> [chmod] /bin/chmod: too few arguments
> [chmod] Try `/bin/chmod --help' for more information.
> [chmod] Result: 1
>
> tomcat:
> [javac] Compiling 1 source file to
> /home/nick/build-web/build/tomcat/classes [javac]
> /home/nick/build-web/jakarta-tomcat-3.2-b7-src/src/share/org/apache/tomcat/net/SSLSocketFactory.java:245: Class
> javax.security.cert.X509Certificate not found in type declaration.
> [javac] javax.security.cert.X509Certificate[] certChain =
> sslSocket. [javac] ^
> [javac]
> /home/nick/build-web/jakarta-tomcat-3.2-b7-src/src/share/org/apache/tomcat/net/SSLSocketFactory.java:245: Incompatible
> type for declaration. Can't convert javax.security.cert.X509Certificate[]
> to <error>[].
> [javac] javax.security.cert.X509Certificate[] certChain =
> sslSocket. [javac] ^
> [javac] 2 errors
>
> BUILD FAILED
>
> /home/nick/build-web/jakarta-tomcat-3.2-b7-src/build.xml:94: Compile
> failed, messages should have been provided.
>
> Total time: 18 seconds
>
>
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
3.2b7 can't build
Posted by Nick Bauman <ni...@cortexity.com>.
What am I missing? I'm trying to build 3.2b7.
[root@fatman jakarta-tomcat-3.2-b7-src]# ant
Searching for build.xml ...
Buildfile: /home/nick/build-web/jakarta-tomcat-3.2-b7-src/build.xml
prepare:
[chmod] /bin/chmod: too few arguments
[chmod] Try `/bin/chmod --help' for more information.
[chmod] Result: 1
tomcat:
[javac] Compiling 1 source file to
/home/nick/build-web/build/tomcat/classes [javac]
/home/nick/build-web/jakarta-tomcat-3.2-b7-src/src/share/org/apache/tomcat/net/SSLSocketFactory.java:245: Class
javax.security.cert.X509Certificate not found in type declaration.
[javac] javax.security.cert.X509Certificate[] certChain =
sslSocket. [javac] ^
[javac]
/home/nick/build-web/jakarta-tomcat-3.2-b7-src/src/share/org/apache/tomcat/net/SSLSocketFactory.java:245: Incompatible
type for declaration. Can't convert javax.security.cert.X509Certificate[]
to <error>[].
[javac] javax.security.cert.X509Certificate[] certChain =
sslSocket. [javac] ^
[javac] 2 errors
BUILD FAILED
/home/nick/build-web/jakarta-tomcat-3.2-b7-src/build.xml:94: Compile
failed, messages should have been provided.
Total time: 18 seconds
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
Re: Ant rant
Posted by Nick Bauman <ni...@cortexity.com>.
On Sun, 12 Nov 2000, Michael Stanley wrote:
> > And don't say "ant is cross platform, make is not" because that just isn't
> > true. Was someone just bored with the wheel and wanted to reinvent it?
>
> Ant is more than a cross platform make utility. Ant is platform independent,
> which means alot more than cross platform. Ant is a make utility geared to meeet
> the needs of Java. Java is "Write once run anywhere" and so is Ant. It is also
> specifically made to meet the build requirements of Java code, capable of
> anything from creating Jars to Javadocs. Its very easy to learn and its high
> modularity makes it very easy to expand.
I guess this is an important distinction to some people. I'm not a
purist; the JVM is written in C, so none of us can claim to be purists ;)
> Ant also goes further than make by adapting to XML for data representation and I
> assume there is no need for me to go into the benefits of that :)
Once again, standard data representation as opposed to problem-specific
data representation is an important distinction to some people.
What would really be nice would be if there were some kind or translator
that could convert a GNU Makefile into Ant build script and vice versa. Is
this on the radar screen Ant devleopers?
I have all kinds of problems using new versions of Tomcat (and someone
said that they are suprised at how few people try the milestone builds /
betas) and many of them come from problems with Ant. So I think Ant is
actually _preventing_ people from getting the most out of Tomcat. (just an
opinion: no flame intended!)
Many many programs that use autoconf are out there in OSS. I feel like we
aren't leveraging our own past.
> My 2 cents
> Michael Stanley
>
And only mine as well, summarized by "Stand on The Shoulders of Giants"
Nick
Re: Ant rant
Posted by Michael Stanley <st...@paragon.ecs.syr.edu>.
> And don't say "ant is cross platform, make is not" because that just isn't
> true. Was someone just bored with the wheel and wanted to reinvent it?
Ant is more than a cross platform make utility. Ant is platform independent,
which means alot more than cross platform. Ant is a make utility geared to meeet
the needs of Java. Java is "Write once run anywhere" and so is Ant. It is also
specifically made to meet the build requirements of Java code, capable of
anything from creating Jars to Javadocs. Its very easy to learn and its high
modularity makes it very easy to expand.
Ant also goes further than make by adapting to XML for data representation and I
assume there is no need for me to go into the benefits of that :)
My 2 cents
Michael Stanley
RE: Ant rant
Posted by Nick Bauman <ni...@cortexity.com>.
My makefile uses a set of make dependencies that are copyright the company
I work for. I'd have to ask first before I could post it.
On Mon, 13 Nov 2000, Conor MacNeill wrote:
> Nick,
>
> Can we see the makefile? Did you get the same file to work on many
> platforms? What make did you use (nmake, gmake, ...)?
>
> Conor
>
> > -----Original Message-----
> > From: Nick Bauman [mailto:nick@cortexity.com]
> > Sent: Monday, 13 November 2000 8:05
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Ant rant
> >
> >
> > Question: WHAT THE HECK IS ANT?
> >
> > Now I know what ant is, I'm just hyperbolizing. But...
> >
> > It's just that I got the entire Tomcat 3.1 tree to compile
> > with a single
> > Makefile in around 10 minutes. I can't figure out what Ant is
> > helping this
> > project with. Maybe I'm just stupid or something but this Ant thing
> > doesn't really impress me very much. Make is very stable, very cross
> > platform; I just don't see what's so cool about ant.
> >
> > Why is ant better than Make?
> >
> > And don't say "ant is cross platform, make is not" because
> > that just isn't
> > true. Was someone just bored with the wheel and wanted to reinvent it?
> >
> > I just want to understand.
> >
> > Thanks.
> >
> > -Nick
> >
> > On Fri, 3 Nov 2000, Pier P. Fumagalli wrote:
> >
> > > Question: WHAT THE HACK IS TOMCAT 3.3 ???
> > >
> > > I believe that this developer community once agreed that Tomcat 4.0
> > > _will_be_ the next major release of the Apache Software
> > Foundation servlet
> > > engine, but, since a couple of weeks, I see a proliferation
> > of emails
> > > talking about Tomcat 3.3.
> > >
> > > Here is where I'm getting confused... When did we vote
> > about having a dual
> > > codebase for two different servlet engines at the same
> > time??? Because I've
> > > never seen such a discussion taking place...
> > >
> > > Also, it seems ridiculous (at least to me) to start talking
> > about what will
> > > be the next release of the 3.x tree (3.3) when 3.2 is not
> > yet out of the
> > > door, and as far as I've read (but I might have missed some
> > emails) Beta-6
> > > is not even compiling...
> > >
> > > Sorry, but as a long time ASF member, and one of the first
> > kids involved in
> > > the glorious JServ, I feel that things here are getting a
> > little bit screwed
> > > up. Are we going to screw our release cycles? Are we going
> > out to the public
> > > with TWO servlet engines equal in features, but different
> > in codebases? Are
> > > we all going NUTS?
> > >
> > > Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3,
> > > expecially before 3.2 final is out of the door. The NEXT
> > major release is
> > > going to be Tomcat 4.0, based on Catalina, as we all agreed
> > on months ago.
> > >
> > > But, I'm not _only_ a pain in the ass... I see there are
> > some developers who
> > > prefer to work on the 3.x tree, rather than helping out on
> > the 4.0, so,
> > > instead of cutting their wings and forcing them to fork the
> > project, I
> > > propose to them what was proposed to Craig in february.
> > >
> > > The "Rules for Evolution and Revolutions" still stands
> > still, as one of the
> > > major constitution documents for this community (James, WTF, post it
> > > somewhere!!! :) and IMNSHO needs to be used...
> > >
> > > I suggest to whoever is interested in further developement
> > of the 3.3 tree
> > > to create a new proposal, as Craig did with Catalina, and
> > stick it on the
> > > "proposals" directory in the CVS. And start working from
> > it. I'm more than
> > > open to see, after Tomcat 4.0 sees light, to reconsider the
> > effort, and
> > > maybe switching codebase again for what will be Tomcat 5.0.
> > >
> > > So, I'm proposing this plan, and please vote on 2 and 4 (1
> > and 3 were
> > > already voted upon with a bunch of +1s)...
> > >
> > > 1) Release Tomcat 3.2 final (soon, please!)
> > > 2) Create a new proposal tree alongside with Catalina (new
> > name to avoid
> > > confusion, please)
> > > 3) Release Tomcat 4.0 (with Catalina, as we all decided)
> > > 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
> > > proposal comes along.
> > >
> > > My 0.02 $... Take care...
> > >
> > > Pier
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> >
> > --
> > Nicolaus Bauman
> > Software Engineer
> > Simplexity Systems
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
RE: Ant rant
Posted by Conor MacNeill <co...@m64.com>.
Nick,
Can we see the makefile? Did you get the same file to work on many
platforms? What make did you use (nmake, gmake, ...)?
Conor
> -----Original Message-----
> From: Nick Bauman [mailto:nick@cortexity.com]
> Sent: Monday, 13 November 2000 8:05
> To: tomcat-dev@jakarta.apache.org
> Subject: Ant rant
>
>
> Question: WHAT THE HECK IS ANT?
>
> Now I know what ant is, I'm just hyperbolizing. But...
>
> It's just that I got the entire Tomcat 3.1 tree to compile
> with a single
> Makefile in around 10 minutes. I can't figure out what Ant is
> helping this
> project with. Maybe I'm just stupid or something but this Ant thing
> doesn't really impress me very much. Make is very stable, very cross
> platform; I just don't see what's so cool about ant.
>
> Why is ant better than Make?
>
> And don't say "ant is cross platform, make is not" because
> that just isn't
> true. Was someone just bored with the wheel and wanted to reinvent it?
>
> I just want to understand.
>
> Thanks.
>
> -Nick
>
> On Fri, 3 Nov 2000, Pier P. Fumagalli wrote:
>
> > Question: WHAT THE HACK IS TOMCAT 3.3 ???
> >
> > I believe that this developer community once agreed that Tomcat 4.0
> > _will_be_ the next major release of the Apache Software
> Foundation servlet
> > engine, but, since a couple of weeks, I see a proliferation
> of emails
> > talking about Tomcat 3.3.
> >
> > Here is where I'm getting confused... When did we vote
> about having a dual
> > codebase for two different servlet engines at the same
> time??? Because I've
> > never seen such a discussion taking place...
> >
> > Also, it seems ridiculous (at least to me) to start talking
> about what will
> > be the next release of the 3.x tree (3.3) when 3.2 is not
> yet out of the
> > door, and as far as I've read (but I might have missed some
> emails) Beta-6
> > is not even compiling...
> >
> > Sorry, but as a long time ASF member, and one of the first
> kids involved in
> > the glorious JServ, I feel that things here are getting a
> little bit screwed
> > up. Are we going to screw our release cycles? Are we going
> out to the public
> > with TWO servlet engines equal in features, but different
> in codebases? Are
> > we all going NUTS?
> >
> > Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3,
> > expecially before 3.2 final is out of the door. The NEXT
> major release is
> > going to be Tomcat 4.0, based on Catalina, as we all agreed
> on months ago.
> >
> > But, I'm not _only_ a pain in the ass... I see there are
> some developers who
> > prefer to work on the 3.x tree, rather than helping out on
> the 4.0, so,
> > instead of cutting their wings and forcing them to fork the
> project, I
> > propose to them what was proposed to Craig in february.
> >
> > The "Rules for Evolution and Revolutions" still stands
> still, as one of the
> > major constitution documents for this community (James, WTF, post it
> > somewhere!!! :) and IMNSHO needs to be used...
> >
> > I suggest to whoever is interested in further developement
> of the 3.3 tree
> > to create a new proposal, as Craig did with Catalina, and
> stick it on the
> > "proposals" directory in the CVS. And start working from
> it. I'm more than
> > open to see, after Tomcat 4.0 sees light, to reconsider the
> effort, and
> > maybe switching codebase again for what will be Tomcat 5.0.
> >
> > So, I'm proposing this plan, and please vote on 2 and 4 (1
> and 3 were
> > already voted upon with a bunch of +1s)...
> >
> > 1) Release Tomcat 3.2 final (soon, please!)
> > 2) Create a new proposal tree alongside with Catalina (new
> name to avoid
> > confusion, please)
> > 3) Release Tomcat 4.0 (with Catalina, as we all decided)
> > 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
> > proposal comes along.
> >
> > My 0.02 $... Take care...
> >
> > Pier
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
> --
> Nicolaus Bauman
> Software Engineer
> Simplexity Systems
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Ant rant
Posted by Nick Bauman <ni...@cortexity.com>.
Question: WHAT THE HECK IS ANT?
Now I know what ant is, I'm just hyperbolizing. But...
It's just that I got the entire Tomcat 3.1 tree to compile with a single
Makefile in around 10 minutes. I can't figure out what Ant is helping this
project with. Maybe I'm just stupid or something but this Ant thing
doesn't really impress me very much. Make is very stable, very cross
platform; I just don't see what's so cool about ant.
Why is ant better than Make?
And don't say "ant is cross platform, make is not" because that just isn't
true. Was someone just bored with the wheel and wanted to reinvent it?
I just want to understand.
Thanks.
-Nick
On Fri, 3 Nov 2000, Pier P. Fumagalli wrote:
> Question: WHAT THE HACK IS TOMCAT 3.3 ???
>
> I believe that this developer community once agreed that Tomcat 4.0
> _will_be_ the next major release of the Apache Software Foundation servlet
> engine, but, since a couple of weeks, I see a proliferation of emails
> talking about Tomcat 3.3.
>
> Here is where I'm getting confused... When did we vote about having a dual
> codebase for two different servlet engines at the same time??? Because I've
> never seen such a discussion taking place...
>
> Also, it seems ridiculous (at least to me) to start talking about what will
> be the next release of the 3.x tree (3.3) when 3.2 is not yet out of the
> door, and as far as I've read (but I might have missed some emails) Beta-6
> is not even compiling...
>
> Sorry, but as a long time ASF member, and one of the first kids involved in
> the glorious JServ, I feel that things here are getting a little bit screwed
> up. Are we going to screw our release cycles? Are we going out to the public
> with TWO servlet engines equal in features, but different in codebases? Are
> we all going NUTS?
>
> Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3,
> expecially before 3.2 final is out of the door. The NEXT major release is
> going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago.
>
> But, I'm not _only_ a pain in the ass... I see there are some developers who
> prefer to work on the 3.x tree, rather than helping out on the 4.0, so,
> instead of cutting their wings and forcing them to fork the project, I
> propose to them what was proposed to Craig in february.
>
> The "Rules for Evolution and Revolutions" still stands still, as one of the
> major constitution documents for this community (James, WTF, post it
> somewhere!!! :) and IMNSHO needs to be used...
>
> I suggest to whoever is interested in further developement of the 3.3 tree
> to create a new proposal, as Craig did with Catalina, and stick it on the
> "proposals" directory in the CVS. And start working from it. I'm more than
> open to see, after Tomcat 4.0 sees light, to reconsider the effort, and
> maybe switching codebase again for what will be Tomcat 5.0.
>
> So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were
> already voted upon with a bunch of +1s)...
>
> 1) Release Tomcat 3.2 final (soon, please!)
> 2) Create a new proposal tree alongside with Catalina (new name to avoid
> confusion, please)
> 3) Release Tomcat 4.0 (with Catalina, as we all decided)
> 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
> proposal comes along.
>
> My 0.02 $... Take care...
>
> Pier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Luke Holden <lu...@dragonarmy.nu>.
"Pier P. Fumagalli" wrote:
> > What is the status of the Tomcat 4.0 web connector for apache (if any)?
> AAAAARRRRRRGGGGGGHHHHH :) :) :) :) You know how to make me suffer... A beta
> will be available soon....
hahahaha :)
Well is there any way I can help? Although slightly new to java Ive been
programming for a number of years. (I mainly program in c/c++ and php)..
however I have recently cought onto the java language and I really enjoy
it. I would love to help in any way I can :)
--
Luke
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Luke Holden <lu...@DragonArmy.nu> wrote:
>
> What is the status of the Tomcat 4.0 web connector for apache (if any)?
AAAAARRRRRRGGGGGGHHHHH :) :) :) :) You know how to make me suffer... A beta
will be available soon....
Pier
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Luke Holden <lu...@dragonarmy.nu>.
What is the status of the Tomcat 4.0 web connector for apache (if any)?
Also, I would be VERY interested in helping this community with the
development of tomcat (and any other related project).
Thanks :)
--
Luke
Doh!
Posted by Roy Wilson <de...@bellatlantic.net>.
Whew!
Pier's text below, or something like it, would be good to have in the
(Tomcat-4.0?) user's guide.
[I know the distinctions made below were made in emails (and docs I
didn't read :-)) by Craig, but being vastly ignorant of servlets and
JSPs, it all ran together in my mind over time.]
Those who want to capitalize on OSS as users, might find paragraph 3
especially important, since it indicates the significance of the names
for use as well as for development activity.
Roy
--
Roy Wilson
E-mail: designrw@bellatlantic.net
> Let's try to explain this a little bit: Tomcat is NOT a servlet engine
and
> it is NOT a JSP engine/compiler; Tomcat is the union of those two
separate
> technologies.
> Some confusion have arised in the past because in the 3.x tree Tomcat is
the
> name of BOTH the servlet engine AND of the full distribution. But,
> recognized this problem, in the new 4.x tree we changed things to make
> better understand this distiction: "Catalina" is the servlet engine,
> "Jasper" is the JSP engine/compiler and "Tomcat" is the union of those
two.
> What does this mean? This means that, at the end, you will be able to
> download Catalina (if you need only servlets), Jasper (if you want to use
> JSPs on ANY servlet engine, even on Allaire's JRun hopefully), or Tomcat
(if
> you want to use the full distribution from Apache).
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Liam Magee <lm...@biziworks.com.au> wrote:
>
> I have been a long-time silent listener on this list, and use Tomcat 3.1 in
> a production environment. I have been greatly appreciative of the hard work
> gone into the software to date, and respect that its development is on a
> volunteer basis. But I fully concur with the sentiments of this posting -
> for the past couple of months it's been completely unclear as what the
> development path and release schedule for Tomcat looks like (3.2?, 3.3?,
> 4.0?). I would like to continue to use Tomcat, and eventually have time to
> get more involved in its development, but the lack of any obvious plan and
> schedule leaves companies like ours considering whether we need to fall back
> to commercial offerings to get any kind of reliability or accountability for
> the direction of releases. Again, I respect that the basis of this project
> is volunteer-driven, but it is possible to get a balance between the
> democratic impulses of OSS and a more rigorous project management approach
> to 'deliverables'?
Let me wear my "foundation member" hat for a while, try to make a point of
the current situation, and explain something that is obvious for long-time
developers, but might not be so clear for newcomers.
First of all let's clear up a long time issue (I reply to webmaster@jakarta
too, and this question keeps popping up) What is Tomcat?
Tomcat, the Jakarta Apache flagship product, is (as the web site states) the
Reference Implementation for the Java Servlet and JavaServer Pages
Technologies.
Let's try to explain this a little bit: Tomcat is NOT a servlet engine and
it is NOT a JSP engine/compiler; Tomcat is the union of those two separate
technologies.
Some confusion have arised in the past because in the 3.x tree Tomcat is the
name of BOTH the servlet engine AND of the full distribution. But,
recognized this problem, in the new 4.x tree we changed things to make
better understand this distiction: "Catalina" is the servlet engine,
"Jasper" is the JSP engine/compiler and "Tomcat" is the union of those two.
What does this mean? This means that, at the end, you will be able to
download Catalina (if you need only servlets), Jasper (if you want to use
JSPs on ANY servlet engine, even on Allaire's JRun hopefully), or Tomcat (if
you want to use the full distribution from Apache).
Why all this confusion? Why do we need Tomcat? Can't we just have "Catalina"
and "Jasper"? No, we can't... Because Tomcat (the full product) is the
reference implementation of the Java Community Process' JSR-53, so, one JSR,
one specification, one name, one distribution...
(Ok, I have to save this one for all the webmaster@jakarta emails).
Now, to explain a little bit how we are organized, let me say that we're far
from the time when we were a bunch of kids playing at Java.Apache.ORG with
JServ. Now we are part of the Apache Software Foundation, and because of
that, we have to obey to some rules. Most of our self-imposed regulations
were derived by the invaluable experience gathered by the HTTPD project (the
web-server) and that was absorbed by all other branches of the foundation by
osmosis.
We have a voting process, a vetoing process, a list of people who have the
right, and the due (I would like to underline this!) to vote on issues. This
all is clearly described in our "Guidelines" page, please READ it, because
that's the LAW in this community. Once an issue is found (a new release, a
new codebase, anything that needs a general agreement), all the committers
(people with access to the CVS) are asked for a vote. And when a decision is
took, it's a responsibility of those voting committers to maintain what was
promised. (Yes, if you're a committer, you have responsibilities in front of
the community... Again, we're far from the old JServ days).
Now, to sum up what happened in the last few months: Some of us (in
particular Craig, me, Jon, Remy and others) weren't feeling comfortable with
the Tomcat 3.x (Servlet Engine) codebase. Craig, the main author of what
would have become JServ 2.0, asked the permission to create a new
propositive servlet engine, we voted, and the "Catalina" proposal was
created.
When Servlet 2.3 and JSP 1.2 came along, this community was asked to vote
again, on what codebase would have been used for this new reference
implementation: we had to choose between Tomcat 3.x (Servlet Engine) and
Catalina, and we decided to adopt Catalina as our next-generation servlet
engine.
In those last few days, I've seen emails going around with a "Tomcat 3.3"
label stamped upon them, and that's when I started to wonder, and get
confused. This community didn't vote for a Tomcat 3.3 release, nor we were
asked what we were thinking about such a thing. Puzzled, I started asking
around, and, aparently, what was clear in the past (Tomcat 3.2 release and
then Tomcat 4.0) was all screwed up.
For what concerns me, Tomcat 3.3 doesn't exist as an Apache Project. It was
not voted upon, and it is in direct contrast with what this community
decided. Just to give you an example, try to go on new-httpd and tell the
developers that you're going to write an Apache Web-Server 1.4.1, completely
ignoring what was voted upon as Apache 2.0... I bet that my colleagues will
either laugh or your flameproof-vest will not last for more than 12
seconds...
Also, this community, has the responsibility to its commitment towards
Tomcat 4.0 because other entities are relying on it:
- Cocoon 2.0 desperately requires it
- Avalon has already integrated it
- OpenEJB is planning to use Catalina as servlet engine
- Sun Microsystems wants something to be distributed in its J2EE platform
- Olliance, Exoffice and others choose it as their primary platform
- The JCP needs a Reference Implementation for the JSR-53 specification
So, for whoever is interested in the future of Tomcat, the guarantee of the
Apache Software Foundation is that Tomcat 4.0 _is_ the future "Reference
Implementation for the Java Servlet and JavaServer Pages Technologies". This
was voted by the community and this is what we're going to do. If any of the
developers currently involved don't want to follow this direction, they're
more than welcome to create a new proposal that will be evaluated for Tomcat
5.0, but, before that, the master plan stands still. ("Rules for Evolution
and Revolutions" is still valid... Read it...)
And with that, I consider the matter closed... Flames are welcome...
Pier
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by Liam Magee <lm...@biziworks.com.au>.
I have been a long-time silent listener on this list, and use Tomcat 3.1 in
a production environment. I have been greatly appreciative of the hard work
gone into the software to date, and respect that its development is on a
volunteer basis. But I fully concur with the sentiments of this posting -
for the past couple of months it's been completely unclear as what the
development path and release schedule for Tomcat looks like (3.2?, 3.3?,
4.0?). I would like to continue to use Tomcat, and eventually have time to
get more involved in its development, but the lack of any obvious plan and
schedule leaves companies like ours considering whether we need to fall back
to commercial offerings to get any kind of reliability or accountability for
the direction of releases. Again, I respect that the basis of this project
is volunteer-driven, but it is possible to get a balance between the
democratic impulses of OSS and a more rigorous project management approach
to 'deliverables'?
Regards,
Liam Magee.
> -----Original Message-----
> From: Pier P. Fumagalli [mailto:pier@betaversion.org]
> Sent: Saturday, 4 November 2000 4:27 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Tomcat 3.3 / 4.0 confusion, rant and plan...
>
>
> Sorry for starting what it might end up as a long flamewar, but reading
> almost 500 emails on the list I ended up a little confused... Also, in a
> bunch of side discussions, but related always to the same topic, I feel
> there's something wrong going around here...
>
> Question: WHAT THE HACK IS TOMCAT 3.3 ???
>
> I believe that this developer community once agreed that Tomcat 4.0
> _will_be_ the next major release of the Apache Software Foundation servlet
> engine, but, since a couple of weeks, I see a proliferation of emails
> talking about Tomcat 3.3.
>
> Here is where I'm getting confused... When did we vote about having a dual
> codebase for two different servlet engines at the same time???
> Because I've
> never seen such a discussion taking place...
>
> Also, it seems ridiculous (at least to me) to start talking about
> what will
> be the next release of the 3.x tree (3.3) when 3.2 is not yet out of the
> door, and as far as I've read (but I might have missed some emails) Beta-6
> is not even compiling...
>
> Sorry, but as a long time ASF member, and one of the first kids
> involved in
> the glorious JServ, I feel that things here are getting a little
> bit screwed
> up. Are we going to screw our release cycles? Are we going out to
> the public
> with TWO servlet engines equal in features, but different in
> codebases? Are
> we all going NUTS?
>
> Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3,
> expecially before 3.2 final is out of the door. The NEXT major release is
> going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago.
>
> But, I'm not _only_ a pain in the ass... I see there are some
> developers who
> prefer to work on the 3.x tree, rather than helping out on the 4.0, so,
> instead of cutting their wings and forcing them to fork the project, I
> propose to them what was proposed to Craig in february.
>
> The "Rules for Evolution and Revolutions" still stands still, as
> one of the
> major constitution documents for this community (James, WTF, post it
> somewhere!!! :) and IMNSHO needs to be used...
>
> I suggest to whoever is interested in further developement of the 3.3 tree
> to create a new proposal, as Craig did with Catalina, and stick it on the
> "proposals" directory in the CVS. And start working from it. I'm more than
> open to see, after Tomcat 4.0 sees light, to reconsider the effort, and
> maybe switching codebase again for what will be Tomcat 5.0.
>
> So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were
> already voted upon with a bunch of +1s)...
>
> 1) Release Tomcat 3.2 final (soon, please!)
> 2) Create a new proposal tree alongside with Catalina (new name to avoid
> confusion, please)
> 3) Release Tomcat 4.0 (with Catalina, as we all decided)
> 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
> proposal comes along.
>
> My 0.02 $... Take care...
>
> Pier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Tomcat 3.3 / 4.0 confusion, rant and plan...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Sorry for starting what it might end up as a long flamewar, but reading
almost 500 emails on the list I ended up a little confused... Also, in a
bunch of side discussions, but related always to the same topic, I feel
there's something wrong going around here...
Question: WHAT THE HACK IS TOMCAT 3.3 ???
I believe that this developer community once agreed that Tomcat 4.0
_will_be_ the next major release of the Apache Software Foundation servlet
engine, but, since a couple of weeks, I see a proliferation of emails
talking about Tomcat 3.3.
Here is where I'm getting confused... When did we vote about having a dual
codebase for two different servlet engines at the same time??? Because I've
never seen such a discussion taking place...
Also, it seems ridiculous (at least to me) to start talking about what will
be the next release of the 3.x tree (3.3) when 3.2 is not yet out of the
door, and as far as I've read (but I might have missed some emails) Beta-6
is not even compiling...
Sorry, but as a long time ASF member, and one of the first kids involved in
the glorious JServ, I feel that things here are getting a little bit screwed
up. Are we going to screw our release cycles? Are we going out to the public
with TWO servlet engines equal in features, but different in codebases? Are
we all going NUTS?
Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3,
expecially before 3.2 final is out of the door. The NEXT major release is
going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago.
But, I'm not _only_ a pain in the ass... I see there are some developers who
prefer to work on the 3.x tree, rather than helping out on the 4.0, so,
instead of cutting their wings and forcing them to fork the project, I
propose to them what was proposed to Craig in february.
The "Rules for Evolution and Revolutions" still stands still, as one of the
major constitution documents for this community (James, WTF, post it
somewhere!!! :) and IMNSHO needs to be used...
I suggest to whoever is interested in further developement of the 3.3 tree
to create a new proposal, as Craig did with Catalina, and stick it on the
"proposals" directory in the CVS. And start working from it. I'm more than
open to see, after Tomcat 4.0 sees light, to reconsider the effort, and
maybe switching codebase again for what will be Tomcat 5.0.
So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were
already voted upon with a bunch of +1s)...
1) Release Tomcat 3.2 final (soon, please!)
2) Create a new proposal tree alongside with Catalina (new name to avoid
confusion, please)
3) Release Tomcat 4.0 (with Catalina, as we all decided)
4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new
proposal comes along.
My 0.02 $... Take care...
Pier