You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2006/07/29 00:12:19 UTC

Re: Tapestry 5 Discussions -- Nice to see people paying attention

The current state of the T4 code is untenable w.r.t. to adding new
features without breaking backwards compatibility.  Each upgrade of
Tapestry (2 to 3 to 4) has had major upgrade problems because of a
number of factors, mostly the design of the APIs and the need to
extend from base classes (as the base classes provide much of the
component functionality).

In the long view of Tapestry, the future users vastly outnumber the
current users. Tapestry 5 is targetting that group of users.

Existing applications coded to Tapestry 4 ... well, leave them on
Tapestry 4!  Many users prefer to stay on Tapestry 3.  They don't want
to face the upgrade from 3 to 4 if their application is working.  The
design of Tapestry 5 will facilitate easy upgrades from 5 on ...
mainly because the API is minimal and flexible, consisting almost
entirely of annotations, rather the classes to extend and interfaces
to extend.

Having an easy upgrade path from Tapestry 4 to 5 is a near
insurmountable challenge.

Is Tapestry 5 a new framework?  Yes.  Will it be an easy transition
for developers (not code)?  Yes.  Tapestry 4 developers will see
Tapestry 5 and understand it quickly and easily, and be happy about
the new features.

I see a lot of feedback from people I'm training in Tapestry 4.  I see
people stumbling because of  inconsistencies of naming, because of the
odd model (abstract classes), because of the need to understand too
much of the internals of Tapestry.

I do get upset when people act like I'm holding a gun to their heads.

Now, in terms of the IoC container specifically ...

I'm preaching about simplicity, simplicity, simplicity.  HiveMind is
simple, but still has a lot of mapping between Java and XML. As happy
as I am with HiveMind and the HiveMind community, the core fact is
that it is not as simple as I need it to be: the pure Java model of
Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry
5 in a way HiveMind (and certainly not Spring) could ever do.

I've repeatedly spoken about, and blogged about, why Spring is simply
not a good fit for Tapestry 4 or Tapestry 5.  Spring exists to allow
an application, a known entity, to be assembled. It simply doesn't
inlcude the concepts necessary to configure a framework, allowing for
the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC
do. I've seen some laughable postings about what it takes to even
start to approximate HiveMind configurations in Spring ... huge
amounts of ugly Java code and uglier XML. No thank you.

My metaphor for all this is that I'm trying to raise the big pole that
the circus tent will hang from. I can't wait to get the pole up so we
can start having the circus!  Under this metaphor, the circus will be
the components and extensions that the community will put together.

Finally, I've been at this for six years now. I enjoy working on the
code, and I suffer through the things necessary to permit that  ...
Tapestry training, and marketting. Writing books. Creating demos. All
that stuff. What I constantly hear is demands and suggestions about
Tapestry and all I ask in return for all this time and effort is for
people to give back a little something in kind. I don't ask for money
(not for the software, not even as a donation), or time, or any other
demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest
of the entire community that the word on Tapestry get out there. There
are good books, better than average documentation, and healthy
community but Tapestry just isn't getting the notice it deserves and a
major reason for this is that people are failing to get the word out.

How many of you have written a white paper on your Tapestry
experience? How many have posted a supportive comment about Tapestry
on a release posting at JavaLobby, TheServerSide or elsewhere? How
many have tried to write an article on their Tapestry experiences for
publication?  Tapestry doesn't have a corporate sponsor like JSF or
even Rails. Tapestry has its technical chops and its community. So if
you are looking for reasons why Tapestry doesn't have the level of
adoption you think it should have, don't look at the compatibility
straw man.  Look to yourself and what you have done to support
Tapestry.



On 7/28/06, Matt Welch <mw...@ptc.com> wrote:
> Howard, if it really will be as difficult to move from Tap4 to Tap5 as you
> suggest, and if this new code base is indeed mostly new, perhaps it might be
> prudent to release what you are now calling Tapestry 5 as a new project
> instead; one that is "inspired" by the Tapestry concepts and intentions.
> Then Tapestry 4 could continued to be mainatained and if other contributers
> we re so inclined, it could be upgraded to a more "migration friendly"
> Tapestry 5.
>
> Personally, I don't have a problem with the migration difficulty as I dont'
> have any Tapestry 3 or 4 projects that I would upgrade. I built what I've
> built using the best options I had available at the time and while I
> continue to maintain some of those appliactions, I dont' feel a pressing
> need to upgrade them to the newest framework. I won't be upgrading them from
> Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm
> concerned, there should be a migration path through all point releases, but
> any easy migration is just gravy.
>
> I for one am thrilled to see that Tap5 is dropping some of the encumberances
> of it's original implementaton. When I start a new project. I want it to be
> using the best tools out available. Here's to Tap5 and all it's
> incompatibilities!
>
> On 7/28/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > Right now its impossible because there's nothing to convert to :-)
> >
> > It will be *VERY* difficult. This isn't a slap of new paint. Basic
> > paradigms are shifting around in a major way.  It would be comparable,
> > or perhaps even larger than, converting between JSF and Tapestry 4.
> > Possibly on the order of converting from Struts to Tapestry 4.
> >
> > On 7/27/06, Norbert Sándor <de...@erinors.com> wrote:
> > > I know that it's far away, but how easy/difficult will it be to convert
> > > an application from 4 to 5?
> > >
> > > Regards,
> > > Norbi
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > Howard M. Lewis Ship
> > TWD Consulting, Inc.
> > Independent J2EE / Open-Source Java Consultant
> > Creator and PMC Chair, Apache Tapestry
> > Creator, Apache HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work.  http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>


-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by Norbert Sándor <de...@erinors.com>.
Please think about what you said: this thread is not against 
renovation/innovation. We all want tapestry to be a perfect, developer 
friendly framework, using the latest-greatest technologies. But when you 
develop real applications using a framework, you have other priorities 
as well (for example compatibility).
It may be much easier (in the good sense of the word) to rewrite a 
software instead of maintaining in a backwards compatible way, but as 
you see this makes the community very uneasy.
For example I personally don't understand why throw away hivemind 
instead of contributing to it, or at least consult with it's developers. 
I did not see long and detailed discussions on the hivemind lists about 
the requirements of tap5 with the conclusion of "it's not possible with 
hivemind and cannot be developed".
Backwards compatibility is very important in a framework which is 
component based and has a key principles of simplicity, consistency, ... 
What do you do with your components if they stop working in the next 
major release of the framework? Just think about how much time you will 
spend to learn the non-trivial functionalities of t5, to learn the 
"tricks" again. Sometimes you do need to be involved in the internals of 
the framework. One may think that it's not necessary but when developing 
large and complex applications you surely need to extend/replace the 
existing functionalities, ie. you must know the internals as well.

"if you like tapestry": this is not arguing, I guess that everyone on 
this list likes tapestry that's why they are all worried...

One of the main problems with tapestry in the past was (at least most 
people thought this) that it was a one-man project: Howard has developed 
it almost alone.
Now it became a little bit worse: Jesse is the only (really) active 
developer on the t4.1 branch, Howard is the only developer of the t5 branch.
My biggest problem is with the current development process (I know it's 
open source, etc.) is that there are two competing branches of 
development. It means that the two really active developers are 
developing two completely separate frameworks instead of first finishing 
the 4.1 branch. Jesse did and does a very great job with 4.1 but there 
are several things to do yet (to mention some: docs, more dojo widgets, 
jira issues to fix). I think that synchronizing the development 
resources in a project which has so few active committers should be the 
highest priority - but it's not.

