Amazing that just 10 days before this release was the alpha release! No beta. No rc. Nice work!!!

Well, it's all about naming, isn't it ;-)

You could call something alpha and release the final version a day later. What does it show? Probably that the original alpha tag was inappropriate, because the software obviously was pretty stable already.

One of those eternal questions: Why is Tomcat still part of Jakarta? Shouldn't it have been turned into a top-level Apache project long ago?

I just don't see the point in Struts being a top-level project but Tomcat still being part of Jakarta. Obviously, Apache does not have a master plan on how to structure their projects in a fair and sensible manner.

I assume that the current structure is the result from lobbying by the Struts team to get their own top-level project, while noone from the Tomcat team has tried. Or have they tried too but it hasn't been granted to them?

If someone from Apache can shed insights on this, I'd be happy to hear them.

Juergen

P.S.:Tomcat 5.5 is the only product that I'm aware of where the standard distribution is tailored for JDK 1.5 only at this point of time. OK, the download size is impressive, but I doubt that many people are currently deploying on JDK 1.5...

I once heard that if they would move Tomcat to a top level project, the Jakarta brand would be weakened. So i believe that Tomcat is essential for the Jakarta community to be its leading project. But thats only what i heard, something more detailed from some Apache rep is appreciated in any way. Not that its that important, but sometimes its easier to write about issues like that compared to emotional discussions about JDO2/EJB3 JSRs ;-)

I once heard that if they would move Tomcat to a top level project, the Jakarta brand would be weakened. So i believe that Tomcat is essential for the Jakarta community to be its leading project.

Well, they turned Ant and Log4J into their own top-level projects too - both were classic Jakarta projects before. So I don't see the point in keeping Tomcat under the Jakarta umbrella; it feels inconsistent from an overall Apache structure perspective.

Not that its that important, but sometimes its easier to write about issues like that compared to emotional discussions about JDO2/EJB3 JSRs ;-)

the question has been floated out several times and the response from the users and developers was to keep tomcat under jakarta. You can search the archives. personally, being top level doesn't have any meaning to me. moving a project out from jakarta just means a lot of work to change the setup, builds and docs.

I personally don't mind Tomcat being part of Jakarta. But if there's no meaning in a top-level project - why were Ant, Struts and Log4J so keen to get it? The migragtion must have meant a lot of work for them too. My main question is not why Tomcat isn't a top-level project per se, but rather why Ant and Struts are but Tomcat isn't.

From the Apache organization perspective, there is an important difference: a top-level project has its own project management committee. So in a top-level project, the project team itself is in full control over its decisions and its direction. As part of Jakarta, other people (i.e. people not involved in your particular product) influence the direction of your product.

I personally don't mind Tomcat being part of Jakarta. But if there's no meaning in a top-level project - why were Ant, Struts and Log4J so keen to get it? The migragtion must have meant a lot of work for them too. My main question is not why Tomcat isn't a top-level project per se, but rather why Ant and Struts are but Tomcat isn't.From the Apache organization perspective, there is an important difference: a top-level project has its own project management committee. So in a top-level project, the project team itself is in full control over its decisions and its direction. As part of Jakarta, other people (i.e. people not involved in your particular product) influence the direction of your product.(Please correct me if there any misassumptions in my reasoning.)Juergen

you'd have to ask the developers of those projects why they wanted to be a top level. the Jakarta PMC uses "hands off" approach, so the developers are the ones that drive it. keep in the mind jakarta PMC and developers participate in many of the jakarta projects. I work on jakarta stuff for pleasure, so I try to avoid taking on administrative tasks when I can. The active developers in jakarta are pretty diverse group of people, so there isn't a nice neat answer to "why tomcat is in jakarta" other than it just is.

I remember a previous reply about this subject. He was quoted as saying that "Since Tomcat was the first Jakarta project and Tomcat is kinda associated with Jakarta, the tomcat guys have some attachment towards Jakarta that other projects didn't have. The developers really don't care (enough) if Tomcat were to become a top level project.

Well, this thread has been amusing ;) Let me try to shed some light on these questions.

Tomcat has not wanted to move to top-level status because it means we'd have to migrate our codebase and do other administrative tasks. We're all busy enough and happy enough where we are that such a move doesn't concern us too much. We can move if we feel like it, and the broader Jakarta and Apache community has made it clear they'd all support such a move if/when the tomcat committers wanted to do it.

On the release labelling, or from alpha to stable in 10 days: the Tomcat release stability labelling is a bit unusual. The initial label (alpha or beta, never stable) is the Release Manager's personal impression, after reviewing the change log and consulting with other devs. We then allow a week or so for power users and other groups (e.g. the folks at Sun who run the relevant TCKs) to use the release and provide us feedback. Then we have a formal stability vote whose results are published. So there's no binary difference between 5.5.7 alpha and 5.5.7 stable, we're just making a different claim about the build's quality.

For this reason, by the way, we always make it very clear on the download pages what's what, and we always leave the latest stable version on there alongside the new alpha/beta releases. The process has worked well for years, because Tomcat does have many power users and we do hear back right away on alpha/beta releases if they have significant issues.

We recognize there are other ways to go about this, e.g. private release candidates and such. I'm not going to get into a discussion of the merits of other configuration/release management systems, but feel free to come convince us on the tomcat-dev mailing list ;)

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.