jvanzyl 01/06/15 10:39:46
Modified: xdocs/proposals package-cleanup.xml
Log:
- additions to package cleanup
Revision Changes Path
1.3 +39 -15 jakarta-turbine/xdocs/proposals/package-cleanup.xml
Index: package-cleanup.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine/xdocs/proposals/package-cleanup.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- package-cleanup.xml 2001/05/01 17:15:48 1.2
+++ package-cleanup.xml 2001/06/15 17:39:45 1.3
@@ -12,28 +12,52 @@
<section name="Renaming and reordering">
<p>
- <li>
- 2.2 will be a good moment to rename, and move classes around.
- </li>
+ Turbine 2.2 will be a good moment to rename, and move classes around
+ and move some of our utility code to the commons where
+ it can be shared and improved by a larger community
+ of developers. Here are some thoughts:
+</p>
- <li>
- WebMacroSite classes could be renamed to just WebMacro
- </li>
+<p>
+ <b>1.</b> Movement of our org.apache.turbine.util.mail.* classes
+ to the commons sandbox where hopefully it will be approved
+ as a utility package. A little bit a decoupling would
+ have to be done to free it from TurbineResources but
+ that wouldn't take much effort.
+</p>
- <li>
- some utility classes could be moved into service packages, to
- decerease the crazy number of packages we have, and help better
- hermetisation of code with package accesible fields/methods.
- </li>
+<p>
+ <b>2.</b> Combine of all the Velocity/WebMacro email
+ classes into a single utility that can be placed
+ in templating tools repository. Such a repository
+ will probably be started in the commons sandbox ASAP
+ so it would again be nice to share the tools
+ we have made with a larger community.
+</p>
+
+<p>
+ <b>3.</b> Movement of all utility code for services
+ into the parent service package. We can leave proxies
+ in the original packages and deprecate them. This would
+ defintely lend to clarity in the source tree and
+ the services will then be completely self contained and
+ using the services framework as an entirely separate
+ entity will be possible. With this self containment it
+ will also be possible to make a build system for
+ the services.
+</p>
+
+<p>
+ <b>4.</b> WebMacroSite classes could be renamed to just WebMacro
+</p>
- <li>
- BasePeer should move to the same package as Criteria. A deprecated
+<p>
+ <b>5.</b> BasePeer should move to the same package as Criteria. A deprecated
stub can be left in om.peer, Though most use of BasePeer should be
through the generated Peers, so there should not be much bad effect
on users and it will lead to much better public api in Criteria.
- </li>
-
</p>
+
</section>
</body>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