The worst thing: this thread discusses real problems, and it harms 
tapestry very much - it is the best example of negative marketing: if a 
new user is reading this thread and sees that old users are worried 
about the future of the framework, then they will probably choose 
another, more "supported" one, with a more "real-life" project 
management style...

Regards,
Norbi

liigo wrote:
> +1
>
> It will be selfish for someone to preventing T5 only because of the
> compatibility.
>
> T5 is a renovation. When it out, everyone will be benefit.
>
> For the future of tapestry, T5 should going on.
>
> If you like tapestry, support it.
>
>
> 2006/7/29, Howard Lewis Ship <hl...@gmail.com>:
>> The current state of the T4 code is untenable w.r.t. to adding new
>> features without breaking backwards compatibility.  Each upgrade of
>> Tapestry (2 to 3 to 4) has had major upgrade problems because of a
>> number of factors, mostly the design of the APIs and the need to
>> extend from base classes (as the base classes provide much of the
>> component functionality).
>>
>> In the long view of Tapestry, the future users vastly outnumber the
>> current users. Tapestry 5 is targetting that group of users.
>>
>> Existing applications coded to Tapestry 4 ... well, leave them on
>> Tapestry 4!  Many users prefer to stay on Tapestry 3.  They don't want
>> to face the upgrade from 3 to 4 if their application is working.  The
>> design of Tapestry 5 will facilitate easy upgrades from 5 on ...
>> mainly because the API is minimal and flexible, consisting almost
>> entirely of annotations, rather the classes to extend and interfaces
>> to extend.
>>
>> Having an easy upgrade path from Tapestry 4 to 5 is a near
>> insurmountable challenge.
>>
>> Is Tapestry 5 a new framework?  Yes.  Will it be an easy transition
>> for developers (not code)?  Yes.  Tapestry 4 developers will see
>> Tapestry 5 and understand it quickly and easily, and be happy about
>> the new features.
>>
>> I see a lot of feedback from people I'm training in Tapestry 4.  I see
>> people stumbling because of  inconsistencies of naming, because of the
>> odd model (abstract classes), because of the need to understand too
>> much of the internals of Tapestry.
>>
>> I do get upset when people act like I'm holding a gun to their heads.
>>
>> Now, in terms of the IoC container specifically ...
>>
>> I'm preaching about simplicity, simplicity, simplicity.  HiveMind is
>> simple, but still has a lot of mapping between Java and XML. As happy
>> as I am with HiveMind and the HiveMind community, the core fact is
>> that it is not as simple as I need it to be: the pure Java model of
>> Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry
>> 5 in a way HiveMind (and certainly not Spring) could ever do.
>>
>> I've repeatedly spoken about, and blogged about, why Spring is simply
>> not a good fit for Tapestry 4 or Tapestry 5.  Spring exists to allow
>> an application, a known entity, to be assembled. It simply doesn't
>> inlcude the concepts necessary to configure a framework, allowing for
>> the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC
>> do. I've seen some laughable postings about what it takes to even
>> start to approximate HiveMind configurations in Spring ... huge
>> amounts of ugly Java code and uglier XML. No thank you.
>>
>> My metaphor for all this is that I'm trying to raise the big pole that
>> the circus tent will hang from. I can't wait to get the pole up so we
>> can start having the circus!  Under this metaphor, the circus will be
>> the components and extensions that the community will put together.
>>
>> Finally, I've been at this for six years now. I enjoy working on the
>> code, and I suffer through the things necessary to permit that  ...
>> Tapestry training, and marketting. Writing books. Creating demos. All
>> that stuff. What I constantly hear is demands and suggestions about
>> Tapestry and all I ask in return for all this time and effort is for
>> people to give back a little something in kind. I don't ask for money
>> (not for the software, not even as a donation), or time, or any other
>> demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest
>> of the entire community that the word on Tapestry get out there. There
>> are good books, better than average documentation, and healthy
>> community but Tapestry just isn't getting the notice it deserves and a
>> major reason for this is that people are failing to get the word out.
>>
>> How many of you have written a white paper on your Tapestry
>> experience? How many have posted a supportive comment about Tapestry
>> on a release posting at JavaLobby, TheServerSide or elsewhere? How
>> many have tried to write an article on their Tapestry experiences for
>> publication?  Tapestry doesn't have a corporate sponsor like JSF or
>> even Rails. Tapestry has its technical chops and its community. So if
>> you are looking for reasons why Tapestry doesn't have the level of
>> adoption you think it should have, don't look at the compatibility
>> straw man.  Look to yourself and what you have done to support
>> Tapestry.
>>
>>
>>
>> On 7/28/06, Matt Welch <mw...@ptc.com> wrote:
>> > Howard, if it really will be as difficult to move from Tap4 to Tap5 
>> as you
>> > suggest, and if this new code base is indeed mostly new, perhaps it 
>> might
>> be
>> > prudent to release what you are now calling Tapestry 5 as a new 
>> project
>> > instead; one that is "inspired" by the Tapestry concepts and 
>> intentions.
>> > Then Tapestry 4 could continued to be mainatained and if other
>> contributers
>> > we re so inclined, it could be upgraded to a more "migration friendly"
>> > Tapestry 5.
>> >
>> > Personally, I don't have a problem with the migration difficulty as I
>> dont'
>> > have any Tapestry 3 or 4 projects that I would upgrade. I built 
>> what I've
>> > built using the best options I had available at the time and while I
>> > continue to maintain some of those appliactions, I dont' feel a 
>> pressing
>> > need to upgrade them to the newest framework. I won't be upgrading 
>> them
>> from
>> > Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm
>> > concerned, there should be a migration path through all point 
>> releases,
>> but
>> > any easy migration is just gravy.
>> >
>> > I for one am thrilled to see that Tap5 is dropping some of the
>> encumberances
>> > of it's original implementaton. When I start a new project. I want 
>> it to
>> be
>> > using the best tools out available. Here's to Tap5 and all it's
>> > incompatibilities!
>> >
>> > On 7/28/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>> > >
>> > > Right now its impossible because there's nothing to convert to :-)
>> > >
>> > > It will be *VERY* difficult. This isn't a slap of new paint. Basic
>> > > paradigms are shifting around in a major way.  It would be 
>> comparable,
>> > > or perhaps even larger than, converting between JSF and Tapestry 4.
>> > > Possibly on the order of converting from Struts to Tapestry 4.
>> > >
>> > > On 7/27/06, Norbert Sándor <de...@erinors.com> wrote:
>> > > > I know that it's far away, but how easy/difficult will it be to
>> convert
>> > > > an application from 4 to 5?
>> > > >
>> > > > Regards,
>> > > > Norbi
>> > > >
>> > > > 
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Howard M. Lewis Ship
>> > > TWD Consulting, Inc.
>> > > Independent J2EE / Open-Source Java Consultant
>> > > Creator and PMC Chair, Apache Tapestry
>> > > Creator, Apache HiveMind
>> > >
>> > > Professional Tapestry training, mentoring, support
>> > > and project work.  http://howardlewisship.com
>> > >
>> > > 
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: dev-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>>
>>
>> -- 
>> Howard M. Lewis Ship
>> TWD Consulting, Inc.
>> Independent J2EE / Open-Source Java Consultant
>> Creator and PMC Chair, Apache Tapestry
>> Creator, Apache HiveMind
>>
>> Professional Tapestry training, mentoring, support
>> and project work.  http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.10.4/401 - Release Date: 2006.07.26.
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by liigo <co...@gmail.com>.
+1

