RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: March 20, 2004 9:44 PM To: Struts Developers List Subject: Re: branching 1.2 and 1.3 and CVS reorg for TLP status On Sat, 20 Mar 2004, Craig R. McClanahan wrote: Quoting Joe Germuska [EMAIL PROTECTED]: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... I think there's a lot of merit in rationalizing the directory structures as part of the move to TLP-ness. Assuming we don't move to Subversion right now (see other thread), the move is effectively a CVS repo rename by the infrastructure folks, lock, stock and barrel. Any rationalisation is totally up to us. If we want to break up our existing repo, we have a couple of options: 1) One top-level 'struts' repo that we break down as we see fit. This option leaves everything in our control, since, as far as infrastructure@ is concerned, there is only one CVS repo. 2) Multiple top-level repos, one of which is a renamed version of our current repo, and the remainder of which are new empty repos. We would then migrate pieces of our current repo out to the new repos. 3) Same as (2) above, except that we don't ask for a repo rename, but just new repos, and we migrate everything ourselves to the appropriate new repo. While (3) is the cleanest insofar as we wouldn't have leftovers in the Attic of the renames repo, it's also a huge amount of work for us, and runs the risk of forgetting things. My preference is for (1). It is the simplest approach, and will allow us to move things around however we see fit, without having to decide up front which other repos we might want. If, at some point, we decide we do want other top-level repos, we can request them at that time. Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are ways to preserve history, but I suspect there will be difficulties if we decide to split up what has been a single repository (jakarta-struts) into per-subpackage repositories. A guru on CVS would definitely be useful here. A CVS repo rename will preserve all of our history, obviously. After that, I can take care of preserving history whatever we decide to do (as long as we stay with CVS ;). It's slightly easier if we have only one repo, but it can still be done across repos. -- Martin Cooper I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. I'm going to focus some energy as well on commons-chain and struts-chain now that JavaServer Faces is done. Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Struts JSR?
On Sat, 20 Mar 2004, Nadeem Bitar wrote: On Sat, 2004-03-20 at 20:41 -0800, Craig R. McClanahan wrote: Quoting Thomas L Roche [EMAIL PROTECTED]: David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of his remarks include - Is JSF a replacement for Struts? Yes! - JSF is a standard. Struts will never be a standard. which I believe to be pretty-nearly-direct quotes. I'm assuming he really meant + JSF 1.0 can do pretty much everything Struts 1.1 can. There is definitely substantial overlap, especially in the HTML tags area, as well as things like outcome-based navigation handling and creating form beans. The design of JavaServer Faces benefited tremendously from the experience we've had with Struts, and the design in these areas exceeds the current functionality of Struts in many respects. Two particular features of Struts that are not present in JavaServer Faces 1.0 -- Tiles for layout management, and the Validator Framework for creating client side JavaScript to enforce the rules (in addition to enforcing them at the server). Fortunately, however, you can use these Struts features in conjunction with JavaServer Faces by using the Struts-Faces integration library. With JSP2.0 attributes and fragments you can do advanced layout and templates without tiles. I am sure the validation would also be addressed with time. There is a huge amount of momentum around Struts, and it's not going to go away any time soon. That being said, however, it's time for Struts to start doing some more innovation instead of incremental improvements, in order to remain as popular for new development. That is my point exactly and I am hoping that struts would innovate and implement some of the things other frameworks use. Such as? What kinds of innovations are you looking for, and specifically what kinds of things are you seeing other frameworks use that Struts could benefit from? -- Martin Cooper + JSF is a JSR, and Struts will never be a JSR. but I'm wondering about that last statement. What prevents Struts from undergoing the JCP? Are there circumstances under which you might consider this? For those not familiar with it, some brief background on the JCP would be useful here. More details are at the JCP web site http://jcp.org. Anyone who is a JCP member can propose a JSR. To be accepted, it would to be accepted by the 16 members of the Executive Committee for the J2SE/J2EE platform (note that Sun has one of these 16 votes -- people who believe that Sun could veto a JSR proposal for something like this, even if Sun wanted to, are misinformed; that veto ability only applies to language changes or uber JSRs like the ones for the entire J2SE and J2EE platforms). The person(s) or organization(s) proposing the JSR would need to plan on (if it's accepted) providing a specification documenting the Java API or technology to be standardized, a Technology Compatibility Kit (TCK) against which other company's implementations of the technology can be tested, and a Reference Implementation (RI) -- which must pass the TCK -- proving that the technology can actually be implemented. If by the you in your question you are referring to the Struts committers, we could indeed propose such a JSR (Apache is a JCP member, and is currently also a voting member of the Executive Committee). But it wouldn't really be a JSR to standardize Struts ... at most it could be a JSR to standardize the APIs supported by Struts. After all, the JCP is really a standards organization that creates specifications to be implemented by others. Struts (and many other open source projects) are often not implementations of some standard -- they can be seen as sort of a combination of spec and implementation rolled into one. If the long term goal is that everyone continues to use the one and only implementation, then the JCP is not really the right development approach. Beyond that, the Executive Committee members will tend to not desire multiple JSRs with large amounts of functional overlap -- which would definitely be the case if someone tried to propose the Struts APIs. After all, these are companies that would need to fund the development of their own versions of the hypothetical standard Struts, and the cost of integrating it into their own products. It is much more cost effective (as well as less confusing and costly for users) to support a single standard in each technology area, and add functionality in future versions as it makes sense to standardize. As such, it seems much more likely that the Executive Committee would accept a JSR for some future version of JavaServer Faces that built on top of of the 1.0 version than a JSR for a different way to solve many of the same problems. The planning for the next steps in this direction, in fact, is already in
Re: OT: Struts JSR?
Such as? What kinds of innovations are you looking for, and specifically what kinds of things are you seeing other frameworks use that Struts could benefit from? I posted this before but here is my struts 2.0 wish list again: * Leverage JSF and JSTL remove struts tags that have similar functionality. * Support for IoC. * Cleaner interfaces. * Workflow integration. * Chained actions * Support for portlet(JSR-168) nadeem bitar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Struts JSR?
I think all of these things are already on the Struts Jericho list. The exception being workflow integration. The Struts Workflow is OK, but I personally don't like to use multiple action paths for workflows. Of course, the really cool thing about the Struts Chain is that it makes it very easy to integrate packages like this into Struts. Struts becomes less of a framework and more a framework for writing frameworks. The other minor exception would be Chained actions . I doubt that any of us will ever recommend forwarding from one action to another to form a chain of responsibility. But, again, that's something that the Commons Chain can do much better than conventional Struts Actions ever could. Here's my question to you: If you were a member of a development team, and someone handed you a list like this, what would you do first? And, having answered the question, go ahead and do it, and post it here. The thing about open source is this: You don't have to wish -- *you* can make it so. -Ted. On Sun, 21 Mar 2004 00:22:25 -0800, Nadeem Bitar wrote: Such as? What kinds of innovations are you looking for, and specifically what kinds of things are you seeing other frameworks use that Struts could benefit from? I posted this before but here is my struts 2.0 wish list again: * Leverage JSF and JSTL remove struts tags that have similar functionality. * Support for IoC. * Cleaner interfaces. * Workflow integration. * Chained actions * Support for portlet(JSR-168) nadeem bitar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We were already getting ready to change things around. And we *do* need to move things around if we are ever going to get away from a monolithic Struts to a modular Struts, were people can assemble the Struts platform they need for their application. If not now, then when? The resolution we submitted says we're suppose to rationalize Struts, so let's rationalize :) My preference would be to have a separate repository for each subproject. Each subproject represents a coherent software product or deliverable with its own release cycle. Another way of thinking of the subprojects/products is as Maven artifacts. As mentioned elsewhere, all Struts Committers can have access to all repositories, and all PMC Members have voting rights over all subprojects. I'd suggest that we setup a legacy jakarta repository that would be frozen. Directories could then be moved over to their new repositories, either from a second copy of the original repository or from a remote copy. The subprojects/repositories/artifacts/products I had in mind were: * core * taglib * app * opt-legacy * opt-el (or jstl) * opt-faces * opt-sandbox Here's some possible path-to-repository mappings. Later entries assume earlier entries were already moved. [taglib] /src/share/o.a.s/taglib - /src/o.a.s/taglib [app] /src/example,examples,tiles-docmentation - /src/ /web/ - /webapp/ [opt-el] /src/contrib/struts-el - / [opt-legacy] /src/contrib/struts-legacy - / [opt-faces] /src/contrib/struts-faces - / [opt-sandbox] /src/contrib/ - / [core] /src/share - core repository /src / - / Something like Struts 2.0 development might start out in the opt-sandbox and then move its own repository (like core2) once we had consensus. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts infrastructure changes
On Sat, Mar 20, 2004 at 09:44:23AM -0800, David Graham wrote: ... I've expressed my opposition to this on commons-dev so I'll sum up my points here: ... 2. We've been fairly consistent with tracking corresponding bugzilla bug numbers in the cvs commit messages. This has proved extremely valuable when researching and fixing bugs. I would hate to lose that meta data. The Bugzilla ID is preserved in JIRA. I've just added a search by old Bugzilla ID portlet to the default JIRA front page, to make this searchable: http://issues.apache.org/jira/ For instance, typing in 15216 will redirect to XMLRPC-21. If the ID isn't found in JIRA, the user is redirected to Bugzilla's show_bug.cgi?id=... URL. Incidentally, JIRA 2.6 has a Version Control tab for each issue, populated by the CVS commit messages mentioning the bug's key, and pointing to file diffs in ViewCVS. If people are diligent about bug references in commit logs, this can be quite useful. Screenshot at: http://confluence.atlassian.com/display/JIRA/JIRA+2.6+Release+Notes --Jeff ... David One other thing is that we'll want to get external mail archivers to switch to the new mailing lists once those are set up. I'm not clear on whether the infrastructure folks arrange that or we need to do it ourselves, but I'll ask when I submit the above. Anything else I missed? (There are a lot of internal changes we'll want to make as well, but I'm not trying to address those here.) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Struts [2004/03/21]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 866|New|Enh|2001-03-06|Clean Way to Add Parameters to Redirecting Forward| | 3202|Opn|Enh|2001-08-21|OptionsTag.doEndTag - calls method to populate se| | 5395|Opn|Enh|2001-12-12|ActionContext class | | 5566|New|Enh|2001-12-21|[PATCH] html:link bug | | 5739|Opn|Enh|2002-01-08|Struts fails silently in too many places | | 5937|New|Enh|2002-01-21|html:form trims all extensions| | 6686|New|Enh|2002-02-26|make action attribute of html:form tag optional | | 6847|Opn|Enh|2002-03-04|Multiple file upload not possible due to MultiPart| | 7892|Opn|Enh|2002-04-09|Using Multiple Resource Bundles for an Application| | 7902|Opn|Enh|2002-04-10|The exception handling declaration in the DTD does| | 9088|Opn|Enh|2002-05-15|FormTag.getActionMappingURL() assumes 1 servlet ma| | 9616|New|Enh|2002-06-05|Some more Struts docs | | 9748|New|Enh|2002-06-10|attribute labelKeyProperty for Options tag| |10550|New|Enh|2002-07-08|Delegate path-management to ActionForwards| |10551|Opn|Enh|2002-07-08|Allow a struts-config element to extend another | |10552|New|Enh|2002-07-08|create helper objects in struts-config| |10867|Opn|Enh|2002-07-16|Add indexedProperty attribute in html taglibs | |11154|Opn|Enh|2002-07-25|html:link tag extension for multiple parameters | |11733|Opn|Enh|2002-08-15|Make error keys more specific | |12170|Opn|Enh|2002-08-29|Added functionality when extending another definit| |12301|Opn|Enh|2002-09-04|nested:messages Tag does not work as expected | |12313|Opn|Enh|2002-09-04|Chaining of RequestProcessors--contribution | |12342|Ass|Enh|2002-09-05|Add default exception handler attribute to global| |12600|New|Enh|2002-09-12|html:form tag always prepends context path to acti| |13125|Opn|Enh|2002-09-30|Lack of character-set while using html:html ta| |13521|New|Enh|2002-10-11|CombinedDispatchAction| |13544|Opn|Enh|2002-10-11|[exception] support contextRelative paths | |13565|Opn|Enh|2002-10-12|To errors, add prefix, suffix, header, footer at| |13638|Opn|Enh|2002-10-15|add Config Factory| |14068|Opn|Enh|2002-10-29|Why can't I use forwards with exception elements i| |14071|Opn|Enh|2002-10-29|Need clear info on which Struts attributes produce| |14183|New|Enh|2002-11-01|html:img does not support forward attribute | |14749|Opn|Enh|2002-11-21|Action input not starting with '/' and not a val| |15023|Opn|Enh|2002-12-03|Use attribute 'id' instead of 'name' in html:form-| |15188|Opn|Enh|2002-12-09|roles attribute of tags and definitions only allow| |15422|Opn|Enh|2002-12-17|Form Tag exportFormName attribute| |15604|Opn|Enh|2002-12-22|Struts framework should use getInstance Method for| |15670|Opn|Enh|2002-12-26|Doc for exception element needs to mention page| |15673|Opn|Enh|2002-12-26|Default Action in ActionMapping | |15805|Opn|Enh|2003-01-05|Enhance ModuleException to allow getting chained E| |15816|Opn|Enh|2003-01-06|html:form focus in pages with several forms | |15849|Opn|Enh|2003-01-07|Incorrect documentation for Developing Your Own M| |15912|Opn|Enh|2003-01-09|Client-side validation fails if not all form-field| |15921|Opn|Enh|2003-01-09|Allow relative actions in struts-config.xml | |15935|Opn|Enh|2003-01-09|WSAD 5.0 Instructions for Struts Example | |15969|Opn|Enh|2003-01-10|Ability to use TilesRequestProcessor even if it no| |16074|New|Enh|2003-01-14|html:form uses 'action' not 'input' to select mapp| |16104|Opn|Enh|2003-01-15|default handler parameter value for LookupDispatch| |16107|Opn|Enh|2003-01-15|Configure if you want to call ActionForm.reset() i| |16207|Opn|Enh|2003-01-17|Add ability to import tile attributes into a java.| |16249|Opn|Enh|2003-01-20|localized float validation|
coming out for JSF + Struts, was: Struts JSR?
NOT speaking for IBM
summary: McClanahan should clearly state *in some major publication*
* that JSF does/will not replace Struts
* how JSF and Struts will likely tend to specialize, in future
* how probable specializations will complement (and compete) in
webapp development
I.e. pretty much what he has already said in this list, but much more
visibly.
details:
Craig R. McClanahan Sat, 20 Mar 2004 20:57:04 -0800 (rearranged)
There is going to be tremendous support for JSF in the industry;
fortunately, we can continue to maintain and enhance Struts without
having to give that up (thanks to the integration library). Instead,
we can embrace it
The problem, as I see it, is how to make the industry understand that
JSF will also embrace Struts? (and not in the sense of embrace and
extend :-) More below, esp re SFIL.
My personal vision is that Struts developers will focus their energy
on the controller and model tiers, leveraging the existence of
standard (and not) technologies in the view tier.
Personally I agree strongly, and FWIW have advocated something very
similar (i.e. JSF both for view AND as a M$-killer for Model1 apps)
in local fora, e.g.
http://ns.cnconsulting.com/pipermail/juglist_trijug.org/2003q4/001106.html
ISTMT this also would also make a lotta sense for JSF, since (again,
it seems to _me_--my bosses may disagree)
* no one framework is ever gonna do all of Java MVC web application
development/execution the way that most IT folks want to do it
(since most folks can never agree on much of anything
specific :-)
* no one framework is ever gonna have all the resources/mindshare to
do all of Java MVC web application development/execution right
(presuming right could be agreed on), therefore specialization
makes sense
* MVC is a natural partition for such specialization
Unfortunately
* The JSF community seems to be putting out a competing message, not a
complementary one: JSF will replace Struts, or even JSF is a
better Struts.
· E.g. Geary said, flat out (not only is it in my notes, I believe
it was verbatim in a slide), Is JSF a replacement for Struts? Yes!
I challenged him, saying that while JSF 1.0 (with Tiles) can do
pretty much everything Struts 1.1 can, Struts 2.0 seemed to be
focused on doing things (e.g. struts-chain) that did not seem to be
in the JSF plan. At which point he backed off, but continued to
suggest that JSF should be favored for new-project development. (To
his credit, Geary also made clear that JSF and Tiles is a sweet
combination.)
· One also hears that JCP is more standard than the Apache
process, thus a more better target for development orgs. (Typically
the Apache process is also deprecated by association with the
unfortunate Struts 1.0--1.1 delays.) A popular variation asserts
that JSF will eventually become part of the J2EE spec, while Struts
never will.
* The JSF replaces Struts line has traction. I have heard it from
consultants (and not just Geary), ISVs, and from ... highly-placed
persons who I believe should know better :-(
* The JSF replaces Struts line has practical impact (which demands
a substantial, visible response--more on that farther below)
· Development organizations have limited budgets. Managers of
development orgs always want to pick _the_ winner (not just a
winner) if they can. There are of course a lotta webapps still to
be written, and still a LOT of Model1 and Model1.5 webapps out
there, many of which folks wanna make more MVC. I suspect managers
of their development groups will be most receptive to the JSF (and
not Struts) for new project development line.
· Java tool developers face an esp crowded field of Java MVC web
apps. We are gonna _hafta_ tool JSF, and we want to--it's nicely
designed, and we wanna target the {Model1, departmental developer,
SMB, ASP.NET} space. But when managers of Java tool developers hear
that JSF will bury Struts, and hear about their budgets, they are
gonna wanna say things like, going forward we expect to actively
tool JSF and to sunset Struts.
Note that while I expect tool adoption/quality to be crucial for JSF
(which very much seems built to tool), I do not consider it quite
so important for Struts. That being said, good tools help, and I am
very proud of my group's Struts tools, such as our web diagram
editor. (FWIW I expect to be equally proud of our JSF tools in the
very near future, and to continue to improve and extend our Struts
support.)
So ... what to do about this? For starters, we can advocate that
* JSF is NOT gonna make Struts obsolete
* JSF AND Struts {is, will be} a sweet combination
but unfortunately I suspect that will not be enough: something's gotta
come from the top, by which I mean (not entirely in jest)
McClanahan.
Steve Raeburn Sat, 20 Mar 2004 11:40:45 -0800 (rearranged)
As the creator of Struts and spec lead for JSF, I think Craig is in
a unique position to understand
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004, Ted Husted wrote: On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We already have the simplest thing in terms of one repo, but we have far from the simplest thing when it comes to organising within that repo. The point I was trying to make with (1) is to distinguish between organising using multiple repos versus organising within one repo. For example, if we do what you suggest below, and have 7 separate CVS repos, we will face a number of problems, as I see it: a) We will not make friends with the infrastructure folks. Each time we add a new committer, they will have to add 7 separate avail entries with that account. b) People will need to do 7 separate 'cvs update' invocations to get all of the latest code. That just doesn't seem practical to me. c) It's not clear to me that the Maven reactor could be made to work across multiple repos. And even if it could, which repo would the Maven files live in? d) Any multi-repo build would have to make assumptions about the location of the other repos on the local disk. It would be reasonable to assume that they are peers within the same directory, but that is an assumption that we would have to make. e) Web site maintenance is going to be, um, challenging. We would actually need an 8th repo for site-wide documentation, and then we'd need to have some tools to avoid having to do 8 separate 'cvs update' invocations to update the entire site on www. f) Any time we want to add something new (e.g. opt-foo or core2), we would need to go back to infrastructure and ask for yet another repo. I see little advantage of all those separate repos over just one repo, since that one repo could be organised in exactly the same way. In other words, why use separate repos over something like this: struts/ core/ taglib/ app/ opt-legacy/ opt-el/ opt-faces/ opt-sandbox/ site/ or even this: struts/ core/ taglib/ app/ opt/ legacy/ el/ faces/ sandbox/ site/ Actually, I'm not sure that a sandbox should be under 'opt' at all. I could see us using a separate repo for that, since there is precedent in both Commons and Taglibs. I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. The reason I've changed my mind since yesterday about 2 repos versus 1 (ignoring the sandbox for the moment) is that I realised that all of the CVS shuffling we want to do will make it very hard, if not impossible, to continue to work on older (pre-shuffle) versions of the product. One other minor comment: I'd prefer to use something like 'archive' over 'legacy', since the latter has a more negative connotation, in my mind at least. But I won't make a big deal of it if other people prefer 'legacy'. ;-) -- Martin Cooper We were already getting ready to change things around. And we *do* need to move things around if we are ever going to get away from a monolithic Struts to a modular Struts, were people can assemble the Struts platform they need for their application. If not now, then when? The resolution we submitted says we're suppose to rationalize Struts, so let's rationalize :) My preference would be to have a separate repository for each subproject. Each subproject represents a coherent software product or deliverable with its own release cycle. Another way of thinking of the subprojects/products is as Maven artifacts. As mentioned elsewhere, all Struts Committers can have access to all repositories, and all PMC Members have voting rights over all subprojects. I'd suggest that we setup a legacy jakarta repository that would be frozen. Directories could then be moved over to their new repositories, either from a second copy of the original repository or from a remote copy. The subprojects/repositories/artifacts/products I had in mind were: * core * taglib * app * opt-legacy * opt-el (or jstl) * opt-faces * opt-sandbox Here's some possible path-to-repository mappings. Later entries assume earlier entries were already moved. [taglib] /src/share/o.a.s/taglib - /src/o.a.s/taglib [app]
Re: Struts JSR?
Craig R. McClanahan said: ... My personal vision is that Struts developers will focus their energy on the controller and model tiers, leveraging the existence of standard (and not) technologies in the view tier. as someone using and working on the VelocityStruts project, this is great to hear! i do hope this is the path the Struts project/community takes. The Struts HTML tags have had their three years of fame :-) -- it's time to get on with life and develop innovative solutions where there are still holes in the big picture. But that's up to each of us individually, of course. ... couldn't agree more! Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004, Martin Cooper wrote:
On Sun, 21 Mar 2004, Ted Husted wrote:
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote:
Option 1 works for me. Simplest thing that could possibly work. As
you've said, we can always change things around later.
The problem is that is that we already have the simplest thing. And, if we want
multiple Maven-based products with independent release cycles, then what we have
won't work. :)
We already have the simplest thing in terms of one repo, but we have far
from the simplest thing when it comes to organising within that repo. The
point I was trying to make with (1) is to distinguish between organising
using multiple repos versus organising within one repo.
For example, if we do what you suggest below, and have 7 separate CVS
repos, we will face a number of problems, as I see it:
a) We will not make friends with the infrastructure folks. Each time we
add a new committer, they will have to add 7 separate avail entries with
that account.
b) People will need to do 7 separate 'cvs update' invocations to get all
of the latest code. That just doesn't seem practical to me.
c) It's not clear to me that the Maven reactor could be made to work
across multiple repos. And even if it could, which repo would the Maven
files live in?
d) Any multi-repo build would have to make assumptions about the location
of the other repos on the local disk. It would be reasonable to assume
that they are peers within the same directory, but that is an assumption
that we would have to make.
e) Web site maintenance is going to be, um, challenging. We would actually
need an 8th repo for site-wide documentation, and then we'd need to have
some tools to avoid having to do 8 separate 'cvs update' invocations to
update the entire site on www.
f) Any time we want to add something new (e.g. opt-foo or core2), we would
need to go back to infrastructure and ask for yet another repo.
I see little advantage of all those separate repos over just one repo,
since that one repo could be organised in exactly the same way. In other
words, why use separate repos over something like this:
struts/
core/
taglib/
app/
opt-legacy/
opt-el/
opt-faces/
opt-sandbox/
site/
or even this:
struts/
core/
taglib/
app/
opt/
legacy/
el/
faces/
sandbox/
site/
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
--
Martin Cooper
Actually, I'm not sure that a sandbox should be under 'opt' at all. I
could see us using a separate repo for that, since there is precedent in
both Commons and Taglibs.
I am now leaning towards 3 repos myself:
struts-legacy
This is our current repo, renamed. I don't really care for this
name, but I can't think of anything better right now, and I hate
sticking numbers in repo names, because they become invalid
quite rapidly if they are associated with versions (unless we
start a new repo for each major version, a la Tomcat, but I
don't like that idea either, for CVS history reasons).
struts
This would be structured per one of the suggestions above.
struts-sandbox
A separate sandbox, a la Commons and Taglibs.
The reason I've changed my mind since yesterday about 2 repos versus 1
(ignoring the sandbox for the moment) is that I realised that all of the
CVS shuffling we want to do will make it very hard, if not impossible, to
continue to work on older (pre-shuffle) versions of the product.
One other minor comment: I'd prefer to use something like 'archive' over
'legacy', since the latter has a more negative connotation, in my mind at
least. But I won't make a big deal of it if other people prefer 'legacy'.
;-)
--
Martin Cooper
We were already getting ready to change things around. And we *do* need to move
things around if we are ever going to get away from a monolithic Struts to a
modular Struts, were people can assemble the Struts platform they need for their
application. If not now, then when? The resolution we submitted says we're suppose
to rationalize Struts, so let's rationalize :)
My preference would be to have a separate repository for each subproject. Each
subproject represents a coherent software product or deliverable with its own
release cycle. Another
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Martin Cooper said:
...
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
interesting. i've wondered before if the VelocityStruts code (but not all of
Velocity Tools, of course) might be better off in Struts land. something to
keep in mind i suppose.
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
Tiles works great for us, and we are able to use it in such a way that we can
mix and match JSP and Velocity tiles. i definitely think Tiles can and should
avoid dependence on any particular presentation technology.
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
At 10:55 AM -0800 3/21/04, Martin Cooper wrote: I see little advantage of all those separate repos over just one repo, since that one repo could be organised in exactly the same way. In other words, why use separate repos over something like this: I was trying to figure out what people meant by multiple repositories. I'm with Martin here. We don't need multiple repositories; I think we can organize a single repository in such a way that achieves the same goal with less administrative overhead. I do see some value to having struts-legacy distinct from struts (and have no strong opinion regarding archive vs. legacy). Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27662] - Add filter attribute to nested:options and nested:optionsCollection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27662. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27662 Add filter attribute to nested:options and nested:optionsCollection [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-22 00:34 --- Thanks for catching this Firepica, and thanks for providing the patch John! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide struts-nested.xml
husted 2004/03/21 16:37:05 Modified:doc/userGuide struts-nested.xml Log: Apply #27662 Add filter attribute to nested:options and nested:optionsCollection submitted by Firepica and John Cavacas. Revision ChangesPath 1.26 +12 -0 jakarta-struts/doc/userGuide/struts-nested.xml Index: struts-nested.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-nested.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- struts-nested.xml 16 Jan 2004 04:12:06 - 1.25 +++ struts-nested.xml 22 Mar 2004 00:37:05 - 1.26 @@ -1993,6 +1993,12 @@ /attribute attribute + namefilter/name + requiredfalse/required + rtexprvaluetrue/rtexprvalue +/attribute + + attribute namelabelName/name requiredfalse/required rtexprvaluetrue/rtexprvalue @@ -2045,6 +2051,12 @@ and usage details. /p /info + +attribute + namefilter/name + requiredfalse/required + rtexprvaluetrue/rtexprvalue +/attribute attribute namelabel/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/upload CommonsMultipartRequestHandler.java
husted 2004/03/21 16:41:34
Modified:src/share/org/apache/struts/upload
CommonsMultipartRequestHandler.java
Log:
Apply #27702 MultipartPost values cannot contain latin1 characters when server is
running on linux reported by Raimo Ihle.
Revision ChangesPath
1.16 +9 -5
jakarta-struts/src/share/org/apache/struts/upload/CommonsMultipartRequestHandler.java
Index: CommonsMultipartRequestHandler.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/CommonsMultipartRequestHandler.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- CommonsMultipartRequestHandler.java 14 Mar 2004 06:23:48 - 1.15
+++ CommonsMultipartRequestHandler.java 22 Mar 2004 00:41:34 - 1.16
@@ -409,7 +409,11 @@
try {
value = item.getString(request.getCharacterEncoding());
} catch (Exception e) {
-value = item.getString();
+try {
+ value = item.getString(ISO-8859-1);
+} catch (java.io.UnsupportedEncodingException uee) {
+ value = item.getString();
+}
}
if (request instanceof MultipartRequestWrapper) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27702] - MultipartPost values cannot contain latin1 characters when server is running on linux
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27702. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27702 MultipartPost values cannot contain latin1 characters when server is running on linux [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-22 00:42 --- Thanks Raimo! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestFrameTag1.jsp TestFrameTag3.jsp
martinc 2004/03/21 16:45:28 Modified:web/test/test/org/apache/struts/taglib/html TestFrameTag1.jsp TestFrameTag3.jsp Log: Fix some tests that were broken when module support was added to TagUtils.computeURL(). Revision ChangesPath 1.4 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag1.jsp Index: TestFrameTag1.jsp === RCS file: /home/cvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag1.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- TestFrameTag1.jsp 26 Dec 2003 22:08:01 - 1.3 +++ TestFrameTag1.jsp 22 Mar 2004 00:45:28 - 1.4 @@ -87,7 +87,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -98,7 +98,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -108,7 +108,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -118,7 +118,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -128,7 +128,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -138,7 +138,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -148,7 +148,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -158,7 +158,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, null, thisMap, null, false)%
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 12:05:44 -0800, Nathan Bubna wrote:
Martin Cooper said:
..
Another thought on this. When we get to Struts 2, I'd like to see
us remove all of the JSP-ness of Struts from the core, and also
add some degree of support for other presentation technologies,
such as XSLT and Velocity. So, instead of having 'taglib' where
it is in the above tree, we might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
interesting. i've wondered before if the VelocityStruts code (but
not all of Velocity Tools, of course) might be better off in Struts
land. something to keep in mind i suppose.
At this point, I'd be in favor of that. :)
I originally encouraged setting up VelocityStruts under Velocity, since the had a
broader base than Struts. (And projects like Maverick proved that to be so.)
Developing the Struts Toolset under Apache Struts might be a good idea now, especially
as we move into a 2.0 timeframe. I think exposure to the Velocity notion of Tools
would be a good thing for Struts developers.
Personally, I think it would be great if Velocity went TLP and brought N-Velocity in
under Apache. Especially now that HTTPD is moving toward adding .NET support.
But, that's just me.
Incidentally, where would Tiles land in all of this? In theory,
it's not tied to JSP, but rather to Servlets, so it might be
applicable to some other presentation technologies, but clearly
not all.
Tiles works great for us, and we are able to use it in such a way
that we can mix and match JSP and Velocity tiles. i definitely
think Tiles can and should avoid dependence on any particular
presentation technology.
Agreed. It might be a good idea of thinking of Tiles as a subproject, especially since
people may want to use it with JSF.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 10:55:00 -0800 (PST), Martin Cooper wrote: I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. This would be fine with me. Checkout granularity cuts both ways. If you are actually working in all aspects of a project, then it's more checkouts. If you are not, then you spend more time checking out code that you don't care about. (Commons is getting to be a chore these days.) My experience with multi-project Maven builds is that its not difficult so long as the JARs are placed in a local repository where other Maven builds can find them. But either way works, it's all good. My suggestions were colored by experience in environments like SourceForge where these sort of things are automated and easy to do. But, if a minimum number of repositories will make it easier for infrastructure, then, absolutely, I'm all for that. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 11:50:27 -0800 (PST), Martin Cooper wrote: Incidentally, where would Tiles land in all of this? In theory, it's not tied to JSP, but rather to Servlets, so it might be applicable to some other presentation technologies, but clearly not all. Yes, it might be a good idea to bring Tiles and Validator up as top-level directories. We might want to think about ways that other frameworks, like JSF, could use these without have to buy into the whole 900lb Struts gorilla. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Quoting Martin Cooper [EMAIL PROTECTED]: On Sun, 21 Mar 2004, Ted Husted wrote: On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We already have the simplest thing in terms of one repo, but we have far from the simplest thing when it comes to organising within that repo. The point I was trying to make with (1) is to distinguish between organising using multiple repos versus organising within one repo. For example, if we do what you suggest below, and have 7 separate CVS repos, we will face a number of problems, as I see it: a) We will not make friends with the infrastructure folks. Each time we add a new committer, they will have to add 7 separate avail entries with that account. That turns out not to be the case, for at least two reasons: * A single avail line can be attached to multiple repositories (as is already true, for example, for Tomcat's multiple repos). * Infrastructure needn't be bothered with CVS karma issues anyway ... lots of folks (including me) can do that edit directly. b) People will need to do 7 separate 'cvs update' invocations to get all of the latest code. That just doesn't seem practical to me. At work our CVS admins have set up aliases so you can do a single cvs co or cvs update on an alias and get them all at once. Don't know how that works with IDEs that interact, but it certainly works sweetly from the command line. c) It's not clear to me that the Maven reactor could be made to work across multiple repos. And even if it could, which repo would the Maven files live in? I plead clueless on the Maven-related aspects of this, but have seen that the Geronimo folks seem to have a pretty good multi-subproject setup going (albeit from a single repository). d) Any multi-repo build would have to make assumptions about the location of the other repos on the local disk. It would be reasonable to assume that they are peers within the same directory, but that is an assumption that we would have to make. e) Web site maintenance is going to be, um, challenging. We would actually need an 8th repo for site-wide documentation, and then we'd need to have some tools to avoid having to do 8 separate 'cvs update' invocations to update the entire site on www. I think we should rip the website stuff out of the webapps anyway. f) Any time we want to add something new (e.g. opt-foo or core2), we would need to go back to infrastructure and ask for yet another repo. Nope ... just an additional name on the avail list, something that I (or anyone else with cvsadmin karma) can do. I see little advantage of all those separate repos over just one repo, since that one repo could be organised in exactly the same way. In other words, why use separate repos over something like this: struts/ core/ taglib/ app/ opt-legacy/ opt-el/ opt-faces/ opt-sandbox/ site/ or even this: struts/ core/ taglib/ app/ opt/ legacy/ el/ faces/ sandbox/ site/ Actually, I'm not sure that a sandbox should be under 'opt' at all. I could see us using a separate repo for that, since there is precedent in both Commons and Taglibs. I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. The reason I've changed my mind since yesterday about 2 repos versus 1 (ignoring the sandbox for the moment) is that I realised that all of the CVS shuffling we want to do will make it very hard, if not impossible, to continue to work on older (pre-shuffle) versions of the product. One other minor comment: I'd prefer to use something like 'archive' over 'legacy', since the latter has a more negative connotation, in my mind at least. But I won't make a big deal of it if other people prefer 'legacy'. ;-) I'd be happy with either the seven approach or the three approach. As you've concluded, I don't see how we can gracefully refactor and continue to work on the old code with only one. Maybe struts-original has better connotations? I'm also very willing to defer any decision to migrate to SVN ... CVS, for all its warts,
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Quoting Martin Cooper [EMAIL PROTECTED]:
On Sun, 21 Mar 2004, Martin Cooper wrote:
On Sun, 21 Mar 2004, Ted Husted wrote:
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote:
Option 1 works for me. Simplest thing that could possibly work. As
you've said, we can always change things around later.
The problem is that is that we already have the simplest thing. And, if
we want multiple Maven-based products with independent release cycles, then
what we have won't work. :)
We already have the simplest thing in terms of one repo, but we have far
from the simplest thing when it comes to organising within that repo. The
point I was trying to make with (1) is to distinguish between organising
using multiple repos versus organising within one repo.
For example, if we do what you suggest below, and have 7 separate CVS
repos, we will face a number of problems, as I see it:
a) We will not make friends with the infrastructure folks. Each time we
add a new committer, they will have to add 7 separate avail entries with
that account.
b) People will need to do 7 separate 'cvs update' invocations to get all
of the latest code. That just doesn't seem practical to me.
c) It's not clear to me that the Maven reactor could be made to work
across multiple repos. And even if it could, which repo would the Maven
files live in?
d) Any multi-repo build would have to make assumptions about the location
of the other repos on the local disk. It would be reasonable to assume
that they are peers within the same directory, but that is an assumption
that we would have to make.
e) Web site maintenance is going to be, um, challenging. We would actually
need an 8th repo for site-wide documentation, and then we'd need to have
some tools to avoid having to do 8 separate 'cvs update' invocations to
update the entire site on www.
f) Any time we want to add something new (e.g. opt-foo or core2), we would
need to go back to infrastructure and ask for yet another repo.
I see little advantage of all those separate repos over just one repo,
since that one repo could be organised in exactly the same way. In other
words, why use separate repos over something like this:
struts/
core/
taglib/
app/
opt-legacy/
opt-el/
opt-faces/
opt-sandbox/
site/
or even this:
struts/
core/
taglib/
app/
opt/
legacy/
el/
faces/
sandbox/
site/
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
I think Ted's been advocating a similar philosophy, although any support for JSF
is going to be an interesting one in this kind of hierarchy, because you can
use JSF via JSP or through other presentation technologies as well.
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
I think the presentation-tier-independent things about Tiles (like mapping
forwards to definitions) should be built in to the core, so there isn't any
such thing as a separate TilesRequestProcessor (or a separate chain or
whatever). In turn, this probably means we might need an API abstraction that
alternative presentation tier technologies can use to integrate themselves into
the underlying support.
--
Martin Cooper
Craig
Actually, I'm not sure that a sandbox should be under 'opt' at all. I
could see us using a separate repo for that, since there is precedent in
both Commons and Taglibs.
I am now leaning towards 3 repos myself:
struts-legacy
This is our current repo, renamed. I don't really care for this
name, but I can't think of anything better right now, and I hate
sticking numbers in repo names, because they become invalid
quite rapidly if they are associated with versions (unless we
start a new repo for each major version, a la Tomcat, but I
don't like that idea either, for CVS history reasons).
struts
This would be structured per one of the suggestions above.
struts-sandbox
A separate sandbox, a la Commons and Taglibs.
The reason I've changed my mind since yesterday about 2 repos versus 1
(ignoring the sandbox for the moment) is that I realised that all of the
CVS shuffling we want to do will make it very hard, if not impossible, to
continue to work on older (pre-shuffle) versions of the product.
One other minor comment:
Re: coming out for JSF + Struts, was: Struts JSR?
On Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM) wrote: summary: McClanahan should clearly state *in some major publication* IMHO, either people like us will be able use JSF without Struts, or we won't. If we can, great. Less is more. If we can't, we'll create whatever components we need to make it so. Darwin will decide. As long as any of us need Struts, we'll keep developing Struts. Period. What other people say doesn't matter. If that want to use what we use, great. If not, also great. It will still work the same for us either way. :) And, of course, Struts isn't just about JSP tags. A lot of people use Struts with Velocity and XLST templates. JSF support for these technologies is a ways off yet. My real feeling is that struts-dev doesn't need to get swept up in the discussions of what-might-be. Market share isn't important. What is important is that we develop what we need to use today so that we can be using it tomorrow. Not the figurative tomorrow, but the literal one :) If anyone is *really* interested in showing what a significant Struts+JSF application looks like, then someone should roll up their own sleeves and just do it. I'd recommend the JPetstore as a likely starting point :) http://www.ibatis.com/jpetstore/jpetstore.html Craig's often said that he'd rather be coding than writing about code. Me, I'm happy doing either :) -- But I think either of us would rather be developing Struts than evangelizing Struts. The proof of the pudding is in the taste. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Ted Husted wrote: On Sun, 21 Mar 2004 10:55:00 -0800 (PST), Martin Cooper wrote: I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. This would be fine with me. Checkout granularity cuts both ways. If you are actually working in all aspects of a project, then it's more checkouts. If you are not, then you spend more time checking out code that you don't care about. (Commons is getting to be a chore these days.) My experience with multi-project Maven builds is that its not difficult so long as the JARs are placed in a local repository where other Maven builds can find them. But either way works, it's all good. I think the point in favor of less repositories is that it's easy to make one module look like many modules (via aliases) but tricky to make many repositories look like one repository. Plus each repository has its own CVSROOT, etc.. -Paul My suggestions were colored by experience in environments like SourceForge where these sort of things are automated and easy to do. But, if a minimum number of repositories will make it easier for infrastructure, then, absolutely, I'm all for that. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestFrameTag3.jsp TestFrameTag5.jsp TestFrameTag7.jsp TestImgTag1a.jsp TestImgTag3a.jsp TestImgTag5a.jsp TestImgTag7a.jsp TestLinkTag1.jsp TestLinkTag3.jsp TestLinkTag4.jsp TestLinkTag5.jsp TestLinkTag6.jsp TestLinkTag7.jsp TestLinkTag8.jsp
martinc 2004/03/21 22:06:58 Modified:web/test/test/org/apache/struts/taglib/html TestFrameTag3.jsp TestFrameTag5.jsp TestFrameTag7.jsp TestImgTag1a.jsp TestImgTag3a.jsp TestImgTag5a.jsp TestImgTag7a.jsp TestLinkTag1.jsp TestLinkTag3.jsp TestLinkTag4.jsp TestLinkTag5.jsp TestLinkTag6.jsp TestLinkTag7.jsp TestLinkTag8.jsp Log: Fix remaining tests that were broken when module support was added to TagUtils.computeURL(). (Man, I wish Java had named parameters!) Revision ChangesPath 1.5 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag3.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag3.jsp.diff?r1=1.4r2=1.5 1.4 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag5.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag5.jsp.diff?r1=1.3r2=1.4 1.4 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag7.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag7.jsp.diff?r1=1.3r2=1.4 1.4 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag1a.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag1a.jsp.diff?r1=1.3r2=1.4 1.4 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag3a.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag3a.jsp.diff?r1=1.3r2=1.4 1.4 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag5a.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag5a.jsp.diff?r1=1.3r2=1.4 1.4 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag7a.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestImgTag7a.jsp.diff?r1=1.3r2=1.4 1.5 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag1.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag1.jsp.diff?r1=1.4r2=1.5 1.5 +10 -10 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag3.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag3.jsp.diff?r1=1.4r2=1.5 1.5 +28 -28 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag4.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag4.jsp.diff?r1=1.4r2=1.5 1.5 +27 -27 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag5.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag5.jsp.diff?r1=1.4r2=1.5 1.5 +28 -28 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag6.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag6.jsp.diff?r1=1.4r2=1.5 1.5 +27 -27 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag7.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag7.jsp.diff?r1=1.4r2=1.5 1.5 +28 -28 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag8.jsp http://cvs.apache.org/viewcvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestLinkTag8.jsp.diff?r1=1.4r2=1.5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/conf/test/tomcat50 - New directory
martinc 2004/03/21 23:06:12 jakarta-struts/conf/test/tomcat50 - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/conf/test/tomcat50 server.xml
martinc 2004/03/21 23:16:37
Modified:.build-tests.xml build.xml
Added: conf/test/tomcat50 server.xml
Log:
Add initial support for Cactus tests running against Tomcat 5.0. The tests
themselves run just fine, but for some reason Tomcat doesn't stop once the
tests have completed. (I have not added the 5.0 targets to the test suite
because of this.)
Revision ChangesPath
1.25 +83 -0 jakarta-struts/build-tests.xml
Index: build-tests.xml
===
RCS file: /home/cvs/jakarta-struts/build-tests.xml,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- build-tests.xml 10 Oct 2003 22:09:26 - 1.24
+++ build-tests.xml 22 Mar 2004 07:16:37 - 1.25
@@ -631,6 +631,89 @@
/target
+!--
+Prepare test directory structure for Tomcat 5.0 servlet engine
+--
+target name=prepare.test.tomcat.50 depends=prepare.test.war
if=tomcat.home.50
+
+property name=out.tomcat.50.dir
value=${out.test.dir}/servers/tomcat50/
+filter token=out.tomcat.50.full.dir value=${out.tomcat.50.dir}/
+filter token=tomcat.connector.port value=${cactus.contextPort}/
+
+mkdir dir=${out.tomcat.50.dir}/webapps/
+mkdir dir=${out.tomcat.50.dir}/conf/
+
+ !-- Delete old directory so new war is unzipped --
+delete dir=${out.tomcat.50.dir}/webapps/test/
+
+!-- Copy war file --
+copy file=${out.test.dir}/test.war todir=${out.tomcat.50.dir}/webapps/
+
+!-- Copy configuration files --
+copy file=${conf.test.dir}/tomcat50/server.xml
+todir=${out.tomcat.50.dir}/conf filtering=on/
+
+/target
+
+!--
+Run unit tests on Tomcat 5.0 servlet engine
+--
+target name=test.tomcat.50 depends=prepare.test.tomcat.50
+
+!-- Start the servlet engine, wait for it to be started, run the
+ unit tests, stop the servlet engine, wait for it to be stopped.
+ The servlet engine is automatically stopped if the tests fail for
+ any reason.--
+
+runservertests testURL=${cactus.contextURL}
+startTarget=start.tomcat.50
+stopTarget=stop.tomcat.50
+testTarget=run.test/
+
+/target
+
+!--
+Start Tomcat 5.0 servlet engine
+--
+target name=start.tomcat.50
+
+java classname=org.apache.catalina.startup.Bootstrap fork=yes
+jvmarg value=-Dcatalina.home=${tomcat.home.50}/
+jvmarg value=-Dcatalina.base=${tomcat.home.50}/
+arg value=-config/
+arg value=${out.tomcat.50.dir}/conf/server.xml/
+arg value=start/
+classpath
+ pathelement location=${java.home}/../lib/tools.jar/
+ fileset dir=${tomcat.home.50}
+ include name=bin/bootstrap.jar/
+!-- include name=server/catalina.jar/ --
+ /fileset
+/classpath
+/java
+
+/target
+
+!--
+Stop Tomcat 5.0 servlet engine
+--
+target name=stop.tomcat.50
+
+java classname=org.apache.catalina.startup.Bootstrap fork=yes
+jvmarg value=-Dcatalina.home=${tomcat.home.50}/
+jvmarg value=-Dcatalina.base=${tomcat.home.50}/
+arg value=-config/
+arg value=${out.tomcat.50.dir}/conf/server.xml/
+arg value=stop/
+classpath
+ fileset dir=${tomcat.home.50}
+ include name=bin/bootstrap.jar/
+!-- include name=server/catalina.jar/ --
+ /fileset
+/classpath
+/java
+
+/target
!-- Non-Cactus JUnit Based Tests --
1.131 +16 -0 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.130
retrieving revision 1.131
diff -u -r1.130 -r1.131
--- build.xml 29 Feb 2004 22:55:45 - 1.130
+++ build.xml 22 Mar 2004 07:16:37 - 1.131
@@ -868,6 +868,22 @@
/target
+target name=skip.tomcat.50 unless=tomcat.home.50
+echo message=*/
+echo message=WARNING : Property 'tomcat.home.50' has not been set./
+echo message= No test will be run on that servlet engine./
+echo message=*/
+echo message=/
+/target
+
+target name=test.tomcat.50 if=tomcat.home.50
+ depends=skip.tomcat.50,compile.library
+ description=Run unit tests on Tomcat 5.0
+echo
