Thread: Re: [Webwork-devel] refactor
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel
|
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: 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: 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: 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: Rickard <ri...@mi...> - 2002-03-03 07:44:11
|
Bill Burton wrote: <snip> > Which generally similar to the way it was. This should provide suffice= nt > flexibility to build the jars with various contents while maintaining a > high degree of backwards compatibility. I'm ok with all of Bill's suggestions. /Rickard --=20 Rickard =D6berg Chief Architect, TheServerSide.com The Middleware Company |
|
From: Kjetil H.P. <kje...@mo...> - 2002-03-03 11:50:21
|
It seems like Bill's suggestion are the best compromise here. I say we
go for this structure and consentrate on getting the 1.0 released.
So:
> * 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.
Package structure:
> webwork.action.{client,factory,standard}
> webwork.config
> webwork.dispatcher
> webwork.examples
> webwork.expr
> webwork.util
> webwork.view.{taglib,velocity,xslt}
> * Make resources/web/example plural (examples).
I also think we should add a test package(s) either one webwork.test or
one test package for each package containing JUnit tests.
And resources/web we do as Matt suggested:
/web/examples
/web/tests
/web/docs
/web/images
/web/logo
/web/templates
/web/index.html - with a short intro on how to get started and links
to the subdirectories content
Everyone happy with this? We have to make a decision now to get this
thing moving.
I can do the refactoring of the code. Matt you do the web tier.
(I'll even disconnect from CVS, Victor :))
/kjetilhp
|
|
From: Rickard <ri...@mi...> - 2002-03-03 17:50:44
|
Kjetil H.Paulsen wrote: > I also think we should add a test package(s) either one webwork.test or= =20 > one test package for each package containing JUnit tests. Do we have any JUnit tests? I didn't know that...geez, I gotta get a=20 clue again... > Everyone happy with this? We have to make a decision now to get this=20 > thing moving. Looks ok to me. /Rickard --=20 Rickard =D6berg Chief Architect, TheServerSide.com The Middleware Company |
|
From: Kjetil H.P. <kje...@mo...> - 2002-03-03 18:27:38
|
> Do we have any JUnit tests? I didn't know that...geez, I gotta get a > clue again... we don't, we should have ;) Why don't you drop in the stuff you did in the TSS project... > Looks ok to me. > Great, because Matt has finished it already... -- /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: Rickard <ri...@mi...> - 2002-03-05 06:54:30
|
Kjetil H.Paulsen wrote: >> Do we have any JUnit tests? I didn't know that...geez, I gotta get a=20 >> clue again... >=20 >=20 >=20 > we don't, we should have ;) >=20 > Why don't you drop in the stuff you did in the TSS project... Hm... not a bad idea at all. I'll look into that. >=20 > Great, because Matt has finished it already... >=20 /Rickard --=20 Rickard =D6berg Chief Architect, TheServerSide.com The Middleware Company |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X