Quick update: The dojo separation is looking easier than I thought. I
plan to finish it tomorrow, however, it requires the latest xwork so
we should probably put it after 2.0.2. It is looking pretty good for
plugins that want to create a new struts-dependent tag library and
want their tags to
On 12/29/06, mraible [EMAIL PROTECTED] wrote:
Do you know know of a better example that uses Confluence for its
documentation?
If you find one let me know, and we'll use it too. :)
A lot of ASF projects use Confluence more and more everyday, and
developing a fully automatic release procedure
:) The first rule of cwiki is don't link to cwiki :)
Please refer to the autoexport URL instead .
* http://cwiki.apache.org/S2PLUGINS/
All we need now is a Maven plugin that install Struts plugins :)
-Ted.
On 12/29/06, Don Brown [EMAIL PROTECTED] wrote:
Before Struts 2 goes GA, I think it
On 12/28/06, Don Brown [EMAIL PROTECTED] wrote:
I think the rule of thumb here should be if you require any additional
tag attributes, then the tag should be in its own tag library. If
followed fully, this would put our xhtml theme in its own tag library,
which if we could ignore backward
On 12/30/06, Ted Husted [EMAIL PROTECTED] wrote:
We are quite close. The autoexport plugin automatically maintains the
HTML version, and a cron job zips it up. The problematic part is
merging the HTML download with the other documentation on the site
that is generated from other sources. It's
The method:
@Inject(StrutsConstants.STRUTS_I18N_ENCODING)
public void setEncoding(String encoding) {
this.encoding = encoding;
}
on FreemarkerManager is never called, that's why it isn't getting the
encoding from struts.18n.encoding. I logged WW-1582 to track it. No idea
how to
[From Tag Reorganization thread]
On 12/30/06, Don Brown [EMAIL PROTECTED] wrote:
Quick update: The dojo separation is looking easier than I thought. I
plan to finish it tomorrow, however, it requires the latest xwork so
we should probably put it after 2.0.2. It is looking pretty good for
That would work fine for the jsp tags, but we wouldn't/couldn't use the
same prefix for Velocity and Freemarker tags since the prefix isn't user
customizable. My quick glance through the tags shows that the Ajax tags
are mainly their own tags, and at least as of yet, I haven't found a
case
Hmm...I'm seeing it being called. Are you sure it isn't being called,
or perhaps it just isn't using the value correctly?
Don
Musachy Barroso wrote:
The method:
@Inject(StrutsConstants.STRUTS_I18N_ENCODING)
public void setEncoding(String encoding) {
this.encoding = encoding;
}
The change I made to xwork is a very minor, internal Guice improvement
that should have no impact on its GA release. I haven't checked with
Rainer lately, but I'd imagine XWork 2.0 could go final very soon.
As for branching for 2.1, yeah, we could do that. I was thinking of
doing the ajax
Don Brown wrote:
The change I made to xwork is a very minor, internal Guice improvement
that should have no impact on its GA release. I haven't checked with
Rainer lately, but I'd imagine XWork 2.0 could go final very soon.
I spoke with him at Javapolis, and I believe everything was ready to
On 12/30/06, Don Brown [EMAIL PROTECTED] wrote:
The change I made to xwork is a very minor, internal Guice improvement
that should have no impact on its GA release. I haven't checked with
Rainer lately, but I'd imagine XWork 2.0 could go final very soon.
As for branching for 2.1, yeah, we
It is an interesting idea, but the showstoppers for me are:
* All the bugs that have been fixed since then
* The documentation would be completely wrong as it is for 2.0.2
* XWork trunk might not even work with 2.0.1
I think we are 95% of the way to a GA release and really do think it
could be
I set breakpoints, and trying the autocompleter page in showcase, it
never stops on the setter method. Setting a breakpoint on
createConfiguration, I see that encoding is null. If the encoding is
being injected properly, the charset of this page:
I'm perfectly willing to backport the bugfixes, and the Struts
documentation is bundled with the release. We'd just have to patch the
release notes pages with any updates.
The XWork trunk does not work with the current release, so we would
have to branch XWork too, and increment its head as
Ted Husted wrote:
I'm perfectly willing to backport the bugfixes, and the Struts
documentation is bundled with the release. We'd just have to patch the
release notes pages with any updates.
Unfortunately, I don't believe that is possible, and really, it would be
counter-productive. There as
On 12/30/06, Don Brown [EMAIL PROTECTED] wrote:
I'd feel a lot better if XWork would move to the milestone release
that we use, and Tomcat uses, and HTTPD uses, and MySQL uses, to name
a few. This hand-over-hand approach, that continually dooms Struts
releases to beta status is a frustrating
17 matches
Mail list logo
