Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@apache.org Received: (qmail 75257 invoked from network); 19 Jan 2003 22:43:49 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 19 Jan 2003 22:43:49 -0000 Received: (qmail 15131 invoked by uid 97); 19 Jan 2003 22:45:12 -0000 Delivered-To: qmlist-jakarta-archive-struts-dev@jakarta.apache.org Received: (qmail 15110 invoked by uid 97); 19 Jan 2003 22:45:11 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 15098 invoked by uid 98); 19 Jan 2003 22:45:11 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) To: struts-dev@jakarta.apache.org Subject: Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1 References: <86el7ati9u.fsf@earthlink.net> <8665smtb3s.fsf@earthlink.net> <3E2A8F22.70900@apache.org> <864r84sw1k.fsf@earthlink.net> <3E2B196D.5060104@apache.org> From: dmkarr@earthlink.net (David M. Karr) Date: 19 Jan 2003 14:44:11 -0800 In-Reply-To: <3E2B196D.5060104@apache.org> Message-ID: <86of6crc90.fsf@earthlink.net> Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Military Intelligence (Windows)) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >>>>> "Ted" == Ted Husted writes: Ted> Is the struts-el taglib now actually broken because html:link gained a missing Ted> property? Or does it simply fail to meet one of our expectations for the taglib? No, I certainly wouldn't call it "broken", just that it wouldn't support an attribute that is supported in the base library. Ted> I am of the opinion that all the taglibs should be packaged separately. In this Ted> way, that fixes and enhancements that do not affect the core Action and Config Ted> packages could be released more easily. The conventional taglibs have stayed Ted> put so far since they arguably do no harm and provide a convenience to a great Ted> many users. I suppose if "core" Struts was separated from the tag library, then both tag libraries could be released together in a single package. Ted> But we now have the situation where you would be obligated to vote against a Ted> release because changes to one package where not reflected in another package, Ted> which at this time lives in the contrib folder. I submit this that this is the Ted> type of coupling that MVC was invented to defeat, and that we not taking our Ted> own advice =:0) The problem is that Struts-EL is not coupled with the MVC parts, just with the tag library. Ted> Craig plans on releasing the Struts-JSF tablib separately, why can't we do the Ted> same with Struts-EL? I don't know enough about what exactly Struts-JSF will be doing to really compare it, but I would guess that it won't be as intimately tied to the Struts MVC core or to the Struts tag library, which would make it logical to be released separately. My other concern about doing this is that we'll be changing the packaging structure of Struts, just before a release. I think I see some of your point about packaging the MVC core separately from the tag libraries, but I think the Struts tag library should be packaged with Struts-EL. In any case, I'm concerned about changing the release and packaging structure so close to a release. -- =================================================================== David M. Karr ; Java/J2EE/XML/Unix/C++ dmkarr@earthlink.net ; SCJP; SCWCD -- To unsubscribe, e-mail: For additional commands, e-mail: