You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Mitchell <jm...@apache.org> on 2005/07/28 06:27:05 UTC
1.3.0 -- stalled
It looks like I won't have the time that I thought I had to get 1.3.0
cut and rolled out any time soon. My day job is heating up and the
kids soccer season starts up very soon. I'm also running 2 local
user groups (web-atlanta and jboss-atlanta) and participating in a
new architects group (IASA).
I wish I had more time to do this, but I just don't have the time I
need to do it right. If someone else wants to take the reigns and
run, I'd be very appreciative.....Wendy?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 -- stalled
Posted by Ted Husted <te...@gmail.com>.
On 7/29/05, Hubert Rabago <hr...@gmail.com> wrote:
> I'll help out where I can. I posted a checklist that's copied from
> 1.2.7. Hopefully that'll help you get started with the team-style
> checklist you're planning. I don't expect a lot of free time today
> but will set aside time tomorrow morning and on sunday.
Thanks Hubert, you did the right thing. You announced a short term
plan on the list, and followed through. I don't think any of us care
who does what, so long as it gets done :)
Like most Apache projects, Struts committer responsibilities are
"joint and several". We are all responsible for everything, and each
of us are responsible for everything.
Anytime we are working on something, we just need to coordinate our
efforts through the mailing list and issue tracker, as you have been
doing.
I'll try to review where we are on the release plan after work tonight.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 -- stalled
Posted by Michael Rasmussen <ra...@gmail.com>.
I'll be out of town this weekend, but if there are any tasks that can
be performed by a non commiter let me know and I might be able to help
out.
Michael
On 7/29/05, Hubert Rabago <hr...@gmail.com> wrote:
> I'll help out where I can. I posted a checklist that's copied from
> 1.2.7. Hopefully that'll help you get started with the team-style
> checklist you're planning. I don't expect a lot of free time today
> but will set aside time tomorrow morning and on sunday.
>
> Hubert
>
> On 7/29/05, Ted Husted <te...@gmail.com> wrote:
> > I suppose I could step up and do it. I'll post a release plan
> > checklist later today.
> >
> > Something that's worked for me in the past is to take a team approach
> > to releases. There's no reason why one person has to do every point on
> > the checklist. I'll modify the list so that different people can sign
> > up for different tasks, if they like, and I'll do the rest.
> >
> > -Ted.
> >
> > On 7/28/05, James Mitchell <jm...@apache.org> wrote:
> > > It looks like I won't have the time that I thought I had to get 1.3.0
> > > cut and rolled out any time soon. My day job is heating up and the
> > > kids soccer season starts up very soon. I'm also running 2 local
> > > user groups (web-atlanta and jboss-atlanta) and participating in a
> > > new architects group (IASA).
> > >
> > > I wish I had more time to do this, but I just don't have the time I
> > > need to do it right. If someone else wants to take the reigns and
> > > run, I'd be very appreciative.....Wendy?
> > >
> > >
> > >
> > > --
> > > James Mitchell
> > > Software Engineer / Open Source Evangelist
> > > Consulting / Mentoring / Freelance
> > > EdgeTech, Inc.
> > > http://www.edgetechservices.net/
> > > 678.910.8017
> > > AIM: jmitchtx
> > > Yahoo: jmitchtx
> > > MSN: jmitchell@apache.org
> > > Skype: jmitchtx
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > --
> > HTH, 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0
Posted by Ted Husted <te...@gmail.com>.
On 7/29/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> These aren't "bugs" so much as problems with the Maven build files... do you
> want Bugzilla tickets opened for them?
Yep.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Nick Heudecker" <nh...@gmail.com>
> Any chance of getting JSTL added to the Struts-Blank WAR for 1.3? Thanks.
It (the Jakarta Taglibs JSTL 1.0 implementation) will be included in the
Struts-EL example webapp, but not in the "basic" struts-blank.war file.
I don't think we could reasonably include JSTL with the blank webapp because
we're supporting both Servlet 2.3 and 2.4, which need different JSTL
versions.
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0
Posted by Nick Heudecker <nh...@gmail.com>.
Any chance of getting JSTL added to the Struts-Blank WAR for 1.3? Thanks.
On 7/29/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Craig McClanahan" <cr...@gmail.com>
> >> Also, can someone make sure that all of the sub-projects are listed as
> >> 'Components' ?
>
> > Added "Struts Flow" (the only missing one).
>
> EL isn't there, either. Should it be, now that it's a separate sub-project?
> I left Bug 35931 (missing example app in EL nightly build) as 'Unknown' for
> the component.
>
> --
> 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: 1.3.0
Posted by Martin Cooper <mf...@gmail.com>.
On 7/29/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Craig McClanahan" <cr...@gmail.com>
> >> Also, can someone make sure that all of the sub-projects are listed as
> >> 'Components' ?
>
> > Added "Struts Flow" (the only missing one).
>
> EL isn't there, either. Should it be, now that it's a separate sub-project?
> I left Bug 35931 (missing example app in EL nightly build) as 'Unknown' for
> the component.
I just added EL as a component and changed Bugzilla #35931 to that component.
--
Martin Cooper
> --
> 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: 1.3.0
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Craig McClanahan" <cr...@gmail.com>
>> Also, can someone make sure that all of the sub-projects are listed as
>> 'Components' ?
> Added "Struts Flow" (the only missing one).
EL isn't there, either. Should it be, now that it's a separate sub-project?
I left Bug 35931 (missing example app in EL nightly build) as 'Unknown' for
the component.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/29/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Wendy Smoak" <ja...@wendysmoak.com>
>
> > - Can 1.3.0 (or 1.3 Family?) be added to the list of 'Targets' for
> Bugzilla?
>
Added "1.3.0" to versions, and "1.3 Family" and "1.3.0 Milestone" to versions.
> Also, can someone make sure that all of the sub-projects are listed as
> 'Components' ?
>
Added "Struts Flow" (the only missing one).
If any Struts committer would like Bugzilla admin rights, send me your
Bugzilla username privately and I'll add you.
> Thanks,
> --
> Wendy Smoak
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Wendy Smoak" <ja...@wendysmoak.com>
> - Can 1.3.0 (or 1.3 Family?) be added to the list of 'Targets' for
Bugzilla?
Also, can someone make sure that all of the sub-projects are listed as
'Components' ?
Thanks,
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0
Posted by Wendy Smoak <ja...@wendysmoak.com>.
> I'll help out where I can. I posted a checklist that's copied from
> 1.2.7. Hopefully that'll help you get started with the team-style
> checklist you're planning. I don't expect a lot of free time today
> but will set aside time tomorrow morning and on sunday.
I'll be away at a conference most of the weekend, but I'm free all day
Monday if anything still needs to be done.
A few things I've come across so far:
- Can 1.3.0 (or 1.3 Family?) be added to the list of 'Targets' for Bugzilla?
After 'maven dist':
- The example webapp is missing from the EL sub-project
- The source code is missing from WEB-INF in (at least) the mailreader
example .war file
These aren't "bugs" so much as problems with the Maven build files... do you
want Bugzilla tickets opened for them?
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 -- stalled
Posted by Hubert Rabago <hr...@gmail.com>.
I'll help out where I can. I posted a checklist that's copied from
1.2.7. Hopefully that'll help you get started with the team-style
checklist you're planning. I don't expect a lot of free time today
but will set aside time tomorrow morning and on sunday.
Hubert
On 7/29/05, Ted Husted <te...@gmail.com> wrote:
> I suppose I could step up and do it. I'll post a release plan
> checklist later today.
>
> Something that's worked for me in the past is to take a team approach
> to releases. There's no reason why one person has to do every point on
> the checklist. I'll modify the list so that different people can sign
> up for different tasks, if they like, and I'll do the rest.
>
> -Ted.
>
> On 7/28/05, James Mitchell <jm...@apache.org> wrote:
> > It looks like I won't have the time that I thought I had to get 1.3.0
> > cut and rolled out any time soon. My day job is heating up and the
> > kids soccer season starts up very soon. I'm also running 2 local
> > user groups (web-atlanta and jboss-atlanta) and participating in a
> > new architects group (IASA).
> >
> > I wish I had more time to do this, but I just don't have the time I
> > need to do it right. If someone else wants to take the reigns and
> > run, I'd be very appreciative.....Wendy?
> >
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > Consulting / Mentoring / Freelance
> > EdgeTech, Inc.
> > http://www.edgetechservices.net/
> > 678.910.8017
> > AIM: jmitchtx
> > Yahoo: jmitchtx
> > MSN: jmitchell@apache.org
> > Skype: jmitchtx
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> HTH, 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: 1.3.0 Release - Next Steps
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:46 AM -0400 9/13/05, Ted Husted wrote:
>Right now, I'm in the middle of a documentation review. I'm through
>Site, and the first part of Core. It's going well. I'm trying to make
>sure that the way we explain everything is consistent with the
>subproject approach. I'll continue to work on it day-by-day (unless
>there's a Falcon's game on!).
>
>I'm also trying to review the new Chain code, before we ship the first
>cut. This would actually be a good time for a full code review, but we
>should probably resolve any outstanding patches first. (I don't expect
>we have outstanding patches for the new Chain stuff.)
>
>One question is where do we stand on stand-alone Tiles? Are we
>comfortable with bringing that up and making it part of Classic 1.3.0,
>or do we want to let things perculate a bit first.
Given this ticket, I think we need to give it some time:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36579
I will try to apply that patch (or actually a slight variation on the
technique) today.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
Re: 1.3.0 Release - Next Steps
Posted by Greg Reddin <li...@reddin.org>.
On Sep 13, 2005, at 8:55 AM, Craig McClanahan wrote:
> I would suggest *not* doing this at this point. When I stop having
> to visit
> three continents in six weeks, I'm going to have time to propose a
> plan for
> a pretty radical change to the internal APIs of Standalone Tiles,
> to make it
> much more friendly to a portlet environment. I would prefer to do this
> before any 1.0.0 of standalone Tiles is ever produced, so that we
> have the
> freedom to make this sort of adjustments.
If you have ideas but no time to implement them I can help. I put up
a wiki page (http://wiki.apache.org/struts/StandaloneTiles) with a
list of current components whose API will be affected by this
change. If there's any way to consolidate your ideas into some text
and add them to the wiki I'm happy to work on the implementation.
I'm *extremely* interested in a portlet-friendly Tiles :-)
I've been thinking about this enhancement for several weeks but just
haven't had the time to put it to code. So I'd love a bit of a
kickstart.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
Providing a migration path (wiki page) fueled by a JDiff report
(http://javadiff.sourceforge.net/) should be pretty easy as well.
(http://maven.apache.org/reference/plugins/jdiff/)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Sep 13, 2005, at 10:12 AM, James Mitchell wrote:
>
> I'm not 100% sure of this myself yet, but it may be a good idea at
> this time to pull out the Tiles dependencies from core and provide
> them via a separate plugin (see struts/current/plugins).
>
> While this does add another jar to our applications, it would allow
> a developer to use either classic Tiles or standalone Tiles for the
> foreseeable future, or until classic is deprecated/removed. Core
> shouldn't have to care one way or the other, and for the few people
> who have extended Tiles, they can continue to use classic even if
> 1.3.x ships with standalone.
>
> Your thoughts?
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: callto://jmitchtx
>
>
>
>
>
> On Sep 13, 2005, at 9:55 AM, Craig McClanahan wrote:
>
>
>> On 9/13/05, Ted Husted <te...@gmail.com> wrote:
>>
>>
>>>
>>> Right now, I'm in the middle of a documentation review. I'm through
>>> Site, and the first part of Core. It's going well. I'm trying to
>>> make
>>> sure that the way we explain everything is consistent with the
>>> subproject approach. I'll continue to work on it day-by-day (unless
>>> there's a Falcon's game on!).
>>>
>>> I'm also trying to review the new Chain code, before we ship the
>>> first
>>> cut. This would actually be a good time for a full code review,
>>> but we
>>> should probably resolve any outstanding patches first. (I don't
>>> expect
>>> we have outstanding patches for the new Chain stuff.)
>>>
>>> One question is where do we stand on stand-alone Tiles? Are we
>>> comfortable with bringing that up and making it part of Classic
>>> 1.3.0,
>>> or do we want to let things perculate a bit first.
>>>
>>>
>>
>>
>> I would suggest *not* doing this at this point. When I stop having
>> to visit
>> three continents in six weeks, I'm going to have time to propose a
>> plan for
>> a pretty radical change to the internal APIs of Standalone Tiles,
>> to make it
>> much more friendly to a portlet environment. I would prefer to do
>> this
>> before any 1.0.0 of standalone Tiles is ever produced, so that we
>> have the
>> freedom to make this sort of adjustments.
>>
>> Note that this won't affect the vast majority of *users* of Tiles
>> unless you
>> are defining your own Controller implementations -- and, for that,
>> it makes
>> sense to provide backwards compatible (but servlet specific)
>> implementations
>> to ease the transition.
>>
>> -Ted.
>>
>>
>> Craig
>>
>> ---------------------------------------------------------------------
>>
>>
>>> 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: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
That seems like a reasonable bridge, James.
A driving force behind plugins, and the new request processor, is
being able to extend the core framework for extensions as radical as
Tiles. It seems appropriate that we keep Tiles at arms-length, to show
that something like this can be plugged in without being hardwired
into the Core.
-Ted.
On 9/13/05, James Mitchell <ja...@mac.com> wrote:
>
> I'm not 100% sure of this myself yet, but it may be a good idea at
> this time to pull out the Tiles dependencies from core and provide
> them via a separate plugin (see struts/current/plugins).
>
> While this does add another jar to our applications, it would allow a
> developer to use either classic Tiles or standalone Tiles for the
> foreseeable future, or until classic is deprecated/removed. Core
> shouldn't have to care one way or the other, and for the few people
> who have extended Tiles, they can continue to use classic even if
> 1.3.x ships with standalone.
>
> Your thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
I'm not 100% sure of this myself yet, but it may be a good idea at
this time to pull out the Tiles dependencies from core and provide
them via a separate plugin (see struts/current/plugins).
While this does add another jar to our applications, it would allow a
developer to use either classic Tiles or standalone Tiles for the
foreseeable future, or until classic is deprecated/removed. Core
shouldn't have to care one way or the other, and for the few people
who have extended Tiles, they can continue to use classic even if
1.3.x ships with standalone.
Your thoughts?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Sep 13, 2005, at 9:55 AM, Craig McClanahan wrote:
> On 9/13/05, Ted Husted <te...@gmail.com> wrote:
>
>>
>> Right now, I'm in the middle of a documentation review. I'm through
>> Site, and the first part of Core. It's going well. I'm trying to make
>> sure that the way we explain everything is consistent with the
>> subproject approach. I'll continue to work on it day-by-day (unless
>> there's a Falcon's game on!).
>>
>> I'm also trying to review the new Chain code, before we ship the
>> first
>> cut. This would actually be a good time for a full code review,
>> but we
>> should probably resolve any outstanding patches first. (I don't
>> expect
>> we have outstanding patches for the new Chain stuff.)
>>
>> One question is where do we stand on stand-alone Tiles? Are we
>> comfortable with bringing that up and making it part of Classic
>> 1.3.0,
>> or do we want to let things perculate a bit first.
>>
>
>
> I would suggest *not* doing this at this point. When I stop having
> to visit
> three continents in six weeks, I'm going to have time to propose a
> plan for
> a pretty radical change to the internal APIs of Standalone Tiles,
> to make it
> much more friendly to a portlet environment. I would prefer to do this
> before any 1.0.0 of standalone Tiles is ever produced, so that we
> have the
> freedom to make this sort of adjustments.
>
> Note that this won't affect the vast majority of *users* of Tiles
> unless you
> are defining your own Controller implementations -- and, for that,
> it makes
> sense to provide backwards compatible (but servlet specific)
> implementations
> to ease the transition.
>
> -Ted.
>
>
> Craig
>
> ---------------------------------------------------------------------
>
>> 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: 1.3.0 Release - Next Steps
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/13/05, Ted Husted <te...@gmail.com> wrote:
>
> Right now, I'm in the middle of a documentation review. I'm through
> Site, and the first part of Core. It's going well. I'm trying to make
> sure that the way we explain everything is consistent with the
> subproject approach. I'll continue to work on it day-by-day (unless
> there's a Falcon's game on!).
>
> I'm also trying to review the new Chain code, before we ship the first
> cut. This would actually be a good time for a full code review, but we
> should probably resolve any outstanding patches first. (I don't expect
> we have outstanding patches for the new Chain stuff.)
>
> One question is where do we stand on stand-alone Tiles? Are we
> comfortable with bringing that up and making it part of Classic 1.3.0,
> or do we want to let things perculate a bit first.
I would suggest *not* doing this at this point. When I stop having to visit
three continents in six weeks, I'm going to have time to propose a plan for
a pretty radical change to the internal APIs of Standalone Tiles, to make it
much more friendly to a portlet environment. I would prefer to do this
before any 1.0.0 of standalone Tiles is ever produced, so that we have the
freedom to make this sort of adjustments.
Note that this won't affect the vast majority of *users* of Tiles unless you
are defining your own Controller implementations -- and, for that, it makes
sense to provide backwards compatible (but servlet specific) implementations
to ease the transition.
-Ted.
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "James Mitchell" <ja...@mac.com>
> When you run Maven, if some goal needs to build documentation or 'site'
> and there is no 'xdocs' dir, Maven adds one.
>
> <sarcastic>
> Gee, thanks.
> </sarcastic>
I noticed that... it happened in Shale and I added a postGoal to clean to
delete the empty xdocs directories it keeps creating under shale/build/*.
> The optimal solution is to tell Maven to stop creating xdocs if it
> doesn't find one.
> The next best thing is just make sure they all have them, and do our best
> to warn me (and the list) that the next 'svn up' will fail because of
> this issue.
IMO, all sub-projects need documentation, at the very least navigation.xml.
So I'd say delete the Maven created xdocs, let svn up add the directory
back, and keep in mind that if you make a new sub-project, you need to add
and check in an xdocs directory, even if it's empty.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
I'm taking a rather drastic step here. Rather than futs around with
Maven to make it behave, I've changed the nightly build process to
checkout a whole new copy of what's in svn so we can avoid this (and
future) issues related to lingering files.
Currently the build happens at 2:00 AM EST, so I'll check the
progress in the morning and fix any issues that come up.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Sep 13, 2005, at 11:45 AM, James Mitchell wrote:
> I found out what's happening.
>
> When you run Maven, if some goal needs to build documentation or
> 'site' and there is no 'xdocs' dir, Maven adds one.
>
> <sarcastic>
> Gee, thanks.
> </sarcastic>
>
> So, since Wendy has volunteered her time (btw...thanks!) to fix our
> documentation, some of the subprojects now have 'xdoc' directories
> where previously there were none.
>
> This, unfortunately, causes the following during the nightly build
> (svn up):
>
> ...
> ...
> Fetching external item into 'foo'
> svn: Failed to add directory 'foo/xdocs': object of the same name
> already exists
> ...
> ...
>
> 'foo' of course being any of the subprojects that were affected.
>
>
>
> So, what are our options going forward?
> The optimal solution is to tell Maven to stop creating xdocs if it
> doesn't find one.
> The next best thing is just make sure they all have them, and do
> our best to warn me (and the list) that the next 'svn up' will fail
> because of this issue.
>
> Your thoughts?
>
>
>
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: callto://jmitchtx
>
>
>
>
>
> On Sep 13, 2005, at 10:32 AM, James Mitchell wrote:
>
>
>> There is some Tiles documentation intermixed in the normal xdocs,
>> which should be moved to the appropriate location.
>>
>> I'm looking into why tiles if failing right now. I'll post back
>> in a few.
>>
>> --
>> James Mitchell
>> Software Engineer / Open Source Evangelist
>> Consulting / Mentoring / Freelance
>> EdgeTech, Inc.
>> http://www.edgetechservices.net/
>> 678.910.8017
>> AIM: jmitchtx
>> Yahoo: jmitchtx
>> MSN: jmitchell@apache.org
>> Skype: callto://jmitchtx
>>
>>
>>
>>
>>
>> On Sep 13, 2005, at 10:10 AM, Wendy Smoak wrote:
>>
>>
>>
>>> Ted wrote:
>>>
>>>
>>>
>>>> One question is where do we stand on stand-alone Tiles? Are we
>>>> comfortable with bringing that up and making it part of Classic
>>>> 1.3.0,
>>>> or do we want to let things perculate a bit first.
>>>>
>>>>
>>>>
>>>
>>> Standalone Tiles needs...
>>>
>>> - tiles-core.tld updated to JSP 1.2 with embedded HTML docs
>>> - some sort of documentation for the website, there's nothing in
>>> xdocs
>>> - Maven to build tiles-documentation.war
>>> - Consistent URI/URLs -- it uses (at least) jakarta.apache.org/
>>> tiles,
>>> apache.org/tlds and struts.apache.org/tlds.
>>>
>>> (I went to check to see if the .war file was in the 1.3.0-dev
>>> nightlies for
>>> struts-tiles, and they've been missing for a while:
>>> http://svn.apache.org/builds/struts/maven/trunk/nightly/struts-
>>> tiles/ .
>>> James?)
>>> --
>>> 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
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
I found out what's happening.
When you run Maven, if some goal needs to build documentation or
'site' and there is no 'xdocs' dir, Maven adds one.
<sarcastic>
Gee, thanks.
</sarcastic>
So, since Wendy has volunteered her time (btw...thanks!) to fix our
documentation, some of the subprojects now have 'xdoc' directories
where previously there were none.
This, unfortunately, causes the following during the nightly build
(svn up):
...
...
Fetching external item into 'foo'
svn: Failed to add directory 'foo/xdocs': object of the same name
already exists
...
...
'foo' of course being any of the subprojects that were affected.
So, what are our options going forward?
The optimal solution is to tell Maven to stop creating xdocs if it
doesn't find one.
The next best thing is just make sure they all have them, and do our
best to warn me (and the list) that the next 'svn up' will fail
because of this issue.
Your thoughts?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Sep 13, 2005, at 10:32 AM, James Mitchell wrote:
> There is some Tiles documentation intermixed in the normal xdocs,
> which should be moved to the appropriate location.
>
> I'm looking into why tiles if failing right now. I'll post back in
> a few.
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: callto://jmitchtx
>
>
>
>
>
> On Sep 13, 2005, at 10:10 AM, Wendy Smoak wrote:
>
>
>> Ted wrote:
>>
>>
>>> One question is where do we stand on stand-alone Tiles? Are we
>>> comfortable with bringing that up and making it part of Classic
>>> 1.3.0,
>>> or do we want to let things perculate a bit first.
>>>
>>>
>>
>> Standalone Tiles needs...
>>
>> - tiles-core.tld updated to JSP 1.2 with embedded HTML docs
>> - some sort of documentation for the website, there's nothing in
>> xdocs
>> - Maven to build tiles-documentation.war
>> - Consistent URI/URLs -- it uses (at least) jakarta.apache.org/tiles,
>> apache.org/tlds and struts.apache.org/tlds.
>>
>> (I went to check to see if the .war file was in the 1.3.0-dev
>> nightlies for
>> struts-tiles, and they've been missing for a while:
>> http://svn.apache.org/builds/struts/maven/trunk/nightly/struts-
>> tiles/ .
>> James?)
>> --
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
There is some Tiles documentation intermixed in the normal xdocs,
which should be moved to the appropriate location.
I'm looking into why tiles if failing right now. I'll post back in a
few.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Sep 13, 2005, at 10:10 AM, Wendy Smoak wrote:
> Ted wrote:
>
>> One question is where do we stand on stand-alone Tiles? Are we
>> comfortable with bringing that up and making it part of Classic
>> 1.3.0,
>> or do we want to let things perculate a bit first.
>>
>
> Standalone Tiles needs...
>
> - tiles-core.tld updated to JSP 1.2 with embedded HTML docs
> - some sort of documentation for the website, there's nothing in xdocs
> - Maven to build tiles-documentation.war
> - Consistent URI/URLs -- it uses (at least) jakarta.apache.org/tiles,
> apache.org/tlds and struts.apache.org/tlds.
>
> (I went to check to see if the .war file was in the 1.3.0-dev
> nightlies for
> struts-tiles, and they've been missing for a while:
> http://svn.apache.org/builds/struts/maven/trunk/nightly/struts-
> tiles/ .
> James?)
> --
> 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: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
Ted wrote:
> One question is where do we stand on stand-alone Tiles? Are we
> comfortable with bringing that up and making it part of Classic 1.3.0,
> or do we want to let things perculate a bit first.
Standalone Tiles needs...
- tiles-core.tld updated to JSP 1.2 with embedded HTML docs
- some sort of documentation for the website, there's nothing in xdocs
- Maven to build tiles-documentation.war
- Consistent URI/URLs -- it uses (at least) jakarta.apache.org/tiles,
apache.org/tlds and struts.apache.org/tlds.
(I went to check to see if the .war file was in the 1.3.0-dev nightlies for
struts-tiles, and they've been missing for a while:
http://svn.apache.org/builds/struts/maven/trunk/nightly/struts-tiles/ .
James?)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
Right now, I'm in the middle of a documentation review. I'm through
Site, and the first part of Core. It's going well. I'm trying to make
sure that the way we explain everything is consistent with the
subproject approach. I'll continue to work on it day-by-day (unless
there's a Falcon's game on!).
I'm also trying to review the new Chain code, before we ship the first
cut. This would actually be a good time for a full code review, but we
should probably resolve any outstanding patches first. (I don't expect
we have outstanding patches for the new Chain stuff.)
One question is where do we stand on stand-alone Tiles? Are we
comfortable with bringing that up and making it part of Classic 1.3.0,
or do we want to let things perculate a bit first.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> It is suppose to be a leaning tool, and so the source should be easy to
> access.
>
> We'd have the same problem with "blank". We are suppose to be able to
> take the source and use it for the base of a new project. [And if it
> ends up being a blank Maven project, that's OK by me :)]
Are you talking about where the source is in the repository, (and what the
"source distribution" looks like) or where the source is in the .war files?
What do you want it to look like?
Struts-blank may eventually go away in favor of something like:
$ mvn archetype:create
-DgroupId=my.package
-DartifactId=my-app
-DarchetypeArtifactId=maven-archetype-struts
-DarchetypeGroupId=org.apache.struts
Sort of like 'maven genapp' from Maven 1 except it looks like we'll be able
to publish our own archetypes in the repository with our other artifacts
rather than try to get them included in someone else's plugin.
Another thing I learned recently about Maven: we can publish source and
javadoc to the repository as additional artifacts. Then IDEs and tools can
automatically retrieve it. That's still an issue with Maven builds. You
can set up dependencies, but if you want to debug you have to go find the
source code.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
It is suppose to be a leaning tool, and so the source should be easy to access.
We'd have the same problem with "blank". We are suppose to be able to
take the source and use it for the base of a new project. [And if it
ends up being a blank Maven project, that's OK by me :)]
-Ted.
On 10/27/05, James Mitchell <ja...@mac.com> wrote:
> The mailreader.war artifact contains the source (thanks Wendy!), but
> it isn't a 'source distribution' in the same sense that you expect.
> Is that ok, or do we have to have a build-able source distro?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
The mailreader.war artifact contains the source (thanks Wendy!), but
it isn't a 'source distribution' in the same sense that you expect.
Is that ok, or do we have to have a build-able source distro?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Oct 27, 2005, at 7:33 AM, Ted Husted wrote:
> I'm not having any luck getting started with the Apps subproject, so I
> think I should go back to reviewing the rest of the documentation for
> now.
>
> I think the only major thing keeping us from rolling 1.3.0 is that the
> source for the MailReader seems disjointed. It looks like part is
> under "shared" and part is under "webapp", and we need them both under
> MailReader. We might also want "dao" to be "mailreader-dao". If anyone
> had a itch to sort out the Apps subproject, I think that would remove
> the last stumbling block. The rest just looks like mopping up.
>
> -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: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
I'll take a look at it.
The initial plan for 'shared' was to prevent a bunch of duplicate
'one-off' mailreaders from getting out of sync, but no-one has
attempted doing a single 'one-off', so I assume it is safe to put it
back the way we originally had it (structure).
Thanks.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: callto://jmitchtx
On Oct 27, 2005, at 7:33 AM, Ted Husted wrote:
> I'm not having any luck getting started with the Apps subproject, so I
> think I should go back to reviewing the rest of the documentation for
> now.
>
> I think the only major thing keeping us from rolling 1.3.0 is that the
> source for the MailReader seems disjointed. It looks like part is
> under "shared" and part is under "webapp", and we need them both under
> MailReader. We might also want "dao" to be "mailreader-dao". If anyone
> had a itch to sort out the Apps subproject, I think that would remove
> the last stumbling block. The rest just looks like mopping up.
>
> -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: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 10/27/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> We have a dependency on a snapshot of Validator. Is that okay for 1.3.0?
> (I thought there was at least a release candidate, if not a vote, on
> commons-dev.)
If a release is dependant on a beta, then the release itself must
remain a beta.
One very good reason for using the "release-and-grade" approach is
that if the validation release was later upgraded to "General
Availability" later, then we could also upgrade our release to GA (if
everything else is kosher).
But, I don't think anyone imagines that 1.3.0 would ever be marked
"GA" anyway, so, yes, a snapshot or RC would be OK :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Don Brown <mr...@twdata.org>.
Sure, go ahead. Thanks,
Don
Niall Pemberton wrote:
> On 10/27/05, Don Brown <mr...@twdata.org> wrote:
>
>>Agreed. The only sticking point is the Validator release doesn't build for me
>>with Java 1.3, and I haven't had time to look into why, but other than that, it
>>is good to go for an RC release.
>
>
> It builds OK for me in JDK 1.3 - do you want me to post a release candidate?
>
> ---------------------------------------------------------------------
> 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: 1.3.0 Release - Next Steps
Posted by Niall Pemberton <ni...@gmail.com>.
On 10/27/05, Don Brown <mr...@twdata.org> wrote:
> Agreed. The only sticking point is the Validator release doesn't build for me
> with Java 1.3, and I haven't had time to look into why, but other than that, it
> is good to go for an RC release.
It builds OK for me in JDK 1.3 - do you want me to post a release candidate?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Don Brown <mr...@twdata.org>.
Agreed. The only sticking point is the Validator release doesn't build for me
with Java 1.3, and I haven't had time to look into why, but other than that, it
is good to go for an RC release.
Don
Niall Pemberton wrote:
> On 10/27/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>
>>We have a dependency on a snapshot of Validator. Is that okay for 1.3.0?
>>(I thought there was at least a release candidate, if not a vote, on
>>commons-dev.)
>
>
> IMO we need a validator release. I believe its ready - I think Don
> does too, Its just a case of posting a release candidate and then
> voting after a reasonable period.
>
> Niall
>
> ---------------------------------------------------------------------
> 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: 1.3.0 Release - Next Steps
Posted by Niall Pemberton <ni...@gmail.com>.
On 10/27/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> We have a dependency on a snapshot of Validator. Is that okay for 1.3.0?
> (I thought there was at least a release candidate, if not a vote, on
> commons-dev.)
IMO we need a validator release. I believe its ready - I think Don
does too, Its just a case of posting a release candidate and then
voting after a reasonable period.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> The rest just looks like mopping up.
Hubert mentioned possibly making a change to the DTD:
http://www.mail-archive.com/dev@struts.apache.org/msg12505.html
We have a dependency on a snapshot of Validator. Is that okay for 1.3.0?
(I thought there was at least a release candidate, if not a vote, on
commons-dev.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
I'm not having any luck getting started with the Apps subproject, so I
think I should go back to reviewing the rest of the documentation for
now.
I think the only major thing keeping us from rolling 1.3.0 is that the
source for the MailReader seems disjointed. It looks like part is
under "shared" and part is under "webapp", and we need them both under
MailReader. We might also want "dao" to be "mailreader-dao". If anyone
had a itch to sort out the Apps subproject, I think that would remove
the last stumbling block. The rest just looks like mopping up.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Dakota Jack <da...@gmail.com>.
Ooops! Forgot the "stuff". Here you go.
An endless source of aggravation is the HTML input image element. The
specification says that browsers should treat this control like an
image map. Unlike other buttons, it does not submit a string
representing the button's label, it submits the X and Y coordinates.
If you look at the HTTP post for an image button, you'll see it looks
something like this
myImageButton.x=200
myImageButton.y=300
For most other controls, a Struts developer can create a simple String
property to represent the element. This clearly won't work with an
image button, because it submits two "dotted" properties instead of a
simple "name=value" entry like other elements.
Happily, Struts allows an ActionForm to contain, or nest, other
JavaBeans, and will automatically populate the beans using the same
syntax as the image element. (What a co-inky-dink!)
To represent an image input element in your ActionForm, say what you
mean, and use an ImageButtonBean to capture the X and Y parameters.
public final class ImageButtonBean extends Object {
private String x = null;
private String y = null;
public String getX() {
return (this.x);
}
public void setX(String x) {
this.x = x;
}
public String getY() {
return (this.y);
}
public void setY(String y) {
this.y = y;
}
public boolean isSelected() {
return ((x!=null) || (y!=null));
}
} // End ImageButtonBean
Note that we've included a helper method on this bean, isSelected().
This just returns true if either the x or y property is not null. If
both are still null, then isSelected() returns false.
Here's how you could declare two ImageButtonBeans on an ActionForm.
// ..
private ImageButtonBean logonButton = new ImageButtonBean();
public void setLogonButton(ImageButtonBean button) {
this.logonButton = button;
}
public ImageButtonBean getLogonButton() {
return this.logonButton;
}
private ImageButtonBean cancelButton = new ImageButtonBean();
public void setCancelButton(ImageButtonBean button) {
this.cancelButton = button;
}
public ImageButtonBean getCancelButton() {
return this.cancelButton;
}
// ...
The next question will be "OK, which button did they push?", so let's
define another helper method on the ActionForm to tell us.
public String getSelected() {
if (getLogonButton().isSelected()) {
return Constants.LOGON;
}
if (getCancelButton().isSelected()) {
return Constants.CANCEL;
}
return null; // nobody home
}
In an Action, determining which button is pressed is then a simple
matter of asking the form what was selected.
String selected = ((myForm) form).getSelected();
if (Constants.CANCEL.equals(selected)) ...
Of course selected doesn't need to be a String; it could be an int, a
custom type to represent your API functions, or even the name of
another method for use with a DispatchAction.
Using "API helper methods" on ActionForms, as we did with
getSelected(), is a very useful technique. We'll use it again in Tip
#2, when we discuss the standard Dispatch Actions.
HTH, Ted.
On 8/17/05, Dakota Jack <da...@gmail.com> wrote:
> Here is Ted's 2002 offering: you will see that this has nothing to do
> with "stripping .x". I think, further, that what Ted is talking about
> originated with Hubert Rabago, although I am not suggesting that Ted
> is suggesting otherwise. Anyway, this is all irrelevnat.
>
> On 7/31/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> > > But, first things first, we should resolve the problem reports and roll 1.3.0.
> >
> > Does this mean, that even if I present MailReader rewritten with
> > Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
> > future version?
> >
> > Or will the answer be more definite after I show how to make
> > MailReader with dialogs?
> >
> > Do you have any timeframe in mind for 1.3?
> >
> > Michael.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Dakota Jack <da...@gmail.com>.
Here is Ted's 2002 offering: you will see that this has nothing to do
with "stripping .x". I think, further, that what Ted is talking about
originated with Hubert Rabago, although I am not suggesting that Ted
is suggesting otherwise. Anyway, this is all irrelevnat.
On 7/31/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> > But, first things first, we should resolve the problem reports and roll 1.3.0.
>
> Does this mean, that even if I present MailReader rewritten with
> Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
> future version?
>
> Or will the answer be more definite after I show how to make
> MailReader with dialogs?
>
> Do you have any timeframe in mind for 1.3?
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
For the 1.3.x release series, we decided to divy Strus 1.2.x into
several subprojects. Right now, I'm focussing on the Core, but we will
also have to release other subprojects like Apps, El, Taglib, and
Tiles to make it a complete distribution.
I expect Struts 1.3.0 to be released very quickly, but I don't expect
it to reach General Availability status. On average, it takes 4 to 6
releases before an Apache project goes from "alpha" to "beta" to
"General Availability". Each of these releases will have its own
serial number, 1.3.1, 1.3.2, 1.3.3, and so forth. If we start making
releases in the Struts 1.3.x series in early August, it possible that
we might see one of these release make GA grade by December. But
since no one is working on Struts full-time, it's not possible to
hazard more than a wild guess.
I have no idea whether the team wants to host several different
MailReaders in the Struts Apps package. Craig mentioned doing one for
Shale, and if one were written, I expect we would bundle it with the
Struts Shale subproject distribution. LIkewise, I would expect that
the Struts Dialog MailReader would be distributed with the Struts
Dialog extension.
-Ted.
On 7/31/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> > But, first things first, we should resolve the problem reports and roll 1.3.0.
>
> Does this mean, that even if I present MailReader rewritten with
> Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
> future version?
>
> Or will the answer be more definite after I show how to make
> MailReader with dialogs?
>
> Do you have any timeframe in mind for 1.3?
>
> Michael.
>
--
HTH, Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> But, first things first, we should resolve the problem reports and roll 1.3.0.
Does this mean, that even if I present MailReader rewritten with
Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
future version?
Or will the answer be more definite after I show how to make
MailReader with dialogs?
Do you have any timeframe in mind for 1.3?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 9/2/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> Can you tell what subproject is doing it? (And did it just start
> happening?)
Tiles. It wasn't happening earlier this week.
> You can run with -Dmaven.test.skip (or
> possibly -Dmaven.test.failure.ignore) to temporarily get around that.
Yep, that did the trick.
> (Based on experimentation in shale/use-cases/project.xml,) Maven uses the
> <artifactId> from project.xml as the directory name. Since flow has none, I
> think it's using the <id>. Maybe James can comment on what else is affected
> by <id> and <artifactId>.
We'd want to do the simplest, most consistent thing. If published as
an artifact, Struts Flow would resolve to struts-flow, and so that's
where the website should be. Every subproject should have an artifact
id.
> How are you bulding the Shale site? It is another multiproject site on its
> own. I haven't been able to get Maven to cooperate and do the whole thing
> automatically, so "building the Struts site" currently consists of (adapted
> from build/maven-nightly.sh.current):
Once we get past this initial hump, I don't think doing them all at
once will be particularly important. Worst case, we can use a batch
file or shell script to run each subproject in progression. Then, if a
subproject needs to be a multiproject of its own, it can.
In regular practice, it will be more important to be able to do each
subproject on its own. People will tend to work on one subproject or
another, and then post only those changes, rather than do all at once.
> Have we decided what to do about the Struts 1.2 docs? There was talk of
> putting them under http://struts.apache.org/docs/1.2 (like HTTPD) or
> http://struts.apache.org/struts-1.2-doc/ (like Tomcat).
For consistency, we might want to treat the docs like they were an
artifact, which would imply a third form, "struts-doc-1.2" :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
Ted Husted wrote:
> $ maven multiproject:site
> from site/build is not. It fails with
Typo? It should be /current/site (not /current/site/build).
> BUILD FAILED
> Unable to obtain goal [site] -- C:\Documents and
> Settings\ted_2\.maven\cache\mav
> en-test-plugin-1.6.2\plugin.jelly:181:54: <fail> There were test failures.
Can you tell what subproject is doing it? (And did it just start
happening?) You can run with -Dmaven.test.skip (or
possibly -Dmaven.test.failure.ignore) to temporarily get around that.
> Meanwhile, the Shale site looks great! I'll use that as a template for
> the other subprojects, so that everything will work the same way.
One thing to think about is the directory structures... right now the Struts
Flow website is http://struts.apache.org/flow, but if you move the content
under the /current/flow/xdocs and do nothing else, the URL will change to
http://struts.apache.org/struts-flow .
(Based on experimentation in shale/use-cases/project.xml,) Maven uses the
<artifactId> from project.xml as the directory name. Since flow has none, I
think it's using the <id>. Maybe James can comment on what else is affected
by <id> and <artifactId>.
> Though, one change might be that the "Struts" link should go to
> "http://struts.apache.org/" since we don't know what they might have
> built locally.
Fixed.
> Obviously, the Shale site build works for me, so next I'll try doing
> the same thing for Core.
How are you bulding the Shale site? It is another multiproject site on its
own. I haven't been able to get Maven to cooperate and do the whole thing
automatically, so "building the Struts site" currently consists of (adapted
from build/maven-nightly.sh.current):
echo "------ build multiproject site (head) ------"
cd /svn/struts/current/site/
maven multiproject:site
echo "------ build multiproject site (head - Shale) ------"
cd /svn/struts/current/shale/
maven multiproject:site -Dmaven.test.skip=true
cp -r target/docs/* ../site/target/docs/shale
echo "------ build multiproject site (head - Sandbox) ------"
cd /svn/struts/current/sandbox/
maven multiproject:site
cp -r target/docs/* ../site/target/docs/sandbox
echo "------ build multiproject site (head - Sandbox - Ti) ------"
cd /svn/struts/current/sandbox/ti
maven multiproject:site
cp -r target/docs/* ../../site/target/docs/sandbox/struts-ti
... then publish from site/target/docs/
> My hope would be to have the patches to the website finished this
> weekend, so that we can at least post that part of the puzzle.
> * http://wiki.apache.org/struts/StrutsWebsiteConversion
Sounds good. I'll be here all weekend doing homework. The website will be
a welcome diversion, so let me know if you need anything. :)
Have we decided what to do about the Struts 1.2 docs? There was talk of
putting them under http://struts.apache.org/docs/1.2 (like HTTPD) or
http://struts.apache.org/struts-1.2-doc/ (like Tomcat).
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
$ maven build-all
from buid/ is working for me, but
$ maven multiproject:site
from site/build is not. It fails with
----
test:test:
[junit] Running org.apache.struts.tiles.TestI18nFactorySet
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.235 sec
[junit] [ERROR] TEST org.apache.struts.tiles.TestI18nFactorySet FAILED
[junit] Running org.apache.struts.tiles.TestTilesPlugin
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.187 sec
BUILD FAILED
File...... C:\Documents and Settings\ted_2\.maven\cache\maven-multiproject-plugi
n-1.3.1\plugin.jelly
Element... maven:reactor
Line...... 103
Column.... 9
Unable to obtain goal [site] -- C:\Documents and Settings\ted_2\.maven\cache\mav
en-test-plugin-1.6.2\plugin.jelly:181:54: <fail> There were test failures.
Total time: 3 minutes 34 seconds
Finished at: Fri Sep 02 06:35:22 EDT 2005
----
I tried again after running clean-all and build-all again, but no joy.
Meanwhile, the Shale site looks great! I'll use that as a template for
the other subprojects, so that everything will work the same way.
Though, one change might be that the "Struts" link should go to
"http://struts.apache.org/" since we don't know what they might have
built locally.
Obviously, the Shale site build works for me, so next I'll try doing
the same thing for Core.
My hope would be to have the patches to the website finished this
weekend, so that we can at least post that part of the puzzle.
* http://wiki.apache.org/struts/StrutsWebsiteConversion
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Classic 1.3.0 Critter Corral (was Re: 1.3.0 Release - Next Steps)
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/8/05, Ted Husted <te...@gmail.com> wrote:
>
> * Remove deprecations prior to 1.3.0 release
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=35953
>
> Hubert, will you still be able to handle this? (Pretty please ..)
>
I have most of these done. AFAIK, the only item I haven't removed yet
is the contextRelative field of ForwardConfig. I should be able to
get that by the end of the week.
H
>
> -Ted.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Classic 1.3.0 Critter Corral (was Re: 1.3.0 Release - Next Steps)
Posted by Ted Husted <te...@gmail.com>.
If no one has any suggestions as to why any tag attributes should be
marked RE false, I'll make this change (and the others) before running
through the shake-down tests on Monday. (If we have the website and
deprecations squared away by then.)
My many thanks to everyone who is making the 1.3.x release series
possible. I love it when a plan comes together ... especially plans
we made eighteen months ago :)
(Yes, it's been that long. We've been planning to divy Struts up into
subprojects and fully support Maven since we went top-level, in March
2004. Our earliest Maven test builds go back another year, to March
2003. Ahh, well, slow and steady ... )
-Ted.
On 8/9/05, Martin Cooper <mf...@gmail.com> wrote:
> > Is there a reason why these tag attributes are marked RE false?
>
> I strongly suspect there was, but not knowing what it was, I can't say
> whether or not it's still valid. My first guess would be because of
> rules about exposing new variables from tags, but perhaps Craig or
> David K could chime in on this one.
>
> --
> Martin Cooper
>
>
> > bean
> > * cookie.id
> > * define.id
> > * header.id
> > * anchor.id
> > * page.id
> > * parameter.id
> > * resource.id
> > * size.id
> > * struts.id
> >
> > html
> > * javascript.dynamicJavascript
> > * javascript.staticJavascript
> > * messages.id
> >
> > logic
> > * collection.id
> > * iterate.indexId
> >
> > ----
> >
> > * Remove deprecations prior to 1.3.0 release
> > * http://issues.apache.org/bugzilla/show_bug.cgi?id=35953
> >
> > Hubert, will you still be able to handle this? (Pretty please ..)
> >
> > ---
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
--
HTH, Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Classic 1.3.0 Critter Corral (was Re: 1.3.0 Release - Next Steps)
Posted by Martin Cooper <mf...@gmail.com>.
On 8/8/05, Ted Husted <te...@gmail.com> wrote:
> Note that the Clssic 1.3.0 release plan wiki page has been renamed:
>
> * http://wiki.apache.org/struts/StrutsClassicRelease130
>
> Some issues have been pushed forward to a 1.3.1 plan.
>
> * http://wiki.apache.org/struts/StrutsClassicRelease131
>
> Here's a roundup of the remaining issues with issues on the 1.3.0 short list.
>
> ----
>
> * [upload] org.apache.struts.upload.MultipartRequestWrapper doesn't
> implement servlet 2.4 api fully
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=33132
>
> > The reason for attaching the 1.3 changes for review,
> > rather than committing them directly is that I
> > understand Martin has some changes underway for file
> > uploading and these changes either may not be required or may be inappropriate.
>
> Any objections to this patch?
I haven't looked at the patch itself, but I guess I'm OK with going
ahead on this. The upload changes I want to make are dependent on
FileUpload 1.1, which in turn is dependent on IO 1.1, which isn't in
danger of happening any time soon, unfortunately, based on the number
of nudges so far. So I'd say upload refactoring isn't going to happen
until Struts 1.4.x. ;-(
> ----
>
> * use charsets given by browser for form field encodings
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=34445
>
> Unless File Upload 1.1 is imminent, we could leave this for Classic 1.3.1
Let's leave it and see what happens in Commons-land in the meantime.
> ----
>
> * [taglib] All Javascript validation fails when <html:xhtml...
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=35127
>
> Unless Commons Validator 1.15 is imminent, we could live this for Classic 1.3.1
I'm pretty sure that Validator 1.1.5 is coming any time soon, so I'd
say push this to later.
> ----
>
> * multiform validation
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=35513
>
> Confirm report during testing. May be support issue.
The description could be more clear, but this looks like a
misunderstanding of the way Struts works. (i.e. yes, a validation
error causes a return to the 'input' page.) Looks like an INVALID to
me, but I could be misreading it.
> ----
>
> * Attributes with <rtexprvalue>false</rtexprvalue>
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=35895
>
> Is there a reason why these tag attributes are marked RE false?
I strongly suspect there was, but not knowing what it was, I can't say
whether or not it's still valid. My first guess would be because of
rules about exposing new variables from tags, but perhaps Craig or
David K could chime in on this one.
--
Martin Cooper
> bean
> * cookie.id
> * define.id
> * header.id
> * anchor.id
> * page.id
> * parameter.id
> * resource.id
> * size.id
> * struts.id
>
> html
> * javascript.dynamicJavascript
> * javascript.staticJavascript
> * messages.id
>
> logic
> * collection.id
> * iterate.indexId
>
> ----
>
> * Remove deprecations prior to 1.3.0 release
> * http://issues.apache.org/bugzilla/show_bug.cgi?id=35953
>
> Hubert, will you still be able to handle this? (Pretty please ..)
>
> ---
>
> -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
Struts Classic 1.3.0 Critter Corral (was Re: 1.3.0 Release - Next Steps)
Posted by Ted Husted <te...@gmail.com>.
Note that the Clssic 1.3.0 release plan wiki page has been renamed:
* http://wiki.apache.org/struts/StrutsClassicRelease130
Some issues have been pushed forward to a 1.3.1 plan.
* http://wiki.apache.org/struts/StrutsClassicRelease131
Here's a roundup of the remaining issues with issues on the 1.3.0 short list.
----
* [upload] org.apache.struts.upload.MultipartRequestWrapper doesn't
implement servlet 2.4 api fully
* http://issues.apache.org/bugzilla/show_bug.cgi?id=33132
> The reason for attaching the 1.3 changes for review,
> rather than committing them directly is that I
> understand Martin has some changes underway for file
> uploading and these changes either may not be required or may be inappropriate.
Any objections to this patch?
----
* use charsets given by browser for form field encodings
* http://issues.apache.org/bugzilla/show_bug.cgi?id=34445
Unless File Upload 1.1 is imminent, we could leave this for Classic 1.3.1
----
* [taglib] All Javascript validation fails when <html:xhtml...
* http://issues.apache.org/bugzilla/show_bug.cgi?id=35127
Unless Commons Validator 1.15 is imminent, we could live this for Classic 1.3.1
----
* multiform validation
* http://issues.apache.org/bugzilla/show_bug.cgi?id=35513
Confirm report during testing. May be support issue.
----
* Attributes with <rtexprvalue>false</rtexprvalue>
* http://issues.apache.org/bugzilla/show_bug.cgi?id=35895
Is there a reason why these tag attributes are marked RE false?
bean
* cookie.id
* define.id
* header.id
* anchor.id
* page.id
* parameter.id
* resource.id
* size.id
* struts.id
html
* javascript.dynamicJavascript
* javascript.staticJavascript
* messages.id
logic
* collection.id
* iterate.indexId
----
* Remove deprecations prior to 1.3.0 release
* http://issues.apache.org/bugzilla/show_bug.cgi?id=35953
Hubert, will you still be able to handle this? (Pretty please ..)
---
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Hubert Rabago <hr...@gmail.com>.
Oh, btw, ResponseUtils has a filter() method that's been deprecated
for 1.2.x because the functionality was moved to TagUtils. Now that
TagUtils is in another project, the filter code is back in
ResponseUtils. It's still marked deprecated, and someone asked why in
the javadoc. If no one objects, and no one does it before me, I'll be
removing the deprecated tag on this method.
Hubert
On 8/15/05, Hubert Rabago <hr...@gmail.com> wrote:
> For deprecations, it's a good news/bad news thing.
>
> Core deprecations are done. There is one item that is left because I
> wasn't sure if now is the right time to remove it. The method is
> DynaActionFormClass.clear(). From what I can find, this was
> deprecated 14 months ago. It's easy to take out if that's what we
> should do now (no references to it that I can find), otherwise we can
> just update the javadoc to state when it'll be taken out. Checking my
> copies of old Struts, it was deprecated by 1.2.1, but I'm not sure
> about 1.2.0, and I'm also not sure about timeframes. If it was
> deprecated by 1.2.0, we remove them now. What if it was only
> deprecated by 1.2.1? Anyway, like I said, this is a quick fix.
>
> I say "core deprecations" because that's where I usually spend time
> at. For some reason I didn't look for deprecated items in taglibs/el.
> I found a few items there yesterday afternoon, and they look like
> deprecated attributes that need to be removed. They could be as
> simple are deleting code, so if anyone out there feels like it, they
> should go ahead and work on those. If not, I can take a look at them
> one of these weeknights.
>
> Tiles, I haven't even checked yet. Anybody here willing to work on that?
>
> Hubert
>
>
> On 8/15/05, Ted Husted <te...@gmail.com> wrote:
> > How are we doing on mavenizing the web site and removing the deprecations?
> >
> > When these two items are stable, I'll apply the remaining patches and
> > try rolling a distribution.
> >
> > -Ted.
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/15/05, Hubert Rabago <hr...@gmail.com> wrote:
> For deprecations, it's a good news/bad news thing.
>
> Core deprecations are done. There is one item that is left because I
> wasn't sure if now is the right time to remove it. The method is
> DynaActionFormClass.clear(). From what I can find, this was
> deprecated 14 months ago. It's easy to take out if that's what we
> should do now (no references to it that I can find), otherwise we can
> just update the javadoc to state when it'll be taken out. Checking my
> copies of old Struts, it was deprecated by 1.2.1, but I'm not sure
> about 1.2.0, and I'm also not sure about timeframes. If it was
> deprecated by 1.2.0, we remove them now. What if it was only
> deprecated by 1.2.1? Anyway, like I said, this is a quick fix.
Thanks so much for doing this, Hubert :)
I'd say that the telling point is whether it was deprecated in a prior
GA release.
The idea being that if someone stays current with each GA release, and
resolves the deprecated items before the next GA release, they should
not need to make any changes simply to use the newest release.
Since 1.2.7 was a GA relesae, anything deprecated in 1.2.7 is fair
game (so long as we have a documented alternative to the
functionality).
>
> I say "core deprecations" because that's where I usually spend time
> at. For some reason I didn't look for deprecated items in taglibs/el.
> I found a few items there yesterday afternoon, and they look like
> deprecated attributes that need to be removed. They could be as
> simple are deleting code, so if anyone out there feels like it, they
> should go ahead and work on those. If not, I can take a look at them
> one of these weeknights.
The release testing for EL would be constrainted to its version of the
Exercises application, so that won't be so bad to do again later. We
can also cut a Struts el 1.3.1 release and include it in a future
release of the Struts Classic 1.3.x distribution. Ditto for Tiles.
>
> Tiles, I haven't even checked yet. Anybody here willing to work on that?
>
> Hubert
>
>
> On 8/15/05, Ted Husted <te...@gmail.com> wrote:
> > How are we doing on mavenizing the web site and removing the deprecations?
> >
> > When these two items are stable, I'll apply the remaining patches and
> > try rolling a distribution.
> >
> > -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Hubert Rabago <hr...@gmail.com>.
For deprecations, it's a good news/bad news thing.
Core deprecations are done. There is one item that is left because I
wasn't sure if now is the right time to remove it. The method is
DynaActionFormClass.clear(). From what I can find, this was
deprecated 14 months ago. It's easy to take out if that's what we
should do now (no references to it that I can find), otherwise we can
just update the javadoc to state when it'll be taken out. Checking my
copies of old Struts, it was deprecated by 1.2.1, but I'm not sure
about 1.2.0, and I'm also not sure about timeframes. If it was
deprecated by 1.2.0, we remove them now. What if it was only
deprecated by 1.2.1? Anyway, like I said, this is a quick fix.
I say "core deprecations" because that's where I usually spend time
at. For some reason I didn't look for deprecated items in taglibs/el.
I found a few items there yesterday afternoon, and they look like
deprecated attributes that need to be removed. They could be as
simple are deleting code, so if anyone out there feels like it, they
should go ahead and work on those. If not, I can take a look at them
one of these weeknights.
Tiles, I haven't even checked yet. Anybody here willing to work on that?
Hubert
On 8/15/05, Ted Husted <te...@gmail.com> wrote:
> How are we doing on mavenizing the web site and removing the deprecations?
>
> When these two items are stable, I'll apply the remaining patches and
> try rolling a distribution.
>
> -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: 1.3.0 Release - Next Steps
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Ted Husted" <te...@gmail.com>
>
> > Thanks, Wendy, increasing the memory setting did the trick. It just
> > finished building, and everything looks as expected. I can get
> > cracking on the fnal round of website changes now, and then we can
> > take a deep breath and roll this beast :)
>
> I'm not sure if this is necessary, but for Struts 1.2.7, the LICENSE and
> NOTICE files were in both the overall distribution and in the struts.jar
> files.
>
> Looking at the struts-core nightlies
> - LICENSE appears in the nightly .zip file
> - struts-core-1.3.0-dev.jar contains neither LICENSE nor NOTICE
>
> http://www.apache.org/dev/apply-license.html says they belong in the top
> level of the "distribution" which would at least point to adding NOTICE to
> the .zip and .tar.gz files.
>
We definitely want these files in the top level of any distribution
artifacts, to meet the requirements. I also suggest, however, that we
ensure they are inside every JAR file we create as well ... that way,
when a user downloads Struts and starts using it, and six months later
their PHB asks "what are the license terms for that arbitrary JAR file
that you grabbed from someplace we don't remember?" the question can
easily be answered by looking inside.
> --
> Wendy
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/22/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Ted Husted" <te...@gmail.com>
>
> > We generally rely on the commit logs rather than the Bugzilla
> > comments, which tend to be longwinded.
>
> I'm mixing up two different things... are you also doing the outstanding
> bugs on the Wiki by hand, then?
> http://wiki.apache.org/struts/StrutsClassicRelease130
Yes, we just punch in the links to the issues we need to close.
If there were too many to do by hand, then we wouldn't be anywhere
ready for a release :)
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
I restored the release-notes.xml file, cleared the 1.2.7 information and got
it ready for someone else to add the changes for 1.3.0-dev. :)
This thread might help:
http://www.mail-archive.com/user%40struts.apache.org/msg30423.html
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Hubert Rabago" <hr...@gmail.com>
>> It's there already: site/xdocs/userGuide/release-notes.xml
> Oh, you mean that one! Well, with 1.2.7 I remember putting changes on
> the release notes after the change was made. At least during the
> latter part. Not sure how it gets started for a particular version,
> and this one is for 1.2.7 and doesn't contain any 1.3.0 changes that
> were not backported.
Niall copied release-notes.xml to release-notes-1.2.7.xml in May. I don't
see a reason to keep duplicate history, so I'm going to delete
release-notes.xml and add back a [very empty] page.
> I always did it by hand. If anyone's doing it automatically, then
> they better let me know, too. :)
This is not the answer I thought I'd hear! ;) At the very least, svn log
has an '--xml' switch. I think I know enough xsl to get that converted into
an HTML table. (And if I could get svn to actually produce a log, that
might be possible.) Ted mentioned 'Maven changelog' which I assume means
'maven maven-changelog-plugin:report'
Unfortunately, that (at version 1.8.2) consistently reports zero changes for
the last month. Unlikely! They say this is fixed...
http://jira.codehaus.org/browse/MPCHANGELOG-55
I can't seem to get the parameters right on the command line, either. None
of these produces any output:
$ svn log -v -r{2005-08-23}:{2005-07-23} --xml
$ svn log -v -r"{2005-08-23}:{2005-07-23}" --xml
$ svn log -v "-r{2005-08-23}:{2005-07-23}" --xml
Then again, I probably don't want date parameters, I probably want something
related to when 1.2.7 was tagged. Once again, I know what I want to do, but
not exactly how. Any advice?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/22/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Hubert Rabago" <hr...@gmail.com>
> > I don't remember having a release notes document for 1.3.0, though.
> > Are you going to set one up? :)
>
> It's there already: site/xdocs/userGuide/release-notes.xml
Oh, you mean that one! Well, with 1.2.7 I remember putting changes on
the release notes after the change was made. At least during the
latter part. Not sure how it gets started for a particular version,
and this one is for 1.2.7 and doesn't contain any 1.3.0 changes that
were not backported.
> I remember looking at it, but I don't know how you're getting the results of
> a Bugzilla search into an html table. (For the release notes or for the
> Wiki. Anyone want to share the secret?)
I always did it by hand. If anyone's doing it automatically, then
they better let me know, too. :)
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> We generally rely on the commit logs rather than the Bugzilla
> comments, which tend to be longwinded.
I'm mixing up two different things... are you also doing the outstanding
bugs on the Wiki by hand, then?
http://wiki.apache.org/struts/StrutsClassicRelease130
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/22/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> I remember looking at it, but I don't know how you're getting the results of
> a Bugzilla search into an html table. (For the release notes or for the
> Wiki. Anyone want to share the secret?)
We generally rely on the commit logs rather than the Bugzilla
comments, which tend to be longwinded.
For other releases, I started by running the Maven changelog and then
editing it by hand, which I imagine I'd try again for this release.
Before Maven, I did the same sort of thing by scrolling through the
email messages.
The release notes can be a lot of work, but it's also fun to find all
the neat changes we forgot about :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Hubert Rabago" <hr...@gmail.com>
> I don't remember having a release notes document for 1.3.0, though.
> Are you going to set one up? :)
It's there already: site/xdocs/userGuide/release-notes.xml
The content just needs to be changed to reflect 1.3.0 and link to the
release-notes-1.2.7.html page that's already being built.
I remember looking at it, but I don't know how you're getting the results of
a Bugzilla search into an html table. (For the release notes or for the
Wiki. Anyone want to share the secret?)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Hubert Rabago <hr...@gmail.com>.
I don't have the list of deprecated items removed with me now, and in
any case, the list I was keeping needs to be reformatted anyway, so
I'll work on that this week. I think we're gonna wanna share this
list, right? :)
I don't remember having a release notes document for 1.3.0, though.
Are you going to set one up? :)
Hubert
On 8/22/05, Ted Husted <te...@gmail.com> wrote:
>
> Thanks, Wendy. It sounds like the ball is back in my court :)
>
> And, many thanks to Hubert for knocking off the rest of the
> deprecations over the weekend.
>
> -T.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/22/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> I'm going to call the website good enough for 1.3.0. There's still some
> work to be done in site/xdocs/userGuide and the links embedded in the new
> tlds, but I don't think it's worth holding up the release.
Thanks, Wendy. It sounds like the ball is back in my court :)
And, many thanks to Hubert for knocking off the rest of the
deprecations over the weekend.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/22/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> I'm going to call the website good enough for 1.3.0.
The build looks great. I would like to make a few structural changes
for 1.3.0, to help clarify that there is an Apache Struts Project
which creates and maintains a set of related products (subprojects).
Nothing major, just a little juggling.
So, building on what Wendy and James have wrought and posted at
* [http://svn.apache.org/builds/struts/maven/trunk/site-test/index.html]
I'd like to try refactoring the top-level menu list as such:
----
Apache Struts
+ Welcome (1st section only, amend text)
+ Who we are
+ Announcements
Projects
+ Overview (add text)
...
+ Sandbox (add text and explain that these are whiteboard proposals only)
...
+ Site (add text explaining reactor build)
...
+ Tiles
Community
+ Mailing Lists
+ Wiki Pages
+ Resource Directory
+ Known Issues (bugzilla)
Download
+ Binaries
+ Source Code
+ Development Releases
Development
+ Bylaws
+ Release Guidelines
+ Source Repository
+ How to Help FAQ
Project Documentation
+ About Struts Site (add text)
+ Project Info
+ Project Reports (fix - SVN issue?)
+ Development Process
----
Then, we can move the rest under the Core subproject:
----
Struts Core
+ Welcome (portions of 1st section, second section)
+ Learning
+ Using
Documentation
+ User and Developer Guides
...
+ FAQs
Project Documentation
+ ...
---
Of course, this would only be the first wave of refinements, but I
think these changes would put us in the ballpark.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/27/05, Ted Husted <te...@gmail.com> wrote:
> If you still have that list you mentioned, Hubert, you can post it here:
>
> * http://wiki.apache.org/struts/StrutsUpgradeNotes12to13
Done.
/h
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/23/05, Hubert Rabago <hr...@gmail.com> wrote:
>
> Deprecations are done, unless anyone finds something I missed.
>
If you still have that list you mentioned, Hubert, you can post it here:
* http://wiki.apache.org/struts/StrutsUpgradeNotes12to13
-Ted/
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> Thanks, Wendy, increasing the memory setting did the trick. It just
> finished building, and everything looks as expected. I can get
> cracking on the fnal round of website changes now, and then we can
> take a deep breath and roll this beast :)
I'm not sure if this is necessary, but for Struts 1.2.7, the LICENSE and
NOTICE files were in both the overall distribution and in the struts.jar
files.
Looking at the struts-core nightlies
- LICENSE appears in the nightly .zip file
- struts-core-1.3.0-dev.jar contains neither LICENSE nor NOTICE
http://www.apache.org/dev/apply-license.html says they belong in the top
level of the "distribution" which would at least point to adding NOTICE to
the .zip and .tar.gz files.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
Thanks, Wendy, increasing the memory setting did the trick. It just
finished building, and everything looks as expected. I can get
cracking on the fnal round of website changes now, and then we can
take a deep breath and roll this beast :)
-Ted.
On 8/23/05, java@wendysmoak.com <ja...@wendysmoak.com> wrote:
> > On 8/23/05, Ted Husted <te...@gmail.com> wrote:
>
> > I tried building the whole enchalida on another machine with Maven
> > 1.0.2 and JDK 1.4.2.9, and ran into the same out of memory issue.
> > Ditto for running the multiproject build.
> >
> > Are we suppose to be using 1.0.2 for this or the 1.1 beta?
>
> I'm using Maven 1.0.2, but having run into the same problem with memory
> earlier, I do have MAVEN_OPTS=-Xmx1024m set.
>
> Reorganizing the website should be a matter of moving files and modifying
> the various navigation.xml files. (Well, and rewriting a bunch of pages.)
>
> Unfortunately, it seems that once you have "user supplied documentation"
> in xdocs that you need to add to the menu, you lose Maven's auto-generated
> menus (except for the last section titled "Project Documentation".)
>
> Someone on maven-user suggested using XML entities to bring in the common
> sections of the menu (they could live in 'build') but I didn't get that
> far.
>
> --
> Wendy
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/23/05, Ted Husted <te...@gmail.com> wrote:
> On 8/22/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > Can someone else try to build the site and let me know if it looks okay?
I tried building the whole enchalida on another machine with Maven
1.0.2 and JDK 1.4.2.9, and ran into the same out of memory issue.
Ditto for running the multiproject build.
Are we suppose to be using 1.0.2 for this or the 1.1 beta?
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Martin Cooper <mf...@gmail.com>.
On 8/23/05, Ted Husted <te...@gmail.com> wrote:
> I've been checking the external links and notice that
> www.waferproject.org seems to be down. Does anyone know if Wafer is
> defunct, or just having server issues?
Don't know. DNS doesn't seem to know about it any more, but the
registration is still valid. I'm cc'ing the domain registrant in case
he can enlighten us...
--
Martin Cooper
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Hubert Rabago <hr...@gmail.com>.
On 8/23/05, Ted Husted <te...@gmail.com> wrote:
>
> I should be able to wrap up the distribution issues while Hubert wraps
> up the deprecations, and I would expect we'd have something rolled and
> ready for review by the end of the month -- just in time for Labor Day
> weekend in the US. :)
Deprecations are done, unless anyone finds something I missed.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/22/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> Can someone else try to build the site and let me know if it looks okay?
My first try at building everything ran out of memory. I rebooted, and
it's running again now.
In the meantime, I'm starting a review of the documentation now, both
as a quality check and with an eye toward creating more separation
between Struts the project and Struts Classic the distribution. But
I'll hold up on committing any changes to the text until we feel the
Maven build is stable (enough). I'll also get cranking on those
release notes.
I should be able to wrap up the distribution issues while Hubert wraps
up the deprecations, and I would expect we'd have something rolled and
ready for review by the end of the month -- just in time for Labor Day
weekend in the US. :)
I've been checking the external links and notice that
www.waferproject.org seems to be down. Does anyone know if Wafer is
defunct, or just having server issues?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <jm...@apache.org>.
I'm looking at it now.
I'll post back in a few.
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
On Aug 22, 2005, at 11:23 AM, Wendy Smoak wrote:
> I'm going to call the website good enough for 1.3.0. There's still
> some work to be done in site/xdocs/userGuide and the links embedded
> in the new tlds, but I don't think it's worth holding up the release.
>
> Can someone else try to build the site and let me know if it looks
> okay? I still have uncommitted changes related to various
> experiments, and I'm not certain I got all of the important ones
> in. James is the obvious choice here-- I'd like to see the site
> get published nightly again. :)
>
> To build the site:
> - cd to /struts/current/site
> - run 'maven multiproject:site'
> - look in site/target/docs for the result.
>
> I opened a ticket for maven-xdoc-plugin asking them to add the
> ability to choose the names of the anchors for the section and
> subsection tags. That will also fix the problem with the pdf
> plugin, in which FOP dies if there are duplicate ids. As it
> stands, you can't have two sections (or subsections) with the same
> name _anywhere_ in any of the xml files you intend to convert to
> PDF. (See: http://jira.codehaus.org/browse/MPXDOC-159 )
>
> 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: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
I'm going to call the website good enough for 1.3.0. There's still some
work to be done in site/xdocs/userGuide and the links embedded in the new
tlds, but I don't think it's worth holding up the release.
Can someone else try to build the site and let me know if it looks okay? I
still have uncommitted changes related to various experiments, and I'm not
certain I got all of the important ones in. James is the obvious choice
here-- I'd like to see the site get published nightly again. :)
To build the site:
- cd to /struts/current/site
- run 'maven multiproject:site'
- look in site/target/docs for the result.
I opened a ticket for maven-xdoc-plugin asking them to add the ability to
choose the names of the anchors for the section and subsection tags. That
will also fix the problem with the pdf plugin, in which FOP dies if there
are duplicate ids. As it stands, you can't have two sections (or
subsections) with the same name _anywhere_ in any of the xml files you
intend to convert to PDF. (See:
http://jira.codehaus.org/browse/MPXDOC-159 )
Thanks,
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Joe Germuska" <Jo...@Germuska.com>
> I just updated the taglib subproject from SVN and don't see standalone TLD
> files, and the maven goal for generating them is still in place -- where
> did you put the new TLDs? Shouldn't the canonical TLD files be under the
> SVN repository for whichever project has the corresponding source code?
Joe, I haven't checked in the changes yet-- I uploaded the tlds under the
test site as a preview:
http://svn.apache.org/builds/struts/maven/trunk/site-test/tlds/
The tld files will go under src/tld/ in taglib, and there are changes to the
Maven build files to get them included in the .jar file as well as to
generate the reports.
Sorry for the confusion. Once I'm sure the tlds are correct, I'll check
everything in. I want to build the entire project and run the example
webapp with the new tlds in place. I'd say "tonight," but I said that
yesterday... Soon. :)
The rest of the changes to the site involve removing href attributes from
<section> and <subsection> tags, and adding anchors (to the files in
site/xdocs/):
<section href="text" name="Long Description">
changes to
<a name="text"/>
<section name="Long Description">
If anyone is exceptionally bored and wants to do that, feel free. :)
Otherwise, it's next on my list after the tlds.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Joe Germuska <Jo...@Germuska.com>.
>If you have time, please review the tlds and click around the taglib
>documentation. Let me know if anything appears to be wrong or missing.
>I'll compare my taglib doc with Joe's version as well.
I just updated the taglib subproject from SVN and don't see
standalone TLD files, and the maven goal for generating them is still
in place -- where did you put the new TLDs? Shouldn't the canonical
TLD files be under the SVN repository for whichever project has the
corresponding source code?
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> That sounds great, Wendy. Thanks!
The taglib doc is done, but I haven't had a chance to test the new tlds and
make sure they actually work-- the taglib plugin claims it's validating
them, but I'm not so sure. :)
Here's what the JSP 1.2 tlds look like so far:
http://svn.apache.org/builds/struts/maven/trunk/site-test/tlds/
An example of the taglib doc...
http://svn.apache.org/builds/struts/maven/trunk/site-test/struts-taglib/tlddoc/html/errors.html
(click 'FRAMES' at the top to get back to the navigation.)
Unfortunately, the tagreference pages are showing all the markup:
http://svn.apache.org/builds/struts/maven/trunk/site-test/struts-taglib/tagreference-struts-html.html
I'll report that to the authors and see if there is a fix.
If you have time, please review the tlds and click around the taglib
documentation. Let me know if anything appears to be wrong or missing.
I'll compare my taglib doc with Joe's version as well.
Thanks again to Greg for help with the XSL stylesheet, and to Craig for
mentioning that taglibrary doc supports CDATA sections in the <description>
tags.
(I updated the entire test site, though I don't think anything has changed
outside of taglibs:
http://svn.apache.org/builds/struts/maven/trunk/site-test/index.html )
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
That sounds great, Wendy. Thanks!
On 8/17/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>
> I'm close to having JSP 1.2 tlds that retain all the html markup from the
> <info> sections of the source xml documents. I got stuck on combining the
> <summary>, <info>, and <since> tags into a single <description> section, and
> had to stop and ask for help with the xsl stylesheet. (Thanks, Greg!)
>
> If all goes well I'll commit those tonight, then go back to fixing the
> internal anchors in the rest of the site.
>
> --
> Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
I'm close to having JSP 1.2 tlds that retain all the html markup from the
<info> sections of the source xml documents. I got stuck on combining the
<summary>, <info>, and <since> tags into a single <description> section, and
had to stop and ask for help with the xsl stylesheet. (Thanks, Greg!)
If all goes well I'll commit those tonight, then go back to fixing the
internal anchors in the rest of the site.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/16/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> Did you have to do any cleanup on the generated tlds?
Nope.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Joe Germuska" <Jo...@Germuska.com>
> Ted has this correct. In fact, the UserGuide HTML pages are
> generated using the base xdoc transformation, and then the TLDs are
> generated with <goal name="struts:generate-tlds"> (in
> taglib/maven.xml)
Thanks! That's what I needed. :)
> Especially with the new non-monolithic distribution, it makes sense to
> generate the TLDs one last time, and then commit those to the SVN
> repository instead of the documentation XML, and then to shift to using
> taglibdoc to generate tag documentation as part of the taglib
> sub-documentation tree.
>
> Easy for me to say -- I'm travelling for work this week so won't have much
> time to put towards helping make it work that way.
Unless I'm missing something, running 'maven struts:generate-tlds' and
moving the result to src/tld/ [where the taglib plugin expects to find
them] won't do it-- the generated tlds don't have the <info> tags.
I changed the stylesheet (tld.xsl) to pick up the those tags from the
taglib/doc/userGuide/struts-*.xml files. That got me close to the taglibdoc
that Joe posted. (It does lose all the markup within <info>, however.)
Did you have to do any cleanup on the generated tlds? I see some
differences such as <ul> in the html-errors taglib doc getting
translated back into <ul> in my version. I had to put the <ul> in a
CDATA section to get it to come out like yours
(http://people.apache.org/~germuska/struts-taglib/docs/tlddoc/html/errors.html).
I stopped short of committing them because I noticed that we're still
generating JSP 1.1 tlds. Once I changed the version, then the <info> tags
are wrong, it's supposed to be <description> and <example> according to the
dtd: http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd . Looks like the
Maven taglib plugin has a 'convert' goal, so I'll try that out tonight.
Thanks,
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Joe Germuska <Jo...@Germuska.com>.
At 2:01 PM -0400 8/15/05, Ted Husted wrote:
>On 8/15/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>> Where are the source files, and how were both the HTML files and the TLDs
>> getting generated originally? If someone explains how it used to work, I
>> can probably make it work again.
>
>Under the "monolithic" distribution, everything was in the one
>UserGuide directory, but when TagLibs became a subproject, the TLD
>XML's went over there.
>
>* http://svn.apache.org/viewcvs.cgi/struts/taglib/trunk/doc/userGuide/
>
>What was happening is that two stylesheets were applied to the one
>file. One stylesheet was used to generate the UserGuide HTML pages,
>and the other stylesheet generated the TLDs.
Ted has this correct. In fact, the UserGuide HTML pages are
generated using the base xdoc transformation, and then the TLDs are
generated with <goal name="struts:generate-tlds"> (in
taglib/maven.xml)
Especially with the new non-monolithic distribution, it makes sense
to generate the TLDs one last time, and then commit those to the SVN
repository instead of the documentation XML, and then to shift to
using taglibdoc to generate tag documentation as part of the taglib
sub-documentation tree.
Easy for me to say -- I'm travelling for work this week so won't have
much time to put towards helping make it work that way.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/15/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> Where are the source files, and how were both the HTML files and the TLDs
> getting generated originally? If someone explains how it used to work, I
> can probably make it work again.
Under the "monolithic" distribution, everything was in the one
UserGuide directory, but when TagLibs became a subproject, the TLD
XML's went over there.
* http://svn.apache.org/viewcvs.cgi/struts/taglib/trunk/doc/userGuide/
What was happening is that two stylesheets were applied to the one
file. One stylesheet was used to generate the UserGuide HTML pages,
and the other stylesheet generated the TLDs.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: database.xml - APB
Posted by Don Brown <mr...@twdata.org>.
Oh right, I removed it since it was talking about data source support,
which I removed. Does it have some other stuff I missed?
Don
Wendy Smoak wrote:
> From: "Ted Husted" <te...@gmail.com>
>
>> If someone can ressurect a copy from SVN without too much trouble,
>> that would be great. Otherwise, I'll pull the copy from the website
>> and rename it as db-howto.xml.
>
>
> I found where it was deleted...
> r155852 | mrdon | 2005-03-01 18:26:14 -0700 (Tue, 01 Mar 2005)
> Changed paths:
> M /struts/core/trunk/conf/share/struts-config_1_3.dtd
> D /struts/core/trunk/doc/faqs/database.xml
> M /struts/core/trunk/doc/faqs/index.xml
>
> So it will be there in r155851. Do you want it in core/xdocs or site/xdocs?
>
>> Meanwhile, on with the copyediting ...
>
>
> ... which is greatly appreciated. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: database.xml - APB
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> If someone can ressurect a copy from SVN without too much trouble,
> that would be great. Otherwise, I'll pull the copy from the website
> and rename it as db-howto.xml.
I found where it was deleted...
r155852 | mrdon | 2005-03-01 18:26:14 -0700 (Tue, 01 Mar 2005)
Changed paths:
M /struts/core/trunk/conf/share/struts-config_1_3.dtd
D /struts/core/trunk/doc/faqs/database.xml
M /struts/core/trunk/doc/faqs/index.xml
So it will be there in r155851. Do you want it in core/xdocs or site/xdocs?
> Meanwhile, on with the copyediting ...
... which is greatly appreciated. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
database.xml - APB
Posted by Ted Husted <te...@gmail.com>.
On 8/15/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> Also, we seem to have lost 'database.xml' somewhere along the way. The
> current site has this page: http://struts.apache.org/faqs/database.html but
> I don't have it locally. I haven't gone looking to see if it was removed on
> purpose, but that seems unlikely.
With all the reorganization, my guess would be that it got confused
with one of the database.xml's from a MailReader application.
If someone can ressurect a copy from SVN without too much trouble,
that would be great. Otherwise, I'll pull the copy from the website
and rename it as db-howto.xml.
Meanwhile, on with the copyediting ...
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Ted Husted" <te...@gmail.com>
> How are we doing on mavenizing the web site
I'll get the internal links/anchors done this week. At least it should be
good enough for 1.3.0, though I'm not sure how we intend to distribute the
documentation this time around. The users don't really need the *entire*
site with all the reports.
I need help with the TLD generation. Maybe it will be simple once I get a
chance to look at it... but at first glance, the 'acquiring' page says that
the TLDs are generated from struts-*.xml files in doc/userGuide [now
site/xdocs/userGuide] and I don't see any such files.
Where are the source files, and how were both the HTML files and the TLDs
getting generated originally? If someone explains how it used to work, I
can probably make it work again.
Also, we seem to have lost 'database.xml' somewhere along the way. The
current site has this page: http://struts.apache.org/faqs/database.html but
I don't have it locally. I haven't gone looking to see if it was removed on
purpose, but that seems unlikely.
Thanks,
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
How are we doing on mavenizing the web site and removing the deprecations?
When these two items are stable, I'll apply the remaining patches and
try rolling a distribution.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 8/1/05, Ted Husted <te...@gmail.com> wrote:
> Thanks Hubert. I'm still getting my Java development environment dusted off :)
OK, making progress. I've got the latest Java's installed (1.3.1_15,
1.4.2_07, 1.5.0_04) and updated Injellij to version 5 (thanks,
JetBrains!).
Now, onto to the code :)
For 1.3.0, I think we should concentrate on bug-fixes and
infrastructure. There have been a lot of internal changes, and job one
should be to get a clean build. Problem reports with working patches
will be applied. If a problem report doesn't have a patch or obvious
fix, then we may have to leave it open, until someone comes up with a
fix.
For 1.3.1, we could move the focus to enhancements, again apply those
with working patches. If people *test* the patch for an enhancement,
and vote for it, I would give the patch higher priority.
It is unlikely that an enhancement request without a patch will be
implemented, and we might consider moving such requests to a "wish
list" or "job jar" wiki page.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
Thanks Hubert. I'm still getting my Java development environment dusted off :)
On 8/1/05, Hubert Rabago <hr...@gmail.com> wrote:
> The fewer than expected time I got to work on this was spent on the
> list of bugs. I got about a quarter from the list, including two
> duplicates and a worksforme. The rest are items I just didn't get
> time to work on, or in an area I'm not that familiar with, or items
> that other people already had a headstart with so perhaps they might
> like a chance to resolve it. There's a few there I think should be
> marked as enhancements (one of which I just marked as such), and even
> then perhaps be closed after updating documentation to tell users to
> watch out for those cases (like 35389 and 35477).
>
> I can take on the deprecated items that need to be removed. Please
> note that this involves the ActionError class. Also note that not all
> cases are just delete-n-commit, but the one case I've seen that isn't
> so far shouldn't be a big deal.
>
> I think I'll have a couple nights this week, but not any significant
> amount of extended periods.
>
> Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Dakota Jack <da...@gmail.com>.
Your assertion in bugzilla that Ted invented stripping .x in 2002 is
incorrect. If you think he invented that in 2002 you need to document
it. The use of getX() and getY() is another matter entirely.
On 8/1/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 8/1/05, Hubert Rabago <hr...@gmail.com> wrote:
> > The fewer than expected time I got to work on this was spent on the
> > list of bugs. I got about a quarter from the list, including two
> > duplicates and a worksforme. The rest are items I just didn't get
> > time to work on, or in an area I'm not that familiar with, or items
> > that other people already had a headstart with so perhaps they might
> > like a chance to resolve it. There's a few there I think should be
> > marked as enhancements (one of which I just marked as such), and even
> > then perhaps be closed after updating documentation to tell users to
> > watch out for those cases (like 35389 and 35477).
>
> I hate to poke the wound, but will something be done with
> http://issues.apache.org/bugzilla/show_bug.cgi?id=30292 (the infamous
> DispatchAction)? Or it is going to just marinate there?
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/1/05, Hubert Rabago <hr...@gmail.com> wrote:
> The fewer than expected time I got to work on this was spent on the
> list of bugs. I got about a quarter from the list, including two
> duplicates and a worksforme. The rest are items I just didn't get
> time to work on, or in an area I'm not that familiar with, or items
> that other people already had a headstart with so perhaps they might
> like a chance to resolve it. There's a few there I think should be
> marked as enhancements (one of which I just marked as such), and even
> then perhaps be closed after updating documentation to tell users to
> watch out for those cases (like 35389 and 35477).
I hate to poke the wound, but will something be done with
http://issues.apache.org/bugzilla/show_bug.cgi?id=30292 (the infamous
DispatchAction)? Or it is going to just marinate there?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Hubert Rabago <hr...@gmail.com>.
The fewer than expected time I got to work on this was spent on the
list of bugs. I got about a quarter from the list, including two
duplicates and a worksforme. The rest are items I just didn't get
time to work on, or in an area I'm not that familiar with, or items
that other people already had a headstart with so perhaps they might
like a chance to resolve it. There's a few there I think should be
marked as enhancements (one of which I just marked as such), and even
then perhaps be closed after updating documentation to tell users to
watch out for those cases (like 35389 and 35477).
I can take on the deprecated items that need to be removed. Please
note that this involves the ActionError class. Also note that not all
cases are just delete-n-commit, but the one case I've seen that isn't
so far shouldn't be a big deal.
I think I'll have a couple nights this week, but not any significant
amount of extended periods.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
There is still more to do with the Core documention for Building
Components and Configuration Applications sections. We tweaked the
product names, but I don't know that the background text is still in
synch with the new distribution paradigm. I do know that the Request
Processor section still refers to the 1.2.x version.
Site seems OK ow, and after Core, next in line would be Taglibs. The
developer guides are already over there, but they need to be reviewed,
and we could also use a better introduction page. There's a copy of
the original "Building_View" page there. We need to scavage from that
the sectiosn that do not already appear in the Core version.
-Ted.
On 10/5/05, Christian Meder <ch...@absolutegiganten.org> wrote:
> On Wed, 2005-10-05 at 07:50 -0400, Ted Husted wrote:
> > Thanks, Wendy.
> >
> > I've had to spend some of my volunteer hours elsewhere lately, but
> > things should be getting back on track for me now. I'm planning to
> > work on the Applications/MailReader project next, and then get back to
> > the Core documentation.
>
> Hi Ted,
>
> I'm willing to spend some cycles helping out with the todos. Now just to
> avoid duplicated efforts: Which todo should I have a look at ?
>
>
> Christian
> >
> > We've always had troubles with the tiles-documentation webapp.
> > Overall, I would suggest that we
> >
> > * Make the MailReader a true best-practices application, including the
> > use of Tiles.
> > * Add the Struts Cookbook.
> > * See if we can move some of the content of tiles-documentation into
> > the Cookbook.
> > * Also see if the struts-examples content can be moved to the
> > cookbook, so that maybe we can get the webapps down to blank,
> > cookbook, exercises, and mailreader. (Plus whatever Shale and
> > standalone Tiles want to do.)
> >
> > If in the meantime, we want to consider moving tiles-documentation
> > into the sandbox, until it can be repaired, refactored, or disbursed
> > into other applications.
> >
> > I haven't looked at EL, but it might be the same situation:
> > Programming examples that we are trying to carry in a solo app might
> > be better handled by the Cookbook.
> >
> > -Ted.
> >
> > On 10/3/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > > The usual Monday update. :)
> > >
> > > The tiles-documentation webapp now builds and (mostly) works, but it's not
> > > included in the overall 'build-all' goal. Right now it lives in
> > > tiles/tiles-documentation, and I don't immediately see how to get Maven to
> > > build it as part of Tiles.
> > >
> > > There's a similar situation (a jar plus a webapp) in EL, but that's not done
> > > quite right either-- there you have to convince Maven to include a second
> > > directory of source code, which it doesn't like to do. Both Tiles and EL
> > > probably need to be reorganized to work better with Maven.
> > >
> > > The Cactus tests for EL still need attention. I'll open a bug ticket for it
> > > in a few days.
> > >
> > > --
> > > Wendy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> --
> Christian Meder, email: chris@absolutegiganten.org
>
> The Way-Seeking Mind of a tenzo is actualized
> by rolling up your sleeves.
>
> (Eihei Dogen Zenji)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Christian Meder <ch...@absolutegiganten.org>.
On Wed, 2005-10-05 at 07:50 -0400, Ted Husted wrote:
> Thanks, Wendy.
>
> I've had to spend some of my volunteer hours elsewhere lately, but
> things should be getting back on track for me now. I'm planning to
> work on the Applications/MailReader project next, and then get back to
> the Core documentation.
Hi Ted,
I'm willing to spend some cycles helping out with the todos. Now just to
avoid duplicated efforts: Which todo should I have a look at ?
Christian
>
> We've always had troubles with the tiles-documentation webapp.
> Overall, I would suggest that we
>
> * Make the MailReader a true best-practices application, including the
> use of Tiles.
> * Add the Struts Cookbook.
> * See if we can move some of the content of tiles-documentation into
> the Cookbook.
> * Also see if the struts-examples content can be moved to the
> cookbook, so that maybe we can get the webapps down to blank,
> cookbook, exercises, and mailreader. (Plus whatever Shale and
> standalone Tiles want to do.)
>
> If in the meantime, we want to consider moving tiles-documentation
> into the sandbox, until it can be repaired, refactored, or disbursed
> into other applications.
>
> I haven't looked at EL, but it might be the same situation:
> Programming examples that we are trying to carry in a solo app might
> be better handled by the Cookbook.
>
> -Ted.
>
> On 10/3/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > The usual Monday update. :)
> >
> > The tiles-documentation webapp now builds and (mostly) works, but it's not
> > included in the overall 'build-all' goal. Right now it lives in
> > tiles/tiles-documentation, and I don't immediately see how to get Maven to
> > build it as part of Tiles.
> >
> > There's a similar situation (a jar plus a webapp) in EL, but that's not done
> > quite right either-- there you have to convince Maven to include a second
> > directory of source code, which it doesn't like to do. Both Tiles and EL
> > probably need to be reorganized to work better with Maven.
> >
> > The Cactus tests for EL still need attention. I'll open a bug ticket for it
> > in a few days.
> >
> > --
> > Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
Thanks, Wendy.
I've had to spend some of my volunteer hours elsewhere lately, but
things should be getting back on track for me now. I'm planning to
work on the Applications/MailReader project next, and then get back to
the Core documentation.
We've always had troubles with the tiles-documentation webapp.
Overall, I would suggest that we
* Make the MailReader a true best-practices application, including the
use of Tiles.
* Add the Struts Cookbook.
* See if we can move some of the content of tiles-documentation into
the Cookbook.
* Also see if the struts-examples content can be moved to the
cookbook, so that maybe we can get the webapps down to blank,
cookbook, exercises, and mailreader. (Plus whatever Shale and
standalone Tiles want to do.)
If in the meantime, we want to consider moving tiles-documentation
into the sandbox, until it can be repaired, refactored, or disbursed
into other applications.
I haven't looked at EL, but it might be the same situation:
Programming examples that we are trying to carry in a solo app might
be better handled by the Cookbook.
-Ted.
On 10/3/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> The usual Monday update. :)
>
> The tiles-documentation webapp now builds and (mostly) works, but it's not
> included in the overall 'build-all' goal. Right now it lives in
> tiles/tiles-documentation, and I don't immediately see how to get Maven to
> build it as part of Tiles.
>
> There's a similar situation (a jar plus a webapp) in EL, but that's not done
> quite right either-- there you have to convince Maven to include a second
> directory of source code, which it doesn't like to do. Both Tiles and EL
> probably need to be reorganized to work better with Maven.
>
> The Cactus tests for EL still need attention. I'll open a bug ticket for it
> in a few days.
>
> --
> Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
The usual Monday update. :)
The tiles-documentation webapp now builds and (mostly) works, but it's not
included in the overall 'build-all' goal. Right now it lives in
tiles/tiles-documentation, and I don't immediately see how to get Maven to
build it as part of Tiles.
There's a similar situation (a jar plus a webapp) in EL, but that's not done
quite right either-- there you have to convince Maven to include a second
directory of source code, which it doesn't like to do. Both Tiles and EL
probably need to be reorganized to work better with Maven.
The Cactus tests for EL still need attention. I'll open a bug ticket for it
in a few days.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ja...@wendysmoak.com>.
A couple of issues from this weekend:
I was able to run the Cactus tests for Struts EL under Maven, but there are
failures. Can someone more familiar with it please take a look? (The
instructions are the same as for Taglib, see the README file.)
The tiles-documentation.war doesn't work yet-- it's still at Servlet 2.2 and
all of the <%@ taglib> tags refer to /WEB-INF/struts-*.tld. If you have
time to bring the webapp up to date, feel free to jump in.
(Both Struts Tiles and Struts EL now have JSP 1.2 TLDs, with the associated
reports for the website. Most of the other activity was just cleaning up
unused/duplicate files.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
The documentation refactorings are going well, but I'd like to set
that aside for now and hop over to the Applications subproject, which
is mentioned from time to time on the other docs.
If anyone wants to jump in on the docs, please feel free. There's
enough done now to set the direction for the rest. Contributions from
non-committers are also welcome. Patches work just as well against XML
as they do against Java source :)
-Ted.
On 7/30/05, Ted Husted <te...@gmail.com> wrote:
> Basically, all we need to do is
>
> * address any outstanding problem reports,
> * update the release notes,
> * test,
> * tag,
> * roll,
> * post, and
> * vote.
>
> If the release is voted past test build, then we can sign it and link
> it from the website.
>
> If the release makes GA, or will be widely distributed, then we can
> enter into the mirroring system.
>
> Of course, the more often we release, the easier this guantlet
> becomes. If the volunteers had time, and there were changes to
> distribute, we've often said that we'd like to release every few
> weeks,
>
> But, first things first, we should resolve the problem reports and roll 1.3.0.
>
> I went through the short list last night and pruned a couple that were
> resolved or redundant.
>
> The rest seem to have patches or coding advice that we could follow.
> Off hand, I don't see any problem with applying the rest of the
> tickets, so we should start doing that as we have time.
>
> When you are ready to code, just post a comment to the ticket that you
> are applying the fix now, and have at it. I won't get back to this
> myself until early Monday morning, but then I can devote some time
> each weekday morning. (It would be a great Monday morning surprise to
> come back and find everything resolved!)
>
> For the 1.3.0 release, I think addressing the problem tickets is
> enough. But, for 1.3.1, we should also take a look at any enhancement
> reports with patches.
>
> At some point, we should reduce the enhancement reports *without*
> patches to a omnibus "wish list" or "idea jar", so we can see the
> forest for the trees. Of course, anyone with a Bugzilla and a Wiki
> account could help with something like this. Once upon a time, I
> started an idea jar page here:
>
> * http://wiki.apache.org/struts/StrutsIdeaJar
>
> But, IMHO, focussing first on tickets with patches is vital. The
> primary role of the committers and PMC is to help the community create
> and maintain Struts. The community does this by supplying patches, and
> Job One of the PMC should be to ensure that all patches are applied or
> declined with cause.
>
> An Apache project is not about a few shining stars, it's about a
> thousand points of light, and those lights speak to us through patches
> :)
>
> Aside from the problem tickets, we have another twenty-odd enhancement
> tickets with patches, which could be the focus of 1.3.1. There are
> several Bugzilla query links on the Roadmap page.
>
> * http://struts.apache.org/roadmap.html
>
> But, again, for 1.3.0, let's resolve the problems that can be
> resolved, and get something out on the floor :)
>
> -Ted.
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
I reviewed the notes in November, and I'll go over the commit logs
since, to see if there is anything else we need to mention. But they
should already be very close.
One question would be whether we should copy the release notes page to
each of the subproject and then edit them down to contain only their
own notes.
For the 1.3.0 release at least, I would be in favor of keeping the
entire set of notes in the Action package too, as a convenience.
-Ted.
On 1/17/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 1/17/06, Ted Husted <te...@gmail.com> wrote:
>
> > OK, I see by the commit and wiki logs that Wendy has done the deed,
> > and everything is checked that going to be checked :)
>
> The release notes could use a final review; I didn't check it off on
> the release plan.
>
> And we also need to remove the example of the cglib enhanced form from
> apps/examples.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Martin Cooper <ma...@apache.org>.
On 1/17/06, Ted Husted <te...@gmail.com> wrote:
>
> OK, I see by the commit and wiki logs that Wendy has done the deed,
> and everything is checked that going to be checked :)
>
> * http://wiki.apache.org/struts/StrutsClassicRelease130
>
> Since a multiproject relesae is still new ground, I'm thinking the
> next step would be to assembly a prototype of what a 1.3.0 release
> would look like, and post it to a home directory, for everyone to
> review. Then, if appropriate, we can tag the repository, and release.
>
> If there are no objections, tonight I can put together a prototype
> release package.
+1, modulo Wendy's comments about release notes and cglib example. I see
light at the end of this tunnel! :-)
--
Martin Cooper
-Ted.
>
>
> On 1/17/06, Laurie Harper <la...@holoweb.net> wrote:
> > I hate to say it, but I'm not going to have time to work on fixing
> > this in time for the 1.3 release. Wendy's suggestion (removing the
> > feature for now) probably makes the most sense; I'll look at adding
> > the serialization support and putting the enhanced form bean support
> > into 'extras' post 1.3.0.
> >
> > L.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/17/06, Wendy Smoak <ws...@gmail.com> wrote:
> And we also need to remove the example of the cglib enhanced form from
> apps/examples.
Done in r370014.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/17/06, Ted Husted <te...@gmail.com> wrote:
> OK, I see by the commit and wiki logs that Wendy has done the deed,
> and everything is checked that going to be checked :)
The release notes could use a final review; I didn't check it off on
the release plan.
And we also need to remove the example of the cglib enhanced form from
apps/examples.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
OK, I see by the commit and wiki logs that Wendy has done the deed,
and everything is checked that going to be checked :)
* http://wiki.apache.org/struts/StrutsClassicRelease130
Since a multiproject relesae is still new ground, I'm thinking the
next step would be to assembly a prototype of what a 1.3.0 release
would look like, and post it to a home directory, for everyone to
review. Then, if appropriate, we can tag the repository, and release.
If there are no objections, tonight I can put together a prototype
release package.
-Ted.
On 1/17/06, Laurie Harper <la...@holoweb.net> wrote:
> I hate to say it, but I'm not going to have time to work on fixing
> this in time for the 1.3 release. Wendy's suggestion (removing the
> feature for now) probably makes the most sense; I'll look at adding
> the serialization support and putting the enhanced form bean support
> into 'extras' post 1.3.0.
>
> L.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Laurie Harper <la...@holoweb.net>.
I hate to say it, but I'm not going to have time to work on fixing
this in time for the 1.3 release. Wendy's suggestion (removing the
feature for now) probably makes the most sense; I'll look at adding
the serialization support and putting the enhanced form bean support
into 'extras' post 1.3.0.
L.
On 16-Jan-06, at 7:27 PM, Ted Husted wrote:
> Any new input on #37730?
>
> If we are not ready to resolve the serialization issue, then we should
> table this new feature for a subsequent release.
>
> -Ted.
>
> On 1/13/06, Wendy Smoak <ws...@gmail.com> wrote:
>> Bug# 37301 looks like an enhancement request to me... I don't
>> think it
>> should prevent a release. So we just need to resolve Bug #37730
>> (serialization) one way or the other. Laurie, any comments on all
>> this?
--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
> 25267 (Cactus test) is still open but will be dealt with later.
Yes, I'm thinking that it's the tests that are broken, rather than the code.
Having the cactus tests would be better, but it's better to release
without than not release.
We have been testing the code through the unit tests and example
applications, as well as real-life deployments. Carpe diem!
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/16/06, Ted Husted <te...@gmail.com> wrote:
> Any new input on #37730?
>
> If we are not ready to resolve the serialization issue, then we should
> table this new feature for a subsequent release.
Done in r369764, see comments on Bug# 37730.
I resolved the CGLIB-related bugs and updated the release plan on the
Wiki. 25267 (Cactus test) is still open but will be dealt with later.
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
Any new input on #37730?
If we are not ready to resolve the serialization issue, then we should
table this new feature for a subsequent release.
-Ted.
On 1/13/06, Wendy Smoak <ws...@gmail.com> wrote:
> Bug# 37301 looks like an enhancement request to me... I don't think it
> should prevent a release. So we just need to resolve Bug #37730
> (serialization) one way or the other. Laurie, any comments on all
> this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Wendy Smoak wrote:
> The CGLib enhancement is already completely optional-- you do not have
> to include cglib-nodep-2.1_3.jar in your webapp. It works if you
> include the jar and use the new 'enhanced' attribute in struts-config.
That's what I thought, just wanted to be sure.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/13/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> That CGLib extension always bugged me a bit... might that not be a
> perfect candidate for the Extras package, which would serve to resolve
> issue #2 as well? The idea of that dependency, even if optional (it
> *is* optional, right?!?) doesn't sit too well with me... if it in fact
> is an optional dependency, why not a completely optional add-on at the
> same time?
The CGLib enhancement is already completely optional-- you do not have
to include cglib-nodep-2.1_3.jar in your webapp. It works if you
include the jar and use the new 'enhanced' attribute in struts-config.
The comments on r345179 indicate that this could be moved to extras:
http://marc.theaimsgroup.com/?l=struts-dev&m=113219888632323&w=2
Bug# 37301 looks like an enhancement request to me... I don't think it
should prevent a release. So we just need to resolve Bug #37730
(serialization) one way or the other. Laurie, any comments on all
this?
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
That CGLib extension always bugged me a bit... might that not be a
perfect candidate for the Extras package, which would serve to resolve
issue #2 as well? The idea of that dependency, even if optional (it
*is* optional, right?!?) doesn't sit too well with me... if it in fact
is an optional dependency, why not a completely optional add-on at the
same time?
Just a though. Anyone else?
Frank
Ted Husted wrote:
> OK then, looking at Wendy's latest update to the status page,
>
> * http://wiki.apache.org/struts/StrutsClassicRelease130
>
> with the Commons Resources dependency on the backburner, now we are
> down to the codependant issues regarding the new EDAF component
>
> * Enhanced DynaActionForms cannot be correct deserialized
> ** http://issues.apache.org/bugzilla/show_bug.cgi?id=37730
> * Allow dynamic interface implementation by ActionForms using CGLib
> ** http://issues.apache.org/bugzilla/show_bug.cgi?id=37301
>
> If the deserialization issue is unresolved, and can't be resolved this
> weekend, then I suggest we pull this into the sandbox too, perhaps
> into Extras, until it's ready for prime-time.
>
> Or, if this has been resolved, and there are no other showstopper
> comments regarding the EDAF, then I'm thinking we're ready to tag and
> roll the various 1.3.0 subprojects and the Library bundle, and proceed
> to the quality testing phase.
>
> -Ted.
>
> On 1/12/06, Wendy Smoak <ws...@gmail.com> wrote:
>> Confirmed. The only class I can find that imports from
>> oa.commons.resources is oas.plugins.resources.CommonsResources, which
>> is in struts-extras.jar.
>>
>> (And the only project.xml file that declares a dependency on
>> struts-extras is the one in apps, but since it does not also declare a
>> dependency on commons-resources, it must be using something else in
>> struts-extras.)
>>
>>> I was thinking that if pull
>>> "org.apache.struts.plugins.resources" from the 1.3.0 release, then we
>>> eliminate the Commons Resources dependency, and we could post an
>>> initial release. Once Commons Resources is sorted out, we could add it
>>> back and roll another Extras.
>> Okay. If I don't hear any objections to this today, I'll move that
>> package to sandbox/extras this evening.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
OK then, looking at Wendy's latest update to the status page,
* http://wiki.apache.org/struts/StrutsClassicRelease130
with the Commons Resources dependency on the backburner, now we are
down to the codependant issues regarding the new EDAF component
* Enhanced DynaActionForms cannot be correct deserialized
** http://issues.apache.org/bugzilla/show_bug.cgi?id=37730
* Allow dynamic interface implementation by ActionForms using CGLib
** http://issues.apache.org/bugzilla/show_bug.cgi?id=37301
If the deserialization issue is unresolved, and can't be resolved this
weekend, then I suggest we pull this into the sandbox too, perhaps
into Extras, until it's ready for prime-time.
Or, if this has been resolved, and there are no other showstopper
comments regarding the EDAF, then I'm thinking we're ready to tag and
roll the various 1.3.0 subprojects and the Library bundle, and proceed
to the quality testing phase.
-Ted.
On 1/12/06, Wendy Smoak <ws...@gmail.com> wrote:
> Confirmed. The only class I can find that imports from
> oa.commons.resources is oas.plugins.resources.CommonsResources, which
> is in struts-extras.jar.
>
> (And the only project.xml file that declares a dependency on
> struts-extras is the one in apps, but since it does not also declare a
> dependency on commons-resources, it must be using something else in
> struts-extras.)
>
> > I was thinking that if pull
> > "org.apache.struts.plugins.resources" from the 1.3.0 release, then we
> > eliminate the Commons Resources dependency, and we could post an
> > initial release. Once Commons Resources is sorted out, we could add it
> > back and roll another Extras.
>
> Okay. If I don't hear any objections to this today, I'll move that
> package to sandbox/extras this evening.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/12/06, Ted Husted <te...@gmail.com> wrote:
> We might be talking past each other.
> The package I'm talking about is here:
> * http://struts.apache.org/struts-extras/apidocs/index.html
> org.apache.struts.plugins.resources
>
> AFAIK, this is the only package with a dependency on Commons
> Resources. I'd check ow to be sure,
Confirmed. The only class I can find that imports from
oa.commons.resources is oas.plugins.resources.CommonsResources, which
is in struts-extras.jar.
(And the only project.xml file that declares a dependency on
struts-extras is the one in apps, but since it does not also declare a
dependency on commons-resources, it must be using something else in
struts-extras.)
> I was thinking that if pull
> "org.apache.struts.plugins.resources" from the 1.3.0 release, then we
> eliminate the Commons Resources dependency, and we could post an
> initial release. Once Commons Resources is sorted out, we could add it
> back and roll another Extras.
Okay. If I don't hear any objections to this today, I'll move that
package to sandbox/extras this evening.
> I'm on my way to the NE JUG
> right now. (Pre-registration are at 357.)
Have fun!
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 1/11/06, Martin Cooper <ma...@apache.org> wrote:
> I think the point is that we can't move Resources to Extras if the core is
> going to depend on it.
We might be talking past each other.
The package I'm talking about is here:
* http://struts.apache.org/struts-extras/apidocs/index.html
org.apache.struts.plugins.resources
AFAIK, this is the only package with a dependency on Commons
Resources. I'd check ow to be sure, but I'm on my way to the NE JUG
right now. (Pre-registration are at 357.) I was thinking that if pull
"org.apache.struts.plugins.resources" from the 1.3.0 release, then we
eliminate the Commons Resources dependency, and we could post an
initial release. Once Commons Resources is sorted out, we could add it
back and roll another Extras.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Martin Cooper <ma...@apache.org>.
On 1/11/06, Ted Husted <te...@gmail.com> wrote:
>
> On 1/11/06, James Mitchell <jm...@apache.org> wrote:
> > I'm not sure where this ended up.
> >
> > Whether Resources is part of the jar in "extras" or not, I don't
> > think we should have a dependency on any called "extras".
> > "extra" (to me) means "optional". Am I wrong on this?
>
> Who is the "we" that has a dependency?
I think the point is that we can't move Resources to Extras if the core is
going to depend on it.
--
Martin Cooper
AFAIK, the only subproject that
> depends on Extras is Apps, because the applications use some of the
> optional classes.
>
> If for some reason you don't like "Extras", we could just call it
> "Optional", like Ant does.
>
> The problem is that we have a class called "PlugIn", and there are
> things besides PlugIn classes that are optional, like the ever growing
> number of dispatch actions :)
>
> Another likely suspect could be that nutty ValidatorActionForm class
> that confues everyone at first. If it were in Extras, it would be
> clear which we consider to be the default.
>
> I think calling the package PlugIns woudl be confusing unless it only
> contained PlugIns. And if that package only contained PlugIns, then we
> would need another package for the other optional classes. 'm not sure
> if I see the value-add in having an eight dwarf :)
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 1/11/06, James Mitchell <jm...@apache.org> wrote:
> I'm not sure where this ended up.
>
> Whether Resources is part of the jar in "extras" or not, I don't
> think we should have a dependency on any called "extras".
> "extra" (to me) means "optional". Am I wrong on this?
Who is the "we" that has a dependency? AFAIK, the only subproject that
depends on Extras is Apps, because the applications use some of the
optional classes.
If for some reason you don't like "Extras", we could just call it
"Optional", like Ant does.
The problem is that we have a class called "PlugIn", and there are
things besides PlugIn classes that are optional, like the ever growing
number of dispatch actions :)
Another likely suspect could be that nutty ValidatorActionForm class
that confues everyone at first. If it were in Extras, it would be
clear which we consider to be the default.
I think calling the package PlugIns woudl be confusing unless it only
contained PlugIns. And if that package only contained PlugIns, then we
would need another package for the other optional classes. 'm not sure
if I see the value-add in having an eight dwarf :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <jm...@apache.org>.
I'm not sure where this ended up.
Whether Resources is part of the jar in "extras" or not, I don't
think we should have a dependency on any called "extras".
"extra" (to me) means "optional". Am I wrong on this?
--
James Mitchell
EdgeTech, Inc.
http://edgetechservices.net/
678.910.8017
Skype: jmitchtx
On Jan 10, 2006, at 8:39 PM, Wendy Smoak wrote:
> On 1/10/06, Ted Husted <te...@gmail.com> wrote:
>
>> As and for an alternative, I suggest we move the classes that depend
>> on Resources from Extras
>>
>> * http://struts.apache.org/struts-extras/apidocs/index.html
>>
>> to a sandbox Extras folder until Commons Message Resources is ready.
>
> The original vote on the 1.3.0 release plan is here:
> http://marc.theaimsgroup.com/?t=113262598200002&r=1&w=2
>
> To recap, we had one veto on the plan itself from Niall because of the
> dependency on the unreleased Commons Resources library, and then one
> from James on making changes to the code that's now in struts-extras.
>
> If James is okay with moving the Resources-dependent code to the
> sandbox, (or otherwise temporarily removing the dependency on
> resources,) then lets do it.
>
> --
> 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: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/10/06, Ted Husted <te...@gmail.com> wrote:
> As and for an alternative, I suggest we move the classes that depend
> on Resources from Extras
>
> * http://struts.apache.org/struts-extras/apidocs/index.html
>
> to a sandbox Extras folder until Commons Message Resources is ready.
The original vote on the 1.3.0 release plan is here:
http://marc.theaimsgroup.com/?t=113262598200002&r=1&w=2
To recap, we had one veto on the plan itself from Niall because of the
dependency on the unreleased Commons Resources library, and then one
from James on making changes to the code that's now in struts-extras.
If James is okay with moving the Resources-dependent code to the
sandbox, (or otherwise temporarily removing the dependency on
resources,) then lets do it.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <jm...@apache.org>.
Actually, what we call 'extras' was originally 'plugins'.
I created that area to host optional plugins that shouldn't be
depended on by anything. While I had bigger plans for 'plugins',
only resources seemed to make it there. I didn't want to put
resources under the sandbox, because each subproject under 'plugins'
was supposed to be a separate jar.
I'm cool with what we've done with extras, but if we move resources
to the sandbox, then I propose we create a subproject under sandbox
called 'plugins' for this (and future) optional plugins. I suppose
the way it would work is if Commons Resources ever sees 1.0, then our
little resources plugin project can get promoted out of the sandbox
into 'extras'.
--
James Mitchell
EdgeTech, Inc.
http://edgetechservices.net/
678.910.8017
Skype: jmitchtx
On Jan 10, 2006, at 6:48 AM, Ted Husted wrote:
> Given the various API changes that are being discussed for
> CommonsResources,
>
> * http://tinyurl.com/8llr6
>
> we might not want to hold the rest of 1.3.0 until Resources is
> released.
>
> As and for an alternative, I suggest we move the classes that depend
> on Resources from Extras
>
> * http://struts.apache.org/struts-extras/apidocs/index.html
>
> to a sandbox Extras folder until Commons Message Resources is ready.
> As I remember, these are new-feature classes, and so moving them to
> the sandbox won't affect existing funcationality.
>
> -Ted.
>
>
> On 1/4/06, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
>> Done.
>>
>> Niall
>> ----- Original Message -----
>> From: "Wendy Smoak" <ws...@gmail.com>
>> Sent: Wednesday, January 04, 2006 4:09 PM
>>
>>
>> Also for 1.3 -- Niall (or another Resources committer) can you please
>> put commons-resources-1.0.0-RC1 in the internal repo so we can change
>> the Struts Extras build to depend on it?
>> http://cvs.apache.org/repository/commons-resources/jars/
>>
>> Thanks,
>> --
>> Wendy
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> --
> HTH, Ted.
> http://www.husted.com/poe/
>
> ---------------------------------------------------------------------
> 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: 1.3.0 Release - Next Steps
Posted by Christian Meder <ch...@absolutegiganten.org>.
On Tue, 2006-01-10 at 06:48 -0500, Ted Husted wrote:
> Given the various API changes that are being discussed for CommonsResources,
>
> * http://tinyurl.com/8llr6
>
> we might not want to hold the rest of 1.3.0 until Resources is released.
Agreed. IMO Resources doesn't feel like 1.0 material yet and Struts
1.3.0 is already cooking for too long.
But Niall has got an better Resources overview than me so perhaps he can
add his additional comments.
Greetings,
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
Given the various API changes that are being discussed for CommonsResources,
* http://tinyurl.com/8llr6
we might not want to hold the rest of 1.3.0 until Resources is released.
As and for an alternative, I suggest we move the classes that depend
on Resources from Extras
* http://struts.apache.org/struts-extras/apidocs/index.html
to a sandbox Extras folder until Commons Message Resources is ready.
As I remember, these are new-feature classes, and so moving them to
the sandbox won't affect existing funcationality.
-Ted.
On 1/4/06, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> Done.
>
> Niall
> ----- Original Message -----
> From: "Wendy Smoak" <ws...@gmail.com>
> Sent: Wednesday, January 04, 2006 4:09 PM
>
>
> Also for 1.3 -- Niall (or another Resources committer) can you please
> put commons-resources-1.0.0-RC1 in the internal repo so we can change
> the Struts Extras build to depend on it?
> http://cvs.apache.org/repository/commons-resources/jars/
>
> Thanks,
> --
> Wendy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Done.
Niall
----- Original Message -----
From: "Wendy Smoak" <ws...@gmail.com>
Sent: Wednesday, January 04, 2006 4:09 PM
Also for 1.3 -- Niall (or another Resources committer) can you please
put commons-resources-1.0.0-RC1 in the internal repo so we can change
the Struts Extras build to depend on it?
http://cvs.apache.org/repository/commons-resources/jars/
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/4/06, Ted Husted <te...@gmail.com> wrote:
> Regardless, I'm thinking that we should rename the "acquiring.xml" to
> "downloads.xml", since that's the usual name, and the one I should
> have used in the first place.
Sounds fine to me. (I think I was the last person to publish
struts-site; I'll look at home to see if I have changes that aren't
checked in.)
Also for 1.3 -- Niall (or another Resources committer) can you please
put commons-resources-1.0.0-RC1 in the internal repo so we can change
the Struts Extras build to depend on it?
http://cvs.apache.org/repository/commons-resources/jars/
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/4/06, Ted Husted <te...@gmail.com> wrote:
> Regardless, I'm thinking that we should rename the "acquiring.xml" to
> "downloads.xml", since that's the usual name, and the one I should
> have used in the first place.
Done, so Maven will stop saying we haven't had any releases. The old
acquiring page will still be there until someone deletes it. A few
more sub-projects need their sites updated first.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 1/3/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 1/3/06, Ted Husted <te...@gmail.com> wrote:
> > Right now, we have blank running, but that's it.
>
> /svn/struts/current/build
> $ maven nightly
>
> was failing when it tried to copy struts-mailreader.war from
> /apps/shared/target. I changed that to apps/mailreader/target and
> added the cookbook app in r365794, so lets see what we get tonight.
That did the trick. :)
Meanwhile, I noticed that the online site is slightly different from
the one I just build here. For one thing, the online site has
"downloads" link again, but my local copy doesn't. SVN tells me that
I'm up to date, so I'm not sure why they would not be identical.
Regardless, I'm thinking that we should rename the "acquiring.xml" to
"downloads.xml", since that's the usual name, and the one I should
have used in the first place. Once 1.3.x is in play, I expect that the
Site downloads would become a portal to the subproject download pages
and a central place to discuss obtaining the source.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/3/06, Ted Husted <te...@gmail.com> wrote:
> So, what do we need to do to get the nightly builds running for the other Apps?
>
> Right now, we have blank running, but that's it.
/svn/struts/current/build
$ maven nightly
was failing when it tried to copy struts-mailreader.war from
/apps/shared/target. I changed that to apps/mailreader/target and
added the cookbook app in r365794, so lets see what we get tonight.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
So, what do we need to do to get the nightly builds running for the other Apps?
Right now, we have blank running, but that's it.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 12/6/05, Wendy Smoak <ws...@gmail.com> wrote:
> The release plan shows including struts-site.jar. There is no source
> code in 'site,' so that jar only contains a manifest. Ted, were you
> thinking of including the generated website in the release?
Yes, the citation to the JAR was just a copy glitch. The idea was to
include the website docs, if we can.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 12/20/05, Wendy Smoak <ws...@gmail.com> wrote:
> The result of 'maven multiproject:site', zipped up, is 17.5 MB.
I still can't get that goal to run, so I've been building the ones I
work on individually.
--
E:\projects\Apache\struts\flow\src\java\org\apache\struts\flow\core\javascript\f
om\PageLocalScopeImpl.java:38: cannot find symbol
symbol : class Scriptable
location: class org.apache.struts.flow.core.javascript.fom.PageLocalScopeImpl
private Scriptable newObject() {
^
Note: E:\projects\Apache\struts\flow\src\java\org\apache\struts\flow\FlowAction.
java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
100 errors
BUILD FAILED
File...... C:\Documents and Settings\ted_2\.maven\cache\maven-multiproject-plugi
n-1.3.1\plugin.jelly
Element... maven:reactor
Line...... 103
Column.... 9
Unable to obtain goal [site] -- C:\Documents and Settings\ted_2\.maven\cache\mav
en-java-plugin-1.5\plugin.jelly:63:48: <ant:javac> Compile failed; see the compi
ler error output for details.
Total time: 4 minutes 51 seconds
Finished at: Tue Dec 20 09:16:35 EST 2005
E:\projects\Apache\struts\build>
I've tried it from my root of Struts current and /site, with the same result.
--
> What did you have in mind to include?
If each of the other subproject distributions include their own
website documentation, like Struts Scripting does, then all we really
need to do is to zip the top-level site docs for the actual site
subproject (as opposed to the multiproject "site" maven goal). If we
did want to include the rest of the site, we wouldn't need to drag
down the site archives. The links to those could be direct to the
website rather than relative.
I'm copying the live website to a local directory now. I'd like to do
a thorough review of what we do have online now and see if there is
any cruft we can remove. (Like some of the legacy JARs from when we
used to burst the WARs.)
But, overall, in terms of the 1.3.0 release, we're mainly waiting on
Message Resources, yes?
If that happens, and #37301 and #37730 are still open, I'd say we
should pull the new Enhanced DynaActionForm feature and roll it.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/12/05, Ted Husted <te...@gmail.com> wrote:
> If we think the problem is the tests, rather than the code, then I
> don't believe that the issue should affect whether we release.
That's what I think. I've had 1.3.0-dev in production since
mid-September and the app uses most of the Struts-EL HTML tags.
Either the code changed out from under the tests, or it's just a
Maven/Cactus misconfiguration.
earlier, Ted wrote:
> The idea was to include the website docs, if we can.
All of it? The result of 'maven multiproject:site', zipped up, is
17.5 MB. (That includes the old api docs and all of the Maven
reports, though.) For comparison, the struts-documentation.war is
around 5 MB.
I've made some progress on PDFs, but the PDF plugin is not
multiproject aware so it's one PDF per sub-project (and the relative
links don't work.)
What did you have in mind to include?
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
If we think the problem is the tests, rather than the code, then I
don't believe that the issue should affect whether we release.
I might try to setup some webtests for the Taglib Exercises and
Cookbook, so that we still have automated tests for the tags.
I'm still twiddling with the MailReader tour page, but what's there is
OK. I think it's just a matter of resolving Commons Resources.
-Ted.
On 12/11/05, Wendy Smoak <ws...@gmail.com> wrote:
> On 12/6/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> > The Cactus tests for EL are still a problem, but I haven't gotten
> > anywhere with them. I'm planning to try again this weekend.
>
> I looked at this again, and I still don't see anything wrong with the
> tags. Unfortunately I still haven't figured out why 'maven
> cactus:test' is failing, either.
>
> Maybe if some of you are bored in between sessions in San Diego, you
> can take a look. :)
>
> (I *think* I might have reclaimed my inbox from Bugzilla, I'm afraid
> to look again...)
>
> --
> Wendy
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/6/05, Wendy Smoak <ws...@gmail.com> wrote:
> The Cactus tests for EL are still a problem, but I haven't gotten
> anywhere with them. I'm planning to try again this weekend.
I looked at this again, and I still don't see anything wrong with the
tags. Unfortunately I still haven't figured out why 'maven
cactus:test' is failing, either.
Maybe if some of you are bored in between sessions in San Diego, you
can take a look. :)
(I *think* I might have reclaimed my inbox from Bugzilla, I'm afraid
to look again...)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
Coming back around to the pending 1.3 release...
It looks like Commons Resources is coming along well, thanks to Niall,
Rahul and Christian.
Laurie, can we please have an update on Bug 37730 and the Enhanced
DynaActionForm addition in general? 37301 is also still open.
Thanks!
The Cactus tests for EL are still a problem, but I haven't gotten
anywhere with them. I'm planning to try again this weekend. As part
of that, I'd like to restructure EL so that the Maven build is less
complicated. (Right now the source code for both the jar and the
example app is in the same directory.)
The release plan shows including struts-site.jar. There is no source
code in 'site,' so that jar only contains a manifest. Ted, were you
thinking of including the generated website in the release?
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/15/05, Ted Husted <te...@gmail.com> wrote:
> I've been through Apps, and it's looking quite good now. There were
> only very minor fixes to the pages, everything seems to be working
> well.
I have a few changes (Validator Plugin config to use the copy of
validator-rules in the struts-core jar) but if they miss Apps 1.3.0
it's not a big deal.
Some time back I started making sure the license/notice files were in
every artifact and I don't think I made it through the entire project.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Martin Cooper <ma...@apache.org>.
On 11/15/05, Ted Husted <te...@gmail.com> wrote:
>
> Is it even useful to tag a SVN repository for a release?
Yes, I believe it is. That way, it's more explicit, you can see the tags
under struts/tags in the repo, and you don't have to dig up the repo
revision number. It's also cheap - nothing actually gets copied unless it's
changed.
--
Martin Cooper
If we document the revision as of the release, then we can always go
> back and branch on that revision later, or retrieve a snapshot of the
> repository as of the release.
>
> -Ted.
>
> On 11/15/05, James Mitchell <ja...@mac.com> wrote:
> > Let's not forget about the updates needed to support all of our uses
> > of svn:exterals. Whenever we branch or tag (it is really just a
> > copy), we'll need to fix any svn:externals to point to the tagged/
> > branched versions since this is not automatically done for us.
> >
> > I just updated this page:
> >
> > http://wiki.apache.org/struts/StrutsMaintenanceSvn
> >
> > ...scroll to the bottom section.
> >
> > --
> > James Mitchell
> > 678.910.8017
> >
> >
> >
> >
> > On Nov 15, 2005, at 8:27 AM, Ted Husted wrote:
> >
> > > I've been through Apps, and it's looking quite good now. There were
> > > only very minor fixes to the pages, everything seems to be working
> > > well.
> > >
> > > Many thanks to Wendy and James and everyone who's been working on the
> > > Maven builds. It's all come together very nicely. IMHO, the process is
> > > more accessible, and it will be much easier for people to get involved
> > > in the project, or get involved again after being away for a while.
> > >
> > > As to remaining steps, I think all we need to do is
> > >
> > > (1) Make a final pass on the documentation and configuration files, to
> > > be sure all is current with the release plan.
> > >
> > > (2) Rename struts-core as struts-action.
> > >
> > > (3) Finalize what we are going to do with #36794 - the CG lib
> > > DynaForm enhancements.
> > >
> > > (4) Final updates the release notes as to recent changes.
> > >
> > > (5) Set 1.3.0 tags for each subproject (ACTION_1_3_0, APPS_1_3_0,
> > > EL_1_3_0, ...) .
> > >
> > > (6) Assembly a ZIP archive of the respective JARs as the "Struts
> > > Action Framework Library".
> > >
> > > (7) Post for review
> > >
> > > As to (3), one option is to move the code to the Extras subproject. We
> > > might also want to consider if we want to move some other optional
> > > classes there too. One candidate might be
> > > [org.apache.struts.validator.ValidatorActionForm], which is the "path"
> > > attribute version of ValidatorForm.
> > >
> > > Release caveats are that we have two dependencies on non-GA code:
> > > Commons Validator and Commons Resources. Commons Resources is being
> > > used as part of the Extras subproject. All I did was build the dev
> > > code from a nighly buid and post the JAR in the Apache repository. Is
> > > anyone up for a Commons Resources release?
> > >
> > > These caveats would keep a 1.3.0 release of Action Framework and
> > > Extras from going GA, but I think we anticipate additional changes
> > > anyway, so I don't see that they should keep us from rolling it.
> > >
> > > -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
Is it even useful to tag a SVN repository for a release?
If we document the revision as of the release, then we can always go
back and branch on that revision later, or retrieve a snapshot of the
repository as of the release.
-Ted.
On 11/15/05, James Mitchell <ja...@mac.com> wrote:
> Let's not forget about the updates needed to support all of our uses
> of svn:exterals. Whenever we branch or tag (it is really just a
> copy), we'll need to fix any svn:externals to point to the tagged/
> branched versions since this is not automatically done for us.
>
> I just updated this page:
>
> http://wiki.apache.org/struts/StrutsMaintenanceSvn
>
> ...scroll to the bottom section.
>
> --
> James Mitchell
> 678.910.8017
>
>
>
>
> On Nov 15, 2005, at 8:27 AM, Ted Husted wrote:
>
> > I've been through Apps, and it's looking quite good now. There were
> > only very minor fixes to the pages, everything seems to be working
> > well.
> >
> > Many thanks to Wendy and James and everyone who's been working on the
> > Maven builds. It's all come together very nicely. IMHO, the process is
> > more accessible, and it will be much easier for people to get involved
> > in the project, or get involved again after being away for a while.
> >
> > As to remaining steps, I think all we need to do is
> >
> > (1) Make a final pass on the documentation and configuration files, to
> > be sure all is current with the release plan.
> >
> > (2) Rename struts-core as struts-action.
> >
> > (3) Finalize what we are going to do with #36794 - the CG lib
> > DynaForm enhancements.
> >
> > (4) Final updates the release notes as to recent changes.
> >
> > (5) Set 1.3.0 tags for each subproject (ACTION_1_3_0, APPS_1_3_0,
> > EL_1_3_0, ...) .
> >
> > (6) Assembly a ZIP archive of the respective JARs as the "Struts
> > Action Framework Library".
> >
> > (7) Post for review
> >
> > As to (3), one option is to move the code to the Extras subproject. We
> > might also want to consider if we want to move some other optional
> > classes there too. One candidate might be
> > [org.apache.struts.validator.ValidatorActionForm], which is the "path"
> > attribute version of ValidatorForm.
> >
> > Release caveats are that we have two dependencies on non-GA code:
> > Commons Validator and Commons Resources. Commons Resources is being
> > used as part of the Extras subproject. All I did was build the dev
> > code from a nighly buid and post the JAR in the Apache repository. Is
> > anyone up for a Commons Resources release?
> >
> > These caveats would keep a 1.3.0 release of Action Framework and
> > Extras from going GA, but I think we anticipate additional changes
> > anyway, so I don't see that they should keep us from rolling it.
> >
> > -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/15/05, James Mitchell <ja...@mac.com> wrote:
> That would be a problem too because we would need a
> StrutsMaintenanceSvnCygwin, StrutsMainenanceSvnLinux.
You forgot Solaris. ;) I haven't found a problem using the
command-line instructions on Cygwin, so I doubt we'd need separate
instructions for each Unix-like type. Adding instructions for
TortoiseSVN should suffice *if* someone wants to write and maintain
them.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
That would be a problem too because we would need a
StrutsMaintenanceSvnCygwin, StrutsMainenanceSvnLinux.
The notes I added are more of a guideline than a recipe.
--
James Mitchell
678.910.8017
Skpe: jmitchtx
On Nov 15, 2005, at 1:12 PM, Niall Pemberton wrote:
> The only problem with these notes (and some Ted added on that page)
> is that
> they're unix specific and don't mean alot to me. Maybe we need a
> could of
> generic sections for things like this and then some additional
> pages for
> different environments. I use TortoiseSVN in a windoze environment and
> achieving the same thing invloves "right clicking" on the tag/
> branch root
> directory, selecting properties from the context menu, selecting the
> "subversion" tab and then editing the "svn:externals" property.
>
> How about pages like "StrutsMaintenanceUnix" and
> "StrusMaintenanceTortoiseSVN" pages for specific examples?
>
> Niall
>
> ----- Original Message -----
> From: "James Mitchell" <ja...@mac.com>
> Sent: Tuesday, November 15, 2005 5:59 PM
>
>
>> Let's not forget about the updates needed to support all of our uses
>> of svn:exterals. Whenever we branch or tag (it is really just a
>> copy), we'll need to fix any svn:externals to point to the tagged/
>> branched versions since this is not automatically done for us.
>>
>> I just updated this page:
>>
>> http://wiki.apache.org/struts/StrutsMaintenanceSvn
>>
>> ...scroll to the bottom section.
>
>
>
> ---------------------------------------------------------------------
> 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: 1.3.0 Release - Next Steps
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/15/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> The only problem with these notes (and some Ted added on that page) is that
> they're unix specific and don't mean alot to me.
Cygwin! I use TortoiseSVN, too, but sometimes it's easier to do
things at the command line.
I don't think anyone would object to adding instructions for how to do
things in other environments, though.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
The only problem with these notes (and some Ted added on that page) is that
they're unix specific and don't mean alot to me. Maybe we need a could of
generic sections for things like this and then some additional pages for
different environments. I use TortoiseSVN in a windoze environment and
achieving the same thing invloves "right clicking" on the tag/branch root
directory, selecting properties from the context menu, selecting the
"subversion" tab and then editing the "svn:externals" property.
How about pages like "StrutsMaintenanceUnix" and
"StrusMaintenanceTortoiseSVN" pages for specific examples?
Niall
----- Original Message -----
From: "James Mitchell" <ja...@mac.com>
Sent: Tuesday, November 15, 2005 5:59 PM
> Let's not forget about the updates needed to support all of our uses
> of svn:exterals. Whenever we branch or tag (it is really just a
> copy), we'll need to fix any svn:externals to point to the tagged/
> branched versions since this is not automatically done for us.
>
> I just updated this page:
>
> http://wiki.apache.org/struts/StrutsMaintenanceSvn
>
> ...scroll to the bottom section.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by James Mitchell <ja...@mac.com>.
Let's not forget about the updates needed to support all of our uses
of svn:exterals. Whenever we branch or tag (it is really just a
copy), we'll need to fix any svn:externals to point to the tagged/
branched versions since this is not automatically done for us.
I just updated this page:
http://wiki.apache.org/struts/StrutsMaintenanceSvn
...scroll to the bottom section.
--
James Mitchell
678.910.8017
On Nov 15, 2005, at 8:27 AM, Ted Husted wrote:
> I've been through Apps, and it's looking quite good now. There were
> only very minor fixes to the pages, everything seems to be working
> well.
>
> Many thanks to Wendy and James and everyone who's been working on the
> Maven builds. It's all come together very nicely. IMHO, the process is
> more accessible, and it will be much easier for people to get involved
> in the project, or get involved again after being away for a while.
>
> As to remaining steps, I think all we need to do is
>
> (1) Make a final pass on the documentation and configuration files, to
> be sure all is current with the release plan.
>
> (2) Rename struts-core as struts-action.
>
> (3) Finalize what we are going to do with #36794 - the CG lib
> DynaForm enhancements.
>
> (4) Final updates the release notes as to recent changes.
>
> (5) Set 1.3.0 tags for each subproject (ACTION_1_3_0, APPS_1_3_0,
> EL_1_3_0, ...) .
>
> (6) Assembly a ZIP archive of the respective JARs as the "Struts
> Action Framework Library".
>
> (7) Post for review
>
> As to (3), one option is to move the code to the Extras subproject. We
> might also want to consider if we want to move some other optional
> classes there too. One candidate might be
> [org.apache.struts.validator.ValidatorActionForm], which is the "path"
> attribute version of ValidatorForm.
>
> Release caveats are that we have two dependencies on non-GA code:
> Commons Validator and Commons Resources. Commons Resources is being
> used as part of the Extras subproject. All I did was build the dev
> code from a nighly buid and post the JAR in the Apache repository. Is
> anyone up for a Commons Resources release?
>
> These caveats would keep a 1.3.0 release of Action Framework and
> Extras from going GA, but I think we anticipate additional changes
> anyway, so I don't see that they should keep us from rolling it.
>
> -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: 1.3.0 Release - Next Steps
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Thanks Ted :-)
From: "Ted Husted" <te...@gmail.com>
On 11/15/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> Validator 1.2.0 has only received 2 +1 votes so far - and so needs at
least
> one more before I can cut a release. Don Brown did alot of the Validator
> 1.2.0 work and I am expecting he will vote (hopefully +1), but hes away on
> vacation at the moment. Anyway until it gets another Jakarta PMC member /
> Commons Commiter to +1 it, its basically stuck in release candidate limbo.
Done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
On 11/15/05, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> Validator 1.2.0 has only received 2 +1 votes so far - and so needs at least
> one more before I can cut a release. Don Brown did alot of the Validator
> 1.2.0 work and I am expecting he will vote (hopefully +1), but hes away on
> vacation at the moment. Anyway until it gets another Jakarta PMC member /
> Commons Commiter to +1 it, its basically stuck in release candidate limbo.
Done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Ted Husted" <te...@gmail.com>
Sent: Tuesday, November 15, 2005 1:27 PM
<snip>
Release caveats are that we have two dependencies on non-GA code:
Commons Validator and Commons Resources. Commons Resources is being
used as part of the Extras subproject. All I did was build the dev
code from a nighly buid and post the JAR in the Apache repository. Is
anyone up for a Commons Resources release?
These caveats would keep a 1.3.0 release of Action Framework and
Extras from going GA, but I think we anticipate additional changes
anyway, so I don't see that they should keep us from rolling it.
</snip>
Validator 1.2.0 has only received 2 +1 votes so far - and so needs at least
one more before I can cut a release. Don Brown did alot of the Validator
1.2.0 work and I am expecting he will vote (hopefully +1), but hes away on
vacation at the moment. Anyway until it gets another Jakarta PMC member /
Commons Commiter to +1 it, its basically stuck in release candidate limbo.
http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg69561.html
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 Release - Next Steps
Posted by Ted Husted <te...@gmail.com>.
I've been through Apps, and it's looking quite good now. There were
only very minor fixes to the pages, everything seems to be working
well.
Many thanks to Wendy and James and everyone who's been working on the
Maven builds. It's all come together very nicely. IMHO, the process is
more accessible, and it will be much easier for people to get involved
in the project, or get involved again after being away for a while.
As to remaining steps, I think all we need to do is
(1) Make a final pass on the documentation and configuration files, to
be sure all is current with the release plan.
(2) Rename struts-core as struts-action.
(3) Finalize what we are going to do with #36794 - the CG lib
DynaForm enhancements.
(4) Final updates the release notes as to recent changes.
(5) Set 1.3.0 tags for each subproject (ACTION_1_3_0, APPS_1_3_0,
EL_1_3_0, ...) .
(6) Assembly a ZIP archive of the respective JARs as the "Struts
Action Framework Library".
(7) Post for review
As to (3), one option is to move the code to the Extras subproject. We
might also want to consider if we want to move some other optional
classes there too. One candidate might be
[org.apache.struts.validator.ValidatorActionForm], which is the "path"
attribute version of ValidatorForm.
Release caveats are that we have two dependencies on non-GA code:
Commons Validator and Commons Resources. Commons Resources is being
used as part of the Extras subproject. All I did was build the dev
code from a nighly buid and post the JAR in the Apache repository. Is
anyone up for a Commons Resources release?
These caveats would keep a 1.3.0 release of Action Framework and
Extras from going GA, but I think we anticipate additional changes
anyway, so I don't see that they should keep us from rolling it.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 -- stalled
Posted by Ted Husted <te...@gmail.com>.
On 7/29/05, Michael Jouravlev <jm...@gmail.com> wrote:
> Is 1.3.0 supposed to be a bugfix release only (plus Chains) ?
No, the internal structure of the Request Processor has been revamped,
and new features, like "extends", have been added. Stuts Classic
1.3.0 represents our fouth release series.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 -- stalled
Posted by Michael Jouravlev <jm...@gmail.com>.
Is 1.3.0 supposed to be a bugfix release only (plus Chains) ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: 1.3.0 -- stalled
Posted by Ted Husted <te...@gmail.com>.
I suppose I could step up and do it. I'll post a release plan
checklist later today.
Something that's worked for me in the past is to take a team approach
to releases. There's no reason why one person has to do every point on
the checklist. I'll modify the list so that different people can sign
up for different tasks, if they like, and I'll do the rest.
-Ted.
On 7/28/05, James Mitchell <jm...@apache.org> wrote:
> It looks like I won't have the time that I thought I had to get 1.3.0
> cut and rolled out any time soon. My day job is heating up and the
> kids soccer season starts up very soon. I'm also running 2 local
> user groups (web-atlanta and jboss-atlanta) and participating in a
> new architects group (IASA).
>
> I wish I had more time to do this, but I just don't have the time I
> need to do it right. If someone else wants to take the reigns and
> run, I'd be very appreciative.....Wendy?
>
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org