"Quinton McCombs" <[EMAIL PROTECTED]> writes:
>Henning is making a great deal of changes to the code base without a
>great deal of discussion. That much is true. However, as long as he is
>not making "breaking" changes, I don't really see a problem with it. I
>for one am very grateful that he is making these changes. They are an
>improvement on the current code.
Well, that's true. But as I said, most of these changes are
"janitorial" like moving hard coded strings to constants and use
commons components to places where tests have been.
80+% of these changes have incubated in our internal CVS and are used
in our application for ages. The only bigger changes that I did
(and I do apologize for not discussing them deeper on the -dev list)
were:
- The large change to the Template/Velocity service (separating out
the lookup policies)
- The Torque Security Service (which incubated for months in the
proposals directory) which was wanted by many users because of the
ability to easy use it with extended security objects (that's the whole
reason it was written)
- The logging and configuration changes, which were discussed on the -dev
list with a "+1, go ahead" as conclusion.
I tried very much not to introduce any breaking changes in the 2.x code
base. At least not until we have 2.3 released :-)
>Perhaps, it would help if we all steped back and asked what our goals
>are? Is this project just for the developers who want to write cool
>code? Is it just an excerise to find the "rigth way" to developer an
>app framework? Perhaps it is about developing a framework that reduces
>the development time for a web based application.
Ok, I tell you in depth what my motivations and "hidden agendas" are:
I came to Turbine because I needed a framework for developing a quite
largeish application for a customer. This happened right after the 2.1
release. While I was struggling to get this app running on T2.1, the
following things happened:
- A T3 was forked off
- Fulcrum was born
- Suddently Torque fell off the code base
- The build tools changed from ant to ant-based maven to maven
- The TDK got unpopular in favour of maven
- Many of the until then active developers of the 2.x code base suddently
moved off
At some point I was no longer amused with having to work an hour to
keep our stuff working on the "changes of the day" and rebuild our
build tools every day and pulled off a code level of Turbine-2 and
Fulcrum into an internal CVS @ INTERMETA and started working there
with my co-developers. We moved in a few days to a Turbine which uses
Fulcrum as its service broker, converted all the non-fulcrum services
in Turbine-2 to use Fulcrum, ripped out the Resource and Logging
Service, created a Component Service (which went back to Jakarta T2
very fast) to start up Torque and had a baseline on which we were able
to do our job. This was September 2002 after almost twelve months of
struggling.
Turbine was still 2.2beta<something> at that point. And it was not
much development going on with the only official release being 2.1
I would consider it a waste not to move that stuff, which is sitting
in my CVS for ages and proved itself to work fine, back into the
jakarta turbine 2 main line.
My personal interest is having a stable framework which is well
documented and working. It might not be that shining and cool, use
aged or cumbersome technology at some points but is proven in some
applications, has a few references under its belt and is actively
worked on. If only that bugs are fixed. From a technology POV, Summit
is cool. But people are already talking about "Plexus/Summit" and I
found at least one reference, that Plexus might be dropped at some
point in favour of other Avalon containers. I want to keep a continous
development in smaller steps to attract users. If we change our core
components on a monthly base, people will give up and move to things
like Struts. Or .NET =:-)
My main agenda post 2.3 will be to remove the "old turbine parts"
Stratum and JCS. And to move our Services to Avalon just like the
Fulcrum components already have done so we can start using the proven
and stable Turbine services alongside Fulcrum and other Avalon based
components. We will still have no pipeline and no real components in
the core parts of Turbine, but then again at that point, the core of
Turbine will be just a few classes left (Turbine.java and some
helpers). That will be 2.4 (to me).
We still have parts that terribly suck and will suck for much
longer. Look at the interactions of PullService with VelocityService
and SecurityService with the core code. Clean separation will lead to
some sort of pipelining structure, no doubt.But I try to move in
smaller steps to be able to verify that I didn't break some
fundamentals just because I ripped out a vital part that users relied
on.
After that, we might simply retrofit the API of Turbine onto either an
avalon based architecture (Summit) or start pulling the T3 code with
cleanups in. The result will be either 2.5 (which would be telling:
Halfway between T2 and T3) or TurbineNG. If Jason and his group have a
much better and cleaner architecture, cool. So they will do
"TurbineNG" and I will try to lead our hopefully growing user base to
unite with them.
If we can integrate with Summit, even better. Jason proposed to get
"glue classes" for the existing T2 code to work on Summit. That might
be a good idea as addon for summit but then we would have to identify
which parts of the Turbine core (not the services) are actively used
by developers.
And then there is e.g. Tammi which seems to be another one-person
effort by Ilkka Priha, (former? current?) Turbine developer which
might contain some interesting ideas for the future Turbine code.
>Now, how do we increase the user base? Will it happen though making it
>easier to migrate to Summit? Will it happen by making Turbine more
>component based? Probabley not.... I think that the best way to
>accomplish that goal is by providing help to the user list, improving
>the web site, improving the documentation, and making the code even more
>stable.
I agree. But we must not confuse "stable" with "standing still". And one
thing I want to avoid is to create new project names for every new idea
that we have. I do remember one point early 2002 when my head was buzzing
from all the new project names and acronyms so that our group was discussing
to move completely away from Turbine and to something like struts.
And ok, at that point I can admit, that I have a small "hidden agenda":
I still hope that any company working with Turbine, Jetspeed or even
post-Turbine frameworks like Summit or Tammi is looking for an
experienced developer/consultant to hire/contract. After finishing up
our contracted project at the end of January I'm actively looking for
a job to do.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