It will be selfish for someone to preventing T5 only because of the
compatibility.

T5 is a renovation. When it out, everyone will be benefit.

For the future of tapestry, T5 should going on.

If you like tapestry, support it.


2006/7/29, Howard Lewis Ship <hl...@gmail.com>:
> The current state of the T4 code is untenable w.r.t. to adding new
> features without breaking backwards compatibility.  Each upgrade of
> Tapestry (2 to 3 to 4) has had major upgrade problems because of a
> number of factors, mostly the design of the APIs and the need to
> extend from base classes (as the base classes provide much of the
> component functionality).
>
> In the long view of Tapestry, the future users vastly outnumber the
> current users. Tapestry 5 is targetting that group of users.
>
> Existing applications coded to Tapestry 4 ... well, leave them on
> Tapestry 4!  Many users prefer to stay on Tapestry 3.  They don't want
> to face the upgrade from 3 to 4 if their application is working.  The
> design of Tapestry 5 will facilitate easy upgrades from 5 on ...
> mainly because the API is minimal and flexible, consisting almost
> entirely of annotations, rather the classes to extend and interfaces
> to extend.
>
> Having an easy upgrade path from Tapestry 4 to 5 is a near
> insurmountable challenge.
>
> Is Tapestry 5 a new framework?  Yes.  Will it be an easy transition
> for developers (not code)?  Yes.  Tapestry 4 developers will see
> Tapestry 5 and understand it quickly and easily, and be happy about
> the new features.
>
> I see a lot of feedback from people I'm training in Tapestry 4.  I see
> people stumbling because of  inconsistencies of naming, because of the
> odd model (abstract classes), because of the need to understand too
> much of the internals of Tapestry.
>
> I do get upset when people act like I'm holding a gun to their heads.
>
> Now, in terms of the IoC container specifically ...
>
> I'm preaching about simplicity, simplicity, simplicity.  HiveMind is
> simple, but still has a lot of mapping between Java and XML. As happy
> as I am with HiveMind and the HiveMind community, the core fact is
> that it is not as simple as I need it to be: the pure Java model of
> Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry
> 5 in a way HiveMind (and certainly not Spring) could ever do.
>
> I've repeatedly spoken about, and blogged about, why Spring is simply
> not a good fit for Tapestry 4 or Tapestry 5.  Spring exists to allow
> an application, a known entity, to be assembled. It simply doesn't
> inlcude the concepts necessary to configure a framework, allowing for
> the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC
> do. I've seen some laughable postings about what it takes to even
> start to approximate HiveMind configurations in Spring ... huge
> amounts of ugly Java code and uglier XML. No thank you.
>
> My metaphor for all this is that I'm trying to raise the big pole that
> the circus tent will hang from. I can't wait to get the pole up so we
> can start having the circus!  Under this metaphor, the circus will be
> the components and extensions that the community will put together.
>
> Finally, I've been at this for six years now. I enjoy working on the
> code, and I suffer through the things necessary to permit that  ...
> Tapestry training, and marketting. Writing books. Creating demos. All
> that stuff. What I constantly hear is demands and suggestions about
> Tapestry and all I ask in return for all this time and effort is for
> people to give back a little something in kind. I don't ask for money
> (not for the software, not even as a donation), or time, or any other
> demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest
> of the entire community that the word on Tapestry get out there. There
> are good books, better than average documentation, and healthy
> community but Tapestry just isn't getting the notice it deserves and a
> major reason for this is that people are failing to get the word out.
>
> How many of you have written a white paper on your Tapestry
> experience? How many have posted a supportive comment about Tapestry
> on a release posting at JavaLobby, TheServerSide or elsewhere? How
> many have tried to write an article on their Tapestry experiences for
> publication?  Tapestry doesn't have a corporate sponsor like JSF or
> even Rails. Tapestry has its technical chops and its community. So if
> you are looking for reasons why Tapestry doesn't have the level of
> adoption you think it should have, don't look at the compatibility
> straw man.  Look to yourself and what you have done to support
> Tapestry.
>
>
>
> On 7/28/06, Matt Welch <mw...@ptc.com> wrote:
> > Howard, if it really will be as difficult to move from Tap4 to Tap5 as you
> > suggest, and if this new code base is indeed mostly new, perhaps it might
> be
> > prudent to release what you are now calling Tapestry 5 as a new project
> > instead; one that is "inspired" by the Tapestry concepts and intentions.
> > Then Tapestry 4 could continued to be mainatained and if other
> contributers
> > we re so inclined, it could be upgraded to a more "migration friendly"
> > Tapestry 5.
> >
> > Personally, I don't have a problem with the migration difficulty as I
> dont'
> > have any Tapestry 3 or 4 projects that I would upgrade. I built what I've
> > built using the best options I had available at the time and while I
> > continue to maintain some of those appliactions, I dont' feel a pressing
> > need to upgrade them to the newest framework. I won't be upgrading them
> from
> > Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm
> > concerned, there should be a migration path through all point releases,
> but
> > any easy migration is just gravy.
> >
> > I for one am thrilled to see that Tap5 is dropping some of the
> encumberances
> > of it's original implementaton. When I start a new project. I want it to
> be
> > using the best tools out available. Here's to Tap5 and all it's
> > incompatibilities!
> >
> > On 7/28/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > >
> > > Right now its impossible because there's nothing to convert to :-)
> > >
> > > It will be *VERY* difficult. This isn't a slap of new paint. Basic
> > > paradigms are shifting around in a major way.  It would be comparable,
> > > or perhaps even larger than, converting between JSF and Tapestry 4.
> > > Possibly on the order of converting from Struts to Tapestry 4.
> > >
> > > On 7/27/06, Norbert Sándor <de...@erinors.com> wrote:
> > > > I know that it's far away, but how easy/difficult will it be to
> convert
> > > > an application from 4 to 5?
> > > >
> > > > Regards,
> > > > Norbi
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > > TWD Consulting, Inc.
> > > Independent J2EE / Open-Source Java Consultant
> > > Creator and PMC Chair, Apache Tapestry
> > > Creator, Apache HiveMind
> > >
> > > Professional Tapestry training, mentoring, support
> > > and project work.  http://howardlewisship.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

RE: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by James Carman <ja...@carmanconsulting.com>.
First of all, let me say that I don't appreciate the name-calling.  I am not
personally attacking anyone here.  I am a very active member of the open
source community and I too do it because I enjoy it.  I enjoy working with
Tapestry and I believe that Tapestry is a very well-designed framework.
That's why I feel so strongly about its future.  The only real issue that I
have is that there's no migration path.  As many others on this thread have
agreed, no migration path really makes the businessey folks very nervous and
they might not let us techey folks use Tapestry because of it and that would
be a shame. 

I have read the documentation on the new IoC container and I've already
started discussion with the HiveMind team about including some of Howard's
concepts into HiveMind itself.  That's not an argument that Tapestry should
keep HiveMind, but an illustration that I actually do support the direction
that Tapestry is heading with the new IoC container.  

James

p.s. Sorry to dual post, but this thread got splintered onto both lists.

