> -----Original Message----- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > Sent: Monday, July 12, 2004 3:45 PM > To: Struts Developers List > Subject: Re: CVS reorg: jakarta-struts -> struts > > > At 2:43 PM -0700 7/12/04, Martin Cooper wrote: > >I'm not completely sure I understand what you're proposing, but here > >are a couple of points to bear in mind: > > I may not understand it either. But I decided I'd like to see it > move forward. So... > > Regarding CVS vs. SVN. I have zero SVN experience. I'm not opposed > to it, but it will be slower for me personally if we go that route, > as I'm starting at the bottom of the learning curve. However, the > tool is much less important to what I'm trying to achieve than the > structuring in preparation for using maven to its fullest.
Well, I have zero experience with SVN at this point as well. ;-) However, one of the most-touted advantages of SVN over CVS is the ease with which files and directories can be moved around. That is extremely appealing, given that that's exactly what we're going to be doing a lot of until we settle on our "final" new repo structure. :-) > Regarding the "limitations of Maven's multi-project capabilities," > I'm sure there are some, but I'm not sure I'll know what they are > until I see them. I've already set up struts-el and struts-chain > with project.xml files which extend the Struts base one and it works > for those, at least. This is just for building, not necessarily for > extended features. > > I would agree that we should have a consensus on the top-level > structure. After that, I would need to have some real files to work > on to make sure that Maven is building correctly, etc. Absolutely. We can talk all we want about theoretical repo structures, but ultimately the rubber has to meet the road, and we have to make it actually work. > Regarding the structure: > > My understanding was that we had settled on a single module, > "struts", under which we would have something like below (mostly > lifted from an email from Ted to the [EMAIL PROTECTED] list) > > struts/ > struts/core > struts/apps > struts/site > struts/opt-taglib > struts/opt-el > struts/opt-faces > > etc. > > But I'm not married to that. I think a single module is easier for a > lot of reasons, and you can partition the space within the module as > much as you want so that I don't think you need parallel modules. I > don't have a strong opinion about how the module is partitioned. One > of the things I need to experiment with is whether it works to have a > "site" directory alongside other directories when you go to build the > site with Maven. I'm not sure if that'll work or not. +1 for a single module. We'll need to be disciplined, I think, so that we don't lump a lot of "common" stuff into the top level, but we can work that out. Regarding the particular structure noted above, I do have a couple of issues that I noted before on this list, mostly related to view technologies. * I would like to see the core be independent of servlets, portlets, and especially JSP. The above structure has nowhere to put code that is JSP specific, but not related to taglibs. * While I understand the intent behind opt-taglib, I feel it is misnamed, since opt-el is also a set of taglibs, and opt-faces includes a taglib as well. * As we move forward, I believe the general concensus is to deprecate (in some sense of the word) the tags that have effectively been supplanted by JSTL. We might want to think about how to separate "legacy" tags from those that retain their utility and are tied to Struts. (The idea of moving the tags out of Struts entirely has been suggested somewhere along the line, but I have concerns about Jakarta Taglibs being somewhat of a SourceForge for taglibs these days, so I'm not sure where I would land on that one.) * There was also discussion of an opt-sandbox (or opt-dev or opt-whiteboard) for experimental stuff, but this is obviously something that can be added later. Here's the thread that has most of the earlier discussion: http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248 > Regarding Martin's suggestion to import the current CVS HEAD into SVN > and then move things around... I don't know enough SVN to know if > that makes sense or not. As mentioned above, I was thinking that having it in SVN would allow us to futz around with the tree more easily. One thing that comes to mind is that we might want to build up the "final" repo structure somewhat incrementally. For example, we could start with trying to put together a core that has no dependencies on servlets, portlets or view technologies. Once we have that, we'll have a better picture of what doesn't fit in there, which will likely suggest ways to structure that, and so on and so forth. Just an idea... > Please speak up with suggestions and opinions... I doubt you'll be short on those! ;-) -- Martin Cooper > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn > back; I'll know I'm in the wrong place." > - Carlos Santana --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
