You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <do...@gmail.com> on 2006/03/17 19:48:35 UTC
[Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
I might as well make this its own proposal: I propose we consolidate the
'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action'
subproject. We would keep the extensions as separate, but include them in
the 'action' subproject meaning they will continue to share the same version
number and release cycle.
The reason I propose this is while the original feeling was these extensions
would develop lives of their own and not hold up releases, the opposite has
proven true, especially now with Action 2 coming down the pipeline. The
same people that update tablibs, for example, are the same people that work
on Action 1, and there just hasn't been a clamoring need to release a new
version of tabligs without a new version of Action. By consolidating, we
stave off user confusion and simply the work of the Struts developer.
The new subversion repository would look like this:
action/trunk/apps
action/trunk/core
action/trunk/el
action/trunk/extras
action/trunk/faces
action/trunk/taglib
The new test for the existence of subprojects should be if:
a) The subproject has its own distinct community that requires a new
release cycle
b) The subproject is relevant to more than one framework (optional, but
encouraged)
I'd imagine this organization would allow the build for these action-related
extensions to try to build each other, leaving the other subprojects to use
snapshots instead. If every subproject had its own release cycle, I
wouldn't think we'd need/want a build that built each from trunk, since each
subproject would require different minimum versions of each other
subproject. For example, Scripting might require only Struts 1.1, so it
wouldn't make since for its build to try to build Action 1 from trunk. On
the other hand, building 'extras' would force a 'core' build.
As far as impact, I'd like to hear from the build folks (Wendy) if this
would seriously impact the build. If so, we could hold off, but I really
think this is the direction we need to move. I know it seems like we are
going backwards, but I see it as simplying our project and better aligning
it with the current energies and direction of its developers.
Don
On 3/17/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> We need to decide on a Maven groupId for Struts Action. Currently,
> we're using 'struts' but we've been asked to conform to the Maven 2
> repository structure and place our artifacts under org/apache/struts.
>
> My plan is to use org.apache.struts.action as the groupId.
>
> As you can see with Shale, that will create a sub-group in the repository:
> http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/
>
> This doesn't have to change the svn repository at all, but something
> I've been wondering about is how we're going to 'make room' for Action
> 2. Right now Action 1 is spread across the top level of the svn repo.
>
> Any thoughts on grouping the Action 1 related modules together in some
> way?
>
> And where do you see the WW/Action 2 code being added, when it comes
> out of the incubator? (Does 1.3 become a branch, or is action2 a
> separate trunk?)
>
> Thanks,
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Don Brown wrote:
> Yes, but really, it wouldn't, from an end user perspective, be much
> different than now. Currently, you have this Struts Library
> Distribution, or whatever it is called now, that contains all the
> extension jars in addition to the Action 1 jar. In this proposal, you'd
> still have that distribution to download, only now, you wouldn't have to
> worry about the version number of each component matching up.
Great! Yes, I think just simply not having to worry about the versions
is worth it.
> Don
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action 2
Posted by Don Brown <mr...@twdata.org>.
At this point, XWork will stay where it is, as the proposal only covers
WebWork 2. There is no IP problem, as Apache code depends on external
libraries all the time. We may decide later to bring over xwork, but
for now, I believe it is staying. If we do decide to bring it in, it
will have to go through the same IP clearance procedures as WebWork 2 is
subjected to now.
Don
Paul Benedict wrote:
> How is Action 2 going to deal with XWork intellectual property?
> I ask this because WebWork is just an extension of XWork,
> which AFAIK, XWork is not becoming Struts too.
> -- Paul
>
> --- Don Brown <mr...@twdata.org> wrote:
>
>
>> Whether we do this now or not is debatable, in my mind, but the more I think about it, the more
>> I think we'll need to do
>> it, and just from a project management perspective, let alone a end user confusion one. Shale
>> has components, Action 2
>> will have components, and certainly Action 1 has components. If the components need their own
>> release cycle, then the
>> alternative is to have a three-tier organization, but I think Apache wants to avoid that after
>> Jakarta.
>>
>> I've been starting to work more on Action 2 (WebWork 2.2.2 has been delayed a day so the release
>> and Apache import
>> should happen tomorrow), and I'm seeing that Action 2 will have at least the following
>> components:
>> - Core (WebWork 2)
>> - Apps
>> - Legacy
>>
>> And probably more if we split up WebWork 2 further. WebWork 2 currently handles this by setting
>> up Ivy
>> "configurations", but leaving the code in one tree. You do have the problem where an
>> infrequently, non-core part of
>> your project holds up releases, but again, unless we could do a three-tiered (Struts -> Action 2
>> -> Core, each having
>> their own releases), that's what we'll have to do. Giving Apps its own subproject, with
>> branches for Action 1, Action
>> 2, and Shale is too complicated, I think.
>>
>> I'm fine staying the course for now to ensure Action 1.3 gets a GA release soon, but we should
>> resolve this before
>> Action 2 gets out of Incubator.
>>
>> Don
>>
>> Ted Husted wrote:
>>
>>> On 3/21/06, Wendy Smoak <ws...@gmail.com> wrote:
>>>
>>>> And I didn't mean to discourage you -- in fact I offered to help. :)
>>>> My comment was qualified with 'from a release manager perspective'.
>>>> Obviously, it's easier to package and verify a release for a single
>>>> jar than several of them plus example apps.
>>>>
>>>> If anyone really wanted to keep the separate sub-projects, I think
>>>> they would have spoken up by now. Somehow I don't think you're going
>>>> to get any opposition, and now that the proposal is on the table, I'd
>>>> like to see a decision made one way or the other.
>>>>
>>> I think the important thing is that we not halt any forward progress.
>>> If someone wants to move forward with another build of one or more of
>>> the Action 1 subprojects, then I would suggest staying the course and
>>> rolling the build.
>>>
>>> If no one is eager to start moving things about, I'd suggest an
>>> optimum time to recombine the subprojects would be after each had a GA
>>> release. At least then we would have something out the door, where
>>> more teams could use it. A GA release orf each would also demonstrate
>>> an ongoing need to move things about.
>>>
>>> But, again, AFAIC, whoever is ready to do the work is welcome to make
>>> the decision.
>>>
>>> -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
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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
Action 2
Posted by Paul Benedict <pa...@yahoo.com>.
How is Action 2 going to deal with XWork intellectual property?
I ask this because WebWork is just an extension of XWork,
which AFAIK, XWork is not becoming Struts too.
-- Paul
--- Don Brown <mr...@twdata.org> wrote:
> Whether we do this now or not is debatable, in my mind, but the more I think about it, the more
> I think we'll need to do
> it, and just from a project management perspective, let alone a end user confusion one. Shale
> has components, Action 2
> will have components, and certainly Action 1 has components. If the components need their own
> release cycle, then the
> alternative is to have a three-tier organization, but I think Apache wants to avoid that after
> Jakarta.
>
> I've been starting to work more on Action 2 (WebWork 2.2.2 has been delayed a day so the release
> and Apache import
> should happen tomorrow), and I'm seeing that Action 2 will have at least the following
> components:
> - Core (WebWork 2)
> - Apps
> - Legacy
>
> And probably more if we split up WebWork 2 further. WebWork 2 currently handles this by setting
> up Ivy
> "configurations", but leaving the code in one tree. You do have the problem where an
> infrequently, non-core part of
> your project holds up releases, but again, unless we could do a three-tiered (Struts -> Action 2
> -> Core, each having
> their own releases), that's what we'll have to do. Giving Apps its own subproject, with
> branches for Action 1, Action
> 2, and Shale is too complicated, I think.
>
> I'm fine staying the course for now to ensure Action 1.3 gets a GA release soon, but we should
> resolve this before
> Action 2 gets out of Incubator.
>
> Don
>
> Ted Husted wrote:
> > On 3/21/06, Wendy Smoak <ws...@gmail.com> wrote:
> >> And I didn't mean to discourage you -- in fact I offered to help. :)
> >> My comment was qualified with 'from a release manager perspective'.
> >> Obviously, it's easier to package and verify a release for a single
> >> jar than several of them plus example apps.
> >>
> >> If anyone really wanted to keep the separate sub-projects, I think
> >> they would have spoken up by now. Somehow I don't think you're going
> >> to get any opposition, and now that the proposal is on the table, I'd
> >> like to see a decision made one way or the other.
> >
> > I think the important thing is that we not halt any forward progress.
> > If someone wants to move forward with another build of one or more of
> > the Action 1 subprojects, then I would suggest staying the course and
> > rolling the build.
> >
> > If no one is eager to start moving things about, I'd suggest an
> > optimum time to recombine the subprojects would be after each had a GA
> > release. At least then we would have something out the door, where
> > more teams could use it. A GA release orf each would also demonstrate
> > an ongoing need to move things about.
> >
> > But, again, AFAIC, whoever is ready to do the work is welcome to make
> > the decision.
> >
> > -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
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Whether we do this now or not is debatable, in my mind, but the more I think about it, the more I think we'll need to do
it, and just from a project management perspective, let alone a end user confusion one. Shale has components, Action 2
will have components, and certainly Action 1 has components. If the components need their own release cycle, then the
alternative is to have a three-tier organization, but I think Apache wants to avoid that after Jakarta.
I've been starting to work more on Action 2 (WebWork 2.2.2 has been delayed a day so the release and Apache import
should happen tomorrow), and I'm seeing that Action 2 will have at least the following components:
- Core (WebWork 2)
- Apps
- Legacy
And probably more if we split up WebWork 2 further. WebWork 2 currently handles this by setting up Ivy
"configurations", but leaving the code in one tree. You do have the problem where an infrequently, non-core part of
your project holds up releases, but again, unless we could do a three-tiered (Struts -> Action 2 -> Core, each having
their own releases), that's what we'll have to do. Giving Apps its own subproject, with branches for Action 1, Action
2, and Shale is too complicated, I think.
I'm fine staying the course for now to ensure Action 1.3 gets a GA release soon, but we should resolve this before
Action 2 gets out of Incubator.
Don
Ted Husted wrote:
> On 3/21/06, Wendy Smoak <ws...@gmail.com> wrote:
>> And I didn't mean to discourage you -- in fact I offered to help. :)
>> My comment was qualified with 'from a release manager perspective'.
>> Obviously, it's easier to package and verify a release for a single
>> jar than several of them plus example apps.
>>
>> If anyone really wanted to keep the separate sub-projects, I think
>> they would have spoken up by now. Somehow I don't think you're going
>> to get any opposition, and now that the proposal is on the table, I'd
>> like to see a decision made one way or the other.
>
> I think the important thing is that we not halt any forward progress.
> If someone wants to move forward with another build of one or more of
> the Action 1 subprojects, then I would suggest staying the course and
> rolling the build.
>
> If no one is eager to start moving things about, I'd suggest an
> optimum time to recombine the subprojects would be after each had a GA
> release. At least then we would have something out the door, where
> more teams could use it. A GA release orf each would also demonstrate
> an ongoing need to move things about.
>
> But, again, AFAIC, whoever is ready to do the work is welcome to make
> the decision.
>
> -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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Ted Husted <te...@gmail.com>.
On 3/21/06, Wendy Smoak <ws...@gmail.com> wrote:
> And I didn't mean to discourage you -- in fact I offered to help. :)
> My comment was qualified with 'from a release manager perspective'.
> Obviously, it's easier to package and verify a release for a single
> jar than several of them plus example apps.
>
> If anyone really wanted to keep the separate sub-projects, I think
> they would have spoken up by now. Somehow I don't think you're going
> to get any opposition, and now that the proposal is on the table, I'd
> like to see a decision made one way or the other.
I think the important thing is that we not halt any forward progress.
If someone wants to move forward with another build of one or more of
the Action 1 subprojects, then I would suggest staying the course and
rolling the build.
If no one is eager to start moving things about, I'd suggest an
optimum time to recombine the subprojects would be after each had a GA
release. At least then we would have something out the door, where
more teams could use it. A GA release orf each would also demonstrate
an ongoing need to move things about.
But, again, AFAIC, whoever is ready to do the work is welcome to make
the decision.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/21/06, Don Brown <mr...@twdata.org> wrote:
> Oh, sorry, I didn't mean to come across as confrontational as I'm still mulling it around in my own mind. Perhaps we
> should put off any major decision like this until Action 2 has been going for several weeks (svn cutover is tomorrow).
> Then, we may have a better idea of who will be working on it and who will still be actively developing Action 1.
And I didn't mean to discourage you -- in fact I offered to help. :)
My comment was qualified with 'from a release manager perspective'.
Obviously, it's easier to package and verify a release for a single
jar than several of them plus example apps.
If anyone really wanted to keep the separate sub-projects, I think
they would have spoken up by now. Somehow I don't think you're going
to get any opposition, and now that the proposal is on the table, I'd
like to see a decision made one way or the other.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Paul Benedict <pa...@yahoo.com>.
I guess it is good to summarize the possible options
everyone has mentioned with regards to distributions:
1. Individual libraries with independent versioning.
2. Individual libraries with single versioning.
3. Action (action+taglib) and Extras libraries only, (independent versioning?).
4. Single monolothic (negative buzzword) library.
I hope this is resolved before Action 2 because I'd like
to use a production quality Struts 1.3 soon.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Oh, sorry, I didn't mean to come across as confrontational as I'm still mulling it around in my own mind. Perhaps we
should put off any major decision like this until Action 2 has been going for several weeks (svn cutover is tomorrow).
Then, we may have a better idea of who will be working on it and who will still be actively developing Action 1.
Don
Ted Husted wrote:
> On 3/21/06, Don Brown <mr...@twdata.org> wrote:
>> The burden of proof, so to speak, should be on separate releases, not consolidation.
>
> :) No one is arguing with you, Don. :) All anyone said is that we
> didn't take the separate releases idea far enough to "prove" anything
> one way or the other. If someone wants to spend their volunteer time
> going back to consolidated releases, so far everyone has said "be our
> guest".
>
> In other words, "You had us at hello." :)
>
> -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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Ted Husted <te...@gmail.com>.
On 3/21/06, Don Brown <mr...@twdata.org> wrote:
> The burden of proof, so to speak, should be on separate releases, not consolidation.
:) No one is arguing with you, Don. :) All anyone said is that we
didn't take the separate releases idea far enough to "prove" anything
one way or the other. If someone wants to spend their volunteer time
going back to consolidated releases, so far everyone has said "be our
guest".
In other words, "You had us at hello." :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Greg Reddin <gr...@apache.org>.
On Mar 21, 2006, at 1:56 PM, Don Brown wrote:
> Wendy Smoak wrote:
>
>> Looking at the list again, struts-tiles is missing. And I'm not sure
>> how Faces is going to fit in there, it has a different set of
>> dependencies than the others. That will all sort itself out when you
>> start moving things around, though. :)
>>
>
> For Faces and Tiles, I put forth the same test for a subproject:
> a) The subproject has its own distinct community that requires a
> new release cycle
> b) The subproject is relevant to more than one framework
> (optional, but encouraged)
I understood the Tiles omission to mean that you intended for it to
remain a subproject. I would like for that to happen so it can be
released independently from anything else. So I'm +1 on your
original proposal and +1 on Tiles remaining a subproject.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
When you released 1.3.1, did you just roll Action or did you create a release for each module? If only action, does
that mean the rest are still at 1.3.0? Frank's idea of a compatibility table, in my mind, shows how potentially ugly
this can become.
Still, if there was a group of Struts committers that only wanted to work on a single part of Action 1, say core and not
taglibs, I can see us leaving things the way it is, however, we need to realize the huge price in end user complexity
and confusion that costs. The burden of proof, so to speak, should be on separate releases, not consolidation. At this
point, I just don't see a lot of new development done on Action 1 with Shale and Action 2 in the works. I could be
wrong, of course. :)
Wendy Smoak wrote:
> Looking at the list again, struts-tiles is missing. And I'm not sure
> how Faces is going to fit in there, it has a different set of
> dependencies than the others. That will all sort itself out when you
> start moving things around, though. :)
For Faces and Tiles, I put forth the same test for a subproject:
a) The subproject has its own distinct community that requires a new release cycle
b) The subproject is relevant to more than one framework (optional, but encouraged)
You know, there might be another option. We could have two subprojects: Action 1 core and Action 1 extras. This would
allow Action releases to not require everyone to wait until Faces bugs are fixed, and with just one extension
subproject, the dependency would be much easier to follow. However, this might have the some of the disadvantages of
both, especially when a project like Tiles is more active than the others.
Don
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/20/06, Don Brown <mr...@twdata.org> wrote:
> Thanks Wendy, that's what I needed to hear. So far, I haven't heard any -1 type objections, so I'll take your advice
> and try the reorg on that other svn site.
>
> When I have it working correctly, I suppose I'll call for the vote. This would be a significant change, and honestly, I
> thought there'd be a lot more resistance :) Not that I'm complaining....
>From me? As long as I get my fancy Maven build, I'm happy. ;)
I'm in favor of grouping the Action-related modules in the repository.
From a release manager perspective, (now that I have one,) I'm less
thrilled about the consolidated release, but that only means I'm less
likely to volunteer to do it.
Struts Action 1.3.1 was simple to put together, while Shale 1.0.1 was
_not_. Being able to concentrate on a single jar, a single set of
docs, etc., better fits into the blocks of time that I can devote to
this. I don't think the separate releases ever got a chance to prove
themselves, but if more people (who are going to do the work) want the
consolidated release, it's fine with me.
Looking at the list again, struts-tiles is missing. And I'm not sure
how Faces is going to fit in there, it has a different set of
dependencies than the others. That will all sort itself out when you
start moving things around, though. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Thanks Wendy, that's what I needed to hear. So far, I haven't heard any -1 type objections, so I'll take your advice
and try the reorg on that other svn site.
When I have it working correctly, I suppose I'll call for the vote. This would be a significant change, and honestly, I
thought there'd be a lot more resistance :) Not that I'm complaining....
Don
Wendy Smoak wrote:
> On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>> Certainly correct me if I'm wrong, but wouldn't this proposal more or
>> less do away with the idea of offering finer grained jar files?
>
> I think the separate jars are still a good idea, so that developers
> can choose what they want to include in their applications. A recent
> thread on the WebWork user forum brought up a similar issue, and it
> sounds like WW is also going to be offering separate jars in addition
> to the single one with everything. Since the sub-projects are already
> separated, there's nothing to be gained from re-consolidating the
> code.
>
> Back to Don's original question, I don't think this change would be
> too difficult. The build doesn't know about the 'trunk' directories
> and if we were to just 'svn mv' it, should work as-is under 'action'
> the same as it now works under 'current'.
>
> Then we would just need to find something to make what in m2 terms is
> an 'assembly,' to contain whatever we're going to include in the
> release. It looks lke the next version of the m1 distribution plugin
> has 'dist:multiproject'.
> * http://maven.apache.org/maven-1.x/plugins/dist/goals.html
>
> It could also be done in maven.xml, but using a plugin would be
> better. Along the way it would be nice to make a few changes, such as
> dropping the svn:external 'build' directory and nudging things into a
> more consistent structure.
>
> I'm in favor of the proposal, but I probably won't be able to work on
> it for a while. I'll help, though, if someone else wants to get
> started. It might be a good idea to try it in the test repo
> (https://svn.apache.org/repos/test/) first.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Wendy Smoak <ws...@gmail.com>.
On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Certainly correct me if I'm wrong, but wouldn't this proposal more or
> less do away with the idea of offering finer grained jar files?
I think the separate jars are still a good idea, so that developers
can choose what they want to include in their applications. A recent
thread on the WebWork user forum brought up a similar issue, and it
sounds like WW is also going to be offering separate jars in addition
to the single one with everything. Since the sub-projects are already
separated, there's nothing to be gained from re-consolidating the
code.
Back to Don's original question, I don't think this change would be
too difficult. The build doesn't know about the 'trunk' directories
and if we were to just 'svn mv' it, should work as-is under 'action'
the same as it now works under 'current'.
Then we would just need to find something to make what in m2 terms is
an 'assembly,' to contain whatever we're going to include in the
release. It looks lke the next version of the m1 distribution plugin
has 'dist:multiproject'.
* http://maven.apache.org/maven-1.x/plugins/dist/goals.html
It could also be done in maven.xml, but using a plugin would be
better. Along the way it would be nice to make a few changes, such as
dropping the svn:external 'build' directory and nudging things into a
more consistent structure.
I'm in favor of the proposal, but I probably won't be able to work on
it for a while. I'll help, though, if someone else wants to get
started. It might be a good idea to try it in the test repo
(https://svn.apache.org/repos/test/) first.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Paul Benedict <pa...@yahoo.com>.
Frank,
Thanks for the response, but I find that idea more creative
and less clear. I don't know if there is a good answer here.
I suppose another solution would be to say if you're in 1.3,
all 1.3 libraries are compatible; any feature that requires
more than one dependency to upgrade in tandem, must wait
until 1.4
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Paul Benedict wrote:
> Agreed. How does anyone feel about this philosophy, which I see
> can solve this problem: On any GA release of a subproject, the version
> number of Struts is incremented, and all the jars are upgraded to the
> next version number? The biggest benefit is that a struts-1.3.5.zip would
> contain all jars labeled 1.3.5. Granted, most of these subproject
upgrades
> would be benign because nothing would change, but there will never be
> confusion about the versioning.
I can't really say I like the idea... you could envision a situation
where one subproject has a number of releases in a relatively short
time, so all of sudden there's X new versions of Struts that people have
to figure out it they need or want or not.
Your goal of wanting to remove questions about version compatibility is
worthy though, I'm just not sure this is the best way to do it.
I actually think this can be dealt with using nothing more than good
documentation. Something simple like a table along these lines:
If you use:
Action 1.2.7
Then you can use:
EL- 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7
Flow- 1.2.9, 1.3.0
If you use:
Action 1.3.0
Then you can use:
EL- 1.2.5, 1.2.6, 1.2.7
Flow- 1.3.0
...and so on...
And also for each subproject:
If you want to use:
EL- 1.2.3
You can use:
Action- 1.2.7, 1.2.8, 1.3.0
If you want to use:
EL- 1.2.4
You can use:
Action- 1.2.8, 1.3.0
...and so on...
Probably a better way to lay it out, but you get the idea, and I think
that would do the trick. The person can grab whatever version of a
given extension they want, after researching the versions to see what
they provide, or they can just grab the highest compatible version. I
think the key though is that it should be driven off the core Action
version. However, it is important to have a reverse-lookup, in effect,
so that if you need a specific feature in a specific extension version,
you can at a glance see what version of Action it will work with.
> Paul
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Paul Benedict <pa...@yahoo.com>.
>> Throw in several jars each with several versions each, and a user
>> wanting to upgrade just enough to get one specific feature, but not to
>> all the newest jars, and you can understand where the confusion can
>> come from.
Agreed. How does anyone feel about this philosophy, which I see
can solve this problem: On any GA release of a subproject, the version
number of Struts is incremented, and all the jars are upgraded to the
next version number? The biggest benefit is that a struts-1.3.5.zip would
contain all jars labeled 1.3.5. Granted, most of these subproject upgrades
would be benign because nothing would change, but there will never be
confusion about the versioning.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Hubert Rabago <hr...@gmail.com>.
On 3/20/06, Nathan Bubna <nb...@gmail.com> wrote:
>
> compatibility is not that difficult to maintain in reality.
>
> for project developers there are just 3 simple rules to follow:
> - no point release (1.3.1 to 1.3.2) should ever break a working,
> outward facing API
> - all minor versions (1.3.x to 1.4.x) should deprecate working,
> outward facing APIs before removing (release foo in 1.3.x, deprecate
> in 1.4.x, and remove no sooner than 1.5.x, if at all).
> - all major versions (1.x.x to 2.x.x) are free to break or change
> whatever they wish.
>
> assuming developers respect these well-established patterns, then
> users worried about compatibility and dependencies and unwilling to
> track all project changes, there are only three simple rules:
> - point release versions that go GA are always safe to upgrade
> - watch for deprecations when upgrading minor version numbers
> - expect things to break with a major version upgrade
One of the problems is when a point release change in one package
relies on a specific point release change in another package.
If struts-action-1.3.2 adds some new functionality, and
struts-taglib-1.3.1 uses this new functionality, a user who is using
struts-action-1.3.1 can't just plug in struts-taglib-1.3.1 without
upgrading the action jar as well.
Throw in several jars each with several versions each, and a user
wanting to upgrade just enough to get one specific feature, but not to
all the newest jars, and you can understand where the confusion can
come from.
Hubert
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Michael Jouravlev <jm...@gmail.com>.
<ot>
Looking at iBatis JPetStore right now. I am curious, were BeanAction
and ActionContext ever suggested to Struts trunk?
They seem unneeded in 1.3 version, but 1.2.x could (can?) benefit from
these classes. Javadoc dates BeanAction with March 2004, that is two
years ago, when 1.3 was just taking shape, and probably mostly in the
minds rather than in the code.
Awhile ago I said that I did not see point in supporting 1.2.x, but
for some people it might be easier to use something like BeanAction
and gain from it, than to learn how properly yank the chain.
</ot>
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Ted Husted <te...@gmail.com>.
On 3/20/06, Don Brown <mr...@twdata.org> wrote:
> I think we are seeing based on previous activity that the new
> subprojects didn't facilitate easier releases and more activity, but rather complicated our
> build and release processes.
I don't have a problem with anything anyone wants to do here, but I
don't think we've had the opportunity to see anything yet.
The only 1.3.x release anyone has actually tried to make so far was
all seven together, so it was no different that the type of release we
did for 1.1 and 1.2 -- and it took forever. Not because there were
subproject releases, but because for the initial 1.3.0 builds,
everything in all seven had to be "just right" before anything was
tagged. Same old, same old.
Case in point: All but 1 subproject was ready to go in November, but
we held the other 6 subprojects for three months waiting for a
dependency to mature that affected only one of the subprojects.
That said, I'm happy to let them that is going to do the work make the decision.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Nathan Bubna wrote:
> heh. who ever heard of a quick Struts release? now you're just
> talking nonsense. ;-) but seriously, this is totally unrealistic.
> the different projects will overlap in their various states of
> readiness/buginess and the next GA release of any of it must wait
> until all of it is ready.
But this hinges on each project having different committed developers, actively developing their code. My original
point is that the committers that are working on action are the same as EL, taglibs, extras, and plugins. Even then,
those projects are more or less in maintenance mode, save perhaps Action 1, which is still being worked on.
The situation you describe is what prompted the splitting of subprojects originally. However, after almost two years of
subprojects and the looming addition of Action 2 later, I think we are seeing based on previous activity that the new
subprojects didn't facilitate easier releases and more activity, but rather complicated our build and release processes.
In the end, if you can do the same thing but with less work and complexity, then do it. I think consolidating Action
1 subprojects, which have no life outside Action 1, is the right step to evolve our code and project structure to better
fit the community and those willing to maintain it.
Don
>
>> Paul
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/20/06, Paul Benedict <pa...@yahoo.com> wrote:
> I do see benefit in having the struts-taglibs (and actions) being their
> own release because there are some very minor enhancements
> that don't really require a new action framework release.
> For instance, Struts 1.2.5 added the errorStyle and errorStyleClass
> attributes, which probably could have been released faster
> if they were separate. This is the same situation for the struts-actions
> library which doesn't need a framework upgrade to add new functionality.
>
> However, the biggest downside of separate releases, as I see it,
> will be the confusion in the separate versioning of the libraries.
> Someone might be asking one day, "Does taglibs-1.3.11 go with
> struts-action-1.3.4 or struts-action-1.3.6?" It is really going to
> be difficult to eyeball which version library depends on which version
> library of another. Did I get this wrong? Isn't this how the independent
> libraies will be released at different schedules?
compatibility is not that difficult to maintain in reality.
for project developers there are just 3 simple rules to follow:
- no point release (1.3.1 to 1.3.2) should ever break a working,
outward facing API
- all minor versions (1.3.x to 1.4.x) should deprecate working,
outward facing APIs before removing (release foo in 1.3.x, deprecate
in 1.4.x, and remove no sooner than 1.5.x, if at all).
- all major versions (1.x.x to 2.x.x) are free to break or change
whatever they wish.
assuming developers respect these well-established patterns, then
users worried about compatibility and dependencies and unwilling to
track all project changes, there are only three simple rules:
- point release versions that go GA are always safe to upgrade
- watch for deprecations when upgrading minor version numbers
- expect things to break with a major version upgrade
and all of that can be done without any documentation apart from the
version numbers themselves. throw in notice of deprecations in
changelogs, and simple instructions about the latest versions
(struts-taglibs 1.6.x depends on struts-action-core 1.4.x) and what's
the big deal?
also, by separating out the various "extra" components, you make the
development and maintenance of entirely new components (e.g.
VelocityStruts) easier, because some former "internal" APIs are now
the "external" APIs of the core compenents. since those are now
outward facing, compatibility and stability of the core is more
rigorously maintained. so for those not under the Struts umbrella,
life becomes better. :)
> If so, an alternative would be to re-tag all libraries and release
> them under one distribution version. If struts-taglibs go through
> 5 quick releases, that's also 5 quick releases of Struts too.
heh. who ever heard of a quick Struts release? now you're just
talking nonsense. ;-) but seriously, this is totally unrealistic.
the different projects will overlap in their various states of
readiness/buginess and the next GA release of any of it must wait
until all of it is ready.
> Paul
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Paul Benedict <pa...@yahoo.com>.
I do see benefit in having the struts-taglibs (and actions) being their
own release because there are some very minor enhancements
that don't really require a new action framework release.
For instance, Struts 1.2.5 added the errorStyle and errorStyleClass
attributes, which probably could have been released faster
if they were separate. This is the same situation for the struts-actions
library which doesn't need a framework upgrade to add new functionality.
However, the biggest downside of separate releases, as I see it,
will be the confusion in the separate versioning of the libraries.
Someone might be asking one day, "Does taglibs-1.3.11 go with
struts-action-1.3.4 or struts-action-1.3.6?" It is really going to
be difficult to eyeball which version library depends on which version
library of another. Did I get this wrong? Isn't this how the independent
libraies will be released at different schedules?
If so, an alternative would be to re-tag all libraries and release
them under one distribution version. If struts-taglibs go through
5 quick releases, that's also 5 quick releases of Struts too.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Craig McClanahan wrote:
> In the Struts 1.x world, the same kind of argument applies to
> struts-el.jar(only needed if you are on a < JSP
> 2.0 platform) and struts-faces.jar (only needed if you are using JSF
> components in a Struts based application).
+1
As I mentioned, I'm proposing each extension still have its own directory structure, build, and artifact, but just be
moved up under action/trunk instead of the root.
Don
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> I've looked at DWR some, but the guys here that did the initial research on
> AJAX frameworks liked DOJO better. Doesn't mean DWR is in any way "bad",
> mind you ... just that we chose differently.
Interestingly, I'll be playing with Dojo all this week :)
> At a 30,000 foot level, there are three basic architectures for usng AJAX
> (and yes, they overlap a bunch too):
>
-snip-
Excellent summation!
> By the way, I agree with you that Spring's dependency injection is more
> powerful than that provided by JSF managed beans. Wouldn't it be cool if
> you could use both Spring and JSF together, but configure your JSF managed
> beans in Spring just like you do your business logic beans?
> Oh yah ... that's already possible :-).
Hehe... of course, I think it would be even cooler to use whatever
framework you want, or no framework at all, and not even have to learn
Spring... oh wait, that's already possible too:
http://javawebparts.sourceforge.net/javadocs/javawebparts/filter/DependencyFilter.html
;)
For the record, I like the remoting stuff your doing. I find it to be
one of the more interesting things in Shale.
> Craig
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Craig McClanahan <cr...@apache.org>.
On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Craig McClanahan wrote:
> > Common in the future? That's the plan ... it's especially designed for
> > folks who want to create the server side of AJAX interactions, plus
> people
> > who want to write AJAX-enabled components. The power of expression
> > evaluation, plus the "basic dependency injection" capabilities of
> managed
> > beans, are just too much goodness to pass up.
>
> Obviously going OT for this thread, so I'd be happy to start a new one
> if you want, but this is very interesting to me as a pretty big AJAX
> booster..
>
> Have you ever looked at DWR? I wonder what your impression is of that?
> Especially since it has Spring integration, which I'm sure you would
> agree if better dependency injection than the basic capabilities JSF
> provides, and since it works with *any* framework, and allows you to
> access POJOs, I would personally favor that than start using a whole new
> framework. What benefits would you say there are to using Shale/JSF
> than that with any other framework over a DWR-based solution? Certainly
> you can fire off a chain in any case if that's your need, so I don't see
> that as being one. Again, just curious here as an "AJAX guy".
I've looked at DWR some, but the guys here that did the initial research on
AJAX frameworks liked DOJO better. Doesn't mean DWR is in any way "bad",
mind you ... just that we chose differently.
I guess what I'm *really* getting at is to ask doesn't AJAX make much of
> this JSF/Shale vs. Struts vs. WW vs. Tapestry vs. whatever else somewhat
> irrelevant? Might it even be better to just develop the Shale remoting
> as a separate AJAX library?
>
> Not trying to pick fight :-)
Not swinging back either :-).
At a 30,000 foot level, there are three basic architectures for usng AJAX
(and yes, they overlap a bunch too):
* "Eye Candy" -- add a little bit of asynch interactivity to an existing
application,
often done by utilizing existing JavaScript event handlers on the relevant
HTML tags directly (perhaps with the help of a client side JS library,
perhaps with just hand coded cut-n-paste JS that you saw on some website).
* "Server Side UI" -- the UI of an app fundamentally based on widgets
with asynchronous callbacks, but it's still rendered on the server side
as is typical of webapps today ... except that the JavaScript/DHTML
madness is encapsulated in some sort of API (custom tags, JSF components,
PHP objects, whatever) that hides the complexity from the developer.
* "Client Side Controller" -- the app itself moves to the client side, and
asynch callbacks are strictly for exchanging model tier data.
JSF UI components (as well as the framework) work great for the first two
cases. The UI components are of less use in the third case (although in an
ideal scenario the client side widgets you encapsulated with JSF components
for the first two cases is the same code you use directly for the third
case), but the framework part is still fully capable of doing what you need
to map incoming requests to particular business logic, and helping you
format the response. Shale Remoting is still very useful in the third case
(as well as being a nice utility library for those building JSF components
to handle the first two cases).
By the way, I agree with you that Spring's dependency injection is more
powerful than that provided by JSF managed beans. Wouldn't it be cool if
you could use both Spring and JSF together, but configure your JSF managed
beans in Spring just like you do your business logic beans?
Oh yah ... that's already possible :-). Spring includes integration with
JSF's expression evaluation facilities, so you can use Spring-created beans
in your JSF value binding and method binding expressions, without the
expression user (UI component, Shale Remoting mapping of an AJAX request,
whatever) having to know that. And that one doesn't even take Shale ...
basic support for this comes out of the box with Spring, and there's an
extension library at SourceForge if you want to get a little fancier (i.e.
put Spring-managed beans into request/session/application scope
automatically, not just create singletons and per-request instances).
> Craig
>
> Frank
Craig
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> Common in the future? That's the plan ... it's especially designed for
> folks who want to create the server side of AJAX interactions, plus people
> who want to write AJAX-enabled components. The power of expression
> evaluation, plus the "basic dependency injection" capabilities of managed
> beans, are just too much goodness to pass up.
Obviously going OT for this thread, so I'd be happy to start a new one
if you want, but this is very interesting to me as a pretty big AJAX
booster..
Have you ever looked at DWR? I wonder what your impression is of that?
Especially since it has Spring integration, which I'm sure you would
agree if better dependency injection than the basic capabilities JSF
provides, and since it works with *any* framework, and allows you to
access POJOs, I would personally favor that than start using a whole new
framework. What benefits would you say there are to using Shale/JSF
than that with any other framework over a DWR-based solution? Certainly
you can fire off a chain in any case if that's your need, so I don't see
that as being one. Again, just curious here as an "AJAX guy".
I guess what I'm *really* getting at is to ask doesn't AJAX make much of
this JSF/Shale vs. Struts vs. WW vs. Tapestry vs. whatever else somewhat
irrelevant? Might it even be better to just develop the Shale remoting
as a separate AJAX library?
Not trying to pick fight :-)
> Craig
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Craig McClanahan <cr...@apache.org>.
On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Craig McClanahan wrote:
> > On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >> You know, I was looking at the Struts front page a few minutes ago,
> >> specifically the "Extensions", which are the seven dwarfs IIRC. The
> one
> >> that sticks out for me as a "problem", if that's the right word, is the
> >> JSP Taglib.
> >
> >
> > I suspect that Struts users who abhor JSP, but like things like
> Velocity,
> > would not agree with you :-).
>
> Hehe, probably right :)
>
> > Indeed, if you're using Struts as the server end of AJAX transactions,
> you
> > don't need this library even if you do happen to use JSP for the human
> user
> > interface portion of your application (perhaps using a different
> framework).
> >
> > I think it's fair to say that the majority of Struts developers consider
> >> the Struts tags to be intrinsically part of the Struts Action Framework
> >> (SAF). Except for me who rarely uses them! :)
> >>
> >> The analogy I would use us the component kit you use in a JSF app...
> >> *can* you build a JSF app with no component kit at all?
> >
> >
> > You bet you can.
>
> Do you have any feel for how common it is though? My guess is that it
> isn't very common, but your certainly in a better position to tell then
> I am. It just doesn't *feel* like something I would expect to find to
> be common, just like not using the Struts taglibs probably isn't the
> most common usage pattern.
Common now? Probably ot very ... especially if you point someone at the
current website documentaton for this feature[1] :-). You need to peruse
the Javadocs, and ask questions on the list, to get very far right at the
moment. And, most people who evaluate JSF never seem to look at the
underlying infrastructure ... they get obsessed with the components and
either like or dislike it on that basis.
Common in the future? That's the plan ... it's especially designed for
folks who want to create the server side of AJAX interactions, plus people
who want to write AJAX-enabled components. The power of expression
evaluation, plus the "basic dependency injection" capabilities of managed
beans, are just too much goodness to pass up. JSF's fundamental front
controller architecture is plenty of power for this sort of use case. With
Shale Remoting, you can plug in (out of the box) a call to any arbitrary
method (it maps based on the request URL), or to any Commons Chain command
or chain implementation. Adding support to map to an XWork (the underlying
framework that WebWork is based on) interceptor chain is on my list of
things to add, but it's going to be really easy. Also, something to think
about for the future ... in JSF 1.2 and JSP 2.1, the expression language
APIs and implementation got factored into their own spec document, which
*might* ultimately be a candidate for inclusion in the JDK. It turns out
that a common expression evaluation library is pretty handy in simplifying
quite a few use cases. For example, anything that Commons BeanUtils can do
is *much* more elegantly handled with EL expressions and a few appropriate
complementary classes (like converters).
We (Sun) are using this library in the next version of the demo AJAX
components that you can get with Java Studio Creator 2 [2]. Doing so cut
the number of lines of code per component down dramatically (besides the
fact that the original approach didn't take advantage of browser caching,
required you to use "/faces/*" mapping, yadda yadda). More importantly, it
got rid of the approach that was used in the initial prototyping of these
components (a separate PhaseListener per component for serving up static
resources and responding to AJAX requests), which is not a particularly
scalable design :-).
> Come to think of it ... there's even a 40kb standalone jar file (
> > shale-remoting.jar) that does exactly this kind of thing, with no
> > dependencies on the UI components part of JSF, or even on the rest of
> Shale
> > :-).
>
> Cute :-)
>
> > Craig
>
> Frank
Craig
[1] http://struts.apache.org/struts-shale/features-remoting.html
[2] http://developers.sun.com/jscreator/
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> You know, I was looking at the Struts front page a few minutes ago,
>> specifically the "Extensions", which are the seven dwarfs IIRC. The one
>> that sticks out for me as a "problem", if that's the right word, is the
>> JSP Taglib.
>
>
> I suspect that Struts users who abhor JSP, but like things like Velocity,
> would not agree with you :-).
Hehe, probably right :)
> Indeed, if you're using Struts as the server end of AJAX transactions, you
> don't need this library even if you do happen to use JSP for the human user
> interface portion of your application (perhaps using a different framework).
>
> I think it's fair to say that the majority of Struts developers consider
>> the Struts tags to be intrinsically part of the Struts Action Framework
>> (SAF). Except for me who rarely uses them! :)
>>
>> The analogy I would use us the component kit you use in a JSF app...
>> *can* you build a JSF app with no component kit at all?
>
>
> You bet you can.
Do you have any feel for how common it is though? My guess is that it
isn't very common, but your certainly in a better position to tell then
I am. It just doesn't *feel* like something I would expect to find to
be common, just like not using the Struts taglibs probably isn't the
most common usage pattern.
> Come to think of it ... there's even a 40kb standalone jar file (
> shale-remoting.jar) that does exactly this kind of thing, with no
> dependencies on the UI components part of JSF, or even on the rest of Shale
> :-).
Cute :-)
> Craig
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Craig McClanahan <cr...@apache.org>.
On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> You know, I was looking at the Struts front page a few minutes ago,
> specifically the "Extensions", which are the seven dwarfs IIRC. The one
> that sticks out for me as a "problem", if that's the right word, is the
> JSP Taglib.
I suspect that Struts users who abhor JSP, but like things like Velocity,
would not agree with you :-).
Indeed, if you're using Struts as the server end of AJAX transactions, you
don't need this library even if you do happen to use JSP for the human user
interface portion of your application (perhaps using a different framework).
I think it's fair to say that the majority of Struts developers consider
> the Struts tags to be intrinsically part of the Struts Action Framework
> (SAF). Except for me who rarely uses them! :)
>
> The analogy I would use us the component kit you use in a JSF app...
> *can* you build a JSF app with no component kit at all?
You bet you can.
I would guess
> yes... but how many people *would* ever do that? I would guess very
> few. I think the same is true of the Struts tags.
Just as an example use case, if you like using the expression evaluation and
managed beans portion of JSF, but don't like the UI component architecture,
you can do exactly that. In fact, this makes a really nice back end for
AJAX type interactions.
Come to think of it ... there's even a 40kb standalone jar file (
shale-remoting.jar) that does exactly this kind of thing, with no
dependencies on the UI components part of JSF, or even on the rest of Shale
:-).
I think everything else, Tiles, Flow, EL, etc., really do seem to me to
> be true "extensions", and as such it makes sense for them to develop on
> their own, be packaged on their own, and be downloaded separately as
> needed. My only concern there is simply to document well what
> version(s) of a given extension can be used with a given version of SAF.
> I think this information should always be front and center and easy to
> find quickly.
>
> But, the JSP Taglib, that one I think really does make more sense to go
> along with the core itself. I'm not saying it can't be its own JAR...
> that's just a matter of the final build artifact. I'd probably opt to
> include it in the Struts JAR, but that's really a minor point IMO. What
> is more important is that I think the taglib should share the same
> version number, release cycle, etc., as the core, and in fact should
> just simply BE part of the core.
>
> I guess I'm saying I would propose amending Don's proposal to only apply
> to the Struts taglibs :)
>
> > Craig
>
> Frank
Craig
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Nathan Bubna wrote:
> > there have been VelocityStruts users eager for the Struts tags to be
> > separated from the core for a long time. there's plenty of people
> > using Struts without the tags.
>
> I didn't know that, thanks for pointing it out. Do the tags being there
> hinder those users in any way though? Assuming not, and assuming my
> belief that more Struts developers *DO* use the tags than don't (which
> may not be true!) then I'm not sure it matters, and I would still
> suggest the tags should be part of the core.
Not directly. But in so far as "extras" can hinder releases and sap
development effort from the core, they do hinder the users. In
general, one of the reasons i liked seeing the Struts "extras" pulled
out of the core was the hope that bugs and slow development in such
non-essential parts of Struts would no longer be a hinderance to fresh
Struts core releases. It's a tough trade-off though, i admit. Either
risk dependency confusion and frustration or else risk having good
code be held back by "extras" that only a portion of the userbase is
interested in. Personally, i prefer a little extra dependency
complexity (and that preference even predates the usefulness of Maven
and Ivy for such things) to the stifling of release frequency and
freedom.
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Nathan Bubna wrote:
> there have been VelocityStruts users eager for the Struts tags to be
> separated from the core for a long time. there's plenty of people
> using Struts without the tags.
I didn't know that, thanks for pointing it out. Do the tags being there
hinder those users in any way though? Assuming not, and assuming my
belief that more Struts developers *DO* use the tags than don't (which
may not be true!) then I'm not sure it matters, and I would still
suggest the tags should be part of the core.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Craig McClanahan wrote:
> > For Shale, at least, I would *not* advocate eliminating separate JAR files.
> > There are optional features of Shale that themselves have their own
> > dependencies, and it would be a burden on all Shale users if everything was
> > combined into one JAR file. As Ted mentioned earlier in some thread, this
> > is a lesson that we in the Struts community can learn from what Spring is
> > doing.
> >
> > Two use cases in the Shale world:
> >
> > * Shale Remoting -- a completely standalone JAR file that does not depend on
> > anything else in Shale, but is useful for component authors and app
> > developers
> > doing AJAX style development. 40k and zero dependencies, versus 140k
> > (for shale-core.jar) and a bunch of dependencies.
> >
> > * Tiger Extensions -- optional layer on top of Shale that utilizes JDK
> > 1.5annotations
> > to reduce or eliminate configuration files. Including this stuff in a
> > core Shale
> > JAR file would require *all* users to be based on JDK 1.5.
> >
> > In the Struts 1.x world, the same kind of argument applies to
> > struts-el.jar(only needed if you are on a < JSP
> > 2.0 platform) and struts-faces.jar (only needed if you are using JSF
> > components in a Struts based application).
>
> That all makes perfect sense, thanks Craig.
>
> You know, I was looking at the Struts front page a few minutes ago,
> specifically the "Extensions", which are the seven dwarfs IIRC. The one
> that sticks out for me as a "problem", if that's the right word, is the
> JSP Taglib.
there have been VelocityStruts users eager for the Struts tags to be
separated from the core for a long time. there's plenty of people
using Struts without the tags.
> I think it's fair to say that the majority of Struts developers consider
> the Struts tags to be intrinsically part of the Struts Action Framework
> (SAF). Except for me who rarely uses them! :)
>
> The analogy I would use us the component kit you use in a JSF app...
> *can* you build a JSF app with no component kit at all? I would guess
> yes... but how many people *would* ever do that? I would guess very
> few. I think the same is true of the Struts tags.
>
> I think everything else, Tiles, Flow, EL, etc., really do seem to me to
> be true "extensions", and as such it makes sense for them to develop on
> their own, be packaged on their own, and be downloaded separately as
> needed. My only concern there is simply to document well what
> version(s) of a given extension can be used with a given version of SAF.
> I think this information should always be front and center and easy to
> find quickly.
>
> But, the JSP Taglib, that one I think really does make more sense to go
> along with the core itself. I'm not saying it can't be its own JAR...
> that's just a matter of the final build artifact. I'd probably opt to
> include it in the Struts JAR, but that's really a minor point IMO. What
> is more important is that I think the taglib should share the same
> version number, release cycle, etc., as the core, and in fact should
> just simply BE part of the core.
>
> I guess I'm saying I would propose amending Don's proposal to only apply
> to the Struts taglibs :)
>
> > Craig
>
> Frank
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> For Shale, at least, I would *not* advocate eliminating separate JAR files.
> There are optional features of Shale that themselves have their own
> dependencies, and it would be a burden on all Shale users if everything was
> combined into one JAR file. As Ted mentioned earlier in some thread, this
> is a lesson that we in the Struts community can learn from what Spring is
> doing.
>
> Two use cases in the Shale world:
>
> * Shale Remoting -- a completely standalone JAR file that does not depend on
> anything else in Shale, but is useful for component authors and app
> developers
> doing AJAX style development. 40k and zero dependencies, versus 140k
> (for shale-core.jar) and a bunch of dependencies.
>
> * Tiger Extensions -- optional layer on top of Shale that utilizes JDK
> 1.5annotations
> to reduce or eliminate configuration files. Including this stuff in a
> core Shale
> JAR file would require *all* users to be based on JDK 1.5.
>
> In the Struts 1.x world, the same kind of argument applies to
> struts-el.jar(only needed if you are on a < JSP
> 2.0 platform) and struts-faces.jar (only needed if you are using JSF
> components in a Struts based application).
That all makes perfect sense, thanks Craig.
You know, I was looking at the Struts front page a few minutes ago,
specifically the "Extensions", which are the seven dwarfs IIRC. The one
that sticks out for me as a "problem", if that's the right word, is the
JSP Taglib.
I think it's fair to say that the majority of Struts developers consider
the Struts tags to be intrinsically part of the Struts Action Framework
(SAF). Except for me who rarely uses them! :)
The analogy I would use us the component kit you use in a JSF app...
*can* you build a JSF app with no component kit at all? I would guess
yes... but how many people *would* ever do that? I would guess very
few. I think the same is true of the Struts tags.
I think everything else, Tiles, Flow, EL, etc., really do seem to me to
be true "extensions", and as such it makes sense for them to develop on
their own, be packaged on their own, and be downloaded separately as
needed. My only concern there is simply to document well what
version(s) of a given extension can be used with a given version of SAF.
I think this information should always be front and center and easy to
find quickly.
But, the JSP Taglib, that one I think really does make more sense to go
along with the core itself. I'm not saying it can't be its own JAR...
that's just a matter of the final build artifact. I'd probably opt to
include it in the Struts JAR, but that's really a minor point IMO. What
is more important is that I think the taglib should share the same
version number, release cycle, etc., as the core, and in fact should
just simply BE part of the core.
I guess I'm saying I would propose amending Don's proposal to only apply
to the Struts taglibs :)
> Craig
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Craig McClanahan <cr...@apache.org>.
On 3/19/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Craig McClanahan wrote:
> > I can certainly buy into release consolidation along these four
> paths. That
> > being said, separating the source artifacts (and the binary jar files
> that
> > result from them) is still useful in terms of clearly articulating
> > dependencies *within* a particular release. That becomes much more
> > important as we offer finer grained jar files that are optional but
> impose
> > their own external dependencies.
>
> Certainly correct me if I'm wrong, but wouldn't this proposal more or
> less do away with the idea of offering finer grained jar files? Except
> for Tiles, which I know is being spun off on its own (I presume so the
> same code base can support Struts, Shale and anything else?), are any of
> the other "dwarfs" in the same kind of boat as Tiles? It sounds from
> this proposal like they may not be?...
For Shale, at least, I would *not* advocate eliminating separate JAR files.
There are optional features of Shale that themselves have their own
dependencies, and it would be a burden on all Shale users if everything was
combined into one JAR file. As Ted mentioned earlier in some thread, this
is a lesson that we in the Struts community can learn from what Spring is
doing.
Two use cases in the Shale world:
* Shale Remoting -- a completely standalone JAR file that does not depend on
anything else in Shale, but is useful for component authors and app
developers
doing AJAX style development. 40k and zero dependencies, versus 140k
(for shale-core.jar) and a bunch of dependencies.
* Tiger Extensions -- optional layer on top of Shale that utilizes JDK
1.5annotations
to reduce or eliminate configuration files. Including this stuff in a
core Shale
JAR file would require *all* users to be based on JDK 1.5.
In the Struts 1.x world, the same kind of argument applies to
struts-el.jar(only needed if you are on a < JSP
2.0 platform) and struts-faces.jar (only needed if you are using JSF
components in a Struts based application).
Craig
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> I can certainly buy into release consolidation along these four paths. That
> being said, separating the source artifacts (and the binary jar files that
> result from them) is still useful in terms of clearly articulating
> dependencies *within* a particular release. That becomes much more
> important as we offer finer grained jar files that are optional but impose
> their own external dependencies.
Certainly correct me if I'm wrong, but wouldn't this proposal more or
less do away with the idea of offering finer grained jar files? Except
for Tiles, which I know is being spun off on its own (I presume so the
same code base can support Struts, Shale and anything else?), are any of
the other "dwarfs" in the same kind of boat as Tiles? It sounds from
this proposal like they may not be?...
>
> Don
>
>
> Craig
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Craig McClanahan <cr...@apache.org>.
On 3/17/06, Don Brown <mr...@twdata.org> wrote:
>
> Frank W. Zammetti wrote:
> > On Fri, March 17, 2006 1:48 pm, Don Brown said:
> >> I might as well make this its own proposal: I propose we consolidate
> the
> >> 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action'
> >> subproject. We would keep the extensions as separate, but include them
> in
> >> the 'action' subproject meaning they will continue to share the same
> >> version
> >> number and release cycle.
> >
> > Just to see if I understand... There would be a single "Action" entity,
> > that contains all of these? If you download "Action" you get extras and
> > el and taglibs, etc.? In other words, what has been the case for some
> > time would still be the case, except that we call the entity "Action" as
> > opposed to "Struts". Is that correct? If so, definite +1 from me.
>
> Yes, but really, it wouldn't, from an end user perspective, be much
> different than now. Currently, you have this Struts
> Library Distribution, or whatever it is called now, that contains all the
> extension jars in addition to the Action 1
> jar. In this proposal, you'd still have that distribution to download,
> only now, you wouldn't have to worry about the
> version number of each component matching up.
>
> > think a very good one. I recall there being a fair bit of concern
> raised
> > when the decision was originally made... if some of those concerns have
> > come to fruition, quite possibly because other things happened in the
> > intervening time (was the WW merger on the table when this was decided
> for
> > instance?) then reversing the decision makes sense.
>
> The subproject split was way before the WW merger, and IIRC, I was the one
> that did the original SVN moving arounds at
> ApacheCon two years ago. The emergence of Action 2 changes things
> completely, and IMO, the reasons we split as we did
> aren't valid anymore. I don't see it as much as a reversal, but a new
> evolution. We are still keeping many of the same
> subprojects, just consolidating the Action 1-specific ones ahead of the
> Action 2 start.
I'm not sure that action2 "changes things completely", but it does introduce
a separate development path that needs to be accounted for. I think that
leaves us with four main development "domains" (or whatever term you like
that implies grouping but does not imply hierarchy :-):
* Struts 1.x -- ongoing maintenance support of the 1.3 codebase
(our users will string us up from the yardarms if this is not a
first class notion in our minds)
* WebWork 2.x -- same thing for existing WW users (although this
might legitimately stay at OpenSymphony?)
* Struts 2.x -- the endgame for the merger efforts
* Shale -- All the stuff around Shale (which, like Struts 1.x, is
segregated in terms of source repository directory structure but
has not actually been released in fine grained units (yet)).
I can certainly buy into release consolidation along these four paths. That
being said, separating the source artifacts (and the binary jar files that
result from them) is still useful in terms of clearly articulating
dependencies *within* a particular release. That becomes much more
important as we offer finer grained jar files that are optional but impose
their own external dependencies.
Don
Craig
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Frank W. Zammetti wrote:
> On Fri, March 17, 2006 1:48 pm, Don Brown said:
>> I might as well make this its own proposal: I propose we consolidate the
>> 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action'
>> subproject. We would keep the extensions as separate, but include them in
>> the 'action' subproject meaning they will continue to share the same
>> version
>> number and release cycle.
>
> Just to see if I understand... There would be a single "Action" entity,
> that contains all of these? If you download "Action" you get extras and
> el and taglibs, etc.? In other words, what has been the case for some
> time would still be the case, except that we call the entity "Action" as
> opposed to "Struts". Is that correct? If so, definite +1 from me.
Yes, but really, it wouldn't, from an end user perspective, be much different than now. Currently, you have this Struts
Library Distribution, or whatever it is called now, that contains all the extension jars in addition to the Action 1
jar. In this proposal, you'd still have that distribution to download, only now, you wouldn't have to worry about the
version number of each component matching up.
> think a very good one. I recall there being a fair bit of concern raised
> when the decision was originally made... if some of those concerns have
> come to fruition, quite possibly because other things happened in the
> intervening time (was the WW merger on the table when this was decided for
> instance?) then reversing the decision makes sense.
The subproject split was way before the WW merger, and IIRC, I was the one that did the original SVN moving arounds at
ApacheCon two years ago. The emergence of Action 2 changes things completely, and IMO, the reasons we split as we did
aren't valid anymore. I don't see it as much as a reversal, but a new evolution. We are still keeping many of the same
subprojects, just consolidating the Action 1-specific ones ahead of the Action 2 start.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs,
and faces under 'action' (was Maven groupId and svn repo structure)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, March 17, 2006 1:48 pm, Don Brown said:
> I might as well make this its own proposal: I propose we consolidate the
> 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action'
> subproject. We would keep the extensions as separate, but include them in
> the 'action' subproject meaning they will continue to share the same
> version
> number and release cycle.
Just to see if I understand... There would be a single "Action" entity,
that contains all of these? If you download "Action" you get extras and
el and taglibs, etc.? In other words, what has been the case for some
time would still be the case, except that we call the entity "Action" as
opposed to "Struts". Is that correct? If so, definite +1 from me.
> The reason I propose this is while the original feeling was these
> extensions
> would develop lives of their own and not hold up releases, the opposite
> has
> proven true, especially now with Action 2 coming down the pipeline. The
> same people that update tablibs, for example, are the same people that
> work
> on Action 1, and there just hasn't been a clamoring need to release a new
> version of tabligs without a new version of Action. By consolidating, we
> stave off user confusion and simply the work of the Struts developer.
If I'm understanding your proposal, it would be a course change, but I
think a very good one. I recall there being a fair bit of concern raised
when the decision was originally made... if some of those concerns have
come to fruition, quite possibly because other things happened in the
intervening time (was the WW merger on the table when this was decided for
instance?) then reversing the decision makes sense.
> I'd imagine this organization would allow the build for these
> action-related
> extensions to try to build each other, leaving the other subprojects to
> use
> snapshots instead. If every subproject had its own release cycle, I
> wouldn't think we'd need/want a build that built each from trunk, since
> each
> subproject would require different minimum versions of each other
> subproject. For example, Scripting might require only Struts 1.1, so it
> wouldn't make since for its build to try to build Action 1 from trunk. On
> the other hand, building 'extras' would force a 'core' build.
I think this proposal would eliminate a lot of potential confusion with
version dependencies, which I think is clearly a good thing.
> As far as impact, I'd like to hear from the build folks (Wendy) if this
> would seriously impact the build. If so, we could hold off, but I really
> think this is the direction we need to move. I know it seems like we are
> going backwards, but I see it as simplying our project and better aligning
> it with the current energies and direction of its developers.
I wouldn't consider it a step backward actually... an idea was proposed...
it was implemented... there is now some thought that maybe it didn't work
out quite as hoped... now a decision is made to do something different
which just happens to be what was done before the decision. This is just
good, flexible, thoughtful decision-making and leadership.
I can only speak as a member of the developer community... I thought the
separate release cycles, while not without merit, had the potential to be
confusing and make things more difficult on developers, and maybe too the
committers. Therefore, I would support this proposal, just as an
interested third-party.
> Don
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Joe Germuska wrote:
> If we're going to consolidate, why not go whole hog and have a single
> artifact?
I still see value in the extensions having their own artifacts. For one, it makes it easier to grok for new folks, and
in cases like taglib and el, they can't be merged. I see it working similarly to how Spring manages its components.
Don
>
> I agree that past experience and the future of action2 suggest that
> there's not going to be a lot of activity in various subprojects
> independent of an individual release.
>
> Joe
>
>
>
> At 10:48 AM -0800 3/17/06, Don Brown wrote:
>> I might as well make this its own proposal: I propose we consolidate the
>> 'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action'
>> subproject. We would keep the extensions as separate, but include
>> them in
>> the 'action' subproject meaning they will continue to share the same
>> version
>> number and release cycle.
>>
>> The reason I propose this is while the original feeling was these
>> extensions
>> would develop lives of their own and not hold up releases, the
>> opposite has
>> proven true, especially now with Action 2 coming down the pipeline. The
>> same people that update tablibs, for example, are the same people that
>> work
>> on Action 1, and there just hasn't been a clamoring need to release a new
>> version of tabligs without a new version of Action. By consolidating, we
>> stave off user confusion and simply the work of the Struts developer.
>>
>> The new subversion repository would look like this:
>> action/trunk/apps
>> action/trunk/core
>> action/trunk/el
>> action/trunk/extras
>> action/trunk/faces
>> action/trunk/taglib
>>
>> The new test for the existence of subprojects should be if:
>> a) The subproject has its own distinct community that requires a new
>> release cycle
>> b) The subproject is relevant to more than one framework (optional, but
>> encouraged)
>>
>> I'd imagine this organization would allow the build for these
>> action-related
>> extensions to try to build each other, leaving the other subprojects
>> to use
>> snapshots instead. If every subproject had its own release cycle, I
>> wouldn't think we'd need/want a build that built each from trunk,
>> since each
>> subproject would require different minimum versions of each other
>> subproject. For example, Scripting might require only Struts 1.1, so it
>> wouldn't make since for its build to try to build Action 1 from
>> trunk. On
>> the other hand, building 'extras' would force a 'core' build.
>>
>> As far as impact, I'd like to hear from the build folks (Wendy) if this
>> would seriously impact the build. If so, we could hold off, but I really
>> think this is the direction we need to move. I know it seems like we are
>> going backwards, but I see it as simplying our project and better
>> aligning
>> it with the current energies and direction of its developers.
>>
>> Don
>>
>> On 3/17/06, Wendy Smoak <ws...@gmail.com> wrote:
>>>
>>> We need to decide on a Maven groupId for Struts Action. Currently,
>>> we're using 'struts' but we've been asked to conform to the Maven 2
>>> repository structure and place our artifacts under org/apache/struts.
>>>
>>> My plan is to use org.apache.struts.action as the groupId.
>>>
>>> As you can see with Shale, that will create a sub-group in the
>>> repository:
>>> http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/
>>>
>>> This doesn't have to change the svn repository at all, but something
>>> I've been wondering about is how we're going to 'make room' for Action
>>> 2. Right now Action 1 is spread across the top level of the svn repo.
>>>
>>> Any thoughts on grouping the Action 1 related modules together in some
>>> way?
>>>
>>> And where do you see the WW/Action 2 code being added, when it comes
>>> out of the incubator? (Does 1.3 become a branch, or is action2 a
>>> separate trunk?)
>>>
>>> Thanks,
>>> Wendy
>>>
>>> ---------------------------------------------------------------------
>>> 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: [Proposal] Consolidate extras, EL, taglibs, and faces under
'action' (was Maven groupId and svn repo structure)
Posted by Joe Germuska <Jo...@Germuska.com>.
If we're going to consolidate, why not go whole hog and have a single artifact?
I agree that past experience and the future of action2 suggest that
there's not going to be a lot of activity in various subprojects
independent of an individual release.
Joe
At 10:48 AM -0800 3/17/06, Don Brown wrote:
>I might as well make this its own proposal: I propose we consolidate the
>'extras', 'el', 'taglibs', and 'faces' subprojects under the 'action'
>subproject. We would keep the extensions as separate, but include them in
>the 'action' subproject meaning they will continue to share the same version
>number and release cycle.
>
>The reason I propose this is while the original feeling was these extensions
>would develop lives of their own and not hold up releases, the opposite has
>proven true, especially now with Action 2 coming down the pipeline. The
>same people that update tablibs, for example, are the same people that work
>on Action 1, and there just hasn't been a clamoring need to release a new
>version of tabligs without a new version of Action. By consolidating, we
>stave off user confusion and simply the work of the Struts developer.
>
>The new subversion repository would look like this:
>action/trunk/apps
>action/trunk/core
>action/trunk/el
>action/trunk/extras
>action/trunk/faces
>action/trunk/taglib
>
>The new test for the existence of subprojects should be if:
> a) The subproject has its own distinct community that requires a new
>release cycle
> b) The subproject is relevant to more than one framework (optional, but
>encouraged)
>
>I'd imagine this organization would allow the build for these action-related
>extensions to try to build each other, leaving the other subprojects to use
>snapshots instead. If every subproject had its own release cycle, I
>wouldn't think we'd need/want a build that built each from trunk, since each
>subproject would require different minimum versions of each other
>subproject. For example, Scripting might require only Struts 1.1, so it
>wouldn't make since for its build to try to build Action 1 from trunk. On
>the other hand, building 'extras' would force a 'core' build.
>
>As far as impact, I'd like to hear from the build folks (Wendy) if this
>would seriously impact the build. If so, we could hold off, but I really
>think this is the direction we need to move. I know it seems like we are
>going backwards, but I see it as simplying our project and better aligning
>it with the current energies and direction of its developers.
>
>Don
>
>On 3/17/06, Wendy Smoak <ws...@gmail.com> wrote:
>>
>> We need to decide on a Maven groupId for Struts Action. Currently,
>> we're using 'struts' but we've been asked to conform to the Maven 2
>> repository structure and place our artifacts under org/apache/struts.
>>
>> My plan is to use org.apache.struts.action as the groupId.
>>
>> As you can see with Shale, that will create a sub-group in the repository:
>> http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/
>>
>> This doesn't have to change the svn repository at all, but something
>> I've been wondering about is how we're going to 'make room' for Action
>> 2. Right now Action 1 is spread across the top level of the svn repo.
>>
>> Any thoughts on grouping the Action 1 related modules together in some
>> way?
>>
>> And where do you see the WW/Action 2 code being added, when it comes
>> out of the incubator? (Does 1.3 become a branch, or is action2 a
>> separate trunk?)
>>
>> Thanks,
>> Wendy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action'
(was Maven groupId and svn repo structure)
Posted by Don Brown <mr...@twdata.org>.
Michael Jouravlev wrote:
> On 3/17/06, Don Brown <do...@gmail.com> wrote:
>> The new subversion repository would look like this:
>> action/trunk/apps
>> action/trunk/core
>> action/trunk/el
>> action/trunk/extras
>> action/trunk/faces
>> action/trunk/taglib
>
> What is the difference between el and taglib besides el support? Would
> not it be more logical to have action/trunk/taglib and
> action/trunk/taglib-el ?
Well, yes, I suppose that name would be more accurate, and we could switch if this proposal was accepted.
Don
>
> Michael.
>
> ---------------------------------------------------------------------
> 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: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/17/06, Don Brown <do...@gmail.com> wrote:
> The new subversion repository would look like this:
> action/trunk/apps
> action/trunk/core
> action/trunk/el
> action/trunk/extras
> action/trunk/faces
> action/trunk/taglib
What is the difference between el and taglib besides el support? Would
not it be more logical to have action/trunk/taglib and
action/trunk/taglib-el ?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org