You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Martin Poeschl <mp...@marmot.at> on 2002/07/04 18:45:09 UTC
[proposal] kill the coupled torque and services
the coupled versions of torque and fulcrum (service stuff) are not maintained any longer.
we told the users to use the decoupled versions ... good idea, but it doesn't work :-(
many people waste there time trying to make them work together, so i propose to kill the coupled
versions and use the decoupled for turbine 2.x
we could release turbine 2.2 including the coupled versions and kill them for 2.3
this will stop people to start with the old code and will make switching to turbine 3 easier for them.
i crosspost this mail, to give the users a chance to comment the plan ;-)
martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] kill the coupled torque and services
Posted by Rodney Schneider <rl...@arcalink.com>.
On Fri, 5 Jul 2002 02:45, Martin Poeschl wrote:
> the coupled versions of torque and fulcrum (service stuff) are not
> maintained any longer. we told the users to use the decoupled versions ...
> good idea, but it doesn't work :-(
We haven't been able to switch over to using the decoupled versions of Torque
and Fulcrum yet as there are still quite a few major problems with the
current version of Turbine 2.x. We rely on the Turbine Security Service (ie:
Users, Roles, Groups, Permissions, ACL) which still uses the coupled version
of Torque. We are still using a version of Turbine (very similar to Turbine
2.2-b1) that was checked out from CVS just before the decoupling of Torque
and Fulcrum. We did this as our company was concerned that the decoupling
would take some time to be implemented and tested properly. I am pretty sure
(correct me if I am wrong) that the decoupling is still not completed in the
current CVS version of Turbine 2.x. If you search the turbine-user mailing
list archives for posts from Eric Dobbs you will find information on what
still needs to be done.
> many people waste there time trying to make them work together, so i
> propose to kill the coupled versions and use the decoupled for turbine 2.x
I would be +1 on killing the coupled versions if the decoupling was
completely implemented and tested... I am happy to help out where I can with
development and testing... we are releasing a product based on Turbine in
about 6 weeks and I would rather use the decoupled versions of Torque and
Fulcrum if possible.
> we could release turbine 2.2 including the coupled versions and kill them
> for 2.3
This sounds like a good plan, but I don't think Turbine 2.2 should be
released until the decoupling is complete.
> this will stop people to start with the old code and will make switching to
> turbine 3 easier for them.
Agreed.
> i crosspost this mail, to give the users a chance to comment the plan ;-)
Thanks for your courtesy... I don't have time to monitor the turbine-dev
mailing lists at the moment.
Could you please keep the turbine-user list informed of any decisions you
make over there on turbine-dev?
Thanks in advance,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Road to Turbine 3.0
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
> There are people (e.g. me :-) ) actually working on the Fulcrum HEAD
> branch and it is really annoying to come into the office in the
> morning to find out that I have to upgrade three more tools just to
> keep working where I left off in the evening.
I feel that.
...
> People, please. Can we get some 1.0 releases? Like Geir does with
> Velocity? There are actually release versions. :-) I'd love to see a
> Maven 1.0. A Torque 3.0. A Fulcrum 3.0. Something without "-dev" or
> "-snap" in the jar names.
+1, I'm with you.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Road to Turbine 3.0
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jason van Zyl <ja...@zenplex.com> writes:
>Not unrealistic. I've basically been working on Maven and Turbine in
>tandem because I don't even want to attempt anything with Turbine until
>Maven is working. b5 is working now, I would like to move the
>descriptors forward because I always use Turbine as a guinea pig. I know
>that for most projects it's not a good idea to use CVS HEAD but again I
>would like to use Turbine as a test.
Please do not use Turbine-2 / Fulcrum / Torque as "guinea pigs". At
least not until there is no longer talk on the maven list about
"features gone from b5 that were present in b4" (war task comes to
mind). Or even better, let's get a maven release. (Scary thought).
There are people (e.g. me :-) ) actually working on the Fulcrum HEAD
branch and it is really annoying to come into the office in the
morning to find out that I have to upgrade three more tools just to
keep working where I left off in the evening.
I have a _completely_ revamped DB Security Service ready to go in. It
has > 1000 lines of documentation (!), allows free selection of peer,
OM and base classes, can make coffee and the world a cleaner, shinier
place. (Martin and Stephen Habermann already got a copy and I will
file a proposal later). I hate to rewrite it all three days because a
new version of maven comes out. :-(
People, please. Can we get some 1.0 releases? Like Geir does with
Velocity? There are actually release versions. :-) I'd love to see a
Maven 1.0. A Torque 3.0. A Fulcrum 3.0. Something without "-dev" or
"-snap" in the jar names.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Road to Turbine 3.0
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <ja...@zenplex.com> writes:
> On Mon, 2002-07-08 at 05:05, Daniel Rall wrote:
> > Martin Poeschl <mp...@marmot.at> writes:
>>
>> > i'm not sure what the timeframe for a 3.0 release is .. there are some
>> > users who don't want to use any packages marked as alpha or beta .. i
>> > think we must shorten our release cycles!!
>>
>> I am willing to help out with a real beta release of 3.0, based on
>> either Fulcrum or an Avalon container.
>
> I definitely think the Avalon container is the way to go. There are two
> containers here:
>
> http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/
>
> One based on Fortress and one based on Tweety.
The one (which I assume is) based on Fortress looks copacetic.
>> Is there a Turbine 3.0 TODO
>> list enumerating the minimal requirements for such a release
>> milestone?
>
> A standardized requirements document would be good.
Yes. I'm willing to work on this if you'll toss in a few
requirements. I'd like to hear from the rest of you on this as well.
>> If not, is there any preference for where I should put it
>> in the jakarta-turbine-3 CVS repository?
>
> I think that's as good a place as any.
Okay. But where within the repo? At the root level, or as an xdoc?
...
> Dan, I know you are used to working with HEAD so at least this way we
> could organize something.
>
> As far as Turbine, there is the plexus container and a little bundle of
> what I would like to see for Turbine 3.0:
>
> http://jakarta.apache.org/~jvanzyl/t3-jvz.tgz
I'll try to find time to look, but I'd prefer an english description.
:)
> It is entirely stripped down (~30k) and I know that what is currently in
> t3 is important for the apps you're involved with. What currently
> exists for t3 is still really t2 cleaned and still doesn't satisfy the
> requirement of full decoupling or ease of use.
Will you describe how you can strip further T3 and maintain backwards
compatibility? I haven't looked through the tarball yet and am sure
there are answers in there, but am hoping to get some requirements out
of your description.
>> If so, how does this schedule compare with the T3 TODO list?
>
> I think the first requirement is to get the build and documentation
> system together. Of course, as per usual this has taken longer than
> expected but the Jelly'ized version of Maven is working now. And
> with heavy weights like Bob McWhirter and James Strachan working on
> Maven now it won't take long.
Indeed. I'll kibitz with you on IRC about this.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Road to Turbine 3.0
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2002-07-08 at 05:05, Daniel Rall wrote:
> Martin Poeschl <mp...@marmot.at> writes:
>
> > i'm not sure what the timeframe for a 3.0 release is .. there are some
> > users who don't want to use any packages marked as alpha or beta .. i
> > think we must shorten our release cycles!!
>
> I am willing to help out with a real beta release of 3.0, based on
> either Fulcrum or an Avalon container.
I definitely think the Avalon container is the way to go. There are two
containers here:
http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/
One based on Fortress and one based on Tweety.
> Is there a Turbine 3.0 TODO
> list enumerating the minimal requirements for such a release
> milestone?
A standardized requirements document would be good.
> If not, is there any preference for where I should put it
> in the jakarta-turbine-3 CVS repository?
I think that's as good a place as any.
> An important part of any release is well organized documentation.
> Previous releases of Turbine contained quite a bit of documentation,
> but these hidden jewels were sequestered in the far recesses of the
> jungle which was the Turbine 2.x web site, accessible only to those
> with native guide and elephant, or to those brave souls stout enough
> of heart to wade through the piranha infested waters of the source.
>
> Maven's XML descriptor and sharp DVSL machete promises to bring order
> to our chaotic jungle, tempting us with a slick hierarchical layout.
> But alas, its shaky rope bridge of stability has washed away every
> time I've returned to ford the river of a build. The tease of web
> site coherency is frustrating, to say the least. A stable build
> system is without a doubt a Turbine release prerequisite. Seeing as
> how Maven originally emerged from the Turbine jungle to statisfy
> Turbine requirements, what are the chances that beta 5 approximates
> release candidate quality, satisfying this most basic of requirements?
In about a week. We've made the switch completely over to using Jelly.
I've made two passes at the plugins, cleaning them up and this week
there are about 4 of us working on it. Right now it is primarily a
matter of documentation and sorting out the plugin structure as I would
like b5 to be close to what is released for 1.0.
> If this is an unrealistic expectation, is there any expected time
> frame for a Jelly-based release candidate of Maven?
Not unrealistic. I've basically been working on Maven and Turbine in
tandem because I don't even want to attempt anything with Turbine until
Maven is working. b5 is working now, I would like to move the
descriptors forward because I always use Turbine as a guinea pig. I know
that for most projects it's not a good idea to use CVS HEAD but again I
would like to use Turbine as a test.
Dan, I know you are used to working with HEAD so at least this way we
could organize something.
As far as Turbine, there is the plexus container and a little bundle of
what I would like to see for Turbine 3.0:
http://jakarta.apache.org/~jvanzyl/t3-jvz.tgz
It is entirely stripped down (~30k) and I know that what is currently in
t3 is important for the apps you're involved with. What currently
exists for t3 is still really t2 cleaned and still doesn't satisfy the
requirement of full decoupling or ease of use.
> If so, how does
> this schedule compare with the T3 TODO list?
I think the first requirement is to get the build and documentation
system together. Of course, as per usual this has taken longer than
expected but the Jelly'ized version of Maven is working now. And with
heavy weights like Bob McWhirter and James Strachan working on Maven now
it won't take long.
>
> - Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
The Road to Turbine 3.0
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Martin Poeschl <mp...@marmot.at> writes:
> i'm not sure what the timeframe for a 3.0 release is .. there are some
> users who don't want to use any packages marked as alpha or beta .. i
> think we must shorten our release cycles!!
I am willing to help out with a real beta release of 3.0, based on
either Fulcrum or an Avalon container. Is there a Turbine 3.0 TODO
list enumerating the minimal requirements for such a release
milestone? If not, is there any preference for where I should put it
in the jakarta-turbine-3 CVS repository?
An important part of any release is well organized documentation.
Previous releases of Turbine contained quite a bit of documentation,
but these hidden jewels were sequestered in the far recesses of the
jungle which was the Turbine 2.x web site, accessible only to those
with native guide and elephant, or to those brave souls stout enough
of heart to wade through the piranha infested waters of the source.
Maven's XML descriptor and sharp DVSL machete promises to bring order
to our chaotic jungle, tempting us with a slick hierarchical layout.
But alas, its shaky rope bridge of stability has washed away every
time I've returned to ford the river of a build. The tease of web
site coherency is frustrating, to say the least. A stable build
system is without a doubt a Turbine release prerequisite. Seeing as
how Maven originally emerged from the Turbine jungle to statisfy
Turbine requirements, what are the chances that beta 5 approximates
release candidate quality, satisfying this most basic of requirements?
If this is an unrealistic expectation, is there any expected time
frame for a Jelly-based release candidate of Maven? If so, how does
this schedule compare with the T3 TODO list?
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] kill the coupled torque and services
Posted by Martin Poeschl <mp...@marmot.at>.
Henning P. Schmiedehausen wrote:
> Martin Poeschl <mp...@marmot.at> writes:
>
>
>>the coupled versions of torque and fulcrum (service stuff) are not maintained any longer.
>>we told the users to use the decoupled versions ... good idea, but it doesn't work :-(
>
>
>>many people waste there time trying to make them work together, so i propose to kill the coupled
>>versions and use the decoupled for turbine 2.x
>
>
>>we could release turbine 2.2 including the coupled versions and kill them for 2.3
>
>
> Hi Martin,
>
> well, actually, the Turbine 2.2 tree over here in my CVS (and used in
> our development) is exactly this.
>
> Problems that you will find (and that I found):
>
> You still have to keep lots of services, simply because they don't
> exist in Fulcrum: castor, freemarker und webmacro are the simplest
> examples. If you pull them simple because they're old, this means that
> people using these are left behind.
>
> You will find out (just as I found out) that the template service, the
> pull service and the velocity service are entwined in the innards of
> the core Turbine 2 (Or maybe I was just too dumb to do it? Could
> be. :-) ). If you try to pull them out and replace them by fulcrum,
> you end up with something similar Turbine 3. If you replace the
> velocity, webmacro and freemarker services by Fulcrum template
> service, you end up with people not using it, because their
> applications don't use velocity.
>
> You will annoy the living daylights out of current Turbine users,
> which start with Turbine/TDK 2.1 (still the only official release),
> stumble through the myriads of changes since then (Try to compare
> Turbine 2.1 with the current Turbine 2.2b/Fulcrum/Torque/Maven system,
> heavily relying on other Projects like Commons and you see that these
> are almost two completely different things), try to make sense and end
> up with an inferior system simply because they will give up in
> frustration.
>
> I remember how long to took me to understand, that there is a
> difference between an screen and the template for a screen, simply
> because in earlier times people used actual Java classes to render a
> screen instead of using a template. The horrors of
> System.out.println("<HTML>\n<HEAD>\"); ... :-)
>
> Quick, can you explain to a newbie struggling with Turbine the
> difference between screen.homepage and template.homepage in
> Turbine.properties? And why the CVS checked-in default of "/Index.vm"
> leads to an annoying mess if you change (at a total different location
> in the TR.properties) from FileResourceLoader to JarResourceLoader?
> (been there, done that. :-( ). And when is screen.homepage used and
> when is template.homepage used? :-)
>
> I personally would go for a stable release of T2.2 and then putting it
> into bugfix only mode after that and put all new efforts into T3
> instead of making T2 something that resembles T3 but keeps all the
> ugly traits. T3 is in many aspects much cleaner (because it sheds all
> the older stuff from T2) and should be promoted instead of dragging T2
> along.
i'm not sure what the timeframe for a 3.0 release is .. there are some users who don't want to use
any packages marked as alpha or beta .. i think we must shorten our release cycles!!
we should be able to release another 2.2 beta based on the existing turbine-2 HEAD code and do some
buxfixes if needed.
>
> For me (and this means, for this company :-) ), T2.2 will definitely
> the final T2 release that we use. If there will ever be a T2.2
> release. T3 is coming along nicely and if I really put more work into
> the Turbine core, it will into T3 once its innards will be better
> documented.
>
> Regards
> Henning
>
> P.S.: Oh, and a working TDK, of course. My TDK (I have some hacked up
> for inhouse use based on Maven) has some dozen K difference to the
> "official" CVS TDK, which does not work with T2 at all. :-( Anyone
> wants to have them for integrating?
sure, send it to my private mail or send a link where i can grab it
martin
>
>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] kill the coupled torque and services
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Martin Poeschl <mp...@marmot.at> writes:
>the coupled versions of torque and fulcrum (service stuff) are not maintained any longer.
>we told the users to use the decoupled versions ... good idea, but it doesn't work :-(
>many people waste there time trying to make them work together, so i propose to kill the coupled
>versions and use the decoupled for turbine 2.x
>we could release turbine 2.2 including the coupled versions and kill them for 2.3
Hi Martin,
well, actually, the Turbine 2.2 tree over here in my CVS (and used in
our development) is exactly this.
Problems that you will find (and that I found):
You still have to keep lots of services, simply because they don't
exist in Fulcrum: castor, freemarker und webmacro are the simplest
examples. If you pull them simple because they're old, this means that
people using these are left behind.
You will find out (just as I found out) that the template service, the
pull service and the velocity service are entwined in the innards of
the core Turbine 2 (Or maybe I was just too dumb to do it? Could
be. :-) ). If you try to pull them out and replace them by fulcrum,
you end up with something similar Turbine 3. If you replace the
velocity, webmacro and freemarker services by Fulcrum template
service, you end up with people not using it, because their
applications don't use velocity.
You will annoy the living daylights out of current Turbine users,
which start with Turbine/TDK 2.1 (still the only official release),
stumble through the myriads of changes since then (Try to compare
Turbine 2.1 with the current Turbine 2.2b/Fulcrum/Torque/Maven system,
heavily relying on other Projects like Commons and you see that these
are almost two completely different things), try to make sense and end
up with an inferior system simply because they will give up in
frustration.
I remember how long to took me to understand, that there is a
difference between an screen and the template for a screen, simply
because in earlier times people used actual Java classes to render a
screen instead of using a template. The horrors of
System.out.println("<HTML>\n<HEAD>\"); ... :-)
Quick, can you explain to a newbie struggling with Turbine the
difference between screen.homepage and template.homepage in
Turbine.properties? And why the CVS checked-in default of "/Index.vm"
leads to an annoying mess if you change (at a total different location
in the TR.properties) from FileResourceLoader to JarResourceLoader?
(been there, done that. :-( ). And when is screen.homepage used and
when is template.homepage used? :-)
I personally would go for a stable release of T2.2 and then putting it
into bugfix only mode after that and put all new efforts into T3
instead of making T2 something that resembles T3 but keeps all the
ugly traits. T3 is in many aspects much cleaner (because it sheds all
the older stuff from T2) and should be promoted instead of dragging T2
along.
For me (and this means, for this company :-) ), T2.2 will definitely
the final T2 release that we use. If there will ever be a T2.2
release. T3 is coming along nicely and if I really put more work into
the Turbine core, it will into T3 once its innards will be better
documented.
Regards
Henning
P.S.: Oh, and a working TDK, of course. My TDK (I have some hacked up
for inhouse use based on Maven) has some dozen K difference to the
"official" CVS TDK, which does not work with T2 at all. :-( Anyone
wants to have them for integrating?
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] kill the coupled torque and services
Posted by Rodney Schneider <rl...@arcalink.com>.
On Fri, 5 Jul 2002 02:45, Martin Poeschl wrote:
> the coupled versions of torque and fulcrum (service stuff) are not
> maintained any longer. we told the users to use the decoupled versions ...
> good idea, but it doesn't work :-(
We haven't been able to switch over to using the decoupled versions of Torque
and Fulcrum yet as there are still quite a few major problems with the
current version of Turbine 2.x. We rely on the Turbine Security Service (ie:
Users, Roles, Groups, Permissions, ACL) which still uses the coupled version
of Torque. We are still using a version of Turbine (very similar to Turbine
2.2-b1) that was checked out from CVS just before the decoupling of Torque
and Fulcrum. We did this as our company was concerned that the decoupling
would take some time to be implemented and tested properly. I am pretty sure
(correct me if I am wrong) that the decoupling is still not completed in the
current CVS version of Turbine 2.x. If you search the turbine-user mailing
list archives for posts from Eric Dobbs you will find information on what
still needs to be done.
> many people waste there time trying to make them work together, so i
> propose to kill the coupled versions and use the decoupled for turbine 2.x
I would be +1 on killing the coupled versions if the decoupling was
completely implemented and tested... I am happy to help out where I can with
development and testing... we are releasing a product based on Turbine in
about 6 weeks and I would rather use the decoupled versions of Torque and
Fulcrum if possible.
> we could release turbine 2.2 including the coupled versions and kill them
> for 2.3
This sounds like a good plan, but I don't think Turbine 2.2 should be
released until the decoupling is complete.
> this will stop people to start with the old code and will make switching to
> turbine 3 easier for them.
Agreed.
> i crosspost this mail, to give the users a chance to comment the plan ;-)
Thanks for your courtesy... I don't have time to monitor the turbine-dev
mailing lists at the moment.
Could you please keep the turbine-user list informed of any decisions you
make over there on turbine-dev?
Thanks in advance,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] kill the coupled torque and services
Posted by Age Mooy <am...@home.nl>.
+1 if that means work will be done on getting the decoupled versions (esspecially Fulcrum) to work well with
turbine-2. At the moment it is totally unclear which Fulcrum service is usable and which is not and most
people are forced to run the coupled and decoupled versions of torque in paralel because the Fulcrum security
service is not functional.
It would be great if someone could finally get turbine-2 going again... it has been virtually dead for the
last few months since b1 was released. Nobody is responding to turbine-2 patches at the moment :(
Age
> -----Original Message-----
> From: Martin Poeschl [mailto:mpoeschl@marmot.at]
> Sent: Thursday, July 04, 2002 18:45
> To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org
> Subject: [proposal] kill the coupled torque and services
>
>
> the coupled versions of torque and fulcrum (service stuff) are not maintained any longer.
> we told the users to use the decoupled versions ... good idea, but it doesn't work :-(
>
> many people waste there time trying to make them work together, so i propose to kill the coupled
> versions and use the decoupled for turbine 2.x
>
> we could release turbine 2.2 including the coupled versions and kill them for 2.3
>
> this will stop people to start with the old code and will make switching to turbine 3 easier for them.
>
> i crosspost this mail, to give the users a chance to comment the plan ;-)
>
> martin
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [proposal] kill the coupled torque and services
Posted by Stephen Haberman <st...@chase3000.com>.
Given that someone commented that decoupling Turbine 2.2 would be a lot
like what Turbine 3.0 is, what if Turbine 3.0 was released soon? Instead
of taking the time to get the decoupled Turbine 2.x released, use it to
ready Turbine 3.0 for release.
I'm not quite up to speed on release cycles and the state of the code
base and what not, so this may not be a good suggestion, but I've been
using Turbine 3 for an app that's in development and it's been going
well.
- Stephen
> -----Original Message-----
> From: Martin Poeschl [mailto:mpoeschl@marmot.at]
> Sent: Thursday, July 04, 2002 11:45 AM
> To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org
> Subject: [proposal] kill the coupled torque and services
>
> the coupled versions of torque and fulcrum (service stuff) are not
maintained any
> longer.
> we told the users to use the decoupled versions ... good idea, but it
doesn't work :-(
>
> many people waste there time trying to make them work together, so i
propose to kill
> the coupled
> versions and use the decoupled for turbine 2.x
>
> we could release turbine 2.2 including the coupled versions and kill
them for 2.3
>
> this will stop people to start with the old code and will make
switching to turbine 3
> easier for them.
>
> i crosspost this mail, to give the users a chance to comment the plan
;-)
>
> martin
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>