Modules subproject ( was: Re: [PATCH] CatalinaBlock.java )
> > Actually, I was thinking starting a modules subprojects for things like that > in 4.1. It would be really great to have a module subproject !!! ( as long as it will host 3.3 modules too :-) This will keep the release more focused on the core functionality, and simplify the testing and release. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
* Sam Ruby ([EMAIL PROTECTED]) wrote on Mon Feb 12, 2001 at 01:39:07PM -0500: > Aaron Mulder wrote: > > > > It's always going to be the case that the Avalon and Tomcat releases > > don't sync up perfectly. How would you feel about making any Tomcat > > changes necessary to support the Avalon patch, but maintaining the > > Avalon block itself outside of the main Tomcat 4.0 module? That way the > > Avalon support could be updated independently for new releases of Avalon > > *or* Tomcat. > > Avalon is currently in Alpha. This means that their APIs are subject to > change. > > Once they ever release (or rather, if they ever release ), then I > have been told that their APIs will be stable, and they will try to > maintain version to version incompatibility. ^ I really _really_ hope you mean version compatability here :) -Thom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
Aaron Mulder wrote: > > It's always going to be the case that the Avalon and Tomcat releases > don't sync up perfectly. How would you feel about making any Tomcat > changes necessary to support the Avalon patch, but maintaining the > Avalon block itself outside of the main Tomcat 4.0 module? That way the > Avalon support could be updated independently for new releases of Avalon > *or* Tomcat. Avalon is currently in Alpha. This means that their APIs are subject to change. Once they ever release (or rather, if they ever release ), then I have been told that their APIs will be stable, and they will try to maintain version to version incompatibility. My preference is that mainline subprojects (no, I don't have a definition for that term, but Tomcat clearly qualifies) do not support Avalon until then. This is to prevent version incompatibility problems, and hopefully motivate Avalon to a release (I can always dream, can't I?). So, my vote is as Remy originally stated - keep this in 4.1; drop it for now from 4.0. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
> It's always going to be the case that the Avalon and Tomcat releases > don't sync up perfectly. How would you feel about making any Tomcat > changes necessary to support the Avalon patch, but maintaining the > Avalon block itself outside of the main Tomcat 4.0 module? That way the > Avalon support could be updated independently for new releases of Avalon > *or* Tomcat. Actually, I was thinking starting a modules subprojects for things like that in 4.1. Right now, the version number for Avalon is 3.1 alpha 1. It's common sense that we will need to keep that component in sync with Avalon, but at least we can indicate users to use a specific stable version until we update, and the amount of updates needed should be reasonable (I hope). Does it make sense ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
Aaron Mulder wrote: > It's always going to be the case that the Avalon and Tomcat releases > don't sync up perfectly. How would you feel about making any Tomcat > changes necessary to support the Avalon patch, but maintaining the > Avalon block itself outside of the main Tomcat 4.0 module? That way the > Avalon support could be updated independently for new releases of Avalon > *or* Tomcat. > That would be my preference. I was thinking, it ought to be possible to create a process/module/project/something that takes the output bits of a Tomcat 4.0 binary distribution, and the output bits of an Avalon release, and combine them into an Avalonized installation of Tomcat 4.0. This is not a lot different than what Henri does when he creates RPMs -- it is done external to the standard Tomcat build process. If we want to go this direction, what modifications does "making any Tomcat changes necessary to support the Avalon patch" include? (I haven't had a chance to look at Jason's proposal in detail yet.) > > Aaron > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
It's always going to be the case that the Avalon and Tomcat releases don't sync up perfectly. How would you feel about making any Tomcat changes necessary to support the Avalon patch, but maintaining the Avalon block itself outside of the main Tomcat 4.0 module? That way the Avalon support could be updated independently for new releases of Avalon *or* Tomcat. Aaron Remy Maucherat wrote: > I'm -1 on applying the Avalon patch in the 4.0 tree. > The rationale is : > - Avalon isn't ready yet. It's still in alpha stage, and I fear there may be > API changes in the pipeline. > - TC 4.0 should be out before Avalon. If Avalon 3.1 evolves *after* TC 4.0 > is released, this would break the wrapper included in TC 4.0 and make it > incompatible with the Avalon 3.1 production release, which would more or > less force us to do a TC maintenance release. > > For these reasons, I'd like to see an official Avalon wrapper introduced in > Tomcat 4.1, but not in Tomcat 4.0. > I also propose to remove the current Avalon wrapper from the Tomcat 4.0 > repository, to avoid the maintenance related issues. > > The 4.1 repository should be recreated very soon, since TC 4.0 has gone back > into feature freeze mode (but we want to fix the sealing violation problems > reported by many people before). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
Remy Maucherat wrote: > > For these reasons, I'd like to see an official Avalon wrapper > introduced in Tomcat 4.1, but not in Tomcat 4.0. I also > propose to remove the current Avalon wrapper from the Tomcat > 4.0 repository, to avoid the maintenance related issues. +1 - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
> If you like that patch, you'll probably also like > the ones I sent in on Friday -- messages with the > title > "[PATCH] TC4: TomcatBlock on Avalon 3.1a1".. I'm -1 on applying the Avalon patch in the 4.0 tree. The rationale is : - Avalon isn't ready yet. It's still in alpha stage, and I fear there may be API changes in the pipeline. - TC 4.0 should be out before Avalon. If Avalon 3.1 evolves *after* TC 4.0 is released, this would break the wrapper included in TC 4.0 and make it incompatible with the Avalon 3.1 production release, which would more or less force us to do a TC maintenance release. For these reasons, I'd like to see an official Avalon wrapper introduced in Tomcat 4.1, but not in Tomcat 4.0. I also propose to remove the current Avalon wrapper from the Tomcat 4.0 repository, to avoid the maintenance related issues. The 4.1 repository should be recreated very soon, since TC 4.0 has gone back into feature freeze mode (but we want to fix the sealing violation problems reported by many people before). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
Sam Ruby wrote: > > Jason van Zyl wrote: > > > > > While playing with Sam Ruby's gump I noticed that the > > CatalinaBlock is out of sync with Avalon. Not sure if > > staying right up-to-date is critical but here's the > > patch anyway. > > > Until Avalon ships, tracking to the current APIs is the only way to go. > > I've committed the changes. Thanks! > > - Sam Ruby If you like that patch, you'll probably also like the ones I sent in on Friday -- messages with the title "[PATCH] TC4: TomcatBlock on Avalon 3.1a1".. Cheers. = Jason Brittain <[EMAIL PROTECTED]> __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] CatalinaBlock.java
Jason van Zyl wrote: > > While playing with Sam Ruby's gump I noticed that the > CatalinaBlock is out of sync with Avalon. Not sure if > staying right up-to-date is critical but here's the > patch anyway. Until Avalon ships, tracking to the current APIs is the only way to go. I've committed the changes. Thanks! - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] CatalinaBlock.java
Hi, While playing with Sam Ruby's gump I noticed that the CatalinaBlock is out of sync with Avalon. Not sure if staying right up-to-date is critical but here's the patch anyway. jvz. Index: CatalinaBlock.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/CatalinaBlock.java,v retrieving revision 1.1 diff -u -r1.1 CatalinaBlock.java --- CatalinaBlock.java 2000/11/13 06:42:30 1.1 +++ CatalinaBlock.java 2001/02/11 03:52:05 @@ -63,9 +63,9 @@ package org.apache.catalina.startup; -import org.apache.avalon.ConfigurationException; -import org.apache.avalon.Configuration; -import org.apache.avalon.blocks.AbstractBlock; +import org.apache.avalon.configuration.ConfigurationException; +import org.apache.avalon.configuration.Configuration; +import org.apache.phoenix.AbstractBlock; /** * Catalina wrapper for Avalon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
