Author: mrdon
Date: Fri Mar 24 22:34:47 2006
New Revision: 388713
URL: http://svn.apache.org/viewcvs?rev=388713&view=rev
Log:
Splitting the build so that the standard build doesn't retrieve LGPL jars or
compile related code. This should allow
us to keep the integration code.
Modified:
incu
On 3/24/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> At 3:34 PM -0500 3/24/06, Frank W. Zammetti wrote:
> >The 2 seems more than unnecessary... my gut feeling is it is the
> >kind of decision that everyone will be lamenting down the road. My
> >suggestion would be to come up with something that
Author: mrdon
Date: Fri Mar 24 20:34:57 2006
New Revision: 388701
URL: http://svn.apache.org/viewcvs?rev=388701&view=rev
Log:
Removing unnecessary lib directories
Removed:
incubator/webwork2/lib/build/
incubator/webwork2/lib/plugin/
--
Frank W. Zammetti wrote:
+1 (non-binding) here. If I had my druthers I would have gone with
"saf", but "ti" works for me too, no objection.
I don't understand. Why not just use webwork if it comes to that, rather
than saf or ti. At least that acknowledges the heritage of the thing.
Jonathan
Author: rgielen
Date: Fri Mar 24 10:46:49 2006
New Revision: 388601
URL: http://svn.apache.org/viewcvs?rev=388601&view=rev
Log:
Adjusted IDEA files
Modified:
incubator/webwork2/WebWork.iml
incubator/webwork2/WebWork.ipr
Modified: incubator/webwork2/WebWork.iml
URL:
http://svn.apache.org
Author: husted
Date: Fri Mar 24 20:08:09 2006
New Revision: 388698
URL: http://svn.apache.org/viewcvs?rev=388698&view=rev
Log:
Action2 Apps
* Mailreader - Work in progress
Modified:
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/MailreaderSupport.java
struts/san
Author: mrdon
Date: Fri Mar 24 20:05:22 2006
New Revision: 388697
URL: http://svn.apache.org/viewcvs?rev=388697&view=rev
Log:
Removing empty directories
Removed:
incubator/webwork2/lib/build/jalopy/
incubator/webwork2/lib/core/
incubator/webwork2/lib/example/
incubator/webwork2/li
Author: mrdon
Date: Fri Mar 24 19:49:18 2006
New Revision: 388696
URL: http://svn.apache.org/viewcvs?rev=388696&view=rev
Log:
Readding the Pell fileupload. I believe we can keep the LGPL code, just not
ship its jars and mark them as optional
Added:
incubator/webwork2/src/java/org/apache/st
Author: mrdon
Date: Fri Mar 24 19:08:15 2006
New Revision: 388693
URL: http://svn.apache.org/viewcvs?rev=388693&view=rev
Log:
Removing the Pell implementation of file upload. According to Jason
Pell's page -
http://www.geocities.com/jasonpell/programs.html#multipartrequest - the
code is under the
Author: mrdon
Date: Fri Mar 24 19:01:50 2006
New Revision: 388692
URL: http://svn.apache.org/viewcvs?rev=388692&view=rev
Log:
Removing the fileupload-cos dependency. This fileupload implementation
used code from servlets.com, which is under an unfriendly license -
http://servlets.com/cos/license.
>>I don't see the problem with Action2 either. Hopefully, we will
>>someday see an Action3 and Action4 too.
I hope I wasn't too brisk :-) But I prefer "action2" because it
describes what it is clearly, and I think you cannot dream up of a more
perfect package name. Names like "ti" or "saf" is toug
I don't see the problem with Action2 either. Hopefully, we will
someday see an Action3 and Action4 too.
But, regardless of what I think, I would suggest that we wait a few
days and give the other new committers a chance to chime in. Ian
indicated a preference for saf, and the other new committers
So, "Struts", "Struts Action 2", "ti" and "a" instead of "WebWork",
"WebWork", "webwork" and "ww". New name system is definetely an
improvent consistency-wise.
I don't like "ti", but I think I have different reasons than Paul. On
the other hand, why should I care at all?
On 3/24/06, Paul Benedict
Oh no. Please don't call it ti. It makes perfect sense
to use the org.apache.struts.action2 package; that fits
perfectly with its name plus, it fits the spring framework
naming strategy (they have a hibernate and hibernate3 package).
But i think "ti" is a terrible name; don't settle for it.
--- Do
+1 (non-binding) here. If I had my druthers I would have gone with
"saf", but "ti" works for me too, no objection.
Frank
Don Brown wrote:
Ok, after listening to all the feedback, here is my revised renaming
strategy proposal:
- com.opensymphony.webwork package -> org.apache.struts.ti
- WebW
Ok, after listening to all the feedback, here is my revised renaming
strategy proposal:
- com.opensymphony.webwork package -> org.apache.struts.ti
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
-
Michael Jouravlev wrote:
On 3/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Joe Germuska wrote:
I'm not extremely fond of the number myself.
Tomcat used "catalina" to denote a major change in direction -- maybe we
could use a name ("ti"? not sure how I feel about that either).
That's n
I think a: is just fine. Besides, this is totally a developer's
preference anyway since he controls the prefix. I am +1 for a:
--- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> The 2 seems more than unnecessary... my gut feeling is it is the kind of
> decision that everyone will be lamenting
On 3/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Joe Germuska wrote:
> > I'm not extremely fond of the number myself.
> >
> > Tomcat used "catalina" to denote a major change in direction -- maybe we
> > could use a name ("ti"? not sure how I feel about that either).
>
> That's not a bad
Joe Germuska wrote:
I'm not extremely fond of the number myself.
Tomcat used "catalina" to denote a major change in direction -- maybe we
could use a name ("ti"? not sure how I feel about that either).
That's not a bad idea either... "ti" as you said makes sense... The
other name that has m
At 3:34 PM -0500 3/24/06, Frank W. Zammetti wrote:
The 2 seems more than unnecessary... my gut feeling is it is the
kind of decision that everyone will be lamenting down the road. My
suggestion would be to come up with something that does not indicate
a version of any sort, and that would chan
I kinda like the "saf" option.
/Ian
Frank W. Zammetti wrote:
The 2 seems more than unnecessary... my gut feeling is it is the kind
of decision that everyone will be lamenting down the road. My
suggestion would be to come up with something that does not indicate a
version of any sort, and t
On Mar 24, 2006, at 1:21 PM, Michael Jouravlev wrote:
On 3/24/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
I hate using things like "action2" in a name. It's like admitting
that we're going to have to change it someday. May as well put
"temp" in the name.
You have not used COM for Windows,
The 2 seems more than unnecessary... my gut feeling is it is the kind of
decision that everyone will be lamenting down the road. My suggestion
would be to come up with something that does not indicate a version of
any sort, and that would change the package names as well. I'm not sure
I have
On 3/24/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> On 3/24/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > I've renamed the WebWork packages, and both the code compiles and all
> > tests pass correctly. However, as I start with the greater renaming
> > task, I thought I'd propose a strategy a
On 3/24/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
> I hate using things like "action2" in a name. It's like admitting
> that we're going to have to change it someday. May as well put
> "temp" in the name.
You have not used COM for Windows, have you? ;-)
Michael.
--
Author: husted
Date: Fri Mar 24 11:17:20 2006
New Revision: 388610
URL: http://svn.apache.org/viewcvs?rev=388610&view=rev
Log:
ActionAction2 Apps
* Try the a2 taglib prefix on for size.
Modified:
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp
struts/san
On Mar 24, 2006, at 12:56 PM, Don Brown wrote:
I've renamed the WebWork packages, and both the code compiles and
all tests pass correctly. However, as I start with the greater
renaming task, I thought I'd propose a strategy and get some
feedback on it:
I hate using things like "action2"
On 3/24/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I've renamed the WebWork packages, and both the code compiles and all
> tests pass correctly. However, as I start with the greater renaming
> task, I thought I'd propose a strategy and get some feedback on it:
>
> - WebWork* classes -> Action2* c
I've renamed the WebWork packages, and both the code compiles and all
tests pass correctly. However, as I start with the greater renaming
task, I thought I'd propose a strategy and get some feedback on it:
- WebWork* classes -> Action2* classes
- WebWork in comments and documentation -> Struts
Hi there,
Please let me know if this is a "user list" question and I can take it
there.
I was looking at the SVN changes for JavascriptValidatorTag through the
web interface (to see what changes made it into 1.2.9):
revision 383907 on struts/taglib/trunk has an accompanying
http://svn.apache
Once you have your Apache account created and karma granted, you'll need
to set your Subversion password before you can start working with the
code. Log into people.apache.org and type 'svnpasswd'. Subversion has
the advantage over CVS of separating accounts from system accounts. For
more in
Author: mrdon
Date: Fri Mar 24 10:02:46 2006
New Revision: 388591
URL: http://svn.apache.org/viewcvs?rev=388591&view=rev
Log:
Changing tag prefix to a2 from ww
Modified:
incubator/webwork2/src/xdt/taglib_tld.xdt
Modified: incubator/webwork2/src/xdt/taglib_tld.xdt
URL:
http://svn.apache.org/
On 3/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> Don't we want these going to [EMAIL PROTECTED] rather than
> dev@ (but with the reply to set to dev@, as it now is)?
Yup. See my reply to Wendy's message on the same topic.
--
Martin Cooper
-Ted.
>
> -- Forwarded message --
I've checked in the change to the SVN mailer. I'm not sure if there's
anything else I need to do, but I'll ask.
--
Martin Cooper
On 3/24/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>
> Can the commit messages for the code in the incubator be directed to
> [EMAIL PROTECTED] instead of dev@ directl
Congratulations! Great job, guys!
Greg
On Mar 23, 2006, at 7:54 PM, Don Brown wrote:
The WebWork team has successfully completed WebWork 2.2.2, which
was immediately imported into the WebWork 2 Incubator podling.
Here is the current status:
- The code is at https://svn.apache.org/repos/as
Don't we want these going to [EMAIL PROTECTED] rather than
dev@ (but with the reply to set to dev@, as it now is)?
-Ted.
-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Mar 23, 2006 9:21 PM
Subject: svn commit: r388331 - in /incubator/webwork2/docs: ...
T
Can the commit messages for the code in the incubator be directed to
[EMAIL PROTECTED] instead of dev@ directly?
Thanks,
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Author: husted
Date: Fri Mar 24 05:25:41 2006
New Revision: 388518
URL: http://svn.apache.org/viewcvs?rev=388518&view=rev
Log:
Welcoem page
* Correct link
Modified:
struts/site/trunk/xdocs/index.xml
Modified: struts/site/trunk/xdocs/index.xml
URL:
http://svn.apache.org/viewcvs/struts/site/
Author: husted
Date: Fri Mar 24 05:20:26 2006
New Revision: 388517
URL: http://svn.apache.org/viewcvs?rev=388517&view=rev
Log:
Welcome page
* Remove non-sequitor
Modified:
struts/site/trunk/xdocs/index.xml
Modified: struts/site/trunk/xdocs/index.xml
URL:
http://svn.apache.org/viewcvs/struts
Author: husted
Date: Fri Mar 24 05:11:41 2006
New Revision: 388513
URL: http://svn.apache.org/viewcvs?rev=388513&view=rev
Log:
Kickstart FAQ / Who We Are / STATUS
* Update for latest WebWork developments
Kickstart FAQ
* Move subproject/extension FAQs lower, since we may be condensing the Action 1
On 3/24/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> With maven 1 you run maven jar:install on the "action" sub-project -
> that should create the jar and install it in your local maven
> repository. Then you can go on and build the taglib sub-project and it
> should find the action jar.
>
> Th
With maven 1 you run maven jar:install on the "action" sub-project -
that should create the jar and install it in your local maven
repository. Then you can go on and build the taglib sub-project and it
should find the action jar.
Theres been a long standing policy of "only HTML 4 attributes" will
CAn anyone give me a crash course on how I can test my changes? I've
made the modifications I need to make, and added the unit tests.. The
maven 2 build is complaining it cant download
http://cvs.apache.org/repository/struts/jars/struts-action-1.3.1-SNAPSHOT.jar
I've been lazy, cd taglibs and the
> I know that autocomplete is a non standard attribute so might
> not be accepted as a patch on the taglib. But if it only
> rendered if specified then it wouldn't force users to use non
> standard stuff.
JSF 1.2 goes the same route. The autocomplete attribute has been
added to component by E
hello
We've got an app built already in production, and the issue of
autocompletion has come up. For now a simple
window.onload = function() {
var form = document.forms['formName'];
form.setAttribute("autocomplete","off");
}
works okay, but patching the taglib to support autocomplete seems
46 matches
Mail list logo