-----Original Message-----
From: Jesse Kuhnert [mailto:jkuhnert@gmail.com] 
Sent: Saturday, July 29, 2006 10:07 AM
To: Tapestry development
Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention

Wow, I have to say I'm pretty disappointed in such talk from someone who is
supposed to be the "chairman" of Hivemind. I'd almost say it sounds kind of
immature.

I support Howard's work on T5 completely, and since he and I are currently
the two most active developers I think it has to count for something.

We do this because we enjoy it, please don't try and take that away. If you
think you can do a better job the door is always open. It ~is~ open source
after all :)

On 7/29/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> Again, Howard, don't get me wrong.  I really like some of the cool new
> stuff
> you're doing with Tap5, except for maybe Tapioca (that's not the official
> name, but my "pet" name) vs. HiveMind.  Anyway, one might interpret what
> you've basically said here:
>
> "future users vastly outnumber the current users"
>
> to mean that you don't mind leaving your current users out in the cold
> when
> it comes to the future of Tapestry.  I'm not saying that's what you said,
> necessarily, but I'm saying it could be interpreted that way.
>
> Here's an interesting question.  When writing T4, did you know that T5 was
> going to be such a drastic rewrite?  Probably not, or you would have just
> architected T4 the right way to avoid the rewrite.  Correct?  Well, then,
> who is to say that two years down the road whenever you get down to
> working
> on T6 that won't you decide the T5 architecture just won't work?  You
> probably thought at the time of writing T4 that the architecture was the
> right way to go for the future and now it's "untenable w.r.t. to adding
> new
> features without breaking backwards compatibility."
>
> I have (not that I necessarily think you were addressing me, but just in
> case) started to help make Tapestry more popular (Hibernate, Acegi, and
> AspectJ integration for starters) and I've contributed to Tapestry itself
> (autowiring), but a lot of my work will have to be completely rewritten
> for
> T5!
>
> Also, as a consultant, I have to recommend to my clients what technologies
> to use in their best interest.  If Tapestry continues down the path that
> it's going, I could not endorse Tapestry as a viable technology solution
> for
> a large, on-going project.  In other words, I wouldn't stick my neck out
> to
> suggest Tapestry given its track record.
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Friday, July 28, 2006 6:12 PM
> To: Tapestry development
> Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention
>
> The current state of the T4 code is untenable w.r.t. to adding new
> features without breaking backwards compatibility.  Each upgrade of
> Tapestry (2 to 3 to 4) has had major upgrade problems because of a
> number of factors, mostly the design of the APIs and the need to
> extend from base classes (as the base classes provide much of the
> component functionality).
>
> In the long view of Tapestry, the future users vastly outnumber the
> current users. Tapestry 5 is targetting that group of users.
>
> Existing applications coded to Tapestry 4 ... well, leave them on
> Tapestry 4!  Many users prefer to stay on Tapestry 3.  They don't want
> to face the upgrade from 3 to 4 if their application is working.  The
> design of Tapestry 5 will facilitate easy upgrades from 5 on ...
> mainly because the API is minimal and flexible, consisting almost
> entirely of annotations, rather the classes to extend and interfaces
> to extend.
>
> Having an easy upgrade path from Tapestry 4 to 5 is a near
> insurmountable challenge.
>
> Is Tapestry 5 a new framework?  Yes.  Will it be an easy transition
> for developers (not code)?  Yes.  Tapestry 4 developers will see
> Tapestry 5 and understand it quickly and easily, and be happy about
> the new features.
>
> I see a lot of feedback from people I'm training in Tapestry 4.  I see
> people stumbling because of  inconsistencies of naming, because of the
> odd model (abstract classes), because of the need to understand too
> much of the internals of Tapestry.
>
> I do get upset when people act like I'm holding a gun to their heads.
>
> Now, in terms of the IoC container specifically ...
>
> I'm preaching about simplicity, simplicity, simplicity.  HiveMind is
> simple, but still has a lot of mapping between Java and XML. As happy
> as I am with HiveMind and the HiveMind community, the core fact is
> that it is not as simple as I need it to be: the pure Java model of
> Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry
> 5 in a way HiveMind (and certainly not Spring) could ever do.
>
> I've repeatedly spoken about, and blogged about, why Spring is simply
> not a good fit for Tapestry 4 or Tapestry 5.  Spring exists to allow
> an application, a known entity, to be assembled. It simply doesn't
> inlcude the concepts necessary to configure a framework, allowing for
> the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC
> do. I've seen some laughable postings about what it takes to even
> start to approximate HiveMind configurations in Spring ... huge
> amounts of ugly Java code and uglier XML. No thank you.
>
> My metaphor for all this is that I'm trying to raise the big pole that
> the circus tent will hang from. I can't wait to get the pole up so we
> can start having the circus!  Under this metaphor, the circus will be
> the components and extensions that the community will put together.
>
> Finally, I've been at this for six years now. I enjoy working on the
> code, and I suffer through the things necessary to permit that  ...
> Tapestry training, and marketting. Writing books. Creating demos. All
> that stuff. What I constantly hear is demands and suggestions about
> Tapestry and all I ask in return for all this time and effort is for
> people to give back a little something in kind. I don't ask for money
> (not for the software, not even as a donation), or time, or any other
> demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest
> of the entire community that the word on Tapestry get out there. There
> are good books, better than average documentation, and healthy
> community but Tapestry just isn't getting the notice it deserves and a
> major reason for this is that people are failing to get the word out.
>
> How many of you have written a white paper on your Tapestry
> experience? How many have posted a supportive comment about Tapestry
> on a release posting at JavaLobby, TheServerSide or elsewhere? How
> many have tried to write an article on their Tapestry experiences for
> publication?  Tapestry doesn't have a corporate sponsor like JSF or
> even Rails. Tapestry has its technical chops and its community. So if
> you are looking for reasons why Tapestry doesn't have the level of
> adoption you think it should have, don't look at the compatibility
> straw man.  Look to yourself and what you have done to support
> Tapestry.
>
>
>
> On 7/28/06, Matt Welch <mw...@ptc.com> wrote:
> > Howard, if it really will be as difficult to move from Tap4 to Tap5 as
> you
> > suggest, and if this new code base is indeed mostly new, perhaps it
> might
> be
> > prudent to release what you are now calling Tapestry 5 as a new project
> > instead; one that is "inspired" by the Tapestry concepts and intentions.
> > Then Tapestry 4 could continued to be mainatained and if other
> contributers
> > we re so inclined, it could be upgraded to a more "migration friendly"
> > Tapestry 5.
> >
> > Personally, I don't have a problem with the migration difficulty as I
> dont'
> > have any Tapestry 3 or 4 projects that I would upgrade. I built what
> I've
> > built using the best options I had available at the time and while I
> > continue to maintain some of those appliactions, I dont' feel a pressing
> > need to upgrade them to the newest framework. I won't be upgrading them
> from
> > Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm
> > concerned, there should be a migration path through all point releases,
> but
> > any easy migration is just gravy.
> >
> > I for one am thrilled to see that Tap5 is dropping some of the
> encumberances
> > of it's original implementaton. When I start a new project. I want it to
> be
> > using the best tools out available. Here's to Tap5 and all it's
> > incompatibilities!
> >
> > On 7/28/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > >
> > > Right now its impossible because there's nothing to convert to :-)
> > >
> > > It will be *VERY* difficult. This isn't a slap of new paint. Basic
> > > paradigms are shifting around in a major way.  It would be comparable,
> > > or perhaps even larger than, converting between JSF and Tapestry 4.
> > > Possibly on the order of converting from Struts to Tapestry 4.
> > >
> > > On 7/27/06, Norbert Sándor <de...@erinors.com> wrote:
> > > > I know that it's far away, but how easy/difficult will it be to
> convert
> > > > an application from 4 to 5?
> > > >
> > > > Regards,
> > > > Norbi
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > > TWD Consulting, Inc.
> > > Independent J2EE / Open-Source Java Consultant
> > > Creator and PMC Chair, Apache Tapestry
> > > Creator, Apache HiveMind
> > >
> > > Professional Tapestry training, mentoring, support
> > > and project work.  http://howardlewisship.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


