Martin Poeschl <[EMAIL PROTECTED]> writes:
>i posted my plans for the next version of turbine some weeks ago .. now
>it's voting time ;-)
>o remove all deprecated stuff (+ code cleanup)
> incl. the freemarker and webmacro support (nobody is using it and the current
>versions are not
>supported)
>o switch to commons-logging
I'm obviously +1 on this. :-)
Here is some more that I _have_ (no need to do coding, just pulling
out of our internal CVS, pushing to jakarta and integrating with the
current code).
- Commons Logging using log4j. This is ready, we use it all the time
here (couldn't live without) and is basically adding some startup
code to Turbine.java, some small glue code to the Velocity Service and
then a big replacement Log -> log and adding lines like this
private static Log log = LogFactory.getLog(foo.class);
to all the classes that need logging. That's why I asked about the
JDK 1.3 / JDK 1.4 incompatibilities regarding to direct class
references. If we really do have problems here, we must either offer
1.3 and 1.4 compiled binary packages or use
private Log log = LogFactory.getLog(this.getClass())
which needs more memory as we have more objects and is less performant.
Opinions? I'd go for the "private static" option, mainly because building
with maven is really not critical and providing two binary distributions
is no problem either.
- Commons Configuration integration.
I removed the TurbineResources Service completely but obviously one
could write a very thin compatbility layer with simply queries the
central configuration object and offers the same methods.
I'm just 0 on keeping TurbineResources as rewriting is pretty simple
(With my code you just change TurbineResources.getString()
to Turbine.getConfiguration().getString()) and you can run in some
"gotchas" because commons-configuration behaves different in some corner
cases from TurbineResources (I did).
I do consider this a breaking change and people should do a "Heads up" here.
- Decoupling the Services and use Fulcrum. Yeah, I know, there are discussions
about Avalon, Services repositories in common yadda, yadda, yadda. My main
point here is: I have code that works. And I have about a bazillion patches
to Fulcrum which I will not move into the Turbine code. This is too much
work and I plan on working only on one code base. To me this is not a
2.3 change but I plan on making a branch tag out from the post-2.2 code
(Once I have everything in place that I need from the main branch, mainly
logging and configuration) and putting the code onto the jakarta repository
to let people decide. I plan on supporting the tree for quite a while and
even if we dissolve Fulcrum at a later date, this will be a nice working
base.
- Revamping the URI handling. The current state of the URI handling is a
mess. I rewrote the whole ContentURI/DynamicURI/RelativeDynamicURI code,
bundled it under turbine/util/uri and made the whole code base use this
in a consistent manner. I removed lots and lots of gotchas from the whole
handling and the nice by-effect of this is, that user visible is only a
small change in the tools to load in the context.
_AND_ my code is fully documented. :-)
If you every tried to implement cookie-less session handling with Turbine,
you will really appreciate this.
- Pull Service rewrite, scope cleanup and rework. Most of the pull service
is simply poor to very poor code quality. I rewrote this, cleaned up the
refresh handling, added a fifth scope and a second tool class.
This BTW made it possible to use pull tools as objects in the JSP pages
(which is untested but should work)
- RunData. Don't get me started on RunData. :-) I factored out the
ServerData, moved lots of code to actually use ServerData objects which
makes the whole Turbine startup pretty slick and allowed the URI code
to take advantage of this.
- Use commons whereever possible. This removes some helper classes.
- Remove the whole Stratum code. Most of it can be replaced with Lifecycle or
with other commons code.
... and there are just the plans for Turbine. Fulcrum is some more... :-)
Martin, that's why I proposed to do Turbine 2.2.x changes along the
branch tag that you did in the repository. If users start writing code
on Turbine-2.2, they _should_ check out from the TURBINE_2_2_BRANCH tag
and can be sure that the checked out code (and the further 2.2 releases
(either 2.2.1, 2.2.2 or 2.2p1, 2.2p2) will work without changes on their
applications. These releases will only be bug-fix releases without any new
features.
If you check out from the HEAD, you must read the changes and be
prepared to adjust your code. That's the price for bleeding edge. The
deprecation scheme simply does not work for bigger changes (like
ripping out LogService and ResourcesService). We must do this, endure
the pain and live on. :-) We won't get up to speed otherwise.
So, people, I propose if you want to live on the T-2.2 bleeding edge,
go for the TURBINE_2_2_BRANCH tag, if you want to live dangerously, go
for HEAD.
Ah, and please add a "<release>" tag to project.xml (or did this
disappear somewhere past maven 1.0b4?) and maybe some documentation
about the branch tags.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
