Re: Subversion Refactoring Frenzy and Maven Questions
On Wed, 2004-10-13 at 23:18, Martin Cooper wrote: On Wed, 13 Oct 2004 06:26:00 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 12 Oct 2004 15:22:38 -0700, Martin Cooper wrote: That said, I would really like to see us all stick together for as long as possible, and not diverge into 1.x and 2.x paths too soon, simply because I don't think there is enough energy here to sustain two parallel version of Struts. Apache teams have had that discussion before. In practice, parallel development creates more energy. People don't work on open source just because it is there. They do it because they have an itch to scratch. People are running out of 1.x itches. A 2.x codebase is not going to steal hours from 1.x. The hours people would put into 2.x are not being put into 1.x now. I think this depends on how we're defining 1.x. If 1.x is simply a maintenance branch, then I agree that there's not going to be a lot of energy put into it. However, if 1.3.x is where we move to Servlets 2.3, push struts-chain into the mainstream, factor out file uploads, separate Tiles, and those kinds of things, while 2.x is the purview of those fortunate enough to be able to use Servlets 2.4 containers, then I really do think that we'll split the community unless we do the bulk of these things before we split off the 2.0 version. Personally, I think 1.3.x should include everything you listed above. I think 2.x should be a strong move to (1) Java 5.0, (2) J2EE = 1.4 In my opinion 2.x should be designed around new capabilities, and design trends. 2.x should make Struts - leading the way again. Most of what I've heard so far on this list and in the (280+ open issues, which are mostly enhancement requests) are changes that fit the 1.3.x mold. Flow control can stay the same, while we adopt chain as the primary request processor, without breaking backwards compatibility so I think that is a 1.3.x feature. Same goes for the other things that were mentioned. Perhaps to signify it is a significant change but still same design, it can be versioned 1.5.x (nicknamed 5.0 to spoof Sun :-) As for the SVN trunks and branches: - leave 1.3.x at the trunk. focus efforts there, while discussing, white boarding, and planning 2.x. (Like I said, most of what I've heard/read so far is 1.3.x) - when planning is complete and code is starting to be contributed create a 2.x branch. - when the branch starts to stabilize (which may take some time ;-) and focus starts to shift to 2.x development, make 2.x the trunk and the 1.x (trunk) to a branch. The head/trunk should be primary development. branches should be used for two things - radical changes that should be done in parallel as not to conflict with primary development, and for maintenance versions and back porting Subversion makes moving between trunk and head, copies, etc. cheap and painless. The trunk is really another branch, which is really just a tag, which is really just a build number alias. Creating copies/branches/tags - are essentially just creating an alias to single build. Since builds are atomic, a build is the entire snapshot. Which is one of the many reasons subversion rules. Every commit is essentially a tag and branch. Because of this you also get the great gift of true history - no matter how you refactor, move, or copy files or folders around, you always have version history going back to were it originated. (and since it is all done with pointers and meta data, folders are files are props). Welcome to Subversion! I don't think a 2.x branch should be created until there is some more planning. We need consensus on 1.x future and 2.x goals. There is still a lot of room for 1.x revolution. It is a good design, and with minor changes can become even more flexible and powerful. scratching a lot of itches. I don't think it should be labeled maintenance. 1.2.x is maintenance. There is a lot you can do with the current framework to (1) excite developers, (2) improve productivity and efficiency of struts application development, (3) increase flexibility and plug-ability through refactoring - chain is a great example of this. next stop forms improvements, (4) prepare for 2.x, and last but definitely not least (5) have fun developing it. In my opinion, were 2.x should be radically different is in the areas of: - configuration - wiring of components - container agnostic (servlet, standalone application, junit test, whatever) - use of latest greatest specs and tech (5.0 features including variable args, meta data/attributes, and typed enums) One thing I haven't mentioned yet, was momentum and timing. I don't think it is the right time or the right momentum to start 2.x coding. There is more MVC framework competition in the industry than any other year. Developers have a hard time keeping up with the new changes. A market place like this creates 2 things - buzz and demand for new techniques, and
Re: Subversion Refactoring Frenzy and Maven Questions
On Tue, 12 Oct 2004 15:22:38 -0700, Martin Cooper wrote: That said, I would really like to see us all stick together for as long as possible, and not diverge into 1.x and 2.x paths too soon, simply because I don't think there is enough energy here to sustain two parallel version of Struts. Apache teams have had that discussion before. In practice, parallel development creates more energy. People don't work on open source just because it is there. They do it because they have an itch to scratch. People are running out of 1.x itches. A 2.x codebase is not going to steal hours from 1.x. The hours people would put into 2.x are not being put into 1.x now. So, I do want to encourage people to diverge into 2.x, since there is not enough energy to sustain 1. x alone :) This is not to say that 1.x would go dormant. I'm sure there are things people still want to there, and I'll continue to apply patches to fix whatever problems people find. And what I'm saying is that I don't see a reason to make the provision (i.e. create /v1) until we know we need it, because it would be just as easy to create then as now. As easy to create on the server, but there'll be a lot of churn on the client. Better to get it over with now and give the project room to grow. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion Refactoring Frenzy and Maven Questions
On Wed, 13 Oct 2004 06:26:00 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 12 Oct 2004 15:22:38 -0700, Martin Cooper wrote: That said, I would really like to see us all stick together for as long as possible, and not diverge into 1.x and 2.x paths too soon, simply because I don't think there is enough energy here to sustain two parallel version of Struts. Apache teams have had that discussion before. In practice, parallel development creates more energy. People don't work on open source just because it is there. They do it because they have an itch to scratch. People are running out of 1.x itches. A 2.x codebase is not going to steal hours from 1.x. The hours people would put into 2.x are not being put into 1.x now. I think this depends on how we're defining 1.x. If 1.x is simply a maintenance branch, then I agree that there's not going to be a lot of energy put into it. However, if 1.3.x is where we move to Servlets 2.3, push struts-chain into the mainstream, factor out file uploads, separate Tiles, and those kinds of things, while 2.x is the purview of those fortunate enough to be able to use Servlets 2.4 containers, then I really do think that we'll split the community unless we do the bulk of these things before we split off the 2.0 version. The bottom line for me personally is that I want (to contribute to) revolution more than evolution, and I need it to happen in a way that I can use it on Servlets 2.3. If we have two parallel development streams, where X is 2.3 compliant and Y is 2.4 compliant, I don't want to have to spend my time back-porting all the cool stuff some people are putting into Y just so that I can use it on a 2.3 container. (I don't really care what the numeric values are for X and Y.) And I don't think we can sustain revolution on more than one version at the same time. So, I do want to encourage people to diverge into 2.x, since there is not enough energy to sustain 1. x alone :) This is not to say that 1.x would go dormant. I'm sure there are things people still want to there, and I'll continue to apply patches to fix whatever problems people find. And what I'm saying is that I don't see a reason to make the provision (i.e. create /v1) until we know we need it, because it would be just as easy to create then as now. As easy to create on the server, but there'll be a lot of churn on the client. Better to get it over with now and give the project room to grow. I disagree. The only churn on the client is that people have to check out a new tree. That's something people do all the time already, so it's no big deal. On the other hand, your proposal means that, as I understand SVN at least, I will lose the ability to have SVN help me copy, merge, move, etc. between /v1 and /v2, since they have separate and independent 'trunk' directories. To me, that has a *much* greater impact overall than just making someone check out a new tree at some point. And, as I've said elsewhere, like Craig, I'd prefer to use branches instead of whole new trees in any case. -- Martin Cooper -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: Subversion Refactoring Frenzy and Maven Questions
On Tue, 12 Oct 2004 06:40:38 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 11 Oct 2004 21:38:26 -0700, Martin Cooper wrote: At this point, I'm not sure we all agree on what would constitute a part of v2 rather than v1, since I anticipate some fairly substantial changes going into what some people have referred to as v1. I'd certainly not want to see us create version-specific trees until we know that we have a disagreement on whether or not some substantial change (that someone is ready to commit) should be going into the current tree. ;-} I'm not saying that we should create the v2 path now, I'm just saying we should make the provision. And what I'm saying is that I don't see a reason to make the provision (i.e. create /v1) until we know we need it, because it would be just as easy to create then as now. In any case, like Craig, I would see us splitting v1 vs. v2 by using a branch for one of them. Unlike Craig, I would see the branch as being 1.x rather than 2.x. ;-) My reasoning is that the trunk should be the future, and branches the past. Also, IMHO, it would be more natural to have 2.0 branch off the trunk later, when 3.0 comes along, than to have 3.0 be a branch off the 2.0 branch. That said, I would really like to see us all stick together for as long as possible, and not diverge into 1.x and 2.x paths too soon, simply because I don't think there is enough energy here to sustain two parallel version of Struts. -- Martin Cooper Since we are reorganizing everything that been imported anyway, it would be just as easy to reorganize it in a way that allows for parallel development. Even without the current discussions, which I believe will bear fruit one day, many projects like Tomcat and HTTP have needed to support parallel development, and it seems like a best practice to allow for it from the beginning. It would be my hope that one day there will be a v3 path too :) -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: Subversion Refactoring Frenzy and Maven Questions
On Sun, 10 Oct 2004 23:25:06 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Sun, 10 Oct 2004 13:22:27 -0700, Craig McClanahan wrote: Splitting out the database part of mailreader seems like an obvious first step. How about a top level examples directory with a mailreader-database subdirectory to contain this artifact? If the business logic turns out to be reusable too, that could go in a parallel mailreader-actions subdirectory. Moving everything over into a standard Subversion layout was the right thing to do, but as we reorganize, we may want to create a top-level directories for each major release series. Such as: /v1/trunk/struts-core /v1/trunk/struts-faces /v1/branches and /v2/trunk/struts-core /v2/trunk/struts-faces (if we needed such a thing) /v2/branches Since it does look like we will have parallel v2 development and v1 maintenance/evolution. At this point, I'm not sure we all agree on what would constitute a part of v2 rather than v1, since I anticipate some fairly substantial changes going into what some people have referred to as v1. I'd certainly not want to see us create version-specific trees until we know that we have a disagreement on whether or not some substantial change (that someone is ready to commit) should be going into the current tree. ;-} -- Martin Cooper Then, whatever is under the root /trunk has not been reorganized yet, and everything under /v1/trunk has already been reorganized as an artifact. Since we have a number of applications knocking around, I would suggest we have an applications or apps subproject, that could host all the various examples. So, we might have something like /v1/trunk/apps/struts-blank /v1/trunk/apps/struts-examples /v1/trunk/apps/struts-mailreader /v1/trunk/apps/struts-mailreader-database /v1/trunk/apps/struts-mailreader-faces /v1/trunk/apps/struts-mailreader-faces-tiles /v1/trunk/apps/struts-tiles-examples Here, each folder under apps/ would represent a separate artifact that could be released separately, or bundled with other subprojects to form a product distribution. (Like the best available of everything.) Aside from apps/, the other top-level folders under trunk/ might each represent a separate artifact that could be released separately, such as: apps/ struts-core/ struts-site/ struts-bsf/ struts-el/ struts-faces/ struts-scripting/ struts-taglib/ -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: Subversion Refactoring Frenzy and Maven Questions
On Sun, 10 Oct 2004 08:29:20 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Sat, 09 Oct 2004 21:06:44 -0700, Craig McClanahan wrote: ... Interestingly, this subproject has four subsubprojects ... Are you counting the MailReader database as a separate artifact? I hadn't been, and that actually makes sense ... it's used by two of the artifacts that I *did* count (both the non-Tiles and Tiles versions of mailreader). We also use it for the conventional Struts example, and it might be best if it were a separate entity that could shared by the various examples. Yep ... even the form beans and actions of mailreader are likely to be abstractable into something separate if we wanted to. For the sake of continuity, I had also started to use the MailReader as an example for using Commons Chain as an web application platform. One of my comrades on Team iBATIS, Larry Meadors, has also done a iBATIS version of MailReader. If there were a MailReaderDatabase subproject, we might be able to get him to donate the code, so there would be both XML and JDBC implementations of the MailReader DAOs. Splitting out the database part of mailreader seems like an obvious first step. How about a top level examples directory with a mailreader-database subdirectory to contain this artifact? If the business logic turns out to be reusable too, that could go in a parallel mailreader-actions subdirectory. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion Refactoring Frenzy and Maven Questions
On Sun, 10 Oct 2004 13:22:27 -0700, Craig McClanahan wrote: Splitting out the database part of mailreader seems like an obvious first step. How about a top level examples directory with a mailreader-database subdirectory to contain this artifact? If the business logic turns out to be reusable too, that could go in a parallel mailreader-actions subdirectory. Moving everything over into a standard Subversion layout was the right thing to do, but as we reorganize, we may want to create a top-level directories for each major release series. Such as: /v1/trunk/struts-core /v1/trunk/struts-faces /v1/branches and /v2/trunk/struts-core /v2/trunk/struts-faces (if we needed such a thing) /v2/branches Since it does look like we will have parallel v2 development and v1 maintenance/evolution. Then, whatever is under the root /trunk has not been reorganized yet, and everything under /v1/trunk has already been reorganized as an artifact. Since we have a number of applications knocking around, I would suggest we have an applications or apps subproject, that could host all the various examples. So, we might have something like /v1/trunk/apps/struts-blank /v1/trunk/apps/struts-examples /v1/trunk/apps/struts-mailreader /v1/trunk/apps/struts-mailreader-database /v1/trunk/apps/struts-mailreader-faces /v1/trunk/apps/struts-mailreader-faces-tiles /v1/trunk/apps/struts-tiles-examples Here, each folder under apps/ would represent a separate artifact that could be released separately, or bundled with other subprojects to form a product distribution. (Like the best available of everything.) Aside from apps/, the other top-level folders under trunk/ might each represent a separate artifact that could be released separately, such as: apps/ struts-core/ struts-site/ struts-bsf/ struts-el/ struts-faces/ struts-scripting/ struts-taglib/ -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion Refactoring Frenzy and Maven Questions
I've taken advantage of the new capabilities that Subversion provides for refactoring, to set up struts-faces as a top-level subproject with the ability to create its own release artifact. Interestingly, this subproject has four subsubprojects that provide its content as well, so the top-level build.xml is set up to delegate as needed to assemble the entire thing. The directory structure is: $STRUTS_HOME/ struts-faces/ build.xml-- top level build script core-library/ -- subsubproject for the library itself example1-webapp/ -- first sample webapp (non-Tiles) example2-webapp/ -- second sample webapp (Tiles) sysclient-app/ -- system integration test ... client side systest1-webapp/-- system integration test ... server side Each of the subsubprojects has its own build.xml to manage the details. So far, this is all still Ant based. While contemplating how we might use Maven for it, I've got some questions I hope the Maven gurus can address: * My understanding is that Maven is easiest to use on projects that create a single artifact ... but I need to assemble that artifact from several subordinate artifacts. So, I guess we'll need some sort of multi-target support? * The Ant scripts still use build.properties files for an important reason: I need to be able to substitute alternative solutions for the dependencies: - Struts itself (1.1, 1.2, or trunk) - JSF implementation (RI or MyFaces) How can I do that with Maven? * The build scripts utilize Ant's filtering tasks to modify the web.xml files based on which JSF implementation is used (as well as conditionally include some extra libraries that MyFaces needs but the JSF RI doesn't). How can I do that with Maven? * As the scripts work now, they include the source code in the same distribution as the binaries, so there's only one file for the user to download. I'm OK with doing them separately, but it would be nice if Maven supported this style as well. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