RE: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by James Carman <ja...@carmanconsulting.com>.
First of all, let me say that I don't appreciate the name-calling.  I am not
personally attacking anyone here.  I am a very active member of the open
source community and I too do it because I enjoy it.  I enjoy working with
Tapestry and I believe that Tapestry is a very well-designed framework.
That's why I feel so strongly about its future.  The only real issue that I
have is that there's no migration path.  As many others on this thread have
agreed, no migration path really makes the businessey folks very nervous and
they might not let us techey folks use Tapestry because of it and that would
be a shame. 

I have read the documentation on the new IoC container and I've already
started discussion with the HiveMind team about including some of Howard's
concepts into HiveMind itself.  That's not an argument that Tapestry should
keep HiveMind, but an illustration that I actually do support the direction
that Tapestry is heading with the new IoC container.  

James

p.s. Sorry to dual post, but this thread got splintered onto both lists.

-----Original Message-----
From: Jesse Kuhnert [mailto:jkuhnert@gmail.com] 
Sent: Saturday, July 29, 2006 10:07 AM
To: Tapestry development
Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention

Wow, I have to say I'm pretty disappointed in such talk from someone who is
supposed to be the "chairman" of Hivemind. I'd almost say it sounds kind of
immature.

I support Howard's work on T5 completely, and since he and I are currently
the two most active developers I think it has to count for something.

We do this because we enjoy it, please don't try and take that away. If you
think you can do a better job the door is always open. It ~is~ open source
after all :)

On 7/29/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> Again, Howard, don't get me wrong.  I really like some of the cool new
> stuff
> you're doing with Tap5, except for maybe Tapioca (that's not the official
> name, but my "pet" name) vs. HiveMind.  Anyway, one might interpret what
> you've basically said here:
>
> "future users vastly outnumber the current users"
>
> to mean that you don't mind leaving your current users out in the cold
> when
> it comes to the future of Tapestry.  I'm not saying that's what you said,
> necessarily, but I'm saying it could be interpreted that way.
>
> Here's an interesting question.  When writing T4, did you know that T5 was
> going to be such a drastic rewrite?  Probably not, or you would have just
> architected T4 the right way to avoid the rewrite.  Correct?  Well, then,
> who is to say that two years down the road whenever you get down to
> working
> on T6 that won't you decide the T5 architecture just won't work?  You
> probably thought at the time of writing T4 that the architecture was the
> right way to go for the future and now it's "untenable w.r.t. to adding
> new
> features without breaking backwards compatibility."
>
> I have (not that I necessarily think you were addressing me, but just in
> case) started to help make Tapestry more popular (Hibernate, Acegi, and
> AspectJ integration for starters) and I've contributed to Tapestry itself
> (autowiring), but a lot of my work will have to be completely rewritten
> for
> T5!
>
> Also, as a consultant, I have to recommend to my clients what technologies
> to use in their best interest.  If Tapestry continues down the path that
> it's going, I could not endorse Tapestry as a viable technology solution
> for
> a large, on-going project.  In other words, I wouldn't stick my neck out
> to
> suggest Tapestry given its track record.
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Friday, July 28, 2006 6:12 PM
> To: Tapestry development
> Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention
>
> The current state of the T4 code is untenable w.r.t. to adding new
> features without breaking backwards compatibility.  Each upgrade of
> Tapestry (2 to 3 to 4) has had major upgrade problems because of a
> number of factors, mostly the design of the APIs and the need to
> extend from base classes (as the base classes provide much of the
> component functionality).
>
> In the long view of Tapestry, the future users vastly outnumber the
> current users. Tapestry 5 is targetting that group of users.
>
> Existing applications coded to Tapestry 4 ... well, leave them on
> Tapestry 4!  Many users prefer to stay on Tapestry 3.  They don't want
> to face the upgrade from 3 to 4 if their application is working.  The
> design of Tapestry 5 will facilitate easy upgrades from 5 on ...
> mainly because the API is minimal and flexible, consisting almost
> entirely of annotations, rather the classes to extend and interfaces
> to extend.
>
> Having an easy upgrade path from Tapestry 4 to 5 is a near
> insurmountable challenge.
>
> Is Tapestry 5 a new framework?  Yes.  Will it be an easy transition
> for developers (not code)?  Yes.  Tapestry 4 developers will see
> Tapestry 5 and understand it quickly and easily, and be happy about
> the new features.
>
> I see a lot of feedback from people I'm training in Tapestry 4.  I see
> people stumbling because of  inconsistencies of naming, because of the
> odd model (abstract classes), because of the need to understand too
> much of the internals of Tapestry.
>
> I do get upset when people act like I'm holding a gun to their heads.
>
> Now, in terms of the IoC container specifically ...
>
> I'm preaching about simplicity, simplicity, simplicity.  HiveMind is
> simple, but still has a lot of mapping between Java and XML. As happy
> as I am with HiveMind and the HiveMind community, the core fact is
> that it is not as simple as I need it to be: the pure Java model of
> Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry
> 5 in a way HiveMind (and certainly not Spring) could ever do.
>
> I've repeatedly spoken about, and blogged about, why Spring is simply
> not a good fit for Tapestry 4 or Tapestry 5.  Spring exists to allow
> an application, a known entity, to be assembled. It simply doesn't
> inlcude the concepts necessary to configure a framework, allowing for
> the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC
> do. I've seen some laughable postings about what it takes to even
> start to approximate HiveMind configurations in Spring ... huge
> amounts of ugly Java code and uglier XML. No thank you.
>
> My metaphor for all this is that I'm trying to raise the big pole that
> the circus tent will hang from. I can't wait to get the pole up so we
> can start having the circus!  Under this metaphor, the circus will be
> the components and extensions that the community will put together.
>
> Finally, I've been at this for six years now. I enjoy working on the
> code, and I suffer through the things necessary to permit that  ...
> Tapestry training, and marketting. Writing books. Creating demos. All
> that stuff. What I constantly hear is demands and suggestions about
> Tapestry and all I ask in return for all this time and effort is for
> people to give back a little something in kind. I don't ask for money
> (not for the software, not even as a donation), or time, or any other
> demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest
> of the entire community that the word on Tapestry get out there. There
> are good books, better than average documentation, and healthy
> community but Tapestry just isn't getting the notice it deserves and a
> major reason for this is that people are failing to get the word out.
>
> How many of you have written a white paper on your Tapestry
> experience? How many have posted a supportive comment about Tapestry
> on a release posting at JavaLobby, TheServerSide or elsewhere? How
> many have tried to write an article on their Tapestry experiences for
> publication?  Tapestry doesn't have a corporate sponsor like JSF or
> even Rails. Tapestry has its technical chops and its community. So if
> you are looking for reasons why Tapestry doesn't have the level of
> adoption you think it should have, don't look at the compatibility
> straw man.  Look to yourself and what you have done to support
> Tapestry.
>
>
>
> On 7/28/06, Matt Welch <mw...@ptc.com> wrote:
> > Howard, if it really will be as difficult to move from Tap4 to Tap5 as
> you
> > suggest, and if this new code base is indeed mostly new, perhaps it
> might
> be
> > prudent to release what you are now calling Tapestry 5 as a new project
> > instead; one that is "inspired" by the Tapestry concepts and intentions.
> > Then Tapestry 4 could continued to be mainatained and if other
> contributers
> > we re so inclined, it could be upgraded to a more "migration friendly"
> > Tapestry 5.
> >
> > Personally, I don't have a problem with the migration difficulty as I
> dont'
> > have any Tapestry 3 or 4 projects that I would upgrade. I built what
> I've
> > built using the best options I had available at the time and while I
> > continue to maintain some of those appliactions, I dont' feel a pressing
> > need to upgrade them to the newest framework. I won't be upgrading them
> from
> > Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm
> > concerned, there should be a migration path through all point releases,
> but
> > any easy migration is just gravy.
> >
> > I for one am thrilled to see that Tap5 is dropping some of the
> encumberances
> > of it's original implementaton. When I start a new project. I want it to
> be
> > using the best tools out available. Here's to Tap5 and all it's
> > incompatibilities!
> >
> > On 7/28/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > >
> > > Right now its impossible because there's nothing to convert to :-)
> > >
> > > It will be *VERY* difficult. This isn't a slap of new paint. Basic
> > > paradigms are shifting around in a major way.  It would be comparable,
> > > or perhaps even larger than, converting between JSF and Tapestry 4.
> > > Possibly on the order of converting from Struts to Tapestry 4.
> > >
> > > On 7/27/06, Norbert Sándor <de...@erinors.com> wrote:
> > > > I know that it's far away, but how easy/difficult will it be to
> convert
> > > > an application from 4 to 5?
> > > >
> > > > Regards,
> > > > Norbi
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > > TWD Consulting, Inc.
> > > Independent J2EE / Open-Source Java Consultant
> > > Creator and PMC Chair, Apache Tapestry
> > > Creator, Apache HiveMind
> > >
> > > Professional Tapestry training, mentoring, support
> > > and project work.  http://howardlewisship.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by Jesse Kuhnert <jk...@gmail.com>.
Wow, I have to say I'm pretty disappointed in such talk from someone who is
supposed to be the "chairman" of Hivemind. I'd almost say it sounds kind of
immature.

