Menu
▾
▴
webwork-devel — WebWork development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(316) |
Dec
(117) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(197) |
Feb
(229) |
Mar
(293) |
Apr
(177) |
May
(84) |
Jun
(40) |
Jul
(43) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: matt b. <ba...@us...> - 2002-03-03 03:31:18
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/helloworld In directory usw-pr-cvs1:/tmp/cvs-serv5809 Modified Files: HelloWorld.java Login.java LoginStatus.java Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:31:10
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/events In directory usw-pr-cvs1:/tmp/cvs-serv5775 Modified Files: Login.java LoginCounter.java Logout.java NameEditor.java PasswordEditor.java Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:31:00
|
Update of /cvsroot/webwork/webwork/src/main/webwork/examples/bank In directory usw-pr-cvs1:/tmp/cvs-serv5736 Modified Files: AccountEditor.java AmountEditor.java NameEditor.java Transfer.java Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:30:35
|
Update of /cvsroot/webwork/webwork/src/main/webwork/core/dispatcher In directory usw-pr-cvs1:/tmp/cvs-serv5682 Modified Files: CachingViewMapping.java ClientServletDispatcher.java ConfigurationViewMapping.java DefaultViewMapping.java ServletDispatcher.java TestDispatcher.java ViewMapping.java Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:30:25
|
Update of /cvsroot/webwork/webwork/src/main/webwork/core/config In directory usw-pr-cvs1:/tmp/cvs-serv5655 Modified Files: Configuration.java DefaultConfiguration.java DelegatingConfiguration.java PropertiesConfiguration.java XMLActionConfiguration.java Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:30:16
|
Update of /cvsroot/webwork/webwork/src/main/webwork/core/action/standard In directory usw-pr-cvs1:/tmp/cvs-serv5637 Modified Files: CardPane.java ClientInfo.java JSP.java Redirect.java Script.java XML.java Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:29:54
|
Update of /cvsroot/webwork/webwork/src/main/webwork/core/action/client In directory usw-pr-cvs1:/tmp/cvs-serv5518 Modified Files: ActionResult.java ClientDispatcher.java Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:29:22
|
Update of /cvsroot/webwork/webwork/src/main/webwork In directory usw-pr-cvs1:/tmp/cvs-serv5419 Modified Files: default.properties log4j.properties Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:29:04
|
Update of /cvsroot/webwork/webwork/src/lib/examples In directory usw-pr-cvs1:/tmp/cvs-serv5326 Added Files: crimson.jar jdom.jar Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:28:31
|
Update of /cvsroot/webwork/webwork/src/lib In directory usw-pr-cvs1:/tmp/cvs-serv5280 Removed Files: crimson.jar jdom.jar Log Message: finishing refactoring |
|
From: matt b. <ba...@us...> - 2002-03-03 03:27:19
|
Update of /cvsroot/webwork/webwork/src/docs In directory usw-pr-cvs1:/tmp/cvs-serv5132 Modified Files: index.xml install.xml Log Message: no message |
|
From: matt b. <ba...@us...> - 2002-03-03 03:26:59
|
Update of /cvsroot/webwork/webwork/src/build In directory usw-pr-cvs1:/tmp/cvs-serv5083 Modified Files: build.xml Log Message: no message |
|
From: matt b. <ba...@us...> - 2002-03-03 03:26:36
|
Update of /cvsroot/webwork/webwork In directory usw-pr-cvs1:/tmp/cvs-serv5025 Modified Files: WebWork.ipr Log Message: no message |
|
From: Matt B. <ma...@sm...> - 2002-03-03 03:23:41
|
The main idea/hope was to allow releases of individual view jar (it would contain everything minus the other views). This would, for instance, allow a velocity release without waiting on taglib, etc. But, I think it is best to leave it as is now. I have finished fixing/testing everything except Velocity. I will try and get on that tomorrow unless someone wants to beat me to it :). I will post everything shortly. The only package change in main was view and examples. The major change was on the web side and just basic cleanup dist, build. -Matt ----- Original Message ----- From: "Maurice Parker" <Ma...@Vi...> To: <ma...@sm...> Cc: <kje...@mo...>; <vsa...@ho...>; <web...@li...> Sent: Saturday, March 02, 2002 5:15 PM Subject: Re: [Webwork-devel] RE: Refactorings... Again > Matt, > > On Friday, March 1, 2002, at 09:15 AM, ma...@sm... wrote: > > > Separating out the views allows incremental releases to support separate > > views. It is not whether they are causing end user problems. I think the > > separation is important. People can grap one jar for all view support or > > an individual jar. This will allow the different views to release > > independently. > > Where did the perception that we need to release the views separate from > the Action engine come from? None of the view technologies have ever held > up the release. Just what exactly is the problem that you are trying to > solve? > > Splitting WebWork into 4 parts is only going to confuse people and make it > more difficult for them to know which parts are compatible. Do you think > we can coordinate 4 separate releases when we can't even get 1.0 out the > door? > > -Maurice > > > |
|
From: Peter D. <pe...@ap...> - 2002-03-03 00:01:52
|
Hi, Recently some Apache projects have started using XDoclet. And thus XDoclet was added to GUMP runs. GUMP is our nightly build/continuous integration tool. See http://jakarta.apache.org/gump for details. As XDoclet depends on webwork we have been building webwork for a few weeks aswell. The latest run can be see at http://jakarta.apache.org/builds/gump/latest/webwork.html We use the tool to check compatability between latest versions of libraries. And it can pick up changes early and warn people of them. For instance changes in webwork made it impossible to build with latest XDoclet. See http://jakarta.apache.org/builds/gump/latest/xdoclet-examples.html Hopefully the XDoclet people will now fix this up quicker due to early warning. Anyways I was writing to you to see if you would like "nags" to be sent out to a webwork mailing list or something. It would allow to be notified when a nightly build fails or one of the librarys you depend upon changes. Usually we send it the develoeprs mailing list -- Cheers, Pete *------------------------------------------------------* | "Common sense is the collection of prejudices | | acquired by age 18. " -Albert Einstein | *------------------------------------------------------* |
|
From: Mike Cannon-B. <mi...@at...> - 2002-03-02 23:42:47
|
Here here! I don't see why the views even need to be in a separate JAR, I don't mind the extra 30k that the velocity views give me by having them in the main JAR - they don't cause any problems if I don't want to use them, but they make it easier if I do? My $0.02 - lots of JARs make things confusing. -mike On 3/3/02 10:15 AM, "Maurice Parker" (Ma...@Vi...) penned the words: > Matt, > > On Friday, March 1, 2002, at 09:15 AM, ma...@sm... wrote: > >> Separating out the views allows incremental releases to support separate >> views. It is not whether they are causing end user problems. I think the >> separation is important. People can grap one jar for all view support or >> an individual jar. This will allow the different views to release >> independently. > > Where did the perception that we need to release the views separate from > the Action engine come from? None of the view technologies have ever held > up the release. Just what exactly is the problem that you are trying to > solve? > > Splitting WebWork into 4 parts is only going to confuse people and make it > more difficult for them to know which parts are compatible. Do you think > we can coordinate 4 separate releases when we can't even get 1.0 out the > door? > > -Maurice > > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Maurice P. <Ma...@Vi...> - 2002-03-02 23:15:28
|
Matt, On Friday, March 1, 2002, at 09:15 AM, ma...@sm... wrote: > Separating out the views allows incremental releases to support separate > views. It is not whether they are causing end user problems. I think the > separation is important. People can grap one jar for all view support or > an individual jar. This will allow the different views to release > independently. Where did the perception that we need to release the views separate from the Action engine come from? None of the view technologies have ever held up the release. Just what exactly is the problem that you are trying to solve? Splitting WebWork into 4 parts is only going to confuse people and make it more difficult for them to know which parts are compatible. Do you think we can coordinate 4 separate releases when we can't even get 1.0 out the door? -Maurice |
|
From: Victor S. <vsa...@ho...> - 2002-03-02 16:39:06
|
Hi Matt:
No objections as everything is the same except for adding .view (which is
just pointless since .velocity .xml .taglib didn't hurt anyone, but makes
people happy -- and for distro purposes 'ant' would have done a great job,
but what the heck he :) )
/V
>From: "Matt Baldree" <ma...@sm...>
>To: "Bill Burton" <bi...@pr...>,
><web...@li...>
>Subject: Re: [Webwork-devel] refactor
>Date: Sat, 2 Mar 2002 09:13:47 -0600
>
>I think this is a good compromise and makes sense. So I would like to
>implement this plan. The planned distribution jars would be ...
>
>webwork-taglib.jar, webwork-velocity.jar, webwork-xslt.jar,
>webwork-all-views.jar, webwork-example.jar.
>
>There would only be one WAR file for running the tests and examples. If you
>have any objections, please yell before I do this by the end of the
>weekend.
>
>-Matt
>
>----- Original Message -----
>From: "Bill Burton" <bi...@pr...>
>To: <kje...@mo...>; <ma...@sm...>;
><web...@li...>
>Sent: Friday, March 01, 2002 8:33 PM
>Subject: Re: [Webwork-devel] refactor
>
>
> > Hello,
> >
> > Jim...@do... wrote:
> > >
> > > As most people voiced, the refactor makes sense structurally and for
> > > deployment. If the refactor is going to happen, I believe it should
>happen
> > > now, *before* 1.0.
> >
> > Agreed.
> >
> > > It will be many times more painful to introduce this type of refactor
>(no
> > > features, just reorg) after 1.0 than it would right now.
> >
> > Definitely.
> >
> > > So suck it up guys and complete it. Most of the "fixing" relates to
> > > package naming, so make sure that the entire codebase rebuilds
>properly
> > > and the examples execute correctly. It is very important to get the
>view
> > > technology out of the true "core" of WebWork. It has never made much
> > > sense.
> >
> > Yes.
> >
> > I think a compromise is in order. Some of the package renaming is a
>very
> > good step forward while not being very disruptive (if at all). However,
> > most of the package renaming isn't necessary (moving most stuff to
> > common/core) because it can be done in the build.xml by specifying which
> > packages are part of the webwork-core.jar.
> >
> > Have pulled the latest CVS and after looking at it out here's my
> > recommendation.
> > * Keep webwork/examples.
> > * Move webwork/{common/core}/view up to webwork/view
> > * For everything else in common/core, move it back to where it was under
> > webwork. This will remove most of the objections to the package
>cleanup.
> >
> > The packages would then look like this (assuming I didn't miss
>anything):
> > webwork.action.{client,factory,standard}
> > webwork.config
> > webwork.dispatcher
> > webwork.examples
> > webwork.expr
> > webwork.util
> > webwork.view.{taglib,velocity,xslt}
> >
> > Which generally similar to the way it was. This should provide
>sufficent
> > flexibility to build the jars with various contents while maintaining a
> > high degree of backwards compatibility.
> >
> > Other suggestions:
> > * Make resources/web/example plural (examples).
> >
> > -Bill
> >
> > > jim
> > >
> > > ma...@sm...
> > > Sent by: web...@li...
> > > 03/01/2002 03:56 PM
> > >
> > >
> > > To: web...@li...
> > > cc:
> > > Subject: [Webwork-devel] refactor
> > >
> > > Well, I guess there is sufficient resistence and rightly so to any
> > > refactoring at this time. Unless Rickard or someone directs
>differently,
>I
> > > would be more than happy to restore cvs tomorrow to its previous
>state.
>I
> > > saved off a snap shot. We can save these concerns and issues for a
>later
> > > time.
> > >
> > > -Matt
> >
> >
>
>
>
>_______________________________________________
>Webwork-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webwork-devel
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
|
|
From: Jason C. <jas...@no...> - 2002-03-02 15:33:06
|
Hey, Has anyone looked at this project? http://jbeans.sourceforge.net/ From a quick look, it looks like it could replace a lot of the = Reflection code used to handle Actions and also already handles type = conversion for properties. Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: jas...@no... |
|
From: Matt B. <ma...@sm...> - 2002-03-02 15:14:13
|
I think this is a good compromise and makes sense. So I would like to
implement this plan. The planned distribution jars would be ...
webwork-taglib.jar, webwork-velocity.jar, webwork-xslt.jar,
webwork-all-views.jar, webwork-example.jar.
There would only be one WAR file for running the tests and examples. If you
have any objections, please yell before I do this by the end of the weekend.
-Matt
----- Original Message -----
From: "Bill Burton" <bi...@pr...>
To: <kje...@mo...>; <ma...@sm...>;
<web...@li...>
Sent: Friday, March 01, 2002 8:33 PM
Subject: Re: [Webwork-devel] refactor
> Hello,
>
> Jim...@do... wrote:
> >
> > As most people voiced, the refactor makes sense structurally and for
> > deployment. If the refactor is going to happen, I believe it should
happen
> > now, *before* 1.0.
>
> Agreed.
>
> > It will be many times more painful to introduce this type of refactor
(no
> > features, just reorg) after 1.0 than it would right now.
>
> Definitely.
>
> > So suck it up guys and complete it. Most of the "fixing" relates to
> > package naming, so make sure that the entire codebase rebuilds properly
> > and the examples execute correctly. It is very important to get the view
> > technology out of the true "core" of WebWork. It has never made much
> > sense.
>
> Yes.
>
> I think a compromise is in order. Some of the package renaming is a very
> good step forward while not being very disruptive (if at all). However,
> most of the package renaming isn't necessary (moving most stuff to
> common/core) because it can be done in the build.xml by specifying which
> packages are part of the webwork-core.jar.
>
> Have pulled the latest CVS and after looking at it out here's my
> recommendation.
> * Keep webwork/examples.
> * Move webwork/{common/core}/view up to webwork/view
> * For everything else in common/core, move it back to where it was under
> webwork. This will remove most of the objections to the package cleanup.
>
> The packages would then look like this (assuming I didn't miss anything):
> webwork.action.{client,factory,standard}
> webwork.config
> webwork.dispatcher
> webwork.examples
> webwork.expr
> webwork.util
> webwork.view.{taglib,velocity,xslt}
>
> Which generally similar to the way it was. This should provide sufficent
> flexibility to build the jars with various contents while maintaining a
> high degree of backwards compatibility.
>
> Other suggestions:
> * Make resources/web/example plural (examples).
>
> -Bill
>
> > jim
> >
> > ma...@sm...
> > Sent by: web...@li...
> > 03/01/2002 03:56 PM
> >
> >
> > To: web...@li...
> > cc:
> > Subject: [Webwork-devel] refactor
> >
> > Well, I guess there is sufficient resistence and rightly so to any
> > refactoring at this time. Unless Rickard or someone directs differently,
I
> > would be more than happy to restore cvs tomorrow to its previous state.
I
> > saved off a snap shot. We can save these concerns and issues for a later
> > time.
> >
> > -Matt
>
>
|
|
From: Bill B. <bi...@pr...> - 2002-03-02 02:33:14
|
Hello,
Jim...@do... wrote:
>
> As most people voiced, the refactor makes sense structurally and for
> deployment. If the refactor is going to happen, I believe it should happen
> now, *before* 1.0.
Agreed.
> It will be many times more painful to introduce this type of refactor (no
> features, just reorg) after 1.0 than it would right now.
Definitely.
> So suck it up guys and complete it. Most of the "fixing" relates to
> package naming, so make sure that the entire codebase rebuilds properly
> and the examples execute correctly. It is very important to get the view
> technology out of the true "core" of WebWork. It has never made much
> sense.
Yes.
I think a compromise is in order. Some of the package renaming is a very
good step forward while not being very disruptive (if at all). However,
most of the package renaming isn't necessary (moving most stuff to
common/core) because it can be done in the build.xml by specifying which
packages are part of the webwork-core.jar.
Have pulled the latest CVS and after looking at it out here's my
recommendation.
* Keep webwork/examples.
* Move webwork/{common/core}/view up to webwork/view
* For everything else in common/core, move it back to where it was under
webwork. This will remove most of the objections to the package cleanup.
The packages would then look like this (assuming I didn't miss anything):
webwork.action.{client,factory,standard}
webwork.config
webwork.dispatcher
webwork.examples
webwork.expr
webwork.util
webwork.view.{taglib,velocity,xslt}
Which generally similar to the way it was. This should provide sufficent
flexibility to build the jars with various contents while maintaining a
high degree of backwards compatibility.
Other suggestions:
* Make resources/web/example plural (examples).
-Bill
> jim
>
> ma...@sm...
> Sent by: web...@li...
> 03/01/2002 03:56 PM
>
>
> To: web...@li...
> cc:
> Subject: [Webwork-devel] refactor
>
> Well, I guess there is sufficient resistence and rightly so to any
> refactoring at this time. Unless Rickard or someone directs differently, I
> would be more than happy to restore cvs tomorrow to its previous state. I
> saved off a snap shot. We can save these concerns and issues for a later
> time.
>
> -Matt
|
|
From: Kjetil H.P. <kje...@mo...> - 2002-03-01 21:36:20
|
I think we at least should keep the examples as they are now, in a seperate package, and make the web structure like you suggested, it would deploy nicer and easier to handle regarding third party libs. /kjetilhp ma...@sm... wrote: > Well, I guess there is sufficient resistence and rightly so to any refactoring at this time. Unless Rickard or someone directs differently, I would be more than happy to restore cvs tomorrow to its previous state. I saved off a snap shot. We can save these concerns and issues for a later time. > > -Matt > > > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel > -- /kjetilhp ......mogul.technology.............................................. mogul technology as > kjetil h.paulsen - senior software architect drammensveien 134, NO-0277 oslo, norway cell +47 93060327, tel +4724114300, fax +4724114399 kje...@mo..., http://www.mogul.com PGP fingerprint: DA54 A106 1989 FEF0 294F 63A4 9FC6 0F8E 21AD 0180 ICQ -> 66288365 ..............................................mogul.technology...... |
|
From: <Jim...@do...> - 2002-03-01 21:33:16
|
As most people voiced, the refactor makes sense structurally and for
deployment. If the refactor is going to happen, I believe it should happen
now, *before* 1.0.
It will be many times more painful to introduce this type of refactor (no
features, just reorg) after 1.0 than it would right now. I am also
speaking as someone developing a huge, mission-critical system on WebWork.
I recognize that the product is still RC and changes such as these can and
will occur. I have prepared myself mentally for this type of change,
especially in a beta product.
So suck it up guys and complete it. Most of the "fixing" relates to
package naming, so make sure that the entire codebase rebuilds properly
and the examples execute correctly. It is very important to get the view
technology out of the true "core" of WebWork. It has never made much
sense.
jim
ma...@sm...
Sent by: web...@li...
03/01/2002 03:56 PM
To: web...@li...
cc:
Subject: [Webwork-devel] refactor
Well, I guess there is sufficient resistence and rightly so to any
refactoring at this time. Unless Rickard or someone directs differently, I
would be more than happy to restore cvs tomorrow to its previous state. I
saved off a snap shot. We can save these concerns and issues for a later
time.
-Matt
_______________________________________________
Webwork-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webwork-devel
|
|
From: Rickard <ri...@mi...> - 2002-03-01 21:10:33
|
ma...@sm... wrote: > Well, I guess there is sufficient resistence and rightly so to any refactoring at this time. Unless Rickard or someone directs differently, I would be more than happy to restore cvs tomorrow to its previous state. I saved off a snap shot. We can save these concerns and issues for a later time. Unfortunately the email I used for the mailing lists had expired, so I've missed the entire discussion. However, I've read some of it, and yes, Keep It Simple. One Step At A Time. No Rush. Rollback. /Rickard -- Rickard Öberg Chief Architect, TheServerSide.com The Middleware Company |
|
From: <ma...@sm...> - 2002-03-01 20:56:34
|
Well, I guess there is sufficient resistence and rightly so to any refactoring at this time. Unless Rickard or someone directs differently, I would be more than happy to restore cvs tomorrow to its previous state. I saved off a snap shot. We can save these concerns and issues for a later time. -Matt |
34982 messages has been excluded from this view by a project administrator.
