Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Martin Cooper wrote: On Mon, 22 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to
Re: Splitting struts-config into multiple jar and read them as resource stream
Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts-config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? Filippo Munafò -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2004 18:33 To: 'Struts Dev Mailing List' Subject: Re: Splitting struts-config into multiple jar and read them as resource stream Quoting Joe Germuska [EMAIL PROTECTED]: We'd like not to subclass ActionServlet, but is really difficult to do something like this outside the ActionServlet hierarchy mainly 'cause of the call to initConfigDigester(), that's obviously protected. The questions are: - is there a way to do the same without subclassing ActionServlet? - do you think is it reasonable to include a similar feature in the main source tree on CVS (dynamic read pieces of struts-config from jar files)? It seems plausible that a factory class could be factored out of the ActionServlet. I'd think you could do this in Struts 1 in a backwards compatible fashion. I think people would like to be able to configure struts from a variety of sources; another popular request is for dynamic reconfiguration -- without a redeploy -- but that's a different and more complicated question. Along the same lines, one of the things we did in JavaServer Faces (with regards to configuration) is to have the controller servlet automatically recognize META-INF/faces-config.xml resources in any JAR files that were included in the application. This makes it very easy to package a module, or some other sub-unit of an overall webapp, as a single JAR file that self-configures. 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote: On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? Well, as you mentioned, another way to go would be for some one to write a tool that could burst and rejar an arbitrary set of jars. (If one doesn't already exist.) The source for such a tool could live in the core since it's just something a volunteer would run offline and the upload. It wouldn't be a true deliverable. And, I'm not convinced that we even need to do such a thing. Even without a few extra JARs of our own, there are still all the Commons JARs. (Though I suppose we could roll together those too.) I'd tend to leave this for a end-user to do, say if there were distributing a particular Struts distribution to several teams in an enterprise. But it would be nice to provide a tool for this (if someone had the itch to write it.) It really sounds like a job for Sun :) On Mon, 22 Mar 2004 20:50:24 -0800 (PST), Martin Cooper wrote: I'd be open to it, but I think we have a lot of things we'd want to do to get our own house in order before we actually take action on this. I also think it might be a tricky issue in some respects. For example, we'll be faced with making subjective decisions on potentially substantial bodies of code, leading to the possibility of why not mine? kinds of things. For larger code bases, we'd also likely need to have some discussions with the incubator folks. But, as you say, let's get our own house in order first, and then come back and talk about this some more. And in deciding how to renovate our house, let's keep in mind that we may be having more children :) How about if we split the difference: core module: /core /site /apps opt-modules: * opt-taglib * opt-el * opt-faces * opt-dev (sandbox) So, we'd go from seven to five. Then, later on, if we invite some of our friends to join us, and they move in, we just add more opt modules. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
On Tue, 23 Mar 2004 02:49:44 +, Peter A. Pilgrim wrote: Would the same principle work with people who have taken Struts and integrated or embedded as another framework? Having spent some type integrating 1.1 into Expresso Framework in 2002, in our case can we be classified as Struts extenders? Also some repository will not want to become a sub project of Struts because of logical sense, politics or legal entity status? Something like Expresso is large enough to be a framework in its own right. If the Expresso Community ever wanted to apply to Apache for incubation as an ASF project, I'd certainly support the idea. Or, if there were a coherent subset of Expresso that could be used by Struts developers as an extension, independently of Expresso, that might be something that could live as a Struts opt-* modules. Personally, I'd love to see a proposal from Expresso of some helpful code that they would like to grant to the ASF -- especially if it gave us an excuse to nominate you as a committer, Peter. :) Of course, it is very true that not every open source project is suited for Apache. There is a specific Apache culture and management style that doesn't work for everyone. We would never simply annex a codebase and then redistribute it under the ASL. We consider the community behind a codebase to be more important than the code itself. It's the extension's community that we would pursue, more than the code itself. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc bylaws.xml
husted 2004/03/23 03:49:34 Added: doc bylaws.xml Log: Initial draft of bylaws page. Not linked in. Other pages to follow, as discussed. Revision ChangesPath 1.1 jakarta-struts/doc/bylaws.xml Index: bylaws.xml === ?xml version=1.0? document url=./bylaws.xml properties titleProject Management Committee Bylaws/title /properties body section name=Project Management Committee Bylaws p Struts is a Project of the a href=http://apache.org/foundation; Apache Software Foundation/a (ASF), formed by a resolution of the a href=http://apache.org/foundation/board/;ASF Board of Directors/a. As an ASF Project, Struts is subject to the a href=http://apache.org/foundation/bylaws.html;ASF Bylaws/a and the direction of the ASF Board. /p p The Project is administered by the Vice President of Struts. The Vice President is appointed by the ASF Board. The Vice President is assisted by the Project Management Committee (PMC) and also serves as the PMC chair. The PMC may nominate new members. Nominees may then be approved with a 3/4 majority vote of the PMC. Membership can be revoked by a unanimous vote of all the active PMC members other than the member in question. The list of active PMC members can be found on our a href=volunteers.htmlVolunteers page/a. /p p bDuties/bbr /The PMC is responsible for the day-to-day management of the Struts Project. The PMC oversees all changes made to the codebase. The PMC must ensure that all code under a Apache Struts CVS is the lawful property of the Foundation and that it may be distributed under the a href=http://apache.org/licenses/; Apache Software License/a. All releases of a Struts subproject must be sanctioned by the Project Management Committee. /p p bSubprojects/bbr / Subprojects are the Project's unit of release. Each subproject should represent an implementation of the Struts core or a releated component. Each subproject should focus on creating, maintaining, and releasing a single softare product or deliverable. /p p All PMC Members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote. All Committers have write access to all subprojects. Subprojects are units of release, not units of work. /p p bCreation of subprojects/bbr / PMC members may propose the creation of new subprojects. Proposals are to contain the scope of the project, identify the initial source from which the project is to be populated, identify the mailing list(s) if any which are to be created, and identify the initial set of committers. Creation of a new subproject requires approval by a 3/4 majority vote of the PMC. /p /section /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
On Tue, 23 Mar 2004 06:31:51 -0500, Ted Husted wrote: Something like Expresso is large enough to be a framework s/framework/Apache project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Ted Husted wrote: On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote: Well, as you mentioned, another way to go would be for some one to write a tool that could burst and rejar an arbitrary set of jars. (If one doesn't already exist.) The source for such a tool could live in the core since it's just something a volunteer would run offline and the upload. It wouldn't be a true deliverable. And, I'm not convinced that we even need to do such a thing. Even without a few extra JARs of our own, there are still all the Commons JARs. (Though I suppose we could roll together those too.) I'd tend to leave this for a end-user to do, say if there were distributing a particular Struts distribution to several teams in an enterprise. But it would be nice to provide a tool for this (if someone had the itch to write it.) It really sounds like a job for Sun :) Did you need something beyond what ANT already provides? An untested example: target name=bundle.struts jar jarfile=lib/struts-all.jar zipgroupfileset dir=lib/struts include name=**/*.jar / /zipgroupfileset /jar /target -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Ted Husted wrote: On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) Now it clearer. Well this is how Expresso CVS is laid out and an old investment bank project which I was involved in a couple years ago was laid out like that as well. I guess the hard part of copying jar and build a web app from CVS modules have already been discussed. Still it is the only way to go if you want to Struts to be modular. So +1 from me. -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Splitting struts-config into multiple jar and read them as resource stream
Do you mean the ChainListener? If yes, is it 'the solution' or 'the beginning, the way to follow'? How can I 'plug' it into struts to load the struts-config from JAR? Filippo -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 12:34 To: Struts Developers List Subject: Re: Splitting struts-config into multiple jar and read them as resource stream On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? -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]
Re: coming out for JSF + Struts, was: Struts JSR?)
+1 At 03:15 AM 3/23/2004, you wrote: On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote: On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? Well, as you mentioned, another way to go would be for some one to write a tool that could burst and rejar an arbitrary set of jars. (If one doesn't already exist.) The source for such a tool could live in the core since it's just something a volunteer would run offline and the upload. It wouldn't be a true deliverable. And, I'm not convinced that we even need to do such a thing. Even without a few extra JARs of our own, there are still all the Commons JARs. (Though I suppose we could roll together those too.) I'd tend to leave this for a end-user to do, say if there were distributing a particular Struts distribution to several teams in an enterprise. But it would be nice to provide a tool for this (if someone had the itch to write it.) It really sounds like a job for Sun :) On Mon, 22 Mar 2004 20:50:24 -0800 (PST), Martin Cooper wrote: I'd be open to it, but I think we have a lot of things we'd want to do to get our own house in order before we actually take action on this. I also think it might be a tricky issue in some respects. For example, we'll be faced with making subjective decisions on potentially substantial bodies of code, leading to the possibility of why not mine? kinds of things. For larger code bases, we'd also likely need to have some discussions with the incubator folks. But, as you say, let's get our own house in order first, and then come back and talk about this some more. And in deciding how to renovate our house, let's keep in mind that we may be having more children :) How about if we split the difference: core module: /core /site /apps opt-modules: * opt-taglib * opt-el * opt-faces * opt-dev (sandbox) So, we'd go from seven to five. Then, later on, if we invite some of our friends to join us, and they move in, we just add more opt modules. -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]
RE: OT: Struts JSR?
First let's be very clear. It's *not* about market share. I have to disagree with you on this one. Struts is the defacto standard because of its market share. Why does Struts need to be defacto standard? Struts in itself has no value, IMHO. Obviously Struts developers have an emotional investment on Struts, but application developers, such as myself, don't care which framework we use as long as it works. If something better than Struts comes along, I'll switch regardless of market share or standards. You guys do not need to worry about market share, just about making Struts the best framework available. If you build it, they will come. -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
FWIW I'm with Martin on this. I don't understand the advantage having separate repositories will give us. Even under one top lever repository directory, we can organize the Struts product(s) however we like. The only advantage I can see in having separate repositories would be to make it easier to grant different groups of committers access to different areas. But that's not what we want to do anyway. Another reason NOT to split into several top level directories is that it adds more clutter to the already busy Apache repository. IMHO fewer top level directories makes it easier for people to find what they need. If there's a compelling reason to split into several top-level repository directories that hasn't been stated (or I've missed), please let me know, otherwise I'd prefer to keep as few as possible. But it's not a life or death issue either way :-) Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: March 22, 2004 11:50 PM To: Craig R. McClanahan Cc: Struts Developers List Subject: Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?) On Mon, 22 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's
Re: Splitting struts-config into multiple jar and read them as resource stream
Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Tue, 23 Mar 2004, Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. Before anyone does dash off and write this, I'd like to have a brief discussion about this in relation to multi-module applications, and removing any need to modify web.xml when adding or removing modules. This is something I did in a project about a year ago, very successfully, so I think it's worth adding to the Struts core. In a similar vein, I'd like to talk about separating out the config reading somewhat, to allow for alternative mechanisms. Unfortunately, I'm about to go off to a 4-hour meeting ;-( so I can't expound further right now. More later... -- Martin Cooper -Ted. 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Peter A. Pilgrim wrote: Ted Husted wrote: On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) Now it clearer. Well this is how Expresso CVS is laid out and an old investment bank project which I was involved in a couple years ago was laid out like that as well. I guess the hard part of copying jar and build a web app from CVS modules have already been discussed. Still it is the only way to go if you want to Struts to be modular. So +1 from me. Let me clarify my own post ( grabbing GNU Emacs and picture-mode ). The way it is organised under the current CVS module is `src' for Java source and `web' file. So you could live with this structure. 1) I think you should keep the same elementary structure Case#1 CVS Repository | + core (including tiles and validator) | | | +---web | +---src | + examples | | | +---web | +---src | + site | | | +---web | +---src | + whiteboard (or sandbox) | | ... + opt-taglib | | ... + opt-el | | ... + opt-faces 2) Or you can remove all the `web' stuff and merge under one `web' (public_html) module. But I have never liked this idea as a workable solution. I seen it once long ago and I hated it then and now. Case#2 CVS Repository | +--web | | | +-- examples | +-- core | +-- ... | + core (including tiles and validator) | | | +---src | + examples | | | +---src | + site | | | +---src | + whiteboard (or sandbox) | | ... + opt-taglib | | ... + opt-el | | ... + opt-faces In any case in order to build a single WAR or EAR, can be quite hard on the ANT XML build file. There is a lot of possible copying of files, JARing, and/or JARing involved in order to build a release. In my limited architectural experience you only need to get the initial build right once, then you can forget about it, as long as other people developers understand what is going on. 1) Developers have to understand the project directory structure and standards in order to not to step on each other shoes. e.g In order to build a WAR of all modules that runs out of the box, you cannot have two different sub project developers, say from `examples' and `site', each with a CVS file called CVS-MODULE/web/some/foobar/acme.jsp. Conflict of interest on files. The same applies to source code and resources as well. Top level package names must be agreed well in advanced. Of the course the current mapping CVS-MODULE/src/shared/org/apache/struts/** can be simplified to: CVS-MODULE/src/org/apache/struts/** in the new modular structure. 2) Organise fragments that are included into a larger configuration files. e.g Each sub project may have TLD files, Properties files, i18n resources, or Servlet Mappings and Servlet Paths that are merged into a final file. Servlet mapping fragments are inserted into the final web.xml file. Same goes for any Servlet filters. NB: This is similar to using XML includes notation in order build a giant `struts-config.xml', which shared by a large development team. I am not sure if you need to do this as committers. Only I mention it if you need to build a Struts Adventure Petstore demonstration example in the far off future. Will properties file probably have to merge them with ANT core tasks or some custom made build tool. 3) Agree to keep to a convention document so that the mythical `master' build.xml does not blow up into smitherings. 4) Some one has to write standards conventions document so that everybody knows what time it is, and plays in a solid team. 5) Another other business obviously include JUnit, Struts documentation, javadoc etc etc It is starting resemble a big project with more 10+ developers working across CVS modules. Having said all that I wish you great bundle of luck. Regards -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail:
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
Ted Husted wrote: On Tue, 23 Mar 2004 02:49:44 +, Peter A. Pilgrim wrote: Would the same principle work with people who have taken Struts and integrated or embedded as another framework? Having spent some type integrating 1.1 into Expresso Framework in 2002, in our case can we be classified as Struts extenders? Also some repository will not want to become a sub project of Struts because of logical sense, politics or legal entity status? Something like Expresso is large enough to be a framework in its own right. If the Expresso Community ever wanted to apply to Apache for incubation as an ASF project, I'd certainly support the idea. Or, if there were a coherent subset of Expresso that could be used by Struts developers as an extension, independently of Expresso, that might be something that could live as a Struts opt-* modules. Personally, I'd love to see a proposal from Expresso of some helpful code that they would like to grant to the ASF -- especially if it gave us an excuse to nominate you as a committer, Peter. :) Not a decision I could make on my own, dear boy. You would have to discuss it with Expresso repository copyright holders. Just like the advert that ask please get permission from the (telephone) bill payer before calling the premium rate competition number. My view might be paraphrased as who ever legally owns the CVS repository and pays real money annually to host it to world wide web has the right to do what they please with the source code base. As for the framework itself, last year, we were looking at some componentisation and micro kernel-like idea but some teething problems prevent us in the present release from dismantling the framework and reassembling it. I suppose any component that might be presented piece-meal to ASF would be derived from this work. Hey, who knows? It's always purple hazey out there in the future. On the other hand. I can certainly see if I can help you personally on Struts 2.0 work in the meantime. Of course, it is very true that not every open source project is suited for Apache. There is a specific Apache culture and management style that doesn't work for everyone. We would never simply annex a codebase and then redistribute it under the ASL. We consider the community behind a codebase to be more important than the code itself. It's the extension's community that we would pursue, more than the code itself. Regards -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
Ted Husted wrote: On Tue, 23 Mar 2004 06:31:51 -0500, Ted Husted wrote: Something like Expresso is large enough to be a framework s/framework/Apache project See my other earlier post for my views. -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote: 1) I think you should keep the same elementary structure Moving forward, we have already decided to use Maven as our build environment, which addresses a number of consistency and structural issues. We had also decided to distribute non-core components, like the taglibs, independantly. Independant releases lead to the idea of independant modules. Modules also seem like a good way to handle bringing on some of the more popular extensions. So, the site subproject would be an overview of the Struts project, and then link to the subprojects (including core) for more detail. A contributor mentioned wanting a single JAR. I don't think that's an itch any of Committers are desparate to scratch. And, if anyone did, it's been pointed out that Ant can be used to burst and combine JARs. Anyone could do that. I don't think anyone wants to build a single Struts WAR, especially since we already have multiple example applications in their own WARs. At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
At 3:47 PM -0500 3/23/04, Ted Husted wrote: At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. I don't have a very strong opinion about it. However, from a Maven perspective, if we want to share resources such as a common project.xml, having multiple modules leaves us with no place to put the shared project. I've also had reasonably good results with the maven multiproject goal for building a number of related projects, which would also require a shared project.xml Plus even if infrastructure doesn't mind making new modules, we don't even have to ask if we want to add new module-like subdirectories under a main struts module. I wouldn't veto a multiple module approach, but these seem like a few decent reasons for having a single CVS module. Cocoon seems to coin new modules with each major version; is that a good approach? 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: At 3:47 PM -0500 3/23/04, Ted Husted wrote: At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. I don't have a very strong opinion about it. However, from a Maven perspective, if we want to share resources such as a common project.xml, having multiple modules leaves us with no place to put the shared project. I've also had reasonably good results with the maven multiproject goal for building a number of related projects, which would also require a shared project.xml I just to try build Struts with Maven, what am I doing wrong? [EMAIL PROTECTED] [175] maven java:compile __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: commons-validator-1.1.2-dev.jar (try downloading from http://jakarta.apache.org/commons/validator/) Total time: 6 seconds Finished at: Tue Mar 23 22:11:19 GMT 2004 -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Separate Tiles From Struts?
Anyone care to educate me on why Tiles is part of Struts (and not commons-tiles?). I'd like to respond to the following post (contents pasted below) with an educated reply. https://sourceforge.net/forum/message.php?msg_id=2488961 snip On the occasion: Do you happen to know why Tiles was integrated into the Struts codebase as of Struts 1.1, rather than kept as separate component with Struts integration? I've been wondering about this for quite a while... Tiles isn't really tied to Struts in a technical manner, as we see in our usage with Spring. So why is every other piece of reusable logic a Commons component but not Tiles? I'd really like to see Tiles being factored out of the Struts codebase again, possibly before the Struts 2.0 timeframe. /snip Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
I just to try build Struts with Maven, what am I doing wrong? ... Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: The problem is that the project.xml file declares a dependency on a version of commons-validator which isn't in your local Maven repository and which is not in the shared repository. Maven looked here: http://ibiblio.org/maven/commons-validator/jars/ for commons-validator-1.1.2-dev.jar and as you can see if you follow that URL, it isn't there. You can control the versions that Maven uses for dependencies by specifying certain properties. (Full details at http://maven.apache.org/reference/user-guide.html#Properties_Processing) Probably the easiest way to set the properties would be to create or edit build.properties in the root of your local Struts sandbox (same directory where build.xml and project.xml are). Add the following lines: maven.jar.override=on maven.jar.commons-validator=1.1.1 That's a version of commons-validator that's on the shared Maven repository, although I don't have time just at the minute to see if Struts will still build against it! You could also check out commons-validator and run maven jar:install-snapshot and use maven.jar.commons-validator=SNAPSHOT instead. Hope that helps. If we stick to our guns about avoiding dependencies on unreleased software, this won't come up again... it's not Maven's fault! 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]
Re: Separate Tiles From Struts?
At first, there was talk of bringing it to Taglibs. Cedric and David Geary chatted about that for a bit, but the conversation trailed off, and we just plunged ahead with 1.1. It could certainly be abstracted and brought to the Commons, like the Validator, if someone had the itch. :) Are you volunteering? -Ted. On Tue, 23 Mar 2004 16:02:28 -0700, Matt Raible wrote: Anyone care to educate me on why Tiles is part of Struts (and not commons-tiles?). I'd like to respond to the following post (contents pasted below) with an educated reply. https://sourceforge.net/forum/message.php?msg_id=2488961 snip On the occasion: Do you happen to know why Tiles was integrated into the Struts codebase as of Struts 1.1, rather than kept as separate component with Struts integration? I've been wondering about this for quite a while... Tiles isn't really tied to Struts in a technical manner, as we see in our usage with Spring. So why is every other piece of reusable logic a Commons component but not Tiles? I'd really like to see Tiles being factored out of the Struts codebase again, possibly before the Struts 2.0 timeframe. /snip Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Separate Tiles From Struts?
On Mar 23, 2004, at 5:23 PM, Ted Husted wrote: At first, there was talk of bringing it to Taglibs. Cedric and David Geary chatted about that for a bit, but the conversation trailed off, and we just plunged ahead with 1.1. It could certainly be abstracted and brought to the Commons, like the Validator, if someone had the itch. :) Are you volunteering? Any idea on what kind of effort this would involve? It seems like it would be simple enough, but you never know... ;-) -Ted. On Tue, 23 Mar 2004 16:02:28 -0700, Matt Raible wrote: Anyone care to educate me on why Tiles is part of Struts (and not commons-tiles?). I'd like to respond to the following post (contents pasted below) with an educated reply. https://sourceforge.net/forum/message.php?msg_id=2488961 snip On the occasion: Do you happen to know why Tiles was integrated into the Struts codebase as of Struts 1.1, rather than kept as separate component with Struts integration? I've been wondering about this for quite a while... Tiles isn't really tied to Struts in a technical manner, as we see in our usage with Spring. So why is every other piece of reusable logic a Commons component but not Tiles? I'd really like to see Tiles being factored out of the Struts codebase again, possibly before the Struts 2.0 timeframe. /snip Thanks, Matt - 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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: I just to try build Struts with Maven, what am I doing wrong? ... Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: The problem is that the project.xml file declares a dependency on a version of commons-validator which isn't in your local Maven repository and which is not in the shared repository. Maven looked here: http://ibiblio.org/maven/commons-validator/jars/ for commons-validator-1.1.2-dev.jar and as you can see if you follow that URL, it isn't there. You can control the versions that Maven uses for dependencies by specifying certain properties. (Full details at http://maven.apache.org/reference/user-guide.html#Properties_Processing) Probably the easiest way to set the properties would be to create or edit build.properties in the root of your local Struts sandbox (same directory where build.xml and project.xml are). Add the following lines: maven.jar.override=on maven.jar.commons-validator=1.1.1 That's a version of commons-validator that's on the shared Maven repository, although I don't have time just at the minute to see if Struts will still build against it! Yes the above did the trick. I have update the Struts Wiki page. Ta also. You could also check out commons-validator and run maven jar:install-snapshot and use maven.jar.commons-validator=SNAPSHOT instead. Hope that helps. If we stick to our guns about avoiding dependencies on unreleased software, this won't come up again... it's not Maven's fault! ==== -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
error building struts-faces
Hi, I am trying to build struts-faces. I got the following error -- C:\apache\struts-facesant Buildfile: build.xml BUILD FAILED C:\apache\struts-faces\build.xml:29: The file or path you specified (..\..\..\bu ild.properties) is invalid relative to C:\apache\struts-faces Total time: 2 seconds What does ..\..\..\build.properties contain.?? and where can I download that file -Aswath Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.
Re: error building struts-faces
That is a relative reference to the root project jakarta-struts as it sits in cvs. Why are you trying to build struts-el by moving it to a different location? Why not just build it where it sits? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Yahoo IM:[EMAIL PROTECTED] - Original Message - From: a s [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 8:20 PM Subject: error building struts-faces Hi, I am trying to build struts-faces. I got the following error -- C:\apache\struts-facesant Buildfile: build.xml BUILD FAILED C:\apache\struts-faces\build.xml:29: The file or path you specified (..\..\..\bu ild.properties) is invalid relative to C:\apache\struts-faces Total time: 2 seconds What does ..\..\..\build.properties contain.?? and where can I download that file -Aswath Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: I just to try build Struts with Maven, what am I doing wrong? ... Attempting to download commons-validator-1.1.2-dev.jar. WARNING: Failed to download commons-validator-1.1.2-dev.jar. The build cannot continue because of the following unsatisfied dependency: I cannot seem to build the resource files. XSL Templates. [EMAIL PROTECTED] [266] maven jar:install ... java:prepare-filesystem: java:compile: [echo] Compiling to m-target/classes java:jar-resources: Copying 16 files to /new/peterp/jakarta-struts/m-target/classes [style] Transforming into /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-bean.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-bean.tld [style] Loading stylesheet /new/peterp/jakarta-struts/doc/stylesheets/tld.xsl [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-html.tld [style] new/peterp/jakarta-struts/doc/userGuide/struts-html.xml:1440:2: Fatal Error! The content of elements must consist of well-formed character data or markup. [style] Failed to process /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml BUILD FAILED File.. file:/new/peterp/jakarta-struts/ Element... ant:style Line.. 29 Column 28 Fatal error during transformation Total time: 16 seconds Finished at: Wed Mar 24 01:14:25 GMT 2004 What are required `build.properties' for Xalan/Struts? Many tia -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
java:jar-resources: Copying 16 files to /new/peterp/jakarta-struts/m-target/classes [style] Transforming into /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-bean.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-bean.tld [style] Loading stylesheet /new/peterp/jakarta-struts/doc/stylesheets/tld.xsl [style] Processing /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml to /new/peterp/jakarta-struts/m-target/classes/META-INF/tlds/struts-html.tld [style] new/peterp/jakarta-struts/doc/userGuide/struts-html.xml:1440:2: Fatal Error! The content of elements must consist of well-formed character data or markup. [style] Failed to process /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml I don't think your problem is with XSLT (Xalan is defined as a dependency in project.xml just for this purpose) -- from the logs it looks as if struts-bean.xml is being styled correctly before struts-html.xml fails. It seems unlikely that this would be the problem, but are you sure you have the head version of doc/userGuide/struts-html.xml? I just did maven clean followed by maven jar and didn't get any errors. === File: struts-html.xml Status: Up-to-date Working revision:1.76 Repository revision: 1.76 /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) It's possible that there's some other setting in my build.properties that I don't recognize, but I did a little searching and didn't see anything. If you'd like to compare mine to yours, I could send it privately. 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]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
Joe Germuska wrote: java:jar-resources: Copying 16 files to /new/peterp/jakarta-struts/m-target/classes ==== [style] new/peterp/jakarta-struts/doc/userGuide/struts-html.xml:1440:2: Fatal Error! The content of elements must consist of well-formed character data or markup. [style] Failed to process /new/peterp/jakarta-struts/doc/userGuide/struts-html.xml I don't think your problem is with XSLT (Xalan is defined as a dependency in project.xml just for this purpose) -- from the logs it looks as if struts-bean.xml is being styled correctly before struts-html.xml fails. It seems unlikely that this would be the problem, but are you sure you have the head version of doc/userGuide/struts-html.xml? I just did maven clean followed by maven jar and didn't get any errors. Thanks Joe Running `maven jar' works now. Looks like it was a CVS conflict with an older version. Purged all the `doc' directory tree, then updated CVS to get latest deltas. I got delta 1.76 for `doc/userGuide/struts-html.xml' too. ==== -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004, Ted Husted wrote: On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote: 1) I think you should keep the same elementary structure Moving forward, we have already decided to use Maven as our build environment, which addresses a number of consistency and structural issues. We had also decided to distribute non-core components, like the taglibs, independantly. Independant releases lead to the idea of independant modules. Modules also seem like a good way to handle bringing on some of the more popular extensions. As Joe mentioned, we would still need somewhere to put the shared files, such as Maven's project.xml, the LICENSE and NOTICE files, the KEYS file, etc. In a single-module world, those would live at the top level, just as they do now. In a multi-module world, those should be in another module solely for that purpose. (I certainly wouldn't want a build file that knows about all the individual modules living in core, or any other independently buildable module.) So, the site subproject would be an overview of the Struts project, and then link to the subprojects (including core) for more detail. A contributor mentioned wanting a single JAR. I don't think that's an itch any of Committers are desparate to scratch. And, if anyone did, it's been pointed out that Ant can be used to burst and combine JARs. Anyone could do that. I don't think anyone wants to build a single Struts WAR, especially since we already have multiple example applications in their own WARs. I don't want a single jar or a single war, but I do want to be able to run *one* build process to get all of the pieces to build. I also don't relish the thought of having to maintain multiple Gump descriptors, either. At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. Yep, that's exactly where we are. ;-) Here's what I think are the pros and cons of each approach: One module, multiple directories: + One checkout grabs it all (but an alias can reference multiple modules). + Natural place (top level) for all cross-module files. (See above.) + Labelling and branching across modules is one CVS command. + Don't need CVS admin karma (i.e. Craig) to create new modules. - Harder (?) to check out only portions of the overall code base. Multiple modules: + Easier (?) to check out only portions of the overall code base. + May scale better as we accumulate extensions. - Need an extra module for cross-module files. - Clutters up the Apache CVS repository. The reason for the question marks is that this issue seems to have been implied, but it's not really true. The difference is literally a single character - 'cvs co struts-core' versus 'cvs co struts/core'. The labelling issue is an interesting one. Someone (hi Ted! ;) is going to argue that we'll want to label each module independently because we'll want to release them independently, and I agree with that. But I also think that there will be points in time that we'll want to label or branch the entire code base, which will be easier to do across a single module. So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;-) -- Martin Cooper My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. -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]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Tue, 23 Mar 2004, Martin Cooper wrote: On Tue, 23 Mar 2004, Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. Before anyone does dash off and write this, I'd like to have a brief discussion about this in relation to multi-module applications, and removing any need to modify web.xml when adding or removing modules. This is something I did in a project about a year ago, very successfully, so I think it's worth adding to the Struts core. So the earlier suggestion / idea was to automatically scan for a Struts config file in a jar's META-INF. This is a nice idea, but by itself, it doesn't work in a multi-module application. The problem is that each module has its own config file, and that config file does not include the name of the module (and neither should it, IMHO). The approach I have used in the past is to create the following structure within the web app: WEB-INF/ modules/ default/ config/ struts-config.xml ... other config files ... jsp/ ... moduleX/ ... moduleY/ ... ... I subclassed ActionServlet so that I could reimplement the config locating code, but it actually wasn't much work at all. The really cool thing about this approach is that adding or removing a module is as simple as adding or removing files and directories. Not one file needs to be edited. This is great for those of us who don't trust installers to do the right thing. ;-) In a similar vein, I'd like to talk about separating out the config reading somewhat, to allow for alternative mechanisms. The point here is that it should be possible to configure Struts in any of the following ways: * Just what we do today, reading the file names from web.xml. * Auto-locating the config file from META-INF (for 1-module apps). * The above-described mechanism for multi-module apps. * Not using Digester at all, possibly not even using XML files. What do people think? -- Martin Cooper Unfortunately, I'm about to go off to a 4-hour meeting ;-( so I can't expound further right now. More later... -- Martin Cooper -Ted. 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: Reviving Struts-Chain (was ... PageController ...)
On Sun, 14 Mar 2004, Ted Husted wrote: On Sun, 14 Mar 2004 11:34:10 -0600, Joe Germuska wrote: At 11:59 AM -0500 3/14/04, Ted Husted wrote: On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote: No one is more gung-ho about Struts Chain than I am, but people should be aware that we're still just into beta with functionality. Using it on my latest project, I've definitely found a few pieces that hadn't yet been implemented. I've put in what I found missing -- tiles and file upload -- but there are probably some other less mainstream pieces that will turn out to be buggy or not even implemented. We would probably want to make a branching CVS tag for this if we do it. I don't have a lot of experience working on branched codebases with a distributed team, so it should be an interesting ride, but I think Struts Chain is far enough from ready that we don't have a choice. 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). Plus, we need to push commons-chain to a full release. And what about commons-resources? That sounded like it was pretty close. Looking at http://jakarta.apache.org/struts/status.html , I think that roadmap may be still be a good strategy -- get the resources transition done for 1.3, then the new request processor for 1.4. Can anyone summarize what's standing between here and moving to commons-resources? I think Commons Chain can move up any time we wanted. It's just a matter of floating a vote. The Resources thing has been a longtime coming and should be stable. I wouldn't hesitate to do both Resources and Struts Chain in the HEAD now. I'm OK with Chain being promoted as is, but I'd prefer to see Resources migrate to a presence-based build (as opposed to a contrib basis) before promotion. And yes, I'm willing to make the change when I have the time to do it. ;-) -- Martin Cooper In general, I'm satisfied with targeting the page prep as a chain- dependent feature. If we introduce a StrutsContext as the chain implementation of o.a.c.chain.Context then we'll have to come up with a Context factory process so that the ComposableRequestProcessor can be given a Context instead of instantiating one itself. My first hunch is that it should be an early chain command which creates a sub-context of a specific type and uses it to do most of the chain processing. Joe - 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]