I support Howard's work on T5 completely, and since he and I are currently
the two most active developers I think it has to count for something.

We do this because we enjoy it, please don't try and take that away. If you
think you can do a better job the door is always open. It ~is~ open source
after all :)

On 7/29/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> Again, Howard, don't get me wrong.  I really like some of the cool new
> stuff
> you're doing with Tap5, except for maybe Tapioca (that's not the official
> name, but my "pet" name) vs. HiveMind.  Anyway, one might interpret what
> you've basically said here:
>
> "future users vastly outnumber the current users"
>
> to mean that you don't mind leaving your current users out in the cold
> when
> it comes to the future of Tapestry.  I'm not saying that's what you said,
> necessarily, but I'm saying it could be interpreted that way.
>
> Here's an interesting question.  When writing T4, did you know that T5 was
> going to be such a drastic rewrite?  Probably not, or you would have just
> architected T4 the right way to avoid the rewrite.  Correct?  Well, then,
> who is to say that two years down the road whenever you get down to
> working
> on T6 that won't you decide the T5 architecture just won't work?  You
> probably thought at the time of writing T4 that the architecture was the
> right way to go for the future and now it's "untenable w.r.t. to adding
> new
> features without breaking backwards compatibility."
>
> I have (not that I necessarily think you were addressing me, but just in
> case) started to help make Tapestry more popular (Hibernate, Acegi, and
> AspectJ integration for starters) and I've contributed to Tapestry itself
> (autowiring), but a lot of my work will have to be completely rewritten
> for
> T5!
>
> Also, as a consultant, I have to recommend to my clients what technologies
> to use in their best interest.  If Tapestry continues down the path that
> it's going, I could not endorse Tapestry as a viable technology solution
> for
> a large, on-going project.  In other words, I wouldn't stick my neck out
> to
> suggest Tapestry given its track record.
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Friday, July 28, 2006 6:12 PM
> To: Tapestry development
> Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention
>
> The current state of the T4 code is untenable w.r.t. to adding new
> features without breaking backwards compatibility.  Each upgrade of
> Tapestry (2 to 3 to 4) has had major upgrade problems because of a
> number of factors, mostly the design of the APIs and the need to
> extend from base classes (as the base classes provide much of the
> component functionality).
>
> In the long view of Tapestry, the future users vastly outnumber the
> current users. Tapestry 5 is targetting that group of users.
>
> Existing applications coded to Tapestry 4 ... well, leave them on
> Tapestry 4!  Many users prefer to stay on Tapestry 3.  They don't want
> to face the upgrade from 3 to 4 if their application is working.  The
> design of Tapestry 5 will facilitate easy upgrades from 5 on ...
> mainly because the API is minimal and flexible, consisting almost
> entirely of annotations, rather the classes to extend and interfaces
> to extend.
>
> Having an easy upgrade path from Tapestry 4 to 5 is a near
> insurmountable challenge.
>
> Is Tapestry 5 a new framework?  Yes.  Will it be an easy transition
> for developers (not code)?  Yes.  Tapestry 4 developers will see
> Tapestry 5 and understand it quickly and easily, and be happy about
> the new features.
>
> I see a lot of feedback from people I'm training in Tapestry 4.  I see
> people stumbling because of  inconsistencies of naming, because of the
> odd model (abstract classes), because of the need to understand too
> much of the internals of Tapestry.
>
> I do get upset when people act like I'm holding a gun to their heads.
>
> Now, in terms of the IoC container specifically ...
>
> I'm preaching about simplicity, simplicity, simplicity.  HiveMind is
> simple, but still has a lot of mapping between Java and XML. As happy
> as I am with HiveMind and the HiveMind community, the core fact is
> that it is not as simple as I need it to be: the pure Java model of
> Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry
> 5 in a way HiveMind (and certainly not Spring) could ever do.
>
> I've repeatedly spoken about, and blogged about, why Spring is simply
> not a good fit for Tapestry 4 or Tapestry 5.  Spring exists to allow
> an application, a known entity, to be assembled. It simply doesn't
> inlcude the concepts necessary to configure a framework, allowing for
> the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC
> do. I've seen some laughable postings about what it takes to even
> start to approximate HiveMind configurations in Spring ... huge
> amounts of ugly Java code and uglier XML. No thank you.
>
> My metaphor for all this is that I'm trying to raise the big pole that
> the circus tent will hang from. I can't wait to get the pole up so we
> can start having the circus!  Under this metaphor, the circus will be
> the components and extensions that the community will put together.
>
> Finally, I've been at this for six years now. I enjoy working on the
> code, and I suffer through the things necessary to permit that  ...
> Tapestry training, and marketting. Writing books. Creating demos. All
> that stuff. What I constantly hear is demands and suggestions about
> Tapestry and all I ask in return for all this time and effort is for
> people to give back a little something in kind. I don't ask for money
> (not for the software, not even as a donation), or time, or any other
> demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest
> of the entire community that the word on Tapestry get out there. There
> are good books, better than average documentation, and healthy
> community but Tapestry just isn't getting the notice it deserves and a
> major reason for this is that people are failing to get the word out.
>
> How many of you have written a white paper on your Tapestry
> experience? How many have posted a supportive comment about Tapestry
> on a release posting at JavaLobby, TheServerSide or elsewhere? How
> many have tried to write an article on their Tapestry experiences for
> publication?  Tapestry doesn't have a corporate sponsor like JSF or
> even Rails. Tapestry has its technical chops and its community. So if
> you are looking for reasons why Tapestry doesn't have the level of
> adoption you think it should have, don't look at the compatibility
> straw man.  Look to yourself and what you have done to support
> Tapestry.
>
>
>
> On 7/28/06, Matt Welch <mw...@ptc.com> wrote:
> > Howard, if it really will be as difficult to move from Tap4 to Tap5 as
> you
> > suggest, and if this new code base is indeed mostly new, perhaps it
> might
> be
> > prudent to release what you are now calling Tapestry 5 as a new project
> > instead; one that is "inspired" by the Tapestry concepts and intentions.
> > Then Tapestry 4 could continued to be mainatained and if other
> contributers
> > we re so inclined, it could be upgraded to a more "migration friendly"
> > Tapestry 5.
> >
> > Personally, I don't have a problem with the migration difficulty as I
> dont'
> > have any Tapestry 3 or 4 projects that I would upgrade. I built what
> I've
> > built using the best options I had available at the time and while I
> > continue to maintain some of those appliactions, I dont' feel a pressing
> > need to upgrade them to the newest framework. I won't be upgrading them
> from
> > Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm
> > concerned, there should be a migration path through all point releases,
> but
> > any easy migration is just gravy.
> >
> > I for one am thrilled to see that Tap5 is dropping some of the
> encumberances
> > of it's original implementaton. When I start a new project. I want it to
> be
> > using the best tools out available. Here's to Tap5 and all it's
> > incompatibilities!
> >
> > On 7/28/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > >
> > > Right now its impossible because there's nothing to convert to :-)
> > >
> > > It will be *VERY* difficult. This isn't a slap of new paint. Basic
> > > paradigms are shifting around in a major way.  It would be comparable,
> > > or perhaps even larger than, converting between JSF and Tapestry 4.
> > > Possibly on the order of converting from Struts to Tapestry 4.
> > >
> > > On 7/27/06, Norbert Sándor <de...@erinors.com> wrote:
> > > > I know that it's far away, but how easy/difficult will it be to
> convert
> > > > an application from 4 to 5?
> > > >
> > > > Regards,
> > > > Norbi
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > > TWD Consulting, Inc.
> > > Independent J2EE / Open-Source Java Consultant
> > > Creator and PMC Chair, Apache Tapestry
> > > Creator, Apache HiveMind
> > >
> > > Professional Tapestry training, mentoring, support
> > > and project work.  http://howardlewisship.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by Howard Lewis Ship <hl...@gmail.com>.
> Here's an interesting question.  When writing T4, did you know that T5 was
> going to be such a drastic rewrite?  Probably not, or you would have just
> architected T4 the right way to avoid the rewrite.  Correct?  Well, then,
> who is to say that two years down the road whenever you get down to working
> on T6 that won't you decide the T5 architecture just won't work?  You
> probably thought at the time of writing T4 that the architecture was the
> right way to go for the future and now it's "untenable w.r.t. to adding new
> features without breaking backwards compatibility."

