On Mon, 19 Jul 2004 21:21:52 -0700, Martin Cooper wrote:
(BTW, that's something I think we should develop a policy on, so
that we're not seen as making arbitrary decisions in this area, but
that's another topic entirely.)
I think the decision would have to depend on who is going to maintain the
On Mon, 19 Jul 2004 21:07:14 -0700, Martin Cooper wrote:
One important question, though: Where are we doing 1.2.x
development / maintenance? Are we leaving that in CVS and splitting
off a new SVN repo for 2.0 development, or are we converting to SVN
lock, stock and barrel?
How about this:
* On
Does this include having Struts 1.x, 2.x, and 3.x, for the Servlet 2.2, 2.3,
and 2.4 respectively?
Niall
- Original Message -
From: Ted Husted [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 1:15 PM
Subject: Re: Repository Reorg (Once More
On Tue, 20 Jul 2004 06:53:04 -0400, Ted Husted [EMAIL PROTECTED] wrote:
On Mon, 19 Jul 2004 21:21:52 -0700, Martin Cooper wrote:
(BTW, that's something I think we should develop a policy on, so
that we're not seen as making arbitrary decisions in this area, but
that's another topic entirely.)
On Sun, 18 Jul 2004 13:15:45 -0700, Craig McClanahan wrote:
Personally, I want to stay focused on the code part first, and
would prefer someone more familiar with Maven and xml-html
transformations would focus on the site module.
What I'm thinking is that we should use an infrastructure
On Mon, 19 Jul 2004 16:48:35 -0700, Craig McClanahan wrote:
I was just following the usual conventions in the Subversion book,
and am not attached to the location (svn move and svn copy are *
sweet*). But first, a question ... if we are thinking about
actually keeping the end result, wouldn't it
On Mon, 19 Jul 2004 20:05:14 -0400, Ted Husted [EMAIL PROTECTED] wrote:
On Mon, 19 Jul 2004 16:48:35 -0700, Craig McClanahan wrote:
I was just following the usual conventions in the Subversion book,
and am not attached to the location (svn move and svn copy are *
sweet*). But first, a question
On Sun, 18 Jul 2004 08:52:21 -0400, Ted Husted [EMAIL PROTECTED] wrote:
On Sat, 17 Jul 2004 14:56:45 -0700, Craig McClanahan wrote:
* Separate modules for independently releaseable artifacts.
* Modules can depend on each other (i.e. pretty much all will
depend on core), but we should
+1 to all of this. :-)
One point about dependencies on 'core', though. It's seldom likely to
be as clear cut as depending on core or not. For example, it's likely
that, once we split out Tiles, there will still be some glue that
depends on 'core', even if Tiles per se does not. Then the question
On Sat, 17 Jul 2004 14:56:45 -0700, Craig McClanahan wrote:
* Separate modules for independently releaseable artifacts.
* Modules can depend on each other (i.e. pretty much all will
depend on core), but we should exercise caution if the dependency
tree gets deep ... complexity lurks here.
[snip]
We might want to start by getting the struts-core and struts-site building first.
Site would have a number of under-construction links at first, which would go away
as each subproject came online. What's in the other subprojects then defined by what
is not in the core. (And for now,
Here's another crack at trying to get us moving forwards on the
repository reorg. Given the feedback of our most recent discussions,
I'd like to focus on the following motivations for a particular decision
on the organization of the repository, followed by what seems to make
sense based on
A few comments:
1) I don't consider Tiles to be core Struts functionality at all, and
would very much prefer to see it be its own module, or another part of
'addons'. Note that we've had numerous requests to make Tiles
available unbundled from Struts, and in his session at JavaOne, David
Geary
Craig McClanahan wrote:
* Focus the new repository on supporting 1.3.x development
(generally backwards compatibile, but using chain-based
request processor, adding support for portlet), in prep for
later migration to 2.x.x development (which might end up
in either separate modules or a separate
14 matches
Mail list logo
