On 1/16/06, Ted Husted [EMAIL PROTECTED] 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
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
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
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
On 1/17/06, Ted Husted [EMAIL PROTECTED] 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
On 1/17/06, Ted Husted [EMAIL PROTECTED] 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
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
On 1/17/06, Wendy Smoak [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional
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 [EMAIL PROTECTED] wrote:
Bug# 37301 looks like an enhancement request to me... I don't think it
should prevent a
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
On 1/13/06, Frank W. Zammetti [EMAIL PROTECTED] 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
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
On 1/11/06, Martin Cooper [EMAIL PROTECTED] 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
On 1/12/06, Ted Husted [EMAIL PROTECTED] 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
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:
On 1/11/06, Ted Husted [EMAIL PROTECTED] wrote:
On 1/11/06, James Mitchell [EMAIL PROTECTED] 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
On 1/4/06, Ted Husted [EMAIL PROTECTED] 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
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
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
On 1/10/06, Ted Husted [EMAIL PROTECTED] 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 1/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 1/3/06, Ted Husted [EMAIL PROTECTED] 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
On 1/4/06, Ted Husted [EMAIL PROTECTED] 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
Done.
Niall
- Original Message -
From: Wendy Smoak [EMAIL PROTECTED]
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
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
On 12/20/05, Wendy Smoak [EMAIL PROTECTED] 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
On 12/12/05, Ted Husted [EMAIL PROTECTED] 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
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
On 12/6/05, Wendy Smoak [EMAIL PROTECTED] 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
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
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
- Original Message -
From: Ted Husted [EMAIL PROTECTED]
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
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:
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 [EMAIL PROTECTED] wrote:
Let's not
On 11/15/05, Niall Pemberton [EMAIL PROTECTED] 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
On 11/15/05, Ted Husted [EMAIL PROTECTED] 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
Thanks Ted :-)
From: Ted Husted [EMAIL PROTECTED]
On 11/15/05, Niall Pemberton [EMAIL PROTECTED] 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
On 11/15/05, Niall Pemberton [EMAIL PROTECTED] 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
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
On 11/15/05, James Mitchell [EMAIL PROTECTED] 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
On 11/15/05, Ted Husted [EMAIL PROTECTED] 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
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
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
Sure, go ahead. Thanks,
Don
Niall Pemberton wrote:
On 10/27/05, Don Brown [EMAIL PROTECTED] 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.
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
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
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
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
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
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
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!).
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
On 9/13/05, Ted Husted [EMAIL PROTECTED] 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
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
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
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,
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
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
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
From: James Mitchell [EMAIL PROTECTED]
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
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
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
On 9/2/05, Wendy Smoak [EMAIL PROTECTED] 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,
On 8/23/05, Hubert Rabago [EMAIL PROTECTED] 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/
On 8/27/05, Ted Husted [EMAIL PROTECTED] 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: [EMAIL
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, [EMAIL PROTECTED] [EMAIL PROTECTED]
From: Ted Husted [EMAIL PROTECTED]
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
On 8/24/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: Ted Husted [EMAIL PROTECTED]
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
On 8/22/05, Wendy Smoak [EMAIL PROTECTED] 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
On 8/23/05, Ted Husted [EMAIL PROTECTED] wrote:
On 8/22/05, Wendy Smoak [EMAIL PROTECTED] 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
On 8/22/05, Wendy Smoak [EMAIL PROTECTED] 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
On 8/23/05, Ted Husted [EMAIL PROTECTED] 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. :)
On 8/23/05, Ted Husted [EMAIL PROTECTED] 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
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
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: [EMAIL PROTECTED]
Skype: jmitchtx
On Aug 22,
On 8/22/05, Wendy Smoak [EMAIL PROTECTED] 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
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
From: Hubert Rabago [EMAIL PROTECTED]
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
On 8/22/05, Wendy Smoak [EMAIL PROTECTED] 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
On 8/22/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: Hubert Rabago [EMAIL PROTECTED]
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
From: Hubert Rabago [EMAIL PROTECTED]
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
From: Ted Husted [EMAIL PROTECTED]
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?
On 8/22/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: Ted Husted [EMAIL PROTECTED]
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,
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
From: Ted Husted [EMAIL PROTECTED]
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
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
From: Joe Germuska [EMAIL PROTECTED]
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
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
That sounds great, Wendy. Thanks!
On 8/17/05, Wendy Smoak [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
On 8/1/05, Hubert Rabago [EMAIL
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
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
From: Joe Germuska [EMAIL PROTECTED]
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
On 8/16/05, Wendy Smoak [EMAIL PROTECTED] wrote:
Did you have to do any cleanup on the generated tlds?
Nope.
-T.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For
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
From: Ted Husted [EMAIL PROTECTED]
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
At 2:01 PM -0400 8/15/05, Ted Husted wrote:
On 8/15/05, Wendy Smoak [EMAIL PROTECTED] 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
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
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
On 8/8/05, Ted Husted [EMAIL PROTECTED] 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
1 - 100 of 106 matches
Mail list logo