Actually, T4 did come out better than I expected it to, which is very
nice. But the entire time I was working on it, I was irritated by the
many things I could not fix.

I've been talking with people as far back as 2003 about the need for a
pure POJO model with a transforming class loader.

The different between the T3 -> T4 transition, and the T4 -> T5
transition is that instead of hacking around the limitations of the
API (the cause of upgrade issues from one release to the next) I'm
building such a minimal, adaptive API that upgrade issues won't exist
in the future.

I want to bring back the metaphor from my blog:  In early 2000 I wound
the spring on the Tapestry code base really tight.  I found pretty
much the right abstractions and patterns.  I've made mistakes,
overcome limitations, added powerful features.  But all that time, the
spring has been winding down. With T5 I want to wind the spring
really, really tight again so that it'll last even longer.

>
> I have (not that I necessarily think you were addressing me, but just in
> case) started to help make Tapestry more popular (Hibernate, Acegi, and
> AspectJ integration for starters) and I've contributed to Tapestry itself
> (autowiring), but a lot of my work will have to be completely rewritten for
> T5!
>
> Also, as a consultant, I have to recommend to my clients what technologies
> to use in their best interest.  If Tapestry continues down the path that
> it's going, I could not endorse Tapestry as a viable technology solution for
> a large, on-going project.  In other words, I wouldn't stick my neck out to
> suggest Tapestry given its track record.
>


-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


RE: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by James Carman <ja...@carmanconsulting.com>.
Again, Howard, don't get me wrong.  I really like some of the cool new stuff
you're doing with Tap5, except for maybe Tapioca (that's not the official
name, but my "pet" name) vs. HiveMind.  Anyway, one might interpret what
you've basically said here:

"future users vastly outnumber the current users"

to mean that you don't mind leaving your current users out in the cold when
it comes to the future of Tapestry.  I'm not saying that's what you said,
necessarily, but I'm saying it could be interpreted that way.

Here's an interesting question.  When writing T4, did you know that T5 was
going to be such a drastic rewrite?  Probably not, or you would have just
architected T4 the right way to avoid the rewrite.  Correct?  Well, then,
who is to say that two years down the road whenever you get down to working
on T6 that won't you decide the T5 architecture just won't work?  You
probably thought at the time of writing T4 that the architecture was the
right way to go for the future and now it's "untenable w.r.t. to adding new
features without breaking backwards compatibility."

I have (not that I necessarily think you were addressing me, but just in
case) started to help make Tapestry more popular (Hibernate, Acegi, and
AspectJ integration for starters) and I've contributed to Tapestry itself
(autowiring), but a lot of my work will have to be completely rewritten for
T5!  

Also, as a consultant, I have to recommend to my clients what technologies
to use in their best interest.  If Tapestry continues down the path that
it's going, I could not endorse Tapestry as a viable technology solution for
a large, on-going project.  In other words, I wouldn't stick my neck out to
suggest Tapestry given its track record. 

-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com] 
Sent: Friday, July 28, 2006 6:12 PM
To: Tapestry development
Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention

The current state of the T4 code is untenable w.r.t. to adding new
features without breaking backwards compatibility.  Each upgrade of
Tapestry (2 to 3 to 4) has had major upgrade problems because of a
number of factors, mostly the design of the APIs and the need to
extend from base classes (as the base classes provide much of the
component functionality).

In the long view of Tapestry, the future users vastly outnumber the
current users. Tapestry 5 is targetting that group of users.

Existing applications coded to Tapestry 4 ... well, leave them on
Tapestry 4!  Many users prefer to stay on Tapestry 3.  They don't want
to face the upgrade from 3 to 4 if their application is working.  The
design of Tapestry 5 will facilitate easy upgrades from 5 on ...
mainly because the API is minimal and flexible, consisting almost
entirely of annotations, rather the classes to extend and interfaces
to extend.

