You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/07/12 23:15:50 UTC
CVS reorg: jakarta-struts -> struts
Apropos of the earlier discussion about Maven repositories and such,
I'm going to try to spend at least a couple of hours staking out a
new CVS repository for "struts-as-TLP". I'm going to try to set up a
local repository on my machine with a copy of
/home/cvs/jakarta-struts and see what I can do with just moving files
around.
Assuming that I get anywhere at all, are people OK with setting it up
in CVS under the module "struts" and letting people use the Apache
CVS server to test it? If not, I might be able to find a place to
host it.
Joe
--
Joe Germuska
Joe@Germuska.com
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
Re: CVS reorg: jakarta-struts -> struts
Posted by Joe Germuska <Jo...@Germuska.com>.
>Looking at what the Geronimo crowd is doing (extensive use of this
>Maven facility) should provide some fruitful material for study.
>I'm sure that those guys would also provide pointers about what
>works (and, more importantly, what doesn't work) when managing a
>large, complex, code base with lots of cross dependencies.
I didn't get very far on this last night; I stayed at the office to
work on it and ended up helping someone else meet a deadline.
But in any case, I'm starting to think about it and will be working
on this as I have time, and I will definitely check out the Geronimo
CVS repository for ideas.
Joe
--
Joe Germuska
Joe@Germuska.com
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
Re: CVS reorg: jakarta-struts -> struts
Posted by Craig McClanahan <cr...@apache.org>.
Martin Cooper wrote:
>
> 3) Given the factoring into sub-projects that we want to do, we'll no
> doubt be making extensive use of Maven's multi-project capabilities.
> It would be nice to know what that actually means, especially in terms
> of constraints. (I'm afraid I don't have much of a clue, so I'm hoping
> someone else does. ;)
>
Looking at what the Geronimo crowd is doing (extensive use of this Maven
facility) should provide some fruitful material for study. I'm sure
that those guys would also provide pointers about what works (and, more
importantly, what doesn't work) when managing a large, complex, code
base with lots of cross dependencies.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Vic Cekvenich <ce...@portalvu.com>.
Repost, I meant to say +1 for CVS.
.V
Vic Cekvenich wrote:
> + 1 for ant, the devil you know.
>
> http://www.unix-girl.com/blog/archives/001516.html
>
> .V
>
> Ted Husted wrote:
>
>> On Mon, 12 Jul 2004 17:44:40 -0500, Joe Germuska wrote:
>>
>>> 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.
>>
>>
>>
>> Subversion is designed (by teams like ours) to be both a replacement
>> and an enhancement to CVS (for teams like ours). If you know CVS, you
>> already know 90% of SVN. Most of the remaining 10% is unlearning a few
>> things that SVN does differently (in a good way) than CVS.
>>
>> The hardest part of the SVN curve is just pulling out of the driveway :)
>>
>> I'll try to get a SVN repository imported from the Struts CVS module
>> today, and then you can see what I mean.
>> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Vic Cekvenich <ce...@portalvu.com>.
+ 1 for ant, the devil you know.
http://www.unix-girl.com/blog/archives/001516.html
.V
Ted Husted wrote:
> On Mon, 12 Jul 2004 17:44:40 -0500, Joe Germuska wrote:
>
>> 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.
>
>
> Subversion is designed (by teams like ours) to be both a replacement and an enhancement to CVS (for teams like ours). If you know CVS, you already know 90% of SVN. Most of the remaining 10% is unlearning a few things that SVN does differently (in a good way) than CVS.
>
> The hardest part of the SVN curve is just pulling out of the driveway :)
>
> I'll try to get a SVN repository imported from the Struts CVS module today, and then you can see what I mean.
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Ted Husted <hu...@apache.org>.
On Mon, 12 Jul 2004 17:44:40 -0500, Joe Germuska wrote:
>�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.
Subversion is designed (by teams like ours) to be both a replacement and an enhancement to CVS (for teams like ours). If you know CVS, you already know 90% of SVN. Most of the remaining 10% is unlearning a few things that SVN does differently (in a good way) than CVS.
The hardest part of the SVN curve is just pulling out of the driveway :)
I'll try to get a SVN repository imported from the Struts CVS module today, and then you can see what I mean.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Carlos Sanchez <ap...@carlos.cousas.net>.
Hi,
Yes, you can have a struts/site with site documentation that can include all
modules documentation (and is the recommended way)
About extending projects you shouldn't extend the concrete projects (e.g.
struts core), it's better to create convenience project.xml files (e.g. in
struts/maven)
BTW the Maven 1.0 will be released by this week, it has already been voted
in the PMC
Carlos Sanchez
A Coruña, Spain
Oness Project
http://oness.sourceforge.net
> -----Original Message-----
> From: Joe Germuska [mailto:Joe@Germuska.com]
> Sent: Tuesday, July 13, 2004 12:45 AM
> 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.
>
> 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.
>
> 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 pmc@struts 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.
>
> 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.
>
> Please speak up with suggestions and opinions...
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 15 Jul 2004, Joe Germuska wrote:
> At 9:03 AM -0700 7/15/04, Martin Cooper wrote:
>> On Tue, 13 Jul 2004, Ted Husted wrote:
>>
>>> On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote:
>>>> As long as it's easy for me to check out the entire gorilla if
>>>> that's what I want. ;-)
>>>
>>> But of course :)
>>>
>>>> That sounds nice in theory, but there are going to be cases where
>>>> we'll need to share code between different 'opt's, and it's not
>>>> clear (to me, at least) where that fits. For example, where would
>>>> we put the methods that are currently in RequestUtils but that are
>>>> tied to JSP? I would be very much opposed to JSP specific code
>>>> being in core, but I'm not sure where else it would go. Would we
>>>> need an opt-jsp just for that, that the other 'opt's depend on?
>>>
>>> For now, they would have to stay in the core. Later, we can try and
>>> refactor them out.
>>
>> My concern is that if we don't think about this kind of thing up front,
>> we're going to find ourselves in a bind when we do try to split these
>> things out.
>>
>> I like the theory of not introducing a "taxonomy", as you put it, but I
>> don't see that it's really avoidable - or even desirable, in some cases.
>> For example, if the core is independent of servlets, portlets, JSP, etc.,
>> then we need somewhere to put shared servlet code, shared JSP code, etc. A
>> hierarchy seems like a pretty good way of partitioning this.
>>
>> So, we might have a JSP tree that has some "shared" or "common" JSP
>> specific code, along with the JSP specific 'opt's like -taglibs, -el, et
>> al.
>>
>> Without something like this, I can't help thinking we'll end up with a
>> bazillion top level 'opt's with nothing other than (hopefully) clear
>> documentation (which people never read ;) to tell people what depends on
>> what.
>>
>> To put all that another way - if we have the structure you propose, where
>> do you anticipate that we would put JSP specific code that is shared among
>> opt-taglibs, opt-el and opt-faces? I think we need to have an answer to
>> that question, at least, before we can know how well the structure will
>> work.
>
> For the foreseeable future, I would expect opt-el to *depend on* opt-taglibs.
> I don't know what opt-faces would share, but if there's that dependency
> relationship, then there may be no need to have another "lib-jsp" artifact.
It makes sense for opt-el to depend on opt-taglibs. It doesn't necessarily
make sense for other taglibs that people might write to have to depend on
that same package, though, especially if the only reason they depend on it
is for a class like TagUtils, and the tags themselves have no relation to
our opt-taglibs tags.
As far as I can tell, the only other classes that have JSP dependencies
(that are not part of taglibs) are RequestUtils and ResponseUtils, as well
as several Tiles classes.
I would like to see a clean separation of the JSP specific code, and
something like lib-jsp, as you suggest below, would be one way of doing
this. However, it seems at this point as if I'm the only one arguing for
such a clean separation.
It just seems to me that if we ever want to get to a clean separation of
dependencies, now is the time to do that, not later, when people start
building on top of the new code organisation, and we're locked into it
ourselves.
--
Martin Cooper
>
> Grepping imports in the struts-faces taglib package, I find these Struts
> imports:
>
> org.apache.struts.Globals;
> org.apache.struts.config.ModuleConfig;
> org.apache.struts.util.MessageResources;
> org.apache.struts.util.RequestUtils;
> org.apache.struts.validator.Resources;
> org.apache.struts.validator.ValidatorPlugIn;
>
> no dependency on other Struts JSP centric stuff. The RequestUtils calls all
> do accept pageContext as an argument:
> ModuleConfig config = RequestUtils.getModuleConfig(pageContext);
> Locale locale = RequestUtils.retrieveUserLocale(this.pageContext,
> null);
> return RequestUtils.isXhtml(this.pageContext);
>
> I kind of thought all of that stuff would have been moved to TagUtils, but if
> it hasn't and won't be, then there's no concern of the type that Martin
> suggests.
>
> If there is no current concern, I wouldn't want to get stuck planning for
> this one might-be. However, if we needed it, I guess I'd propose a general
> "lib-*" naming convention for libraries which are pieces of the puzzle. So
> in this case, we might have
>
> struts/lib-jsp/
> /src
> /project.xml
> etc
>
> I'd be fine with them being at the top. But I'd rather not create them until
> they have substance.
>
> Joe
>
>
>
> --
> Joe Germuska Joe@Germuska.com 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Craig McClanahan <cr...@apache.org>.
Joe Germuska wrote:
> At 9:03 AM -0700 7/15/04, Martin Cooper wrote:
>
>> On Tue, 13 Jul 2004, Ted Husted wrote:
>>
>>> On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote:
>>>
>>>> As long as it's easy for me to check out the entire gorilla if
>>>> that's what I want. ;-)
>>>
>>>
>>> But of course :)
>>>
>>>> That sounds nice in theory, but there are going to be cases where
>>>> we'll need to share code between different 'opt's, and it's not
>>>> clear (to me, at least) where that fits. For example, where would
>>>> we put the methods that are currently in RequestUtils but that are
>>>> tied to JSP? I would be very much opposed to JSP specific code
>>>> being in core, but I'm not sure where else it would go. Would we
>>>> need an opt-jsp just for that, that the other 'opt's depend on?
>>>
>>>
>>> For now, they would have to stay in the core. Later, we can try and
>>> refactor them out.
>>
>>
>> My concern is that if we don't think about this kind of thing up
>> front, we're going to find ourselves in a bind when we do try to
>> split these things out.
>>
>> I like the theory of not introducing a "taxonomy", as you put it, but
>> I don't see that it's really avoidable - or even desirable, in some
>> cases. For example, if the core is independent of servlets, portlets,
>> JSP, etc., then we need somewhere to put shared servlet code, shared
>> JSP code, etc. A hierarchy seems like a pretty good way of
>> partitioning this.
>>
>> So, we might have a JSP tree that has some "shared" or "common" JSP
>> specific code, along with the JSP specific 'opt's like -taglibs, -el,
>> et al.
>>
>> Without something like this, I can't help thinking we'll end up with
>> a bazillion top level 'opt's with nothing other than (hopefully)
>> clear documentation (which people never read ;) to tell people what
>> depends on what.
>>
>> To put all that another way - if we have the structure you propose,
>> where do you anticipate that we would put JSP specific code that is
>> shared among opt-taglibs, opt-el and opt-faces? I think we need to
>> have an answer to that question, at least, before we can know how
>> well the structure will work.
>
>
> For the foreseeable future, I would expect opt-el to *depend on*
> opt-taglibs.
That seems like a rational viewpoint. Indeed, the only reason to keep
opt-el separate is so that we could publish packages that work on
Servlet 2.2/JSP 1.1 versus Servlet 2.3/JSP 1.2.
> I don't know what opt-faces would share, but if there's that
> dependency relationship, then there may be no need to have another
> "lib-jsp" artifact.
The core of the JSF integration code doesn't have any clue whether JSP
is actually used or not, because JSF itself is view-agnostic.
Therefore, we *could* separate struts-faces into two pieces (analogous
to what we're doing elsewhere) -- the core integration library
(including components and renderers) and the (JSP-specific) tag
library. However, it's small enough (and you'd always release them
together, regardless), that there comes a point of diminishing returns
on divisions like this.
At the moment, struts-faces imports only o.a.s.Globals, o.a.s.action.*,
o.a.s.config.*, and o.a.s.util.* classes -- in other words, it only
depends on what we're proposing for core. I'd just as soon leave it one
module.
TagUtils is (AFAICT) only referenced in the tag implementation classes
itself, so it makes sense to put it with the tags. I don't see much
likelihood of a JSP oriented view tier that doesn't use the tags, so
there's little need for stuff like that being separated.
As Joe points out, we can split it later if need be, but let's not
succumb to premature optimization here :-).
>
> Grepping imports in the struts-faces taglib package, I find these
> Struts imports:
>
> org.apache.struts.Globals;
> org.apache.struts.config.ModuleConfig;
> org.apache.struts.util.MessageResources;
> org.apache.struts.util.RequestUtils;
> org.apache.struts.validator.Resources;
> org.apache.struts.validator.ValidatorPlugIn;
>
> no dependency on other Struts JSP centric stuff. The RequestUtils
> calls all do accept pageContext as an argument:
> ModuleConfig config = RequestUtils.getModuleConfig(pageContext);
> Locale locale =
> RequestUtils.retrieveUserLocale(this.pageContext, null);
> return RequestUtils.isXhtml(this.pageContext);
>
> I kind of thought all of that stuff would have been moved to TagUtils,
> but if it hasn't and won't be, then there's no concern of the type
> that Martin suggests.
>
The whole point of TagUtils was to migrate those calls and deprecate
them in RequestUtils. Are you referring to just the deprecated methods
(which we can banish in 1.3)?
> If there is no current concern, I wouldn't want to get stuck planning
> for this one might-be. However, if we needed it, I guess I'd propose
> a general "lib-*" naming convention for libraries which are pieces of
> the puzzle. So in this case, we might have
>
> struts/lib-jsp/
> /src
> /project.xml
> etc
>
> I'd be fine with them being at the top. But I'd rather not create
> them until they have substance.
>
> Joe
>
Craig
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:03 AM -0700 7/15/04, Martin Cooper wrote:
>On Tue, 13 Jul 2004, Ted Husted wrote:
>
>>On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote:
>>> As long as it's easy for me to check out the entire gorilla if
>>> that's what I want. ;-)
>>
>>But of course :)
>>
>>> That sounds nice in theory, but there are going to be cases where
>>> we'll need to share code between different 'opt's, and it's not
>>> clear (to me, at least) where that fits. For example, where would
>>> we put the methods that are currently in RequestUtils but that are
>>> tied to JSP? I would be very much opposed to JSP specific code
>>> being in core, but I'm not sure where else it would go. Would we
>>> need an opt-jsp just for that, that the other 'opt's depend on?
>>
>>For now, they would have to stay in the core. Later, we can try and
>>refactor them out.
>
>My concern is that if we don't think about this kind of thing up
>front, we're going to find ourselves in a bind when we do try to
>split these things out.
>
>I like the theory of not introducing a "taxonomy", as you put it,
>but I don't see that it's really avoidable - or even desirable, in
>some cases. For example, if the core is independent of servlets,
>portlets, JSP, etc., then we need somewhere to put shared servlet
>code, shared JSP code, etc. A hierarchy seems like a pretty good way
>of partitioning this.
>
>So, we might have a JSP tree that has some "shared" or "common" JSP
>specific code, along with the JSP specific 'opt's like -taglibs,
>-el, et al.
>
>Without something like this, I can't help thinking we'll end up with
>a bazillion top level 'opt's with nothing other than (hopefully)
>clear documentation (which people never read ;) to tell people what
>depends on what.
>
>To put all that another way - if we have the structure you propose,
>where do you anticipate that we would put JSP specific code that is
>shared among opt-taglibs, opt-el and opt-faces? I think we need to
>have an answer to that question, at least, before we can know how
>well the structure will work.
For the foreseeable future, I would expect opt-el to *depend on*
opt-taglibs. I don't know what opt-faces would share, but if there's
that dependency relationship, then there may be no need to have
another "lib-jsp" artifact.
Grepping imports in the struts-faces taglib package, I find these
Struts imports:
org.apache.struts.Globals;
org.apache.struts.config.ModuleConfig;
org.apache.struts.util.MessageResources;
org.apache.struts.util.RequestUtils;
org.apache.struts.validator.Resources;
org.apache.struts.validator.ValidatorPlugIn;
no dependency on other Struts JSP centric stuff. The RequestUtils
calls all do accept pageContext as an argument:
ModuleConfig config = RequestUtils.getModuleConfig(pageContext);
Locale locale =
RequestUtils.retrieveUserLocale(this.pageContext, null);
return RequestUtils.isXhtml(this.pageContext);
I kind of thought all of that stuff would have been moved to
TagUtils, but if it hasn't and won't be, then there's no concern of
the type that Martin suggests.
If there is no current concern, I wouldn't want to get stuck planning
for this one might-be. However, if we needed it, I guess I'd propose
a general "lib-*" naming convention for libraries which are pieces of
the puzzle. So in this case, we might have
struts/lib-jsp/
/src
/project.xml
etc
I'd be fine with them being at the top. But I'd rather not create
them until they have substance.
Joe
--
Joe Germuska
Joe@Germuska.com
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
RE: CVS reorg: jakarta-struts -> struts
Posted by Martin Cooper <ma...@apache.org>.
On Tue, 13 Jul 2004, Ted Husted wrote:
> On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote:
>> �As long as it's easy for me to check out the entire gorilla if
>> �that's what I want. ;-)
>
> But of course :)
>
>
>> �That sounds nice in theory, but there are going to be cases where
>> �we'll need to share code between different 'opt's, and it's not
>> �clear (to me, at least) where that fits. For example, where would
>> �we put the methods that are currently in RequestUtils but that are
>> �tied to JSP? I would be very much opposed to JSP specific code
>> �being in core, but I'm not sure where else it would go. Would we
>> �need an opt-jsp just for that, that the other 'opt's depend on?
>
> For now, they would have to stay in the core. Later, we can try and refactor them out.
My concern is that if we don't think about this kind of thing up front,
we're going to find ourselves in a bind when we do try to split these
things out.
I like the theory of not introducing a "taxonomy", as you put it, but I
don't see that it's really avoidable - or even desirable, in some cases.
For example, if the core is independent of servlets, portlets, JSP, etc.,
then we need somewhere to put shared servlet code, shared JSP code, etc. A
hierarchy seems like a pretty good way of partitioning this.
So, we might have a JSP tree that has some "shared" or "common" JSP
specific code, along with the JSP specific 'opt's like -taglibs, -el, et
al.
Without something like this, I can't help thinking we'll end up with a
bazillion top level 'opt's with nothing other than (hopefully) clear
documentation (which people never read ;) to tell people what depends on
what.
To put all that another way - if we have the structure you propose, where
do you anticipate that we would put JSP specific code that is shared among
opt-taglibs, opt-el and opt-faces? I think we need to have an answer to
that question, at least, before we can know how well the structure will
work.
--
Martin Cooper
>
> It's also possible that other taglib distributions are dependant on RequestUtils, so once we decide what to do, they'd have to be deprecated and available in both places for a while.
>
> For starters, we can make a clean drop of the taglib package into struts-opt-taglib, and proceed from there.
>
> (Better to get 80% of what you want now, then 100% never.)
>
> -Ted.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
RE: CVS reorg: jakarta-struts -> struts
Posted by Ted Husted <hu...@apache.org>.
On Tue, 13 Jul 2004 12:03:00 -0700 (PDT), Martin Cooper wrote:
> As long as it's easy for me to check out the entire gorilla if
> that's what I want. ;-)
But of course :)
> That sounds nice in theory, but there are going to be cases where
> we'll need to share code between different 'opt's, and it's not
> clear (to me, at least) where that fits. For example, where would
> we put the methods that are currently in RequestUtils but that are
> tied to JSP? I would be very much opposed to JSP specific code
> being in core, but I'm not sure where else it would go. Would we
> need an opt-jsp just for that, that the other 'opt's depend on?
For now, they would have to stay in the core. Later, we can try and refactor them out.
It's also possible that other taglib distributions are dependant on RequestUtils, so once we decide what to do, they'd have to be deprecated and available in both places for a while.
For starters, we can make a clean drop of the taglib package into struts-opt-taglib, and proceed from there.
(Better to get 80% of what you want now, then 100% never.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Martin Cooper <ma...@apache.org>.
On Tue, 13 Jul 2004, Ted Husted wrote:
> I got the opt- convention from Maverick. They have a core distribution, and then several optional distributions for using the framework with different view technologies. The idea is that all of these other distributions are optional. Of course, Linux also uses "/opt" for packages that are not installed by RPM.
>
> It's my feeling that the repository should be as flat as possible. Each of the top-level directories should represent a discrete subproject, or Maven artifact, with its own release cycle. The subproject under each of these directories would not share any source code. All sharing would be by the JAR each produces.
>
> In other words, we treat the top-level directories like modules even though they would be defined with the one CVS module. Under SVN, you can could check-out any of these subdirectories out as if they were modules, so we can have it both ways. (You don't have to checkout the gorilla if you only want the banana.)
As long as it's easy for me to check out the entire gorilla if that's what
I want. ;-)
> I don't recommend trying to apply a taxonomy within the repository. If we want to categorize subprojects by technology on a webpage that's fine. But I don't want to have the conversation of whether "faces" belongs under "view" or not. :)
>
> A structure like this (opt names for example only -- I don't know if all of these communities would want to be Struts subprojects or not):
>
> struts-apps/
> struts-core/
> struts-site/
> struts-opt-bsf/
> struts-opt-el/
> struts-opt-faces/
> struts-opt-menu/
> struts-opt-stxx/
> struts-opt-taglib/
> struts-opt-testcase/
> struts-opt-workflow/
>
> says that we host 11 distributions (yahoo!). Each of these subdirectory names would also be the name of the Maven artifact produced (struts-core-jar, struts-opt-el.jar). The first three distributions are part of the standard release, and the other eight are optional. You can use them or not, in whatever combination you please.
That sounds nice in theory, but there are going to be cases where we'll
need to share code between different 'opt's, and it's not clear (to me,
at least) where that fits. For example, where would we put the methods
that are currently in RequestUtils but that are tied to JSP? I would be
very much opposed to JSP specific code being in core, but I'm not sure
where else it would go. Would we need an opt-jsp just for that, that the
other 'opt's depend on?
> If this many root folders is a real problem for people, I could also see
>
> struts/
> ./apps
> ./core
> ./site
>
> struts-opt/
> ./bsf
> ./el
> ./faces
> ./menu
> ./stxx
> ./taglib
> ./testcase
> ./workflow
>
> So, a project.xml at
>
> /struts-opt/bsf/project.xml
>
> would generate an artifact like struts-opt-bsf-1.0.1.jar.
>
> Anyway, I'm getting the Struts SVN module setup, and hopefully it will be available later today. This will be a direct dump of the current CVS that we can refactor.
Cool! ;-)
--
Martin Cooper
>
> -Ted.
>
>
> On Tue, 13 Jul 2004 10:52:44 -0500, Joe Germuska wrote:
>> �OK, here's a revised idea. � James H had a post
>> �(http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248)
>> �where he mentioned a few popular Struts projects. �Please note that
>> �none of these have been officially invited to be part of Struts,
>> �and some may not want to be part of Struts... �This is just to help
>> �flesh out the exercise.
>>
>> �I'm not sure how we settled on the "opt-*" convention, but my
>> �feeling is that it will get annoyingly wide at the top of the
>> �module, so this proposes changing "opt" to a directory. �I agree
>> �with Martin that we may want better names to distinguish between
>> �"taglib" and "el", especially if we were to introduce other taglib-
>> �ish things (like Struts Menu). �But for now -- (a) does anyone hate
>> �"opt" as a directory, or really think it needs to be part of
>> �another directory name (do we need "opt-*/...") and (b) do people
>> �have strong feelings about an opt directory having a subdirectory
>> �like "view". �Should "view" be parallel to "opt"?
>>
>> �struts/
>> �struts/core
>> �struts/apps
>> �struts/site
>> �struts/opt/view/taglib
>> �struts/opt/view/el
>> �struts/opt/view/menu
>> �struts/opt/view/stxx
>> �struts/opt/faces
>> �struts/opt/testcase
>> �struts/opt/workflow
>> �struts/opt/bsf
>>
>>
>> �Regarding a place for non-taglib JSP stuff, I'm not sure how that
>> �would look, so I'm not sure how to propose handling it.
>>
>> �Joe
>>
>>
>>>> �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 pmc@struts 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.)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
RE: CVS reorg: jakarta-struts -> struts
Posted by Ted Husted <hu...@apache.org>.
On Tue, 13 Jul 2004 13:01:05 -0500, Joe Germuska wrote:
>�struts-apps would not map to a single Maven artifact, I don't
>�think. Not if it maps to all of: ���struts-blank.war ���struts-
>�documentation.war ���struts-examples.war ���struts-mailreader.war �
>��tiles-documentation.war
True. Kinda of the exception that proves the rule. :)
The "outer" portion of struts-documentation would become struts-site. Most of the userGuide portion would be rolled into struts-core, except for parts that pertain to the taglibs, which would rolled into that subproject instead.
struts-blank, struts-examples, struts-mailreader, and tiles-documentation (or maybe tiles-examples), would all be subprojects of the struts-apps master project, and so, yes, struts-apps would produce multiple WAR artifacts. But there would be one for every directory immediately below struts-apps.
./struts/apps/blank
./struts/apps/examples
./struts/apps/mailreader
./struts/apps/tiles-examples
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Joe Germuska <Jo...@Germuska.com>.
At 12:32 PM -0400 7/13/04, Ted Husted wrote:
>It's my feeling that the repository should be as flat as possible.
>Each of the top-level directories should represent a discrete
>subproject, or Maven artifact, with its own release cycle. The
>subproject under each of these directories would not share any
>source code. All sharing would be by the JAR each produces.
I see the appeal of this, and accept that using directories to make
taxonomies may lead to unnecessary and uninteresting debates.
Now that I think about it, Maven's "multiproject" facilities will
also probably work better with a number of parallel directories
instead of projects arbitrarily scattered around the tree. At least,
I have only ever used it with parallel projects. The main question
here is how the Maven report-type documentation (like Javadoc, source
code Xref, test reports, etc) from the various directories other than
"struts-site" would get folded in.
struts-apps would not map to a single Maven artifact, I don't think.
Not if it maps to all of:
struts-blank.war
struts-documentation.war
struts-examples.war
struts-mailreader.war
tiles-documentation.war
Or even just to examples and mailreader.
Joe
At 12:32 PM -0400 7/13/04, Ted Husted wrote:
>A structure like this (opt names for example only -- I don't know if
>all of these communities would want to be Struts subprojects or not):
>
>struts-apps/
>struts-core/
>struts-site/
>struts-opt-bsf/
>struts-opt-el/
>struts-opt-faces/
>struts-opt-menu/
>struts-opt-stxx/
>struts-opt-taglib/
>struts-opt-testcase/
>struts-opt-workflow/
>
>says that we host 11 distributions (yahoo!). Each of these
>subdirectory names would also be the name of the Maven artifact
>produced (struts-core-jar, struts-opt-el.jar). The first three
>distributions are part of the standard release, and the other eight
>are optional. You can use them or not, in whatever combination you
>please.
>
>If this many root folders is a real problem for people, I could also see
>
>struts/
> ./apps
> ./core
> ./site
>
>struts-opt/
> ./bsf
> ./el
> ./faces
> ./menu
> ./stxx
> ./taglib
> ./testcase
> ./workflow
>
>So, a project.xml at
>
> /struts-opt/bsf/project.xml
>
>would generate an artifact like struts-opt-bsf-1.0.1.jar.
--
Joe Germuska
Joe@Germuska.com
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Ted Husted <hu...@apache.org>.
I got the opt- convention from Maverick. They have a core distribution, and then several optional distributions for using the framework with different view technologies. The idea is that all of these other distributions are optional. Of course, Linux also uses "/opt" for packages that are not installed by RPM.
It's my feeling that the repository should be as flat as possible. Each of the top-level directories should represent a discrete subproject, or Maven artifact, with its own release cycle. The subproject under each of these directories would not share any source code. All sharing would be by the JAR each produces.
In other words, we treat the top-level directories like modules even though they would be defined with the one CVS module. Under SVN, you can could check-out any of these subdirectories out as if they were modules, so we can have it both ways. (You don't have to checkout the gorilla if you only want the banana.)
I don't recommend trying to apply a taxonomy within the repository. If we want to categorize subprojects by technology on a webpage that's fine. But I don't want to have the conversation of whether "faces" belongs under "view" or not. :)
A structure like this (opt names for example only -- I don't know if all of these communities would want to be Struts subprojects or not):
struts-apps/
struts-core/
struts-site/
struts-opt-bsf/
struts-opt-el/
struts-opt-faces/
struts-opt-menu/
struts-opt-stxx/
struts-opt-taglib/
struts-opt-testcase/
struts-opt-workflow/
says that we host 11 distributions (yahoo!). Each of these subdirectory names would also be the name of the Maven artifact produced (struts-core-jar, struts-opt-el.jar). The first three distributions are part of the standard release, and the other eight are optional. You can use them or not, in whatever combination you please.
If this many root folders is a real problem for people, I could also see
struts/
./apps
./core
./site
struts-opt/
./bsf
./el
./faces
./menu
./stxx
./taglib
./testcase
./workflow
So, a project.xml at
/struts-opt/bsf/project.xml
would generate an artifact like struts-opt-bsf-1.0.1.jar.
Anyway, I'm getting the Struts SVN module setup, and hopefully it will be available later today. This will be a direct dump of the current CVS that we can refactor.
-Ted.
On Tue, 13 Jul 2004 10:52:44 -0500, Joe Germuska wrote:
>�OK, here's a revised idea. � James H had a post
>�(http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248)
>�where he mentioned a few popular Struts projects. �Please note that
>�none of these have been officially invited to be part of Struts,
>�and some may not want to be part of Struts... �This is just to help
>�flesh out the exercise.
>
>�I'm not sure how we settled on the "opt-*" convention, but my
>�feeling is that it will get annoyingly wide at the top of the
>�module, so this proposes changing "opt" to a directory. �I agree
>�with Martin that we may want better names to distinguish between
>�"taglib" and "el", especially if we were to introduce other taglib-
>�ish things (like Struts Menu). �But for now -- (a) does anyone hate
>�"opt" as a directory, or really think it needs to be part of
>�another directory name (do we need "opt-*/...") and (b) do people
>�have strong feelings about an opt directory having a subdirectory
>�like "view". �Should "view" be parallel to "opt"?
>
>�struts/
>�struts/core
>�struts/apps
>�struts/site
>�struts/opt/view/taglib
>�struts/opt/view/el
>�struts/opt/view/menu
>�struts/opt/view/stxx
>�struts/opt/faces
>�struts/opt/testcase
>�struts/opt/workflow
>�struts/opt/bsf
>
>
>�Regarding a place for non-taglib JSP stuff, I'm not sure how that
>�would look, so I'm not sure how to propose handling it.
>
>�Joe
>
>
>>>�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 pmc@struts 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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Joe Germuska <Jo...@Germuska.com>.
OK, here's a revised idea. James H had a post
(http://thread.gmane.org/gmane.comp.jakarta.struts.devel/18248) where
he mentioned a few popular Struts projects. Please note that none of
these have been officially invited to be part of Struts, and some may
not want to be part of Struts... This is just to help flesh out the
exercise.
I'm not sure how we settled on the "opt-*" convention, but my feeling
is that it will get annoyingly wide at the top of the module, so this
proposes changing "opt" to a directory. I agree with Martin that we
may want better names to distinguish between "taglib" and "el",
especially if we were to introduce other taglib-ish things (like
Struts Menu). But for now -- (a) does anyone hate "opt" as a
directory, or really think it needs to be part of another directory
name (do we need "opt-*/...") and (b) do people have strong feelings
about an opt directory having a subdirectory like "view". Should
"view" be parallel to "opt"?
struts/
struts/core
struts/apps
struts/site
struts/opt/view/taglib
struts/opt/view/el
struts/opt/view/menu
struts/opt/view/stxx
struts/opt/faces
struts/opt/testcase
struts/opt/workflow
struts/opt/bsf
Regarding a place for non-taglib JSP stuff, I'm not sure how that
would look, so I'm not sure how to propose handling it.
Joe
> > 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 pmc@struts 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.)
--
Joe Germuska
Joe@Germuska.com
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
RE: CVS reorg: jakarta-struts -> struts
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Joe Germuska [mailto:Joe@Germuska.com]
> 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 pmc@struts 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
> Joe@Germuska.com
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Joe Germuska <Jo...@Germuska.com>.
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.
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.
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 pmc@struts 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.
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.
Please speak up with suggestions and opinions...
Joe
--
Joe Germuska
Joe@Germuska.com
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
RE: CVS reorg: jakarta-struts -> struts
Posted by Ted Husted <hu...@apache.org>.
On Tue, 13 Jul 2004 07:48:37 -0700, Martin Cooper wrote:
> That would be excellent, Ted. That would let us all learn SVN as
> well as play around with ideas without fear of messing things up
> too badly. ;-)
>
> If I could have found the time, I'd been thinking I wanted to do
> something like this too, except that I don't have any externally
> visible hardware. ;-(
Minor holdup (mea culpa). I expect the CVS will be imported sometime today, and I'll setup accounts for the active Committers. I'll also set these people up to get SVN changelog mailings (unless you opt out).
Since this will be a temporary, test, stomp-around repository, I don't know if want to announce the URI here, or just make it available to people on an individual "want to know" basis.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Tuesday, July 13, 2004 2:42 AM
> To: Struts Developers List
> Subject: Re: CVS reorg: jakarta-struts -> struts
>
>
> On Mon, 12 Jul 2004 14:43:28 -0700 (PDT), 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:
> >
> > 1) As we move out of the Jakarta repo into our own TLP repo, we
> > need to decide whether we want to ask infrastructure@ for a new CVS
> > repo or an SVN repo. (Personally, I'm leaning towards saying that
> > what's in CVS is the 1.2.x "branch", and taking exactly what's
> > labelled as 1.2.1 and moving that to SVN, where we can
> > (theoretically) mess around to our hearts' content, but that's just
> > my on opinion.)
>
> +1
>
> But if people would like to experiment on non-Apache hardware
> first, I can help with that too.
>
> <snip/>
>
> > IMHO, we really need to come up with a complete proposal for all of
> > this - or at least a proposal for a plan for getting there - before
> > we start making actual changes to what's in CVS today.
> >
> > That shouldn't stop you experimenting with the CVS tree locally,
> > but I wouldn't want to see changes in the real live repo before
> > we've agreed on where we want to go with all of this.
>
> I agree that a living repository would be the best proposal.
>
> If there are different approaches, we'd like to try, we can
> discuss and demo those too.
>
> If we're uncomfortable with having infrastructure@ setting up a
> SVN repository for us now, I can setup one elsewhere and provide
> access to the commiters.
That would be excellent, Ted. That would let us all learn SVN as well as
play around with ideas without fear of messing things up too badly. ;-)
If I could have found the time, I'd been thinking I wanted to do something
like this too, except that I don't have any externally visible hardware. ;-(
> In the end, the bulk of a proposal might be the easiest way to
> import (SVN) or rename (CVS) our latest repository and reorganize
> it again, since once we are done, we might want to do it again
> with the latest revision of jakarta-struts (which will hopefully
> remain a moving target).
I'm hoping that it wouldn't be too terribly long before we have something
we're mostly happy with in a new repo, so that a 1.2.x branch wouldn't have
got too far ahead of the experimental repo. On the other hand, I think it
would be good to assume that we'll want to transform the tree more than once
before we're done. ;-)
BTW, Fitz has been working on a much-improved cvs2svn tool. Not sure what
state that is in right now, but I can find out.
--
Martin Cooper
>
> -Ted.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Ted Husted <hu...@apache.org>.
On Mon, 12 Jul 2004 14:43:28 -0700 (PDT), 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:
>
> 1) As we move out of the Jakarta repo into our own TLP repo, we
> need to decide whether we want to ask infrastructure@ for a new CVS
> repo or an SVN repo. (Personally, I'm leaning towards saying that
> what's in CVS is the 1.2.x "branch", and taking exactly what's
> labelled as 1.2.1 and moving that to SVN, where we can
> (theoretically) mess around to our hearts' content, but that's just
> my on opinion.)
+1
But if people would like to experiment on non-Apache hardware first, I can help with that too.
<snip/>
> IMHO, we really need to come up with a complete proposal for all of
> this - or at least a proposal for a plan for getting there - before
> we start making actual changes to what's in CVS today.
>
> That shouldn't stop you experimenting with the CVS tree locally,
> but I wouldn't want to see changes in the real live repo before
> we've agreed on where we want to go with all of this.
I agree that a living repository would be the best proposal.
If there are different approaches, we'd like to try, we can discuss and demo those too.
If we're uncomfortable with having infrastructure@ setting up a SVN repository for us now, I can setup one elsewhere and provide access to the commiters.
In the end, the bulk of a proposal might be the easiest way to import (SVN) or rename (CVS) our latest repository and reorganize it again, since once we are done, we might want to do it again with the latest revision of jakarta-struts (which will hopefully remain a moving target).
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Martin Cooper <ma...@apache.org>.
I'm not completely sure I understand what you're proposing, but here are a
couple of points to bear in mind:
1) As we move out of the Jakarta repo into our own TLP repo, we need to
decide whether we want to ask infrastructure@ for a new CVS repo or an
SVN repo. (Personally, I'm leaning towards saying that what's in CVS is
the 1.2.x "branch", and taking exactly what's labelled as 1.2.1 and moving
that to SVN, where we can (theoretically) mess around to our hearts'
content, but that's just my on opinion.)
2) We've agreed we want to restructure the repo (whether in CVS or SVN) as
a Struts core and multiple peer projects (e.g. for JSP view, Faces, etc.).
However, I don't believe we've entirely settled on what we want that to
look like. (Reviewing the old threads would be a good start, though there
were multiple different ideas.)
3) Given the factoring into sub-projects that we want to do, we'll no
doubt be making extensive use of Maven's multi-project capabilities. It
would be nice to know what that actually means, especially in terms of
constraints. (I'm afraid I don't have much of a clue, so I'm hoping
someone else does. ;)
4) Ted has suggested (and I agree) that we should do an overhaul and
restructuring of the documentation and web site, including perhaps
rethinking the way we map between docs and web site today. Obviously this
will interact with splitting into multiple sub-projects too.
IMHO, we really need to come up with a complete proposal for all of this -
or at least a proposal for a plan for getting there - before we start
making actual changes to what's in CVS today.
That shouldn't stop you experimenting with the CVS tree locally, but I
wouldn't want to see changes in the real live repo before we've agreed on
where we want to go with all of this.
--
Martin Cooper
On Mon, 12 Jul 2004, Joe Germuska wrote:
> Apropos of the earlier discussion about Maven repositories and such, I'm
> going to try to spend at least a couple of hours staking out a new CVS
> repository for "struts-as-TLP". I'm going to try to set up a local
> repository on my machine with a copy of /home/cvs/jakarta-struts and see what
> I can do with just moving files around.
>
> Assuming that I get anywhere at all, are people OK with setting it up in CVS
> under the module "struts" and letting people use the Apache CVS server to
> test it? If not, I might be able to find a place to host it.
>
> Joe
>
> --
> Joe Germuska Joe@Germuska.com 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by James Mitchell <jm...@apache.org>.
I would prefer to see it as you first mentioned..."struts". And yes, I
would be one of the first to help iron out the kinks. I would love to see
thing structured such that we can move forward with all the items previously
mentioned (separate release for components, taglibs, extensions, etc).
I'm still a bit apprehensive about Maven, but I am slowly coming around ;)
The work I am doing over in resources is helping. Any news on a 1.0 of
Maven?
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
To: <de...@struts.apache.org>
Sent: Monday, July 12, 2004 5:15 PM
Subject: CVS reorg: jakarta-struts -> struts
> Apropos of the earlier discussion about Maven repositories and such,
> I'm going to try to spend at least a couple of hours staking out a
> new CVS repository for "struts-as-TLP". I'm going to try to set up a
> local repository on my machine with a copy of
> /home/cvs/jakarta-struts and see what I can do with just moving files
> around.
>
> Assuming that I get anywhere at all, are people OK with setting it up
> in CVS under the module "struts" and letting people use the Apache
> CVS server to test it? If not, I might be able to find a place to
> host it.
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Ludovic Maitre <lu...@fr.oleane.com>.
Michael Rassmussen wrote:
> There is obviously a strong push from some people to move struts to
> subversion. I have no idea at all what subversion offers as benefits,
> but I can say that I know it will create some immediate problems for
> me. I use eclipse and I enjoy wonderful tools support for CVS. This
> is also the case across the board with winCVS, Tortise, and others.
> What happens to those of us used to using tools to work with our
> version control. Subversion is not nearly as supported as CVS. There
> is a Subversion Eclipse plugin, but I think it is still in beta and
> only works with some point release of subversion. Not exactly the
> upgrade I would be hoping for.
>
> Michael
I'm agree with you, i'm not a committer but i frequently synchronize my
struts build with the apache repository.
With subversion, which isn't integrated as well as CVS into Eclipse
(AFAIK), it would be more difficult.
Also a lot of people knows CVS, and perhaps (like me) don't want to
integrate another software (svn) just for doing a rebuild of struts from
CVS distro.
I understand that SVN is - perhaps - the futur of versionning - and that
this futur is really near us - but i think that it's more easy to
install CVS (client at least) or, better, CVs is integrated into all
unix, which is not the case of SVN.
Please don't blame my english (nor my laziness to upgrade my develoment
environment, but it's a lot of work!)
--
Ludovic Maître
Factory Productions | Tél: (33) 04 93 07 08 00
149, avenue des mimosas | Fax: (33) 04 93 07 04 02
06700 Saint-Laurent-du-Var (France) | Web: http://www.factory.fr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Michael Rassmussen <ra...@gmail.com>.
There is obviously a strong push from some people to move struts to
subversion. I have no idea at all what subversion offers as benefits,
but I can say that I know it will create some immediate problems for
me. I use eclipse and I enjoy wonderful tools support for CVS. This
is also the case across the board with winCVS, Tortise, and others.
What happens to those of us used to using tools to work with our
version control. Subversion is not nearly as supported as CVS. There
is a Subversion Eclipse plugin, but I think it is still in beta and
only works with some point release of subversion. Not exactly the
upgrade I would be hoping for.
Michael
On Mon, 12 Jul 2004 17:57:04 -0400, Ted Husted <hu...@apache.org> wrote:
> On Mon, 12 Jul 2004 14:41:32 -0700, Craig McClanahan wrote:
> > * Did we end up deciding to stick with CVS versus Subversion? I
> > know the infrastructure team would be happier if we switched to
> > svn ... I haven't
> > played with it enough to form an opinion on that yet.
>
> I would be +1 for Subversion.
>
> I could also host a SVN repository for us, temporarily.
>
> -Ted.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: CVS reorg: jakarta-struts -> struts
Posted by James Holmes <ja...@jamesholmes.com>.
+1 for svn
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Monday, July 12, 2004 4:57 PM
To: Struts Developers List
Subject: Re: CVS reorg: jakarta-struts -> struts
On Mon, 12 Jul 2004 14:41:32 -0700, Craig McClanahan wrote:
> * Did we end up deciding to stick with CVS versus Subversion? I
> know the infrastructure team would be happier if we switched to
> svn ... I haven't
> played with it enough to form an opinion on that yet.
I would be +1 for Subversion.
I could also host a SVN repository for us, temporarily.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Ted Husted <hu...@apache.org>.
On Mon, 12 Jul 2004 14:41:32 -0700, Craig McClanahan wrote:
> * Did we end up deciding to stick with CVS versus Subversion? I
> know the infrastructure team would be happier if we switched to
> svn ... I haven't
> played with it enough to form an opinion on that yet.
I would be +1 for Subversion.
I could also host a SVN repository for us, temporarily.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: CVS reorg: jakarta-struts -> struts
Posted by Craig McClanahan <cr...@apache.org>.
Joe Germuska wrote:
> Apropos of the earlier discussion about Maven repositories and such,
> I'm going to try to spend at least a couple of hours staking out a new
> CVS repository for "struts-as-TLP". I'm going to try to set up a
> local repository on my machine with a copy of /home/cvs/jakarta-struts
> and see what I can do with just moving files around.
>
> Assuming that I get anywhere at all, are people OK with setting it up
> in CVS under the module "struts" and letting people use the Apache CVS
> server to test it? If not, I might be able to find a place to host it.
>
> Joe
>
+1 on having a repository available somewhere to play with, if what you
come up with looks useful.
-0 on having it on Apache hardware, until we adopt it officially. I
think it would be confusing to people in the interim period between when
it was installed and when it was adopted/abandoned.
Regarding a couple of other issues that are fuzzy in my mind:
* Did we end up agreeing with one repository (versus multiple) in the
"new world" repository? If so, "struts" is a good name for it.
Otherwise,
we might want to call it "struts-experimental" or something during the
trial and testing phase.
* Did we end up deciding to stick with CVS versus Subversion? I know
the infrastructure team would be happier if we switched to svn ... I
haven't
played with it enough to form an opinion on that yet.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org