Having an easy upgrade path from Tapestry 4 to 5 is a near
insurmountable challenge.

Is Tapestry 5 a new framework?  Yes.  Will it be an easy transition
for developers (not code)?  Yes.  Tapestry 4 developers will see
Tapestry 5 and understand it quickly and easily, and be happy about
the new features.

I see a lot of feedback from people I'm training in Tapestry 4.  I see
people stumbling because of  inconsistencies of naming, because of the
odd model (abstract classes), because of the need to understand too
much of the internals of Tapestry.

I do get upset when people act like I'm holding a gun to their heads.

Now, in terms of the IoC container specifically ...

I'm preaching about simplicity, simplicity, simplicity.  HiveMind is
simple, but still has a lot of mapping between Java and XML. As happy
as I am with HiveMind and the HiveMind community, the core fact is
that it is not as simple as I need it to be: the pure Java model of
Tapestry 5 IoC is going to fit like a glove with the rest of Tapestry
5 in a way HiveMind (and certainly not Spring) could ever do.

I've repeatedly spoken about, and blogged about, why Spring is simply
not a good fit for Tapestry 4 or Tapestry 5.  Spring exists to allow
an application, a known entity, to be assembled. It simply doesn't
inlcude the concepts necessary to configure a framework, allowing for
the precise ovrrides and extensions that HiveMind and Tapestry 5 IoC
do. I've seen some laughable postings about what it takes to even
start to approximate HiveMind configurations in Spring ... huge
amounts of ugly Java code and uglier XML. No thank you.

My metaphor for all this is that I'm trying to raise the big pole that
the circus tent will hang from. I can't wait to get the pole up so we
can start having the circus!  Under this metaphor, the circus will be
the components and extensions that the community will put together.

Finally, I've been at this for six years now. I enjoy working on the
code, and I suffer through the things necessary to permit that  ...
Tapestry training, and marketting. Writing books. Creating demos. All
that stuff. What I constantly hear is demands and suggestions about
Tapestry and all I ask in return for all this time and effort is for
people to give back a little something in kind. I don't ask for money
(not for the software, not even as a donation), or time, or any other
demand BUT that people HELP PUBLICIZE TAPESTRY. It is in the interest
of the entire community that the word on Tapestry get out there. There
are good books, better than average documentation, and healthy
community but Tapestry just isn't getting the notice it deserves and a
major reason for this is that people are failing to get the word out.

How many of you have written a white paper on your Tapestry
experience? How many have posted a supportive comment about Tapestry
on a release posting at JavaLobby, TheServerSide or elsewhere? How
many have tried to write an article on their Tapestry experiences for
publication?  Tapestry doesn't have a corporate sponsor like JSF or
even Rails. Tapestry has its technical chops and its community. So if
you are looking for reasons why Tapestry doesn't have the level of
adoption you think it should have, don't look at the compatibility
straw man.  Look to yourself and what you have done to support
Tapestry.



On 7/28/06, Matt Welch <mw...@ptc.com> wrote:
> Howard, if it really will be as difficult to move from Tap4 to Tap5 as you
> suggest, and if this new code base is indeed mostly new, perhaps it might
be
> prudent to release what you are now calling Tapestry 5 as a new project
> instead; one that is "inspired" by the Tapestry concepts and intentions.
> Then Tapestry 4 could continued to be mainatained and if other
contributers
> we re so inclined, it could be upgraded to a more "migration friendly"
> Tapestry 5.
>
> Personally, I don't have a problem with the migration difficulty as I
dont'
> have any Tapestry 3 or 4 projects that I would upgrade. I built what I've
> built using the best options I had available at the time and while I
> continue to maintain some of those appliactions, I dont' feel a pressing
> need to upgrade them to the newest framework. I won't be upgrading them
from
> Spring 1.2 to Spring 2.0 either. What's the big deal? As far as I'm
> concerned, there should be a migration path through all point releases,
but
> any easy migration is just gravy.
>
> I for one am thrilled to see that Tap5 is dropping some of the
encumberances
> of it's original implementaton. When I start a new project. I want it to
be
> using the best tools out available. Here's to Tap5 and all it's
> incompatibilities!
>
> On 7/28/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > Right now its impossible because there's nothing to convert to :-)
> >
> > It will be *VERY* difficult. This isn't a slap of new paint. Basic
> > paradigms are shifting around in a major way.  It would be comparable,
> > or perhaps even larger than, converting between JSF and Tapestry 4.
> > Possibly on the order of converting from Struts to Tapestry 4.
> >
> > On 7/27/06, Norbert Sándor <de...@erinors.com> wrote:
> > > I know that it's far away, but how easy/difficult will it be to
convert
> > > an application from 4 to 5?
> > >
> > > Regards,
> > > Norbi
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > Howard M. Lewis Ship
> > TWD Consulting, Inc.
> > Independent J2EE / Open-Source Java Consultant
> > Creator and PMC Chair, Apache Tapestry
> > Creator, Apache HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work.  http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>


-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Tapestry 5 Discussions -- Nice to see people paying attention

Posted by Danny Angus <Da...@slc.co.uk>.
Howard,

With all due respect, and I do sincerely respect what you have done here;


"Howard Lewis Ship" <hl...@gmail.com> wrote on 28/07/2006 23:12:19:

> In the long view of Tapestry, the future users vastly outnumber the
> current users. Tapestry 5 is targetting that group of users.

This is a very difficult message to take on board for people who, in good
failt, made a significant investment in Tapestry 3 or 4.

> Existing applications coded to Tapestry 4 ... well, leave them on
> Tapestry 4!  Many users prefer to stay on Tapestry 3.

This would *only* be acceptable if it could be seen that the community was
supporting the earlier versions, it is not clear that this is happening for
Tapestry 3.

> They don't want to face the upgrade from 3 to 4 if their application is
working.

Can't afford to.

<snip/>
> Having an easy upgrade path from Tapestry 4 to 5 is a near
> insurmountable challenge.

But IMHO shifting the burden onto your loyal existing users is a big PR
mistake.

> people to give back a little something in kind.
..
> people HELP PUBLICIZE TAPESTRY.

It would be nice to, but when we are faced with such rapid revolutionalry
change we are naturally cautious about putting our names to something whose
direction we cannot predict.

You need us early adopters to evangelise, yet it appears from the first
statement I quote that you aren't interested in making concesions to the
needs of current users c.f. new adopters.


> How many of you have written a white paper on your Tapestry
> experience?

Howard, we would have been happy to present our Tap3 case study at
Apachecon had it not been rendered obsolete before we'd even finished the
project by the introduction of Tapestry 4 and now the announcements about
Tap 5. I won't in good faith tell people how good Tap3 is if I know they
will have a big problem ahead to upgrade to Tap4 when it is released.


> Tapestry has its technical chops and its community. So if
> you are looking for reasons why Tapestry doesn't have the level of
> adoption you think it should have, don't look at the compatibility
> straw man.  Look to yourself and what you have done to support
> Tapestry.

Thats another real good way to ensure our continued support, blame us and
slag us off for trying to raise the issues which are really causeing us
real pain and costs, and which we would not have if we moved to a competing
product.

Tapestry benefited from being first to market of the new generation of
frameworks, don't throw that advantage away.

d.


*******************************************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

********************************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